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