Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Microsoft

Active Directory - Organizational Units or Discrete Domains? 27

Posted by Cliff from the arranging-your-resources dept.
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."
This discussion has been archived. No new comments can be posted.

Active Directory - Organizational Units or Discrete Domains? More

Active Directory - Organizational Units or Discrete Domains?

Comments Filter:

  • OU (Score:5, Insightful)

    by duffbeer703 ( 177751 ) on Wednesday April 09, 2003 @08:23PM (#5697723)
    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 (Score:4, Insightful)

    by imsmith ( 239784 ) on Wednesday April 09, 2003 @09:12PM (#5697975)
    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! (Score:5, Insightful)

    by wonkamaster ( 599507 ) on Wednesday April 09, 2003 @09:38PM (#5698105)
    ...(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.

  • AD OUs and Domains (Score:3, Informative)

    by sarob ( 618642 ) on Thursday April 10, 2003 @12:36AM (#5698982)
    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 used to work at a University where the computing department had its own Novell infrastructure. Eventually we wound up joining the NDS tree (Novell's equivalent of AD, predating it by several years) of the university under some pretty clear guidelines that we wanted full control over our "branch" of the tree.

    It solved a lot of problems (users coming to our labs, our users going to other departments) and wound up being worth the hassle.

    You will find cases where having a group-wide tree is more useful t

    • AD doesn't allow for the same kind of delegation that NDS does. In NDS, the root admin can actually make a portion of the tree that he has no rights to, can't get back, and possibly not even see. Under AD, the top-level admins can ALWAYS somehow take ownership.
  • 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).

  • AD Design (Score:2, Informative)

    by jayrcee ( 517607 )
    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 becau

  • Forests and Trees (Score:4, Informative)

    by haplo21112 ( 184264 ) <haplo@ep[ ]na.com ['ith' in gap]> on Thursday April 10, 2003 @08:57AM (#5700588) Homepage
    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...
  • We had one child domain here, and I'll never do that again! It was on a T1/384 frame, and it would lose site of the other AD servers quite frequently. The building would remain functional, but I could see the errors, sometimes not even being able to find it in network neighborhood, esp from Win 9.x machines. We finally got a new server, so I was able to move everything off of the old one and take the domain out. What a pain! And it has still taken a bite out of our AD and DNS. (our roles master just we

  • Geographic vs. Logical (Score:3, Informative)

    by forsetti ( 158019 ) on Friday April 11, 2003 @01:39PM (#5711824)
    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.
  • This may have been stated other places, but in general, I start with two domains, an "empty" root and a child that contains everything. I only add domains if there is a good reason to do so. Wanting to have a domain is not a good reason. Some good reasons are:

    - Need to have different password policies (these are only configurable at the domain level).

    - Replication issues that cannot be handled through the site topology.

    You don't really talk about what is being put in this OU, is it your users' accounts,

Slashdot Top Deals

Software production is assumed to be a line function, but it is run like a staff function. -- Paul Licker

Close