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."
You would only really need another domain if the namespace needed to be different and/or you needed to upgrade in place a legacy domain without merging it with the parent domain. You could gain control over your OU and reset the ACLs on the OU so that only your OU administrators had access. Some things like domain admins, enterprise admins, and schema admins you would not have control over. To be honest, if you are not familar with Active Directory then hand the responsiblity of maintaining the domain controllers and the active directory databases over to a central group that will be focus on that task. Maintaining Active Directory is more like Exchange or SQL database management.
I worked in a medium sized division of a large company and we were in the exact same situation. I had the same concerns that you do. We ended up collapsing into an OU and have not looked back. There are several services that get consolidated as well. For example, you would (probably) no longer have to support domain controllers if you went into an OU. Also, there is very little that can be done with a domain that can't be accomplished with an OU (password policy is one).
Having just been through a consolidation of 4+ NT4 Domains (1000+ users) to a single AD installation last year and the addition of an additional Child Domain overseas within the last 6 months I can say that there is really only one reason to consider using a child domain instead of OUs, and that reason is replication.
All DC's in a domain have an exact copy of the AD structure and it needs to be replicated fairly often for the domain to function correctly. We decided to make a child domain overseas because it really cuts down on the amount of replication traffic between the sites and will allow the child to still run well even if the overseas link is down for any substantial amount of time.
As long as you have a good (1/2 T1+) stable connection between all the different locations all other administrative functions can be delegated at the OU level, policy inheritance can be blocked and there really is no reason to use a child domain instead of an Organizational Unit.
"Because I have balls like atom bombs, two of them, 100 megatons each. Nobody fucks with me."
I would go the route of being a tree(or as you put it subdomain) within their active directory forest. If they built their AD correctly in the first place it should be a snap to make your NT Domain part of their forest. In fact its even easier now with the release of Server 2003, if makes the whole relationship much more robust, and allows established domains to easily join the forest....
Why this solution is Ideal...
1. You still own your domain, and have complete control as you always have.
2. The larger entity, also has control since they are higher up, any thing at their level can flow down to you as an integrated entity, if need be...
3. An OU's purpose is not to for containing entire subdivions of a company as your relationship seems to be...an OU is just that Organizational Unit...so you divide your domain up into the company departments with them....
4. This will become especially important for using SMS if you folks desire...particularly if you impliment SMS 2003, or whatever the next version beyond 2.0 ends up getting called since its heavily AD oriented...
Only other questions, e-mail me, we have been down all these roads here, and can probably provide insights if you wish...
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
Generally, Domains should be used for geographically distinct locations. OUs should be used for logical subdivisions within the same geographical location.
However, if you need different password policies, you need your own domain.
10b||~10b -- aah, what a question!