[389-users] Windows Sync Agreement Help
Rich Megginson
rmeggins at redhat.com
Wed Jun 1 16:03:33 UTC 2011
On 06/01/2011 09:21 AM, Albert Teh wrote:
> The user: mailadm should have a full privilege from the AD because we
> are using this user for SUN's IDSYNC synchronizing/passwdsyc from the
> AD to the SUN's DS which is our current LDAP environment. We are
> trying to change SUN's Directory server to the Linux's 389-Directory
> server.
Ok. I don't know how Sun's IDSYNC works - it is possible it doesn't use
the DirSync control which requires Replicator privileges. Can you
confirm that
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" has
Replication/Replicator rights in AD/Windows?
>
>
> "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=com" has
> Replication/Replicator rights in AD/Windows?
>
> Thanks.
> Albert
>
> On Wed, Jun 1, 2011 at 10:12 AM, Rich Megginson <rmeggins at redhat.com
> <mailto:rmeggins at redhat.com>> wrote:
>
> 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 <tel: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
>> <mailto: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 <mailto:Teh.Albert at Gmail.com>
>
>
>
>
> --
> 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/86a1ecde/attachment.html>
More information about the 389-users
mailing list