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 -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
