[389-users] Windows Sync Agreement Help
Rich Megginson
rmeggins at redhat.com
Wed Jun 1 14:12:31 UTC 2011
On 05/31/2011 06:30 PM, Albert Teh wrote:
>
>
> On Tue, May 31, 2011 at 2:58 PM, Rich Megginson <rmeggins at redhat.com
> <mailto:rmeggins at redhat.com>> wrote:
>
> On 05/31/2011 12:49 PM, Albert Teh wrote:
>> Hi Rich,
>>
>> Sorry, What I understand doing the OneWay Sync from the AD to the DS
>>
>> Users in the Active Directory domain are synced if it is
>> configured in the sync agreement by selecting the *Sync New
>> Windows Users* option. All of the Windows users are copied to the
>> Directory Server when synchronization is initiated and then new
>> users are synced over when they are created.
>>
>> I do not need to do any AD to DS Group Sync
>>
>> and I am not doing any DS sync to the AD.
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w - -D
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> -s base -b "" "objectclass=*"
>
> You should get the contents of the AD
>
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w - -D
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> -s sub -b "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> "objectclass=person"
>
> you should get the list of users
>
>>
>>
>> Thanks.
>> Al
>>
>> On Tue, May 31, 2011 at 1:40 PM, Rich Megginson
>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>> wrote:
>>
>> On 05/31/2011 10:30 AM, Albert Teh wrote:
>>>
>>> HI Rich,
>>>
>>> [root at algldap ~]# /usr/lib/mozldap/ldapsearch -x -w - -D
>>> cn="Directory Manager" -b
>>> "ou=People,dc=algonquincollege,dc=com"
>>> "(|(objectclass=ntuser)(objectclass=ntgroup))"
>>> Enter bind password:
>>> [root at algldap ~]#
>>>
>>> No Entry found !!!.
>> You have to tell directory server which entries you want to sync.
>> See
>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Windows_Sync-About_Windows_Sync
>>
>>>
>>> Thanks.
>>> Albert
>>>
>>> On Tue, May 31, 2011 at 11:42 AM, Rich Megginson
>>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>> wrote:
>>>
>>> On 05/30/2011 08:32 AM, Albert Teh wrote:
>>>> Hi Rich,
>>>>
>>>> I followed the Guide and still got the same result.
>>>> Checked with the AD administrator, the AD's user:
>>>> mailadm has a full privilege.
>>> /usr/bin/ldapsearch -x -w - -D cn="Directory Manager"-b
>>> "ou=People,dc=algonquincollege,dc=com"
>>> "(|(objectclass=ntuser)(objectclass=ntgroup))"
>>>
>>> How many entries match that search?
>>>
>>>>
>>>> Thanks.
>>>> Albert
>>>>
>>>> Here is the Windows Sync Agreement info:
>>>>
>>>> [root at algldap slapd-algldap]#
>>>> /usr/lib/mozldap/ldapsearch -w - -D cn="Directory
>>>> Manager" -b cn=config cn=ADSync
>>>> Enter bind password:
>>>> version: 1
>>>> dn:
>>>> cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
>>>> tree,c
>>>> n=config
>>>> objectClass: top
>>>> objectClass: nsDSWindowsReplicationAgreement
>>>> description: AD Sync Agreement
>>>> cn: ADSync
>>>> nsds7WindowsReplicaSubtree:
>>>> cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=co
>>>> m
>>>> nsds7DirectoryReplicaSubtree: ou=People,
>>>> dc=algonquincollege,dc=com
>>>> nsds7NewWinUserSyncEnabled: on
>>>> nsds7NewWinGroupSyncEnabled: on
>>>> nsds7WindowsDomain: ottawa.ad.algonquincollege.com
>>>> <http://ottawa.ad.algonquincollege.com>
>>>> nsDS5ReplicaRoot: dc=algonquincollege,dc=com
>>>> nsDS5ReplicaHost:
>>>> wodcstage-1.ottawa.ad.algonquincollege.com
>>>> <http://wodcstage-1.ottawa.ad.algonquincollege.com>
>>>> nsDS5ReplicaPort: 389
>>>> nsDS5ReplicaBindDN:
>>>> cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc
>>>> =com
>>>> nsDS5ReplicaBindMethod: SIMPLE
>>>> nsDS5ReplicaCredentials: {DES}U68ooQM3C15xjJ/taDmy0A==
>>>> nsds5replicareapactive: 0
>>>> nsds5replicaLastUpdateStart: 20110530141648Z
>>>> nsds5replicaLastUpdateEnd: 20110530141648Z
>>>> nsds5replicaChangesSentSinceStartup:
>>>> nsds5replicaLastUpdateStatus: 0 Replica acquired
>>>> successfully: Incremental upd
>>>> ate succeeded
>>>> nsds5replicaUpdateInProgress: FALSE
>>>> nsds5replicaLastInitStart: 20110530140648Z
>>>> nsds5replicaLastInitEnd: 20110530140648Z
>>>> nsds5replicaLastInitStatus: 0 Total update succeeded
>>>> [root at algldap slapd-algldap]#
>>>>
>>>>
>>>>
>>>> On Fri, May 27, 2011 at 10:57 AM, Rich Megginson
>>>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>> wrote:
>>>>
>>>> On 05/27/2011 04:22 AM, Albert Teh wrote:
>>>>> Hi Rich,
>>>>>
>>>>> I reinstalled 389-ds-base 1.2.8.3 from EPEL5 and
>>>>> added onewaysync set as fromWindows in the
>>>>> multimaster replication plugin. I still got the
>>>>> same result with no user created in the DS subtree.
>>>> Have you read
>>>> http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html-single/Administration_Guide/index.html#Windows_Sync-About_Windows_Sync
>>>>
>>>>
>>>>>
>>>>> Errors log:
>>>>>
>>>>> [27/May/2011:06:18:26 -0400] NSMMReplicationPlugin
>>>>> - Beginning total update of replica
>>>>> "agmt="cn=ADSync" (wodcstage-1:389)".
>>>>> [27/May/2011:06:18:26 -0400] NSMMReplicationPlugin
>>>>> - Finished total update of replica
>>>>> "agmt="cn=ADSync" (wodcstage-1:389)". Sent 0 entries.
>>>>>
>>>>>
>>>>> Access log:
>>>>>
>>>>> [27/May/2011:06:18:29 -0400] conn=1 op=114 SRCH
>>>>> base="cn=ADSync,cn=replica,cn=dc\3Dalgonquincollege\2Cdc\3Dcom,cn=mapping
>>>>> tree,cn=config" scope=0
>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>> attrs="nsds5replicaLastUpdateStart
>>>>> nsds5replicaLastUpdateEnd
>>>>> nsds5replicaChangesSentSinceStartup
>>>>> nsds5replicaLastUpdateStatus
>>>>> nsds5replicaUpdateInProgress
>>>>> nsds5replicaLastInitStart nsds5replicaLastInitEnd
>>>>> nsds5replicaLastInitStatus nsds5BeginReplicaRefresh"
>>>>> [27/May/2011:06:18:29 -0400] conn=1 op=114 RESULT
>>>>> err=0 tag=101 nentries=1 etime=
>>>>>
>>>>> Thanks for your help.
>>>>>
>>>>> Albert
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 26, 2011 at 11:13 AM, Rich Megginson
>>>>> <rmeggins at redhat.com <mailto:rmeggins at redhat.com>>
>>>>> wrote:
>>>>>
>>>>> On 05/26/2011 08:58 AM, Albert Teh wrote:
>>>>>> Hi,
>>>>>>
>>>>>> We are setting up a new CENTOS-DS version
>>>>>> 8.1.0. and CENTOS 5.5 and attempt to
>>>>>> synchronize with the existing 2003 Windows AD
>>>>>> server.
>>>>>> Performing the full sync completed. There is
>>>>>> no user created in the DS subtree.
>>>>>>
>>>>>> We would like to perform one way Sync: AD
>>>>>> ----> DS. Once it works, we will set up the
>>>>>> password Sync from the AD to DS.
>>>>> One way sync isn't supported with 8.1.0. I
>>>>> suggest using 389-ds-base 1.2.8.3 from EPEL5
>>>>> which does support one way sync.
>>>>> http://directory.fedoraproject.org/wiki/One_Way_Active_Directory_Sync
>>>>>>
>>>>>> AD: cn=Users,cn=location,dc=ad,dc=domain,dc=com
>>>>>> DS: ou=Peoples,dc=domain,dc=com
>>>>>>
>>>>>> errors log:
>>>>>>
>>>>>>
>>>>>> [26/May/2011:10:20:34 -0400]
>>>>>> NSMMReplicationPlugin - Beginning total
>>>>>> update of replica "agmt="cn=ADsync"
>>>>>> (wodcstage-1:389)".
>>>>>> [26/May/2011:10:20:34 -0400]
>>>>>> NSMMReplicationPlugin - Finished total update
>>>>>> of replica "agmt="cn=ADsync"
>>>>>> (wodcstage-1:389)". Sent 0 entries.
>>>>>>
>>>>>> access log:
>>>>>>
>>>>>> 26/May/2011:10:20:37 -0400] conn=11 op=819
>>>>>> SRCH base="cn=ADsync, cn=replica,
>>>>>> cn=\22dc=algonquincollege, dc=com\22,
>>>>>> cn=mapping tree, cn=config" scope=0
>>>>>> filter="(|(objectClass=*)(objectClass=ldapsubentry))"
>>>>>> attrs="nsds5replicaLastUpdateStart
>>>>>> nsds5replicaLastUpdateEnd
>>>>>> nsds5replicaChangesSentSinceStartup
>>>>>> nsds5replicaLastUpdateStatus
>>>>>> nsds5replicaUpdateInProgress
>>>>>> nsds5replicaLastInitStart
>>>>>> nsds5replicaLastInitEnd
>>>>>> nsds5replicaLastInitStatus
>>>>>> nsds5BeginReplicaRefresh"
>>>>>> [26/May/2011:10:20:37 -0400] conn=11 op=819
>>>>>> RESULT err=0 tag=101 nentries=1 etime=0
>>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>> Albert
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users at lists.fedoraproject.org <mailto:389-users at lists.fedoraproject.org>
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Albert Teh
>>>>> Email: Teh.Albert at Gmail.com
>>>>> <mailto:Teh.Albert at Gmail.com>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Albert Teh
>>>> Email: Teh.Albert at Gmail.com <mailto:Teh.Albert at Gmail.com>
>>>
>>>
>>>
>>>
>>> --
>>> Albert Teh
>>> Email: Teh.Albert at Gmail.com <mailto:Teh.Albert at Gmail.com>
>>
>>
>>
>>
>> --
>> Albert Teh
>> Email: Teh.Albert at Gmail.com <mailto:Teh.Albert at Gmail.com>
>
>
>
> HI Rich,
>
> These two commands worked and got the result. I have been gone
> through the Windows Sync agreement setup for many times. I could not
> figure out what went wrong.
> Thanks a lot for your help again.
Are you sure that the user
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" has
Replication/Replicator rights in AD/Windows?
>
> Albert
>
> /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> <http://wodcstage-1.ottawa.ad.algonquincollege.com/> -w - -D
> "cn=mailadm,cn=Users,dc=[root at algldap ~]# /usr/lib/mozldap/ldapsearch
> -x -h wodcstage-1.ottawa.ad.algonquincollege.com
> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w - -D
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" -s
> base -b "" "objectclass=*"
> Enter bind password:
> version: 1
> dn:
> currentTime: 20110601001342.0Z
> subschemaSubentry:
> CN=Aggregate,CN=Schema,CN=Configuration,DC=ad,DC=algonquinc
> ollege,DC=com
> dsServiceName: CN=NTDS
> Settings,CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Sit
> e-Name,CN=Sites,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> namingContexts: CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> namingContexts:
> CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> namingContexts: DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> defaultNamingContext: DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> schemaNamingContext:
> CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege,DC=c
> om
> configurationNamingContext:
> CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> rootDomainNamingContext: DC=ad,DC=algonquincollege,DC=com
> supportedControl: 1.2.840.113556.1.4.319
> supportedControl: 1.2.840.113556.1.4.801
> supportedControl: 1.2.840.113556.1.4.473
> supportedControl: 1.2.840.113556.1.4.528
> supportedControl: 1.2.840.113556.1.4.417
> supportedControl: 1.2.840.113556.1.4.619
> supportedControl: 1.2.840.113556.1.4.841
> supportedControl: 1.2.840.113556.1.4.529
> supportedControl: 1.2.840.113556.1.4.805
> supportedControl: 1.2.840.113556.1.4.521
> supportedControl: 1.2.840.113556.1.4.970
> supportedControl: 1.2.840.113556.1.4.1338
> supportedControl: 1.2.840.113556.1.4.474
> supportedControl: 1.2.840.113556.1.4.1339
> supportedControl: 1.2.840.113556.1.4.1340
> supportedControl: 1.2.840.113556.1.4.1413
> supportedControl: 2.16.840.1.113730.3.4.9
> supportedControl: 2.16.840.1.113730.3.4.10
> supportedControl: 1.2.840.113556.1.4.1504
> supportedControl: 1.2.840.113556.1.4.1852
> supportedControl: 1.2.840.113556.1.4.802
> supportedControl: 1.2.840.113556.1.4.1907
> supportedControl: 1.2.840.113556.1.4.1948
> supportedLDAPVersion: 3
> supportedLDAPVersion: 2
> supportedLDAPPolicies: MaxPoolThreads
> supportedLDAPPolicies: MaxDatagramRecv
> supportedLDAPPolicies: MaxReceiveBuffer
> supportedLDAPPolicies: InitRecvTimeout
> supportedLDAPPolicies: MaxConnections
> supportedLDAPPolicies: MaxConnIdleTime
> supportedLDAPPolicies: MaxPageSize
> supportedLDAPPolicies: MaxQueryDuration
> supportedLDAPPolicies: MaxTempTableSize
> supportedLDAPPolicies: MaxResultSetSize
> supportedLDAPPolicies: MaxNotificationPerConn
> supportedLDAPPolicies: MaxValRange
> highestCommittedUSN: 3103418
> supportedSASLMechanisms: GSSAPI
> supportedSASLMechanisms: GSS-SPNEGO
> supportedSASLMechanisms: EXTERNAL
> supportedSASLMechanisms: DIGEST-MD5
> dnsHostName: WODCStage-1.ottawa.ad.algonquincollege.com
> <http://WODCStage-1.ottawa.ad.algonquincollege.com>
> ldapServiceName:
> ad.algonquincollege.com:wodcstage-1$@OTTAWA.AD.ALGONQUINCOLLE
> GE.COM <http://GE.COM>
> serverName:
> CN=WODCSTAGE-1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=C
> onfiguration,DC=ad,DC=algonquincollege,DC=com
> supportedCapabilities: 1.2.840.113556.1.4.800
> supportedCapabilities: 1.2.840.113556.1.4.1670
> supportedCapabilities: 1.2.840.113556.1.4.1791
> isSynchronized: TRUE
> isGlobalCatalogReady: TRUE
> domainFunctionality: 2
> forestFunctionality: 2
> domainControllerFunctionality: 2
> [root at algldap ~]#
>
> Partial out:
>
> [root at algldap ~]# /usr/lib/mozldap/ldapsearch -x -h
> wodcstage-1.ottawa.ad.algonquincollege.com
> <http://wodcstage-1.ottawa.ad.algonquincollege.com> -w - -D
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" -s
> sub -b "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com"
> "objectclass=person" | more
> Enter bind password:
> version: 1
> dn: CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> cn: isp-transfer
> description: Transfer for Genesis Data to International Student
> Program share
> givenName: isp-transfer
> distinguishedName:
> CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincolleg
> e,DC=com
> instanceType: 4
> whenCreated: 20040517155823.0Z
> whenChanged: 20081016173006.0Z
> displayName: isp-transfer
> uSNCreated: 255422
> memberOf:
> CN=NAS_Transfer_Genesis_ISP,OU=Groups,DC=ottawa,DC=ad,DC=algonquinco
> llege,DC=com
> uSNChanged: 255422
> name: isp-transfer
> objectGUID:: EaeRW3KiMUac6hzEs//X/g==
> userAccountControl: 66048
> badPwdCount: 0
> codePage: 0
> countryCode: 0
> badPasswordTime: 0
> lastLogoff: 0
> lastLogon: 0
> pwdLastSet: 127292831041031250
> primaryGroupID: 513
> objectSid:: AQUAAAAAAAUVAAAArhyVdhR1dBOOfkA4DN8BAA==
> accountExpires: 9223372036854775807
> logonCount: 0
> sAMAccountName: isp-transfer
> sAMAccountType: 805306368
> userPrincipalName: isp-transfer at algonquincollege.com
> <mailto:isp-transfer at algonquincollege.com>
> lockoutTime: 0
> objectCategory:
> CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algonquincollege
> ,DC=com
> dSCorePropagationData: 20110131155635.0Z
> dSCorePropagationData: 20091227191115.0Z
> dSCorePropagationData: 20090127144505.0Z
> dSCorePropagationData: 20081201175842.0Z
> dSCorePropagationData: 16010714223649.0Z
> lastLogonTimestamp: 128686221598537375
>
> dn: CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> cn: heatweb
> sn: heatweb
> description: Used to communicate between HEAT and IIS
> distinguishedName:
> CN=heatweb,CN=Users,DC=ottawa,DC=ad,DC=algonquincollege,DC=
> com
> instanceType: 4
> whenCreated: 20050218192725.0Z
> whenChanged: 20081016172611.0Z
> displayName: heatweb
> uSNCreated: 89976
> memberOf: CN=Heat
> Users,OU=Groups,DC=ottawa,DC=ad,DC=algonquincollege,DC=com
> uSNChanged: 89976
> name: heatweb
> objectGUID:: 07KJaAgkGUapXbQN7VprrQ==
> userAccountControl: 66048
> badPwdCount: 0
> codePage: 0
> countryCode: 0
>
>
>
>
>
>
>
>
>
> --
> Albert Teh
> Email: Teh.Albert at Gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20110601/b4a2cf81/attachment.html>
More information about the 389-users
mailing list