Active Directory - Organizational Units or Discrete Domains?

flosofl asks: "I work for a large (1,000+ emp.) company and will be in charge of its Active Directory implementation. Our company is in turn owned by a much larger corporation (15,000+ emp.), but we are for the most part autonomous in terms of managing our internal IT dept. Since the larger corporation has ADS in place, they want us to roll in as an OU in their domain (xxx.com). I want to be a child domain (yyy.xxx.com). The SAP portal relies on LDAP and we are told it would not work correctly with a multi-domain model. I on the other hand want total control over MY domain (yes, I know as a parent domain they could do what they want - the illusion is enough). My question is, has anyone been in this type of situation before? How did you resolve it, and did it work? I am worried I am reacting more from a 'you can't play with my toys' than a legitimate tech/business reason. I want to use the method that will work best (which may not be the one I want). Any comments would be appreciated."

Comments

OU

[duffbeer703]

I work with Enterprise Management Software in a huge and diverse environment and have seen from experience that in the end it is easier for everyone to consolidate environments and services whenever possible.

Also, since you indicated that applications require you to use the OU model, you should use it.

Talk to the AD admins and get them to grant you administrative authority over everything within your OU. You might even be able to offload some of the more menial roles that you perform to the larger IT group.

be a tree in the forest

[imsmith]

If your organizational structure is autonomous as you say it it, and the AD implementation isn't being done in conjunction with some sort of hierarchical reformation in the Enterprise, the more elegant solution is to become a Tree in the AD Forest - not a sub-domain but another domain inside the AD Forest. This saves you from a lot of administration headaches caused by several geographically distributed administrators trying to perform policy-based user administration in the vaious domains - especially because the OS has no real good way of logging administrative activity (no rcs functionality) so you can spend all day trying to understand why Joe can't print and it turns out to be caused by a policy change initiated in Witchita, or whatever, where his primary OU has most of its staff.

Obviously if your Enterprise IT dept can't or won't do the schematic work required to create an AD Forest with multiple trees, or your vendor's can't or won't ship an SAP product that supports them, you are screwed and will end up as another OU in the AD.

Being a sub-domain in a single tree is just a bad idea all around for this circumstance - its not like you want to have a truely subordinate entity with local administration like a research lab or a test network.

The illusion is NOT enough!

[wonkamaster]

...(yes, I know as a parent domain they could do what they want - the illusion is enough)

You are right, by having control of the forest root the parent domain can override your security permissions in your domain and there's not really anything you can do about it. And although we can debate the design limitations of Active Directory, your problem boils down to the fact that you are looking to implement an "alternative" domain implementation that has been verified will not work with your SAP portal in the interests of gaining additional security which you know you won't get.

Perhaps I am missing something, but it sounds like a really bad idea. It's of course technically possible to bridge the LDAP between two domains (or forests for that matter), but without more knowledge of the portals LDAP requirements -- and with full knowledge that in a subdomain your additional security is a façade anyway, I wouldn't bother.

Just my 2 cents.