----- Ursprüngliche Nachricht -----
Von: Albert Teh <teh.albert@gmail.com>
Datum: Mittwoch, 1. Juni 2011, 2:30
Betreff: Re: [389-users] Windows Sync Agreement Help
An: Rich Megginson <rmeggins@redhat.com>
Cc: "General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>

>
>
> On Tue, May 31, 2011 at 2:58 PM, Rich Megginson <rmeggins@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=algonquinc ollege,dc=com" -s
base -b "" "objectclass=*"

>
>
You should get the contents of the AD
This is a good test, but take a notice of that winsync use the dirsync ldap control which require additional priviledges on AD. This can tested with a python script of rich:

https://github.com/richm/scripts/blob/master/dirsyncctrl.py

which need python an the ldap lib for python.

Regards Carsten


>
>
/usr/lib/mozldap/ldapsearch -x -h
wodcstage-1.ottawa.ad.algonquincollege.com -w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com" -s
sub -b "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person"

>
>
you should get the list of users>

>

>
>
Thanks.
>
Al

>

> On Tue, May 31, 2011 at 1:40 PM, Rich
Megginson <rmeggins@redhat.com>
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.
>
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@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@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=dc3Dalgonquincollege2Cdc3D com,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=algonquinco llege,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@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=dc3Dalgonquincollege 2Cdc3Dcom,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@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=com22,
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@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.
>
> Albert
> *
> /usr/lib/mozldap/ldapsearch -x -h wodcstage-1.ottawa.ad.algonquincollege.com -w
- -D
"cn=mailadm,cn=Users,dc=[root@algldap ~]# /usr/lib/mozldap/ldapsearch -x -h wodcstage-1.ottawa.ad.algonquincollege.com -w - -D "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,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=a lgonquinc
> *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=algonquinc ollege,DC=com
> namingContexts: CN=Configuration,DC=ad,DC=algonquincollege,DC=com
> namingContexts: CN=Schema,CN=Configuration,DC=ad,DC=algonquincolle ge,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=algonquincolle ge,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 -h wodcstage-1.ottawa.ad.algonquincollege.com -w - -D "cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com" -s sub -b "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om" "objectclass=person" | more
>
Enter bind password:
> version: 1
> dn: CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincoll ege,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=algonquincoll eg
> *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@algonquincollege.com
>
lockoutTime: 0
> objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algo nquincollege
> *,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=algonquinco llege,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=algonquinco llege,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=algonquincolleg e,DC=com
> uSNChanged: 89976
>
name: heatweb
> objectGUID:: 07KJaAgkGUapXbQN7VprrQ==
> userAccountControl: 66048
> badPwdCount: 0
> codePage: 0
> countryCode: 0
>
>
>
>
>
>
>
> >
> --
> Albert Teh
> Email: Teh.Albert@Gmail.com


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

On 05/31/2011 06:30 PM, Albert Teh wrote:




On Tue, May 31, 2011 at 2:58 PM, Rich
Megginson <rmeggins@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=algonquinc ollege,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person"



you should get the list of users







Thanks.

Al



On Tue, May 31, 2011 at 1:40
PM, Rich Megginson <rmeggins@redhat.com>
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.

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@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@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=dc3Dalgonquincollege2Cdc3D com,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=algonquinco llege,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@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=dc3Dalgonquincollege 2Cdc3Dcom,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@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=com22,
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users











--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@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=algonquinc ollege,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@algldap ~]#
/usr/lib/mozldap/ldapsearch -x -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,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=a lgonquinc

*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=algonquinc ollege,DC=com

namingContexts: CN=Configuration,DC=ad,DC=algonquincollege,DC=com

namingContexts:
CN=Schema,CN=Configuration,DC=ad,DC=algonquincolle ge,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=algonquincolle ge,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 -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com"
-s sub -b "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person" | more

Enter bind password:

version: 1

dn:
CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincoll ege,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=algonquincoll eg

*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@algonquincollege.com

lockoutTime: 0

objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algo nquincollege

*,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=algonquinco llege,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=algonquinco llege,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=algonquincolleg e,DC=com

uSNChanged: 89976

name: heatweb

objectGUID:: 07KJaAgkGUapXbQN7VprrQ==

userAccountControl: 66048

badPwdCount: 0

codePage: 0

countryCode: 0


















--

Albert Teh

Email: Teh.Albert@Gmail.com






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

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=algonquinc ollege,dc=com" has
Replication/Replicator rights in AD/Windows?

Thanks.
Albert

On Wed, Jun 1, 2011 at 10:12 AM, Rich Megginson <rmeggins@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@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=algonquinc ollege,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person"



you should get the list of users







Thanks.

Al



On Tue, May 31, 2011 at 1:40
PM, Rich Megginson <rmeggins@redhat.com>
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.

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@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@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=dc3Dalgonquincollege2Cdc3D com,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=algonquinco llege,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@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=dc3Dalgonquincollege 2Cdc3Dcom,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@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=com22,
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users











--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@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=algonquinc ollege,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@algldap ~]#
/usr/lib/mozldap/ldapsearch -x -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,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=a lgonquinc

*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=algonquinc ollege,DC=com

namingContexts: CN=Configuration,DC=ad,DC=algonquincollege,DC=com

namingContexts:
CN=Schema,CN=Configuration,DC=ad,DC=algonquincolle ge,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=algonquincolle ge,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 -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com"
-s sub -b "cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person" | more

Enter bind password:

version: 1

dn:
CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincoll ege,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=algonquincoll eg

*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@algonquincollege.com

lockoutTime: 0

objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algo nquincollege

*,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=algonquinco llege,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=algonquinco llege,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=algonquincolleg e,DC=com

uSNChanged: 89976

name: heatweb

objectGUID:: 07KJaAgkGUapXbQN7VprrQ==

userAccountControl: 66048

badPwdCount: 0

codePage: 0

countryCode: 0


















--

Albert Teh

Email: Teh.Albert@Gmail.com








--
Albert Teh
Email: Teh.Albert@Gmail.com

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

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=algonquinc ollege,dc=com" has
Replication/Replicator rights in AD/Windows?




*

"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com"
has Replication/Replicator rights in AD/Windows?



Thanks.

Albert



On Wed, Jun 1, 2011 at 10:12 AM, Rich
Megginson <rmeggins@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@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=algonquinc ollege,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person"



you should get the list of users







Thanks.

Al



On Tue, May 31,
2011 at 1:40 PM, Rich Megginson <rmeggins@redhat.com>
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.

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@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@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=dc3Dalgonquincollege2Cdc3D com,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=algonquinco llege,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@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=dc3Dalgonquincollege 2Cdc3Dcom,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@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=com22,
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users











--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@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=algonquinc ollege,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@algldap ~]#
/usr/lib/mozldap/ldapsearch -x -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,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=a lgonquinc

*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=algonquinc ollege,DC=com

namingContexts:
CN=Configuration,DC=ad,DC=algonquincollege,DC=com

namingContexts:
CN=Schema,CN=Configuration,DC=ad,DC=algonquincolle ge,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=algonquincolle ge,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 -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person" | more

Enter bind password:

version: 1

dn:
CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincoll ege,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=algonquincoll eg

*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@algonquincollege.com

lockoutTime: 0

objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algo nquincollege

*,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=algonquinco llege,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=algonquinco llege,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=algonquincolleg e,DC=com

uSNChanged: 89976

name: heatweb

objectGUID:: 07KJaAgkGUapXbQN7VprrQ==

userAccountControl: 66048

badPwdCount: 0

codePage: 0

countryCode: 0


















--

Albert Teh

Email: Teh.Albert@Gmail.com














--

Albert Teh

Email: Teh.Albert@Gmail.com






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

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@redhat.com> 写�：
-----原始邮件-----

�件人:"Rich Megginson" <rmeggins@redhat.com>

��时间:2011年6月2日 星期四

收件人:"Albert Teh" <teh.albert@gmail.com>


抄�:"General discussion list for the 389 Directory server project." <389-users@lists.fedoraproject.org>


主题: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=algonquinc ollege,dc=com" has
Replication/Replicator rights in AD/Windows?




Â*

"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com"
has Replication/Replicator rights in AD/Windows?



Thanks.

Albert



On Wed, Jun 1, 2011 at 10:12 AM, Rich
Megginson<rmeggins@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@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 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=algonquinc ollege,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person"



you should get the list of users







Thanks.

Al



On Tue, May 31,
2011 at 1:40 PM, Rich Megginson<rmeggins@redhat.com>
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@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@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=dc3Dalgonquincollege2Cdc3D com,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=algonquinco llege,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@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=dc3Dalgonquincollege 2Cdc3Dcom,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@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=com22,
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users











--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@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=algonquinc ollege,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=algonquinc ollege,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=a lgonquinc

Â*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=algonquinc ollege,DC=com

namingContexts:
CN=Configuration,DC=ad,DC=algonquincollege,DC=com

namingContexts:
CN=Schema,CN=Configuration,DC=ad,DC=algonquincolle ge,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=algonquincolle ge,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person" | more

Enter bind password:

version: 1

dn:
CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincoll ege,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=algonquincoll eg

Â*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@algonquincollege.com

lockoutTime: 0

objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algo nquincollege

Â*,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=algonquinco llege,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=algonquinco llege,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=algonquincolleg e,DC=com

uSNChanged: 89976

name: heatweb

objectGUID:: 07KJaAgkGUapXbQN7VprrQ==

userAccountControl: 66048

badPwdCount: 0

codePage: 0

countryCode: 0


















--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@Gmail.com








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

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@redhat.com> дµÀ£º
-----
Ô*ʼÓʼþ-----

·¢¼þÈË:"Rich Megginson" <rmeggins@redhat.com>

·¢ËÍʱ¼ä:2011Äê6ÔÂ2ÈÕ ÐÇÆÚËÄ

ÊÕ¼þÈË:"Albert Teh" <teh.albert@gmail.com>

³*ËÍ:"General discussion list for the 389 Directory server
project." <389-users@lists.fedoraproject.org>

Ö÷Ìâ: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=algonquinc ollege,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=algonquinc ollege,dc=com"

has Replication/Replicator rights in AD/Windows?



Thanks.

Albert



On Wed, Jun 1, 2011 at 10:12 AM, Rich
Megginson<rmeggins@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@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 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=algonquinc ollege,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person"



you should get the list of users







Thanks.

Al



On Tue, May
31, 2011 at 1:40 PM, Rich Megginson<rmeggins@redhat.com>
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@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@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=dc3Dalgonquincollege2Cdc3D com,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=algonquinco llege,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@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=dc3Dalgonquincollege 2Cdc3Dcom,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@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=com22,
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users











--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@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=algonquinc ollege,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=algonquinc ollege,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=a lgonquinc

*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=algonquinc ollege,DC=com

namingContexts:
CN=Configuration,DC=ad,DC=algonquincollege,DC=com

namingContexts:
CN=Schema,CN=Configuration,DC=ad,DC=algonquincolle ge,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=algonquincolle ge,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person" | more

Enter bind password:

version: 1

dn:
CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincoll ege,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=algonquincoll eg

*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@algonquincollege.com

lockoutTime: 0

objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algo nquincollege

*,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=algonquinco llege,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=algonquinco llege,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=algonquincolleg e,DC=com

uSNChanged: 89976

name: heatweb

objectGUID:: 07KJaAgkGUapXbQN7VprrQ==

userAccountControl: 66048

badPwdCount: 0

codePage: 0

countryCode: 0


















--

Albert Teh

Email:Teh.Albert@Gmail.com














--

Albert Teh

Email:Teh.Albert@Gmail.com












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





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

----- Ursprüngliche Nachricht -----
Von: Rich Megginson <rmeggins@redhat.com>
Datum: Mittwoch, 1. Juni 2011, 18:05
Betreff: Re: [389-users] Windows Sync Agreement Help
An: Albert Teh <teh.albert@gmail.com>
Cc: "General discussion list for the 389 Directory server project." <389-users@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=algonquinc ollege,dc=com" has
Replication/Replicator rights in AD/Windows?


>
>
*
>
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com"
has Replication/Replicator rights in AD/Windows?

>
>
Thanks.
>
Albert

>

> On Wed, Jun 1, 2011 at 10:12 AM, Rich
Megginson <rmeggins@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@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=algonquinc ollege,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=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person"

>
>
you should get the list of users



>

>
>
Thanks.
>
Al

>

> On Tue, May 31,
2011 at 1:40 PM, Rich Megginson <rmeggins@redhat.com>
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.
>
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@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@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=dc3Dalgonquincollege2Cdc3D com,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=algonquinco llege,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@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=dc3Dalgonquincollege 2Cdc3Dcom,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@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=com22,
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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@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=algonquinc ollege,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@algldap ~]#
/usr/lib/mozldap/ldapsearch -x -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,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=a lgonquinc
>
*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=algonquinc ollege,DC=com
>
namingContexts:
CN=Configuration,DC=ad,DC=algonquincollege,DC=com
>
namingContexts:
CN=Schema,CN=Configuration,DC=ad,DC=algonquincolle ge,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=algonquincolle ge,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 -h wodcstage-1.ottawa.ad.algonquincollege.com
-w - -D
"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquinc ollege,dc=com"
-s sub -b
"cn=Users,dc=ottawa,dc=ad,dc=algonquincollege,dc=c om"
"objectclass=person" | more
>
Enter bind password:
>
version: 1
>
dn:
CN=isp-transfer,CN=Users,DC=ottawa,DC=ad,DC=algonquincoll ege,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=algonquincoll eg
>
*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@algonquincollege.com
>
lockoutTime: 0
>
objectCategory:
CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=algo nquincollege
>
*,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=algonquinco llege,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=algonquinco llege,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=algonquincolleg e,DC=com
>
uSNChanged: 89976
>
name: heatweb
>
objectGUID:: 07KJaAgkGUapXbQN7VprrQ==
>
userAccountControl: 66048
>
badPwdCount: 0
>
codePage: 0
>
countryCode: 0

>

>

>

>

>

>

>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>






>

>
>
>
--
>
Albert Teh
>
Email: Teh.Albert@Gmail.com


>



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

Great News.
After talked to the AD Administrator, assigned the user: mailadm as a administrator. The Windows Sync is working. Thank you all for the great help.

My next step is to get the Password Sync working.


Need help again: 1) need to remap the attributes synchronizing from the AD to the DS.
************************* Is there any plugin for this process?

************************* 2) What password attribute is using on the DS for the LDAP* client's authencation?

***************************** I do not find the attribute: userPassword from the AD to the DS
***************************** after* the SYNC.

Thanks again for all the help.
Albert

*

On Fri, Jun 3, 2011 at 3:37 AM, <389-users-request@lists.fedoraproject.org> wrote:

Send 389-users mailing list submissions to

* * * *389-users@lists.fedoraproject.org



To subscribe or unsubscribe via the World Wide Web, visit

* * * *https://admin.fedoraproject.org/mailman/listinfo/389-users

or, via email, send a message with subject or body 'help' to

* * * *389-users-request@lists.fedoraproject.org



You can reach the person managing the list at

* * * *389-users-owner@lists.fedoraproject.org



When replying, please edit your Subject line so it is more specific

than "Re: Contents of 389-users digest..."





Today's Topics:



* 1. ds-admin script/package (Danny Wall)

* 2. Re: ds-admin script/package (solarflow99)

* 3. Re: ds-admin script/package (Danny Wall)

* 4. Re: ds-admin script/package (solarflow99)

* 5. Re: ds-admin script/package (Danny Wall)

* 6. Re: ds-admin script/package (Rich Megginson)

* 7. Re: Windows Sync Agreement Help (Carsten Grzemba)





----------------------------------------------------------------------



Message: 1

Date: Thu, 2 Jun 2011 16:40:37 -0400

From: Danny Wall <dwall72@gmail.com>

Subject: [389-users] ds-admin script/package

To: 389-users@lists.fedoraproject.org

Message-ID: <BANLkTi=kzFoCphzp1a1ckniuwumRTUnH-w@mail.gmail.com>

Content-Type: text/plain; charset="iso-8859-1"



I am setting up three RHEL 6 servers and am unable to find the packages or

scripts to install the admin console. In CentOS 5.5 and the 389 project, the

packages are available, and I see references to setup-ds-admin.pl in RHEL 6

documentation and in searches. I have the dirsrv package installed and a

couple LDAP instances configured, but I have to use generic LDAP browsers

for administration and can not configure password policies, etc. that appear

to require the admin console or web page.



Can anyone point me to the missing link?



Thanks

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/c3418661/attachment-0001.html





------------------------------



Message: 2

Date: Thu, 2 Jun 2011 16:56:52 -0400

From: solarflow99 <solarflow99@gmail.com>

Subject: Re: [389-users] ds-admin script/package

To: "General discussion list for the 389 Directory server project."

* * * *<389-users@lists.fedoraproject.org>

Message-ID: <BANLkTinV443CJfUCBnXeoQXfeh2uTWAPhw@mail.gmail.co m>

Content-Type: text/plain; charset="iso-8859-1"



There are several RPM's involved, what repo and yum command did you use?





2011/6/2 Danny Wall <dwall72@gmail.com>



> I am setting up three RHEL 6 servers and am unable to find the packages or

> scripts to install the admin console. In CentOS 5.5 and the 389 project, the

> packages are available, and I see references to setup-ds-admin.pl in RHEL

> 6 documentation and in searches. I have the dirsrv package installed and a

> couple LDAP instances configured, but I have to use generic LDAP browsers

> for administration and can not configure password policies, etc. that appear

> to require the admin console or web page.

>

> Can anyone point me to the missing link?

>

> Thanks

>

>

> --

> 389 users mailing list

> 389-users@lists.fedoraproject.org

> https://admin.fedoraproject.org/mailman/listinfo/389-users

>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/59f5428b/attachment-0001.html





------------------------------



Message: 3

Date: Thu, 2 Jun 2011 17:01:36 -0400

From: Danny Wall <dwall72@gmail.com>

Subject: Re: [389-users] ds-admin script/package

To: "General discussion list for the 389 Directory server project."

* * * *<389-users@lists.fedoraproject.org>

Message-ID: <BANLkTimNg3HGJZgvLO6MdRB-LiQBAsfAMw@mail.gmail.com>

Content-Type: text/plain; charset="iso-8859-1"



I first tried to the default rhel 6 repo then tried adding the epel 6 repo.



Thanks

On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99@gmail.com> wrote:

> There are several RPM's involved, what repo and yum command did you use?

>

>

> 2011/6/2 Danny Wall <dwall72@gmail.com>

>

>> I am setting up three RHEL 6 servers and am unable to find the packages

or

>> scripts to install the admin console. In CentOS 5.5 and the 389 project,

the

>> packages are available, and I see references to setup-ds-admin.pl in RHEL

>> 6 documentation and in searches. I have the dirsrv package installed and

a

>> couple LDAP instances configured, but I have to use generic LDAP browsers

>> for administration and can not configure password policies, etc. that

appear

>> to require the admin console or web page.

>>

>> Can anyone point me to the missing link?

>>

>> Thanks

>>

>>

>> --

>> 389 users mailing list

>> 389-users@lists.fedoraproject.org

>> https://admin.fedoraproject.org/mailman/listinfo/389-users

>>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/7ac1b8cf/attachment-0001.html





------------------------------



Message: 4

Date: Thu, 2 Jun 2011 17:11:13 -0400

From: solarflow99 <solarflow99@gmail.com>

Subject: Re: [389-users] ds-admin script/package

To: "General discussion list for the 389 Directory server project."

* * * *<389-users@lists.fedoraproject.org>

Message-ID: <BANLkTikoc5p3WRQSoJO3toL28-wkzc+anQ@mail.gmail.com>

Content-Type: text/plain; charset="iso-8859-1"



good, epel is the one to use. *Did you use yum install 389-ds *? that will

pull in the whole thing.









2011/6/2 Danny Wall <dwall72@gmail.com>



> I first tried to the default rhel 6 repo then tried adding the epel 6 repo.

>

>

> Thanks

> On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99@gmail.com> wrote:

> > There are several RPM's involved, what repo and yum command did you use?

> >

> >

> > 2011/6/2 Danny Wall <dwall72@gmail.com>

> >

> >> I am setting up three RHEL 6 servers and am unable to find the packages

> or

> >> scripts to install the admin console. In CentOS 5.5 and the 389 project,

> the

> >> packages are available, and I see references to setup-ds-admin.pl in

> RHEL

> >> 6 documentation and in searches. I have the dirsrv package installed and

> a

> >> couple LDAP instances configured, but I have to use generic LDAP

> browsers

> >> for administration and can not configure password policies, etc. that

> appear

> >> to require the admin console or web page.

> >>

> >> Can anyone point me to the missing link?

> >>

> >> Thanks

> >>

> >>

> >> --

> >> 389 users mailing list

> >> 389-users@lists.fedoraproject.org

> >> https://admin.fedoraproject.org/mailman/listinfo/389-users

> >>

>

> --

> 389 users mailing list

> 389-users@lists.fedoraproject.org

> https://admin.fedoraproject.org/mailman/listinfo/389-users

>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/d5c1f43a/attachment-0001.html





------------------------------



Message: 5

Date: Thu, 2 Jun 2011 17:14:59 -0400

From: Danny Wall <dwall72@gmail.com>

Subject: Re: [389-users] ds-admin script/package

To: "General discussion list for the 389 Directory server project."

* * * *<389-users@lists.fedoraproject.org>

Message-ID: <BANLkTin08GVsHrwh6EZV0ZdchXUKcwchsw@mail.gmail.co m>

Content-Type: text/plain; charset="iso-8859-1"



I may have used 389 base. I will try it later without the base. Thanks

On Jun 2, 2011 5:11 PM, "solarflow99" <solarflow99@gmail.com> wrote:

> good, epel is the one to use. Did you use yum install 389-ds ? that will

> pull in the whole thing.

>

>

>

>

> 2011/6/2 Danny Wall <dwall72@gmail.com>

>

>> I first tried to the default rhel 6 repo then tried adding the epel 6

repo.

>>

>>

>> Thanks

>> On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99@gmail.com> wrote:

>> > There are several RPM's involved, what repo and yum command did you

use?

>> >

>> >

>> > 2011/6/2 Danny Wall <dwall72@gmail.com>

>> >

>> >> I am setting up three RHEL 6 servers and am unable to find the

packages

>> or

>> >> scripts to install the admin console. In CentOS 5.5 and the 389

project,

>> the

>> >> packages are available, and I see references to setup-ds-admin.pl in

>> RHEL

>> >> 6 documentation and in searches. I have the dirsrv package installed

and

>> a

>> >> couple LDAP instances configured, but I have to use generic LDAP

>> browsers

>> >> for administration and can not configure password policies, etc. that

>> appear

>> >> to require the admin console or web page.

>> >>

>> >> Can anyone point me to the missing link?

>> >>

>> >> Thanks

>> >>

>> >>

>> >> --

>> >> 389 users mailing list

>> >> 389-users@lists.fedoraproject.org

>> >> https://admin.fedoraproject.org/mailman/listinfo/389-users

>> >>

>>

>> --

>> 389 users mailing list

>> 389-users@lists.fedoraproject.org

>> https://admin.fedoraproject.org/mailman/listinfo/389-users

>>

-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/7ab1793d/attachment-0001.html





------------------------------



Message: 6

Date: Thu, 02 Jun 2011 15:18:02 -0600

From: Rich Megginson <rmeggins@redhat.com>

Subject: Re: [389-users] ds-admin script/package

To: "General discussion list for the 389 Directory server project."

* * * *<389-users@lists.fedoraproject.org>

Message-ID: <4DE7FE0A.9020806@redhat.com>

Content-Type: text/plain; charset="iso-8859-1"



On 06/02/2011 03:14 PM, Danny Wall wrote:

>

> I may have used 389 base. I will try it later without the base. Thanks

>

389-ds-base is in the base RHEL 6.1 OS. *None of the other 389 packages

such as 389-admin are available yet. *I'm in the process of building

them now for EPEL6. *setup-ds.pl is provided by the 389-ds-base

package. *setup-ds-admin.pl is provided by the 389-admin package.

> On Jun 2, 2011 5:11 PM, "solarflow99" <solarflow99@gmail.com

> <mailto:solarflow99@gmail.com>> wrote:

> > good, epel is the one to use. Did you use yum install 389-ds ? that will

> > pull in the whole thing.

> >

> >

> >

> >

> > 2011/6/2 Danny Wall <dwall72@gmail.com <mailto:dwall72@gmail.com>>

> >

> >> I first tried to the default rhel 6 repo then tried adding the epel

> 6 repo.

> >>

> >>

> >> Thanks

> >> On Jun 2, 2011 4:57 PM, "solarflow99" <solarflow99@gmail.com

> <mailto:solarflow99@gmail.com>> wrote:

> >> > There are several RPM's involved, what repo and yum command did

> you use?

> >> >

> >> >

> >> > 2011/6/2 Danny Wall <dwall72@gmail.com <mailto:dwall72@gmail.com>>

> >> >

> >> >> I am setting up three RHEL 6 servers and am unable to find the

> packages

> >> or

> >> >> scripts to install the admin console. In CentOS 5.5 and the 389

> project,

> >> the

> >> >> packages are available, and I see references to

> setup-ds-admin.pl <http://setup-ds-admin.pl> in

> >> RHEL

> >> >> 6 documentation and in searches. I have the dirsrv package

> installed and

> >> a

> >> >> couple LDAP instances configured, but I have to use generic LDAP

> >> browsers

> >> >> for administration and can not configure password policies, etc.

> that

> >> appear

> >> >> to require the admin console or web page.

> >> >>

> >> >> Can anyone point me to the missing link?

> >> >>

> >> >> Thanks

> >> >>

> >> >>

> >> >> --

> >> >> 389 users mailing list

> >> >> 389-users@lists.fedoraproject.org

> <mailto:389-users@lists.fedoraproject.org>

> >> >> https://admin.fedoraproject.org/mailman/listinfo/389-users

> >> >>

> >>

> >> --

> >> 389 users mailing list

> >> 389-users@lists.fedoraproject.org

> <mailto:389-users@lists.fedoraproject.org>

> >> https://admin.fedoraproject.org/mailman/listinfo/389-users

> >>

>

>

> --

> 389 users mailing list

> 389-users@lists.fedoraproject.org

> https://admin.fedoraproject.org/mailman/listinfo/389-users



-------------- next part --------------

An HTML attachment was scrubbed...

URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20110602/60f0ddb1/attachment-0001.html





------------------------------



Message: 7

Date: Fri, 03 Jun 2011 09:37:08 +0200

From: Carsten Grzemba <grzemba@contac-dt.de>

Subject: Re: [389-users] Windows Sync Agreement Help

To: "General discussion list for the 389 Directory server project."

* * * *<389-users@lists.fedoraproject.org>

Message-ID: <fc54d5723506.4de8ab44@contac-dt.de>

Content-Type: text/plain; charset="iso-8859-1"







----- Urspr?ngliche Nachricht -----

Von: Rich Megginson <rmeggins@redhat.com>

Datum: Mittwoch, 1. Juni 2011, 18:05

Betreff: Re: [389-users] Windows Sync Agreement Help

An: Albert Teh <teh.albert@gmail.com>

Cc: "General discussion list for the 389 Directory server project." <389-users@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=algonquin college,dc=com" has

* *Replication/Replicator rights in AD/Windows?





* * *>

>

* * *?

>

* * *"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquin college,dc=com"

* * *has Replication/Replicator rights in AD/Windows?



* * *>

>

* * *Thanks.

>

* * *Albert



* * *>



* * *> On Wed, Jun 1, 2011 at 10:12 AM, Rich

* * * *Megginson <rmeggins@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@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=algonquin college,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=algonquin college,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@redhat.com>

* * * * * * * * * * * * * * * *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.

>

* * * * * * * * * * * * * * * * * *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@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@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=dc3Dalgonquincollege2Cdc3 Dcom,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=algonquinco llege,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@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=dc3Dalgonquincolleg e2Cdc3Dcom,cn=mapping











* * * * * * * * * * * * * * * * * * * * * * * * * * * * *tree,cn=config"



* * * * * * * * * * * * * * * * * * * * * * * * * * * * *scope=0

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *filter="(|(objectClass=*)(objectClass=ldapsubentr y))"

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *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@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=com22,

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *cn=mapping

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *tree,

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *cn=config"

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *scope=0

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *filter="(|(objectClass=*)(objectClass=ldapsubentr y))"

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *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@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users













* * * * * * * * * * * * * * * * * * * * * * * * * * * * *>



* * * * * * * * * * * * * * * * * * * * * * * * * * * * *>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *>

>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *--

>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *Albert Teh

>

* * * * * * * * * * * * * * * * * * * * * * * * * * * * *Email: Teh.Albert@Gmail.com





* * * * * * * * * * * * * * * * * * * * * * * * * * * * *>













* * * * * * * * * * * * * * * * * * * * * * * * * * *>



* * * * * * * * * * * * * * * * * * * * * * * * * * *>

* * * * * * * * * * * * * * * * * * * * * * * * * * *>

>

* * * * * * * * * * * * * * * * * * * * * * * * * * *--

>

* * * * * * * * * * * * * * * * * * * * * * * * * * *Albert Teh

>

* * * * * * * * * * * * * * * * * * * * * * * * * * *Email: Teh.Albert@Gmail.com





* * * * * * * * * * * * * * * * * * * * * * * * * *>













* * * * * * * * * * * * * * * * * * * * *>



* * * * * * * * * * * * * * * * * * * * *>

* * * * * * * * * * * * * * * * * * * * *>

>

* * * * * * * * * * * * * * * * * * * * *--

>

* * * * * * * * * * * * * * * * * * * * *Albert Teh

>

* * * * * * * * * * * * * * * * * * * * *Email: Teh.Albert@Gmail.com





* * * * * * * * * * * * * * * * * * * *>













* * * * * * * * * * * * * * *>



* * * * * * * * * * * * * * *>

* * * * * * * * * * * * * * *>

>

* * * * * * * * * * * * * * *--

>

* * * * * * * * * * * * * * *Albert Teh

>

* * * * * * * * * * * * * * *Email: Teh.Albert@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=algonquin college,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@algldap ~]#

* * * * * * * * */usr/lib/mozldap/ldapsearch -x -h wodcstage-1.ottawa.ad.algonquincollege.com

* * * * * * * * *-w - -D

* * * * * * * * *"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquin college,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=algonquinc ollege,DC=com

>

* * * * * * * * *namingContexts:

* * * * * * * * *CN=Configuration,DC=ad,DC=algonquincollege,DC=com

>

* * * * * * * * *namingContexts:

* * * * * * * * *CN=Schema,CN=Configuration,DC=ad,DC=algonquincoll ege,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=algonquincoll ege,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 -h wodcstage-1.ottawa.ad.algonquincollege.com

* * * * * * * * *-w - -D

* * * * * * * * *"cn=mailadm,cn=Users,dc=ottawa,dc=ad,dc=algonquin college,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=algonquincoll ege,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=algonquincoll eg

>

* * * * * * * * *?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,D C=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@algonquincollege.com

>

* * * * * * * * *lockoutTime: 0

>

* * * * * * * * *objectCategory:

* * * * * * * * *CN=Person,CN=Schema,CN=Configuration,DC=ad,DC=alg onquincollege

>

* * * * * * * * *?,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=algonquinc ollege,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=algonquinc ollege,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=algonquincolle ge,DC=com

>

* * * * * * * * *uSNChanged: 89976

>

* * * * * * * * *name: heatweb

>

* * * * * * * * *objectGUID:: 07KJaAgkGUapXbQN7VprrQ==

>

* * * * * * * * *userAccountControl: 66048

>

* * * * * * * * *badPwdCount: 0

>

* * * * * * * * *codePage: 0

>

* * * * * * * * *countryCode: 0



* * * * * * * * *>



* * * * * * * * *>



* * * * * * * * *>



* * * * * * * * *>



* * * * * * * * *>



* * * * * * * * *>



* * * * * * * * *>



* * * * * * * * *>

* * * * * * * * *>

>

* * * * * * * * *--

>

* * * * * * * * *Albert Teh

>

* * * * * * * * *Email: Teh.Albert@Gmail.com





* * * * * * * *>













* * *>



* * *>

* * *>

>

* * *--

>

* * *Albert Teh

>

* * *Email: Teh.Albert@Gmail.com





* *>







> --

> 389 users mailing list

> 389-users@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@contac-dt.de>

Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20110603/0a1d0dec/attachment.vcf





------------------------------



--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users



End of 389-users Digest, Vol 73, Issue 7

****************************************



--
Albert Teh
Email: Teh.Albert@Gmail.com

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