Wednesday, October 21, 2009

The Method to My Madness - Active Directory Structure

I get a hard time at work because I am very picky about the way Active Directory is structured in our environment. What can I say, I like doing things a certain way. Now don't get me wrong, I am open to doing things differently and changing my ways, but there has to be a very good reason. For this reason, I am publishing my preferred structure for all to see and critique. I hope to improve upon this structure by getting feedback from as many people as possible. I will try (as much as possible) to explain my thought process and reasoning. When there is a comment for an OU, I will give it a number and explain below.

I do not really change any of the default active directory folders and OUs. I leave them as is, but I do not add any new objects to any of these folders if at all possible (Except for the 'Domain Controllers' OU). Here is what the rest of my structure looks like. I will use an asterisk to denote a sublevel with one asterisk being a root-level OU. For my example, I will use the fictitious name HazarInc with locations in Provo, Utah, Scottsdale, Arizona, and Guayaquil, Ecuador. I use [type] as a placeholder, for example, when you see 'Computers [type]', I am trying to convey that there could be an OU for a specific type of Computer (e.g. 'Computers Removable Media Allowed'). The following are all Organizational Units.

        * HazarInc - 1
        *        * Provo - 2
        *        *        * Human Resources - 3
        *        *        *        * Computers
        *        *        *        * Computers [type] - 4
        *        *        *        * Users
        *        *        *        * Users [type]
        *        *        * Information Systems
        *        *        *        * Computers
        *        *        *        * Users
        *        *        * Sales
        *        *        *        * Computers
        *        *        *        * Users
        *        *        * Operations
        *        *        *        * Computers
        *        *        *        * Users
        *        * Scottsdale
        *        *        * Human Resources
        *        *        *        * Computers
        *        *        *        * Computers [type]
        *        *        *        * Users
        *        *        *        * Users [type]
        *        *        * Information Systems
        *        *        *        * Computers
        *        *        *        * Users
        *        *        * Sales
        *        *        *        * Computers
        *        *        *        * Users
        *        *        * Operations
        *        *        *        * Computers
        *        *        *        * Users
        *        * Guayaquil
        *        *        * Human Resources
        *        *        *        * Computers
        *        *        *        * Computers [type]
        *        *        *        * Users
        *        *        *        * Users [type]
        *        *        * Information Systems
        *        *        *        * Computers
        *        *        *        * Users
        *        *        * Sales
        *        *        *        * Computers
        *        *        *        * Users
        *        *        * Operations
        *        *        *        * Computers
        *        *        *        * Users
        * HazarInc Email - 5
        *        * Provo
        *        *        * Contacts
        *        *        *        * [type] - 6
        *        *        * Distribution Groups
        *        *        * Resources
        *        * Scottsdale
        *        *        * Contacts
        *        *        * Distribution Groups
        *        *        * Resources
        *        * Guayaquil
        *        *        * Contacts
        *        *        * Distribution Groups
        *        *        * Resources
        *        * Enterprise - 7
        *        *        * Contacts
        *        *        * Distribution Groups
        *        *        * Resources
        * HazarInc Groups - 8
        *        * Provo
        *        *        * Domain Local Security - 9
        *        *        * Global Security - 10
        *        *        * Universal Security - 11
        *        *        * Group Policy Security - 12
        *        *        * SQL Security - 13
        *        *        * Firewall Security - 14
        *        *        * Restriced Security - 15
        *        * Scottsdale
        *        *        * Domain Local Security
        *        *        * Global Security
        *        *        * Universal Security
        *        *        * Group Policy Security
        *        *        * SQL Security
        *        *        * Firewall Security
        *        *        * Restriced Security
        *        * Guayaquil
        *        *        * Domain Local Security
        *        *        * Global Security
        *        *        * Universal Security
        *        *        * Group Policy Security
        *        *        * SQL Security
        *        *        * Firewall Security
        *        *        * Restriced Security
        *        * Enterprise - 16
        *        *        * Global Security
        *        *        * Universal Security
        *        *        * Group Policy Security
        *        *        * Firewall Security
  *        * Restricted Security
        * HazarInc Servers
        *        * Provo - 17
        *        *        * Web - 18
        *        *        * Terminal - 19
        *        *        * SQL - 20
        *        *        * File - 21
        *        * Scottsdale
        *        *        * Web
        *        *        * Terminal
        *        *        * SQL
        *        *        * File
        *        * Guayaquil
        *        *        * Web
        *        *        * Terminal
        *        *        * SQL
        *        *        * File
        * HazarInc Service Accounts - 22
        *        * Provo
        *        *        * Users
        *        *        * Users [type]
        *        * Scottsdale
        *        *        * Users
        *        * Guayaquil
        *        *        * Users
        *        * Enterprise
        *        *        * Users

Explanations
1 - Any group policy you want to apply to the entire company can be applied here with the exception of policies that are required to be set on the 'Domain Controllers' OU and policies that are required to be set at the 'Domain Level'. I use other policies at the domain level as a catch-all to make sure some policy gets applied to objects that are improperly put in the default folders.

2 - Any group policy you want to apply to the location (e.g. location specific login scripts or location specific update servers)

3 - I put all of my computer and user policies here to cover all OUs that are not a specific [type]

4 - Very specific group policies that override the defaults inherited from above

5 - I like having a separate location for all of my email objects so they don't get mixed in with the rest

6 - If you have a lot of contacts, you may want to use subgroups. This applies for other OUs also

7 - Sometimes these types of objects do not really correspond to a location

8 - I do not like my groups mixed with other objects

9 - Look for information on 'Domain Local' groups and when I use them in an upcoming post

10 - Look for information on 'Global' groups and when I use them in an upcoming post

11 - Look for information on 'Universal' groups and when I use them in an upcoming post

12 - Groups created to filter group policy to specific groups - rarely used as most policies can be separated by OU. Most common use for me is software installation policy

13 - Look for information on 'SQL Security' groups (Domain Local groups) that are used specifically to assign rights to SQL Server in an upcoming post

14 - Groups used in our Fortinet FortiGate firewalls - I will have a post about Fortinet in the near future

15 - Look for information on 'Restricted' groups in an upcoming post - Here's the link

16 - Some groups do not correlate to a location

17 - Apply policies that are required for servers in this location (e.g. update server)

18 - Apply policies specific to Web servers

19 - Apply policies specific to Terminal servers

20 - Apply policies specific to SQL servers

21 - Apply policies specific to File servers

22 - Every security professional's nightmare, the dreaded service account. I like to keep my eye on these so I keep them separate from the other users

Up Next: The Method to My Madness Part II - Active Directory Standards & Role-Based Access

7 comments:

  1. As an Active Directory enterprise engineer, I can appreciate you being picky about the design of AD...most people just don't get it. :)
    I like your ideas and thought process here...but I do have a few questions.

    * What do you store in the Email\Resources OU....I would assume resource mailboxes?

    * How do you handle stale accounts?

    ReplyDelete
  2. Jason,

    Apparently I don't have this set up correctly so that I can respond via email. So, if you get this twice I apologize.

    You are correct. I store resource mailboxes under Email\Resources (conference rooms, company cars, etc.). We handle stale accounts with a program that our developers wrote that checks for stale accounts, disables them after a specified period of time, and then deletes them after another period of time. If we get a termination request, it goes through our work order system and the account is disabled.

    How do you handle stale accounts?

    ReplyDelete
  3. I applaud you for putting your OU structure where all can gaze at it. Not many would and as such I hope the excercise proves very useful to you and others.

    I certainly agree with being picky as well. And I can see structure to your OU structure which is always a good thing.
    Obviously there are many factors in designing an OU structure for an organisation. However, when designing it we must always be mindful of one thing, it is for administrative purposes only and users never see it. This is in fact more important than it sounds.
    What I mean by this is make it as simple as possible, doing so will simplify administrative activity and ease troubleshooting. An optimized Active Directory, including OU structure and Group Policy can definately help in reducing the cost in maintaining it.

    So, there are three main reasons for the existence of an OU. They are:
    :: Delegation of Administration
    :: Application of Group Policy
    :: Visibility of objects

    If an OU exists but cannot be placed into one of these buckets, chances are it does not need to be there and the objects can be placed elsewhere.

    As far as your structure is concerned, I would ask the following questions if I were carrying out an AD audit (actually I go through more than a hundred questions but clearly I'm not going to do that here):

    Apart from location, what is the difference between a Sales person in Provo and another Sales person in Scottsdale?

    What is the difference from a person in Human Resources to a person in Sales etc. (same location or different one)?

    Same as the questions above but for computers?

    Same as the questions above but for groups?

    Why have you got a specific OU for [type]? If, for example, you need to allow some users the ability to write to removable media, create a GPO that allows this, amend the security of the GPO to only allow a certain security group read and apply rights, link it to a single OU where all these objects reside. Job done.

    Explanation 4 above talks about override the defaults inherited. It tends to suggest that the Enforce (No override) switch is being used or the Block Inheritance option which can complicate GPO application and troubleshooting and should be used only when absolutely necessary.

    How are Adminisrtative accounts dealt with, where are they placed and controlled? (Regarding yourself for example, can I assume you have a normal account that is mail enabled and used to access your data etc, and a separate Admin account that you use to RunAs admin tasks).

    Obviously I don't know key information like number of users, administrative responsibility, data administrators, Active Directory sites, etc., etc., etc.

    One last thing, you talk about a catch-all for objects placed in the default containers (and as such cannot have GPOs linked to them). I would always recommend the redirection of the default containers to staging OUs for both users and computers. That way, any rogue administrator who has not followed correct procedures of placing objects in the correct OU will find the new objects relocated to an OU that can be controlled directly with GPO. Check out REDIRUSR and REDIRCOMP to do this.

    Hope this helps. :)

    ReplyDelete
  4. Konsultancy,

    Thanks for the comments. I will definitely check out REDIRUSR and REDIRCOMP. I do not store Admin accounts in a separate container I will have to think about that, but I agree with having separate user accounts and using RunAs. I have posted your questions below so that I can try to answer them.

    Apart from location, what is the difference between a Sales person in Provo and another Sales person in Scottsdale?

    The difference here would be stuff like which WSUS server they are pointed at and which login script they use.

    What is the difference from a person in Human Resources to a person in Sales etc. (same location or different one)?

    The main difference here are application settings like IE. We customize some departments.

    Same as the questions above but for computers?

    There are others, but the main reason for the separation here is how I use Restricted Groups. You can check out what I mean here.

    Same as the questions above but for groups?

    The main reason here is personal preference. I like them separated this way. However, I could also see a use in delegation of control if we managed our locations separately.

    As far as the overrides go, I just meant that the GPOs closest to the object may overwrite the settings set higher up in the tree. We do not use Enforce or Block Inheritance.

    ReplyDelete
  5. David,

    Some very typical reasons for the separations and good to see you have some. I have come across many where no real thought process had been gone through. :)
    Do you have an Active Directory Site for each of your physical locations you stipulate above? If so, link the GPO to the Site for things like WSUS.
    Alternatively, do you have a security group for each site? You can then use security group filtering to ensure only the objects within that group have read and apply permissions on that GPO.

    I read through your Restricted Groups article and this is whats known as the AG/RG Method. It is fairly standard practice, especially in larger organisations as it scales very well. The only thing I'd say here is try not to use the same method when delegating permissions within AD.

    Have a look at the following structure and seeing how that would work in your environment:

    * HazarInc
    * * Computers
    * * * Activity Based Computers
    * * * Knowledge Based Computers
    * * * Unmanaged Computers
    * * Data Administrators
    * * Email
    * * * Contacts
    * * * Distribution Groups
    * * * Resources
    * * Groups
    * * Servers
    * * * Web
    * * * Terminal
    * * * SQL
    * * * File
    * * * etc
    * * Service Accounts
    * * Staging
    * * Retired
    * * Users
    * * * Activity Based Users
    * * * Knowledge Based Users
    * * * Unmanaged Users

    Explanations:
    :: Activity Based - Highly managed and can be split out again to cater for specific departments if needed
    :: Knowledge Based - Lightly managed allowing more control for the user (like power users)
    :: Unmanaged - Development/Third-party/etc.
    :: Staging - Where REDIRUSR and REDIRCOMP point to. This could include a different WSUS GPO to ensure rapid deployment of security fixes to get machines up to date ASAP when joined to the domain.
    :: Data Administrators refers to Active Directory and Infrastructure Data and not actual data (e.g. to house separate Admin accounts and groups to use Delegation of Administration)

    This structure also assumes the following:
    :: Good naming convention is in place for workstations (LT***** and DT*****), groups (AG-Location-***** and RG-Location-*****), etc.
    :: Security groups exist to house location based users and computers
    :: GPOs linked at the lower levels are amended to use security group filtering (in other words replace Authenticated Users with the security group you want to allow to apply the GPO)

    ReplyDelete
  6. Konsultancy,

    Thanks for the comments. This is the type of the information I was hoping to get by posting this. Let me answer your question and then I will address some of the other information.

    Do you have an Active Directory Site for each of your physical locations you stipulate above?

    Yes, we have sites set up for our physical locations in order to control replication and also becuase we use DFS Namespaces.

    We have never used sites to apply policy though, so I will definitely check this out and see if it makes more sense for our organization to move to this model.

    I have also used security filtering, but mainly for software installations. I was under the impression that this would affect performance, but after your post I did some research and that does not appear to be the case. This is also an area I will have to ponder for my organization.

    The company I am currently with has gone through a merger and an acquisition in the last two years. After seeing and dealing with the integration of these other directories, I came to a realization that most people (at least in small to mid-size organizations) do not spend a lot of time planning and designing their structure. (Ok, I realize that 2 is not a statistically significant number, but it is all I have.)

    I don't think it is for lack of caring as much as it is lack of understanding. How will a better AD structure save me time, make my organization more secure, or increase performance?

    Also, it is my opinion that too many people become complacent because they have a solution that works and do not spend the time to rethink and reanalyze. The structure that I have designed here works for my organization now and is based heavily on Active Directory as implemented in Windows Server 2003. Will this structure work in AD 2008? Sure, it will probably work, but will it be the best design to take advantage of new features and new concepts?

    ReplyDelete
  7. Late post, but I like the single top level OU and Ive argued its benefit to little effect most of the time.

    I also like Konsultancy's comments and make the observation that his simplified stucture relates to Microsoft's default containers somewhat.

    I like the KISS principle so my preference is single top level OU for Global policies (which may be very minimal, PKI etc)

    Then functional type GPO's with the caveat that Geography may suggest that an additional layer for delegation is required..

    ReplyDelete