[389-users] Windows Replication Agreement Help

[John A. Sullivan III]

On Tue, 2010-07-20 at 23:15 -0400, John A. Sullivan III wrote:
> 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
<snip>
We were finally successful in our endeavors but it was not easy.  We
first needed to use ADSI Edit.  This allowed us to create an
Organization  at the top level of our tree.  Then we hit the next
problem.  Our LDAP DIT has a second organization under the first.  The
Microsoft AD schema only allows Countries, Localities, and Domain
Components to be superior to Organizations and not other Organizations.

We thus needed to modify the AD schema in order to allow nested
Organizations by using a combination of lde.exe and ADSI Edit.  We
launched ldp.exe, connected to local host and did a bind as the current
user (since we were administrator).  We next chose Browse / Modify and
entered
CN=Organization,CN=Schema,CN=Configuration,DC=pacad,DC=pacifera,DC=com
as the DN.  We entered the systemPossSuperiors attribute.

Unfortunately, I did not document the next steps as well as I should
have.  I believe simply adding organization gave us a not very helpful
error 19.  I think we had to delete the current value
"country;locality;domainDNS" and replace it with
"organization;country;locality;domainDNS".  Once this was added we
returned to ADSI Edit, right clicked on the RootDSE and reloaded the
schema.  Hope this helps someone else! - John