Re: [389-users] Windows Sync Agreement Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On 06/01/2011 07:26 PM, 彭胜文 wrote:

nss_base_passwd        cn=Users,dc=dev,dc=jz,dc=com
nss_base_shadow        cn=Users,dc=dev,dc=jz,dc=com
nss_base_group        cn=Users,dc=dev,dc=jz,dc=com

##----AD------------------
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User

ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5



--
BR,
Thanks!

在2011-06-02，"Rich Megginson" <rmeggins@xxxxxxxxxx> 写道：
----- 原始邮件-----
发件人:"Rich Megginson" <rmeggins@xxxxxxxxxx>
发送时间:2011年6月2日 星期四
收件人:"Albert Teh" <teh.albert@xxxxxxxxx>
抄送:"General discussion list for the 389 Directory server project." <389-users@xxxxxxxxxxxxxxxxxxxxxxx>
主题:Re: [389-users] Windows Sync Agreement Help

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?
I don't think the reply answers this question.

 
"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@xxxxxxxxxx> wrote:
On 05/31/2011 06:30 PM, Albert Teh wrote:


On Tue, May 31, 2011 at 2:58 PM, Rich Megginson<rmeggins@xxxxxxxxxx> 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 theSync New Windows Usersoption. 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 -hwodcstage-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 -hwodcstage-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@xxxxxxxxxx> wrote:
On 05/31/2011 10:30 AM, Albert Teh wrote:

HI Rich,

[root@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@algldap ~]#

No Entry found !!!.
You have to tell directory server which entries you want to sync.
Seehttp://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@xxxxxxxxxx> 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@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@algldap slapd-algldap]#



On Fri, May 27, 2011 at 10:57 AM, Rich Megginson<rmeggins@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users




--
Albert Teh
Email:Teh.Albert@xxxxxxxxx




--
Albert Teh
Email:Teh.Albert@xxxxxxxxx




--
Albert Teh
Email:Teh.Albert@xxxxxxxxx




--
Albert Teh
Email:Teh.Albert@xxxxxxxxx



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 -hwodcstage-1.ottawa.ad.algonquincollege.com -w - -D "cn=mailadm,cn=Users,dc=[root@algldap ~]# /usr/lib/mozldap/ldapsearch -x -hwodcstage-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@algldap ~]#

Partial out:

[root@algldap ~]# /usr/lib/mozldap/ldapsearch -x -hwodcstage-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@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx




--
Albert Teh
Email:Teh.Albert@xxxxxxxxx




--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users

--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux