----- Ursprüngliche Nachricht -----
Von: Rich Megginson <rmeggins at redhat.com>
Datum: Mittwoch, 1. Juni 2011, 18:05
Betreff: Re: [389-users] Windows Sync Agreement Help
An: Albert Teh <teh.albert at gmail.com>
Cc: "General discussion list for the 389 Directory server project." <389-users at lists.fedoraproject.org>
>
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.
No, its not true in general, Suns Idsync needs only a normal user, if you sync only from AD to DS. The user for Suns Idsync needs only additional privileges for see the 'deleted objects' container for syncing the object deletion. It do not use the dirsync ldap control where you need the Replication/Replicator rights
Regards, Carsten
>
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>
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 list
> 389-users at lists.fedoraproject.org
https://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
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: grzemba.vcf
Type: text/x-vcard
Size: 233 bytes
Desc: Card for Carsten Grzemba <grzemba at contac-dt.de>
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20110603/0a1d0dec/attachment.vcf>