Hi, We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0. Performing the full sync fails after about 30 seconds with a message in the error log: [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like: dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com. Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created. Though for some reason the replication is traversing the whole of the internal AD tree.

Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ?

On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote: > --[ UxBoD ]-- wrote: > > Hi, > > > > We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0. > > > > Performing the full sync fails after about 30 seconds with a message in the error log: > > > > [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value > > [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value > > > > and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like: > > > > dc=domain,dc=com > > |_ o=Internal > > |___o=a0000 > > |____ou=Desktops > > |_____uid=fred > > > > We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com. > > > > Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created. > > > > Though for some reason the replication is traversing the whole of the internal AD tree. > Because you set the AD subtree to be dc=domain,dc=com ? > > Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ? > > > I think that's the way it was designed. Usually AD trees have a > CN=Users,DC=domain,DC=com where all of the user entries live, and > winsync is designed to work with that sort of structure. <snip> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized at cn=users,dc=myad,dc=domain,dc=com but still have the exact same problem :(

On Mon, 2010-07-19 at 04:26 -0400, John A. Sullivan III wrote: > On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote: > >> On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote: >> >>> --[ UxBoD ]-- wrote: >>> >>>> Hi, >>>> >>>> We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0. >>>> >>>> Performing the full sync fails after about 30 seconds with a message in the error log: >>>> >>>> [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value >>>> [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value >>>> >>>> and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like: >>>> >>>> dc=domain,dc=com >>>> |_ o=Internal >>>> |___o=a0000 >>>> |____ou=Desktops >>>> |_____uid=fred >>>> >>>> We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com. >>>> >>>> Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created. >>>> >>>> Though for some reason the replication is traversing the whole of the internal AD tree. >>>> >>> Because you set the AD subtree to be dc=domain,dc=com ? >>> >>>> Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ? >>>> >>>> >>> I think that's the way it was designed. Usually AD trees have a >>> CN=Users,DC=domain,DC=com where all of the user entries live, and >>> winsync is designed to work with that sort of structure. >>> >> <snip> >> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized >> at cn=users,dc=myad,dc=domain,dc=com but still have the exact same >> problem :( >> > <snip> > I also tried creating an ou in AD, e.g., > ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building > Organizations under CNs but that also failed - John > <snip> Hmm .. .more inconsistent behavior. I thought it might be a schema violation to put an O under a CN or O.

I tried creating it under DC; that did not work. I tried synching an OU instead of an O. That appeared to work but only transferred one of five users. I wonder if it is a 64 bit problem. The system where it is working is a 32 bit version of Windows

-- 389 users mailing list 389-users(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users

John A. Sullivan III wrote: > On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote: > >> On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote: >> >>> --[ UxBoD ]-- wrote: >>> >>>> Hi, >>>> >>>> We are setting up a new Windows 2K3 AD server and attempting to syncronise the users from our LDAP server version 8.1.0. >>>> >>>> Performing the full sync fails after about 30 seconds with a message in the error log: >>>> >>>> [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type "ARecord" in entry "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value >>>> [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to attribute type "dnsproperty" in entry "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" failed: duplicate new value >>>> >>>> and none of the users or groups are sent to AD. I am guessing it may be how our LDAP server schema is setup as we use something like: >>>> >>>> dc=domain,dc=com >>>> |_ o=Internal >>>> |___o=a0000 >>>> |____ou=Desktops >>>> |_____uid=fred >>>> >>>> We have set the Windows subtree to be dc=domain,dc=com and the replication subtree to be dc=domain,dc=com with a DS subtree of o=Internal,dc=domain,dc=com. >>>> >>>> Our understanding was that within AD Users & Groups GUI we should have seen a similar schema created. >>>> >>>> Though for some reason the replication is traversing the whole of the internal AD tree. >>>> >>> Because you set the AD subtree to be dc=domain,dc=com ? >>> >>>> Should we create a new Organisational Unit within AD called, for arguments sake, clients and set the Windows subtree to be ou=clients,dc=domain,dc=com so that it forces it to that branch ? >>>> >>>> >>> I think that's the way it was designed. Usually AD trees have a >>> CN=Users,DC=domain,DC=com where all of the user entries live, and >>> winsync is designed to work with that sort of structure. >>> >> <snip> >> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and synchronized >> at cn=users,dc=myad,dc=domain,dc=com but still have the exact same >> problem :( >> > <snip> > I also tried creating an ou in AD, e.g., > ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like building > Organizations under CNs but that also failed - John > Not sure what you mean by "building Organizations" - but it shouldn't matter if it is under a CN or not.

----- Original Message ----- > On Mon, 2010-07-19 at 07:01 -0600, Rich Megginson wrote: > >> John A. Sullivan III wrote: >> >>> On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote: >>> >>> >>>> On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote: >>>> >>>> >>>>> --[ UxBoD ]-- wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> We are setting up a new Windows 2K3 AD server and attempting to >>>>>> syncronise the users from our LDAP server version 8.1.0. >>>>>> >>>>>> Performing the full sync fails after about 30 seconds with a >>>>>> message in the error log: >>>>>> >>>>>> [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute type >>>>>> "ARecord" in entry >>>>>> "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >>>>>> failed: duplicate new value >>>>>> [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" to >>>>>> attribute type "dnsproperty" in entry >>>>>> "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >>>>>> failed: duplicate new value >>>>>> >>>>>> and none of the users or groups are sent to AD. I am guessing >>>>>> it may be how our LDAP server schema is setup as we use >>>>>> something like: >>>>>> >>>>>> dc=domain,dc=com >>>>>> |_ o=Internal >>>>>> |___o=a0000 >>>>>> |____ou=Desktops >>>>>> |_____uid=fred >>>>>> >>>>>> We have set the Windows subtree to be dc=domain,dc=com and the >>>>>> replication subtree to be dc=domain,dc=com with a DS subtree of >>>>>> o=Internal,dc=domain,dc=com. >>>>>> >>>>>> Our understanding was that within AD Users & Groups GUI we >>>>>> should have seen a similar schema created. >>>>>> >>>>>> Though for some reason the replication is traversing the whole >>>>>> of the internal AD tree. >>>>>> >>>>>> >>>>> Because you set the AD subtree to be dc=domain,dc=com ? >>>>> >>>>> >>>>>> Should we create a new Organisational Unit within AD called, >>>>>> for arguments sake, clients and set the Windows subtree to be >>>>>> ou=clients,dc=domain,dc=com so that it forces it to that branch >>>>>> ? >>>>>> >>>>>> >>>>>> >>>>> I think that's the way it was designed. Usually AD trees have a >>>>> CN=Users,DC=domain,DC=com where all of the user entries live, >>>>> and >>>>> winsync is designed to work with that sort of structure. >>>>> >>>>> >>>> <snip> >>>> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and >>>> synchronized >>>> at cn=users,dc=myad,dc=domain,dc=com but still have the exact >>>> same >>>> problem :( >>>> >>>> >>> <snip> >>> I also tried creating an ou in AD, e.g., >>> ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like >>> building >>> Organizations under CNs but that also failed - John >>> >>> >> Not sure what you mean by "building Organizations" - but it >> shouldn't >> matter if it is under a CN or not. >> > <snip> > We're running 8.1. Based upon some of the change logs I've seen for > some of the more recent versions of 389, I wonder if this is just a > problem between 8.1 and Windows Server 2008. We are downgrading a > Domain Controller to 2003 to see if the problem goes away - John > > The problem still exists on W2K3/32bit and we see the following error: windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1

The user we are bind with in AD is a member of Domain Admins; do we need to add some other group or security membership ?

----- Original Message ----- > --[ UxBoD ]-- wrote: > >> ----- Original Message ----- >> >> >>> On Mon, 2010-07-19 at 07:01 -0600, Rich Megginson wrote: >>> >>> >>>> John A. Sullivan III wrote: >>>> >>>> >>>>> On Mon, 2010-07-19 at 04:15 -0400, John A. Sullivan III wrote: >>>>> >>>>> >>>>> >>>>>> On Wed, 2010-07-14 at 15:40 -0600, Rich Megginson wrote: >>>>>> >>>>>> >>>>>> >>>>>>> --[ UxBoD ]-- wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We are setting up a new Windows 2K3 AD server and attempting >>>>>>>> to >>>>>>>> syncronise the users from our LDAP server version 8.1.0. >>>>>>>> >>>>>>>> Performing the full sync fails after about 30 seconds with a >>>>>>>> message in the error log: >>>>>>>> >>>>>>>> [14/Jul/2010:07:46:10 -0400] - add value "^V" to attribute >>>>>>>> type >>>>>>>> "ARecord" in entry >>>>>>>> "DC=@,DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >>>>>>>> failed: duplicate new value >>>>>>>> [14/Jul/2010:07:46:10 -0400] - add value "null or non-ASCII" >>>>>>>> to >>>>>>>> attribute type "dnsproperty" in entry >>>>>>>> "DC=RootDNSServers,CN=MicrosoftDNS,CN=System,DC=domain,DC=com" >>>>>>>> failed: duplicate new value >>>>>>>> >>>>>>>> and none of the users or groups are sent to AD. I am guessing >>>>>>>> it may be how our LDAP server schema is setup as we use >>>>>>>> something like: >>>>>>>> >>>>>>>> dc=domain,dc=com >>>>>>>> |_ o=Internal >>>>>>>> |___o=a0000 >>>>>>>> |____ou=Desktops >>>>>>>> |_____uid=fred >>>>>>>> >>>>>>>> We have set the Windows subtree to be dc=domain,dc=com and the >>>>>>>> replication subtree to be dc=domain,dc=com with a DS subtree >>>>>>>> of >>>>>>>> o=Internal,dc=domain,dc=com. >>>>>>>> >>>>>>>> Our understanding was that within AD Users & Groups GUI we >>>>>>>> should have seen a similar schema created. >>>>>>>> >>>>>>>> Though for some reason the replication is traversing the whole >>>>>>>> of the internal AD tree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Because you set the AD subtree to be dc=domain,dc=com ? >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Should we create a new Organisational Unit within AD called, >>>>>>>> for arguments sake, clients and set the Windows subtree to be >>>>>>>> ou=clients,dc=domain,dc=com so that it forces it to that >>>>>>>> branch >>>>>>>> ? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> I think that's the way it was designed. Usually AD trees have a >>>>>>> CN=Users,DC=domain,DC=com where all of the user entries live, >>>>>>> and >>>>>>> winsync is designed to work with that sort of structure. >>>>>>> >>>>>>> >>>>>>> >>>>>> <snip> >>>>>> Hmm . . . we've rooted AD in dc=myad,dc=domain,dc=com and >>>>>> synchronized >>>>>> at cn=users,dc=myad,dc=domain,dc=com but still have the exact >>>>>> same >>>>>> problem :( >>>>>> >>>>>> >>>>>> >>>>> <snip> >>>>> I also tried creating an ou in AD, e.g., >>>>> ou=LDAPUSers,dc=myad,dc=domain,dc=com in case it did not like >>>>> building >>>>> Organizations under CNs but that also failed - John >>>>> >>>>> >>>>> >>>> Not sure what you mean by "building Organizations" - but it >>>> shouldn't >>>> matter if it is under a CN or not. >>>> >>>> >>> <snip> >>> We're running 8.1. Based upon some of the change logs I've seen for >>> some of the more recent versions of 389, I wonder if this is just a >>> problem between 8.1 and Windows Server 2008. We are downgrading a >>> Domain Controller to 2003 to see if the problem goes away - John >>> >>> >>> >> The problem still exists on W2K3/32bit and we see the following >> error: >> >> windows_tot_run: failed to obtain data to send to the consumer; LDAP >> error - 1 >> >> > Enable the replication log level - > http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting > >> The user we are bind with in AD is a member of Domain Admins; do we >> need to add some other group or security membership ? >> >> Hi Rich, that is what I did not get the error message. Here is the complete output: [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation

[20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay add operation. [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain data to send to the consumer; LDAP error - 1 [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): No linger to cancel on the connection [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - agmt="cn=DomainAD" (adc01:636): State: start -> ready_to_acquire_replica

----- Original Message ----- <SNIP> > >> Hi Rich, >> >> that is what I did not get the error message. Here is the complete >> output: >> >> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >> agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: >> NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best match >> of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation >> >> > This is saying that the DN mapping is not working - are you trying to > add an RHDS entry like uid=foo,ou=bar,ou=people,DC=domain,DC=com to > AD, > but AD doesn't have ou=bar,CN=Users,DC=ad,DC=domain,DC=com > > ? Note that winsync will not add sub-ou containers > >> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >> agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot replay >> add operation. >> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >> agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection >> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >> agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain >> data to send to the consumer; LDAP error - 1 >> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >> agmt="cn=DomainAD" (adc01:636): No linger to cancel on the >> connection >> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >> agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer >> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >> agmt="cn=DomainAD" (adc01:636): State: start -> >> ready_to_acquire_replica >> >> >> In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like: dc=domain,dc=com |_ o=Internal |___o=a0000 |____ou=Desktops |_____uid=fred Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ?

----- Original Message ----- > --[ UxBoD ]-- wrote: > >> ----- Original Message ----- >> <SNIP> > >> >> >>>> Hi Rich, >>>> >>>> that is what I did not get the error message. Here is the complete >>>> output: >>>> >>>> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >>>> agmt="cn=DomainAD" (adc01:636): Received result code 32 (0000208D: >>>> NameErr: DSID-031001CD, problem 2001 (NO_OBJECT), data 0, best >>>> match >>>> of: 'CN=Users,DC=ad,DC=domain,DC=com' ) for add operation >>>> >>>> >>>> >>> This is saying that the DN mapping is not working - are you trying >>> to >>> add an RHDS entry like uid=foo,ou=bar,ou=people,DC=domain,DC=com to >>> AD, >>> but AD doesn't have ou=bar,CN=Users,DC=ad,DC=domain,DC=com >>> >>> ? Note that winsync will not add sub-ou containers >>> >>> >>>> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >>>> agmt="cn=DomainAD" (adc01:636): windows_replay_update: Cannot >>>> replay >>>> add operation. >>>> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >>>> agmt="cn=DomainAD" (adc01:636): Beginning linger on the connection >>>> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >>>> agmt="cn=DomainAD" (adc01:636): windows_tot_run: failed to obtain >>>> data to send to the consumer; LDAP error - 1 >>>> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >>>> agmt="cn=DomainAD" (adc01:636): No linger to cancel on the >>>> connection >>>> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >>>> agmt="cn=DomainAD" (adc01:636): Disconnected from the consumer >>>> [20/Jul/2010:10:42:20 -0400] NSMMReplicationPlugin - >>>> agmt="cn=DomainAD" (adc01:636): State: start -> >>>> ready_to_acquire_replica >>>> >>>> >>>> >>>> >> In AD we have the standard mappings of >> CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across >> users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema >> looks like: >> >> dc=domain,dc=com >> |_ o=Internal >> |___o=a0000 >> |____ou=Desktops >> |_____uid=fred >> >> Am I right in assuming that we would need to create those levels in >> AD manually instead of the replication plugin creating them ? >> >> > Yes. > Thanks Rich Would the entry look something like cn=fred,ou=Desktops,ou=a0000,ou=Internal,dc=ad,dc=domain,dc=com

Just trying to visualise how to set it up in AD.

On Tue, 2010-07-20 at 10:05 -0600, Rich Megginson wrote: > --[ UxBoD ]-- wrote: > > ----- Original Message ----- > > <SNIP> > > > > <snip>>> > >> ? Note that winsync will not add sub-ou containers > <snip>> > > In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like: > > > > dc=domain,dc=com > > |_ o=Internal > > |___o=a0000 > > |____ou=Desktops > > |_____uid=fred > > > > Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ? > > > Yes. <snip> Strange - in the past it has for us and it did again when testing yesterday. However, it did not create an O subcontainer. In the past, we have had: dc=domain,dc=com |_o=Internal |_o=Client |_ou=Desktops |_ou=Groups and synchronized o=Client at dc=client,dc=com in the client's AD and got: dc=client,dc=com |_ou=Desktops |_ou=Groups I'll play with it some more. I hope we do not have to redefine all the O's under O=Internal as OU's. That would be a nightmare. Thanks - John

On Tue, 2010-07-20 at 18:08 -0400, John A. Sullivan III wrote: > On Tue, 2010-07-20 at 14:15 -0400, John A. Sullivan III wrote: > > On Tue, 2010-07-20 at 10:05 -0600, Rich Megginson wrote: > > > --[ UxBoD ]-- wrote: > > > > ----- Original Message ----- > > > > <SNIP> > > > > > > > > <snip>>> > > > >> ? Note that winsync will not add sub-ou containers > > > <snip>> > > > > In AD we have the standard mappings of CN=Users,DC=ad,DC=domain,DC=com and we are trying to sync across users from RHDS DS o=Internal,dc=domain,dc=com. Our RHDS schema looks like: > > > > > > > > dc=domain,dc=com > > > > |_ o=Internal > > > > |___o=a0000 > > > > |____ou=Desktops > > > > |_____uid=fred > > > > > > > > Am I right in assuming that we would need to create those levels in AD manually instead of the replication plugin creating them ? > > > > > > > Yes. > > <snip> > > Strange - in the past it has for us and it did again when testing > > yesterday. However, it did not create an O subcontainer. In the past, > > we have had: > > dc=domain,dc=com > > |_o=Internal > > |_o=Client > > |_ou=Desktops > > |_ou=Groups > > > > and synchronized o=Client at dc=client,dc=com in the client's AD and > > got: > > dc=client,dc=com > > |_ou=Desktops > > |_ou=Groups > > > > I'll play with it some more. I hope we do not have to redefine all the > > O's under O=Internal as OU's. That would be a nightmare. Thanks - John > > This is starting to make sense but it is also looking really, really > ugly. We do have this working but I think it is by accident. When we > first set it up in the working instance, it failed. Strangely, after a > second attempt (and there may have been a reboot of the Windows PDC), it > worked. I do not know how but, in some cases even in our testing today, > OU objects are created. Most of the time they are not. I do not know > what trips that unexpected behavior but I have seen it. That must have > happened in this "successful" attempt. When we tried the second time, > the OUs were in place and the users were successfully created and > maintained. It happened by accident. > > Now, we are pushing further. We are trying to create a hierarchy of > Organizations and OUs. As you explained earlier, I suppose the synch > tools don't do that. > > So, I thought I would bite the bullet and create the hierarchy. Alas, I > see no way to create an object of type Organization in AD. Is there a > way and I'm just completely ignorant? > > I then thought I'd cheat and try to sync an Organization to the top of > the tree. That worked. I created a user and they appeared at the top > of the tree. I then tried to create an Organization to see if that > would work. The synchronization seemed successful but the Organization > does not display. > > I checked the Microsoft Schema reference and it says they have an > Organization. Does anyone know how one enables the AD management tools > to see it and create new ones? Then we might be able to get it to sync > with 389. Thanks - John <snip> Well . . .I've been battling this literally all day and it still looks ugly. As far as I can tell, just as Rich said, the sync does not handle O and OU objects. Ours worked by accident as explained previously. We hit a problem if we try to reproduce the hierarchy because Windows AD seems to have not way to define an Organization object even though the schema supposedly includes it. If the hierarchy contains only OU objects and is predefined, the users populate throughout the hierarchy. I tried using views to "convert" the O objects to OU objects in a parallel hierarchy. The synchronization does not error but no users are created. It looks like we need to design our entire multi-tenant LDAP structure to eliminate all references to O= (which seems absolutely stupid and a project fraught with potential production impact) or we need to find a way to manipulate Organization objects in AD. Does anyone have any idea how to do the latter? Thanks - John