[389-users] Windows Sync Agreement Help

Albert Teh teh.albert at gmail.com
Wed Jun 1 15:21:44 UTC 2011


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.


"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> 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>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 -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 -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>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>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
>>>> nsDS5ReplicaRoot: dc=algonquincollege,dc=com
>>>> nsDS5ReplicaHost: 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>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>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 list389-users at lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Albert Teh
>>>>> Email: Teh.Albert at Gmail.com
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Albert Teh
>>>> Email: Teh.Albert at Gmail.com
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Albert Teh
>>> Email: Teh.Albert at Gmail.com
>>>
>>>
>>>
>>
>>
>> --
>> Albert Teh
>> Email: 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 -w - -D
> "cn=mailadm,cn=Users,dc=[root at algldap ~]# /usr/lib/mozldap/ldapsearch -x
> -h 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
> ldapServiceName:
> ad.algonquincollege.com:wodcstage-1$@OTTAWA.AD.ALGONQUINCOLLE
>  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 -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
> 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
>
>
>


-- 
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/cd1755eb/attachment.html>


More information about the 389-users mailing list