Security on single forest domain design

Discussion in 'Active Directory' started by agcastle2000, Mar 1, 2006.

  1. agcastle2000

    agcastle2000 Guest


    Aside from delegation, what else I can do to properly secure our single
    forest domain design which are spread on three sites?

    I read the technet article "Best Practice Active Directory Design for
    Managing Windows Networks" and I've done most what's recommended there but I
    feel like there's probably more that can be done in addition to delegating an
    <account_ou>_1, <account_ou>_2, <account_ou>_3 where <account_ou> is the name
    of the office location. Then I have users, svc_accts, computers, groups,
    admins and resource_ou underneath.

    As it's a single forest domain shared between 3 sites, it looks like we are
    limited to just delegation.

    Grateful if you could share someting useful.

    agcastle2000, Mar 1, 2006
    1. Advertisements

  2. agcastle2000

    agcastle2000 Guest

    Hi Paul,

    Thanks for you reply.

    Correct me if misunderstood you but you sound to suggest that by delegating
    the administration as oppose to using the the built-in and default groups,
    I'm going a long (and maybe painful) way to secure the AD.

    What I mean is that by I've done the delegation on the account ou level
    where each Administrator have full control on all objects under its account
    (site) ou. In addition to this, I removed all Windows Adminstrators from
    Enterprise Admins, Domain Admins and Schema Admins groups (they were all
    added to these groups after our upgrade from NT). The downside to this is
    that they can no longer do a lot of things.
    Basically, I just don't any of the Windows Admins to do whatever they want
    to do at the forest domain level.

    Let's set aside DMZ for the time being and Group Policy which is the next
    thing I have to do.

    Considering our requirements, what's the best balanced strategy between
    administration and security? Balanced in the sense that Windows Admins should
    only be constrained to their respective OUs but it should also not be too
    restrictive to the point that they will have difficulty doing their
    day-to-day work.

    agcastle2000, Mar 3, 2006
    1. Advertisements

  3. That is, the ultimate question. In an ideal setup, you and one or two
    others would be domain admins. Everyone else wouldn't - they'd be
    delegated. However, depending on your setup and more importantly your
    management and budget, this might not be immediately achievable. In which
    case you need to secure this as best you can, with the idea of bettering
    this over time. However, the easiest time to do this is at the beginning,
    otherwise it's difficult to remove permissions and rights from people.
    Paul Williams [MVP], Mar 4, 2006
  4. agcastle2000

    agcastle2000 Guest

    Hi Paul,

    I was so surprised to see a response from you knowing that it's early
    morning now in the US. I guess it's the price you have to pay for being an

    I got your point on the ideal setup and your point on removing rights from
    the people.

    Thanks and regards,
    agcastle2000, Mar 4, 2006
  5. It's not so early over here in the UK... ;-)

    But it is a Saturday, so half of your comment is correct <g>

    Sorry I couldn't be more help. But this really does depend on so many
    factors, that it is something that you have to plan and design yourself.
    You can get advice from people here and whitepapers, etc. but at the end of
    the day, sometimes security is impractical. And other times it's practical,
    if you have understanding management who are willing to pay lots of money
    for no perceived benefit whatsoever...
    Paul Williams [MVP], Mar 4, 2006
  6. agcastle2000

    Cary Shultz Guest


    Paul is located across the Pond! So, depending on where you are in the US
    (I am on the East Coast) add six, seven, eight or nine hours...

    But, Paul is always here. And Thank God for that!

    Paul is correct. It is better to set things up 'correctly' first. However,
    that might not be possible. It is really difficult, as Paul stated, to give
    someone Domain Admin membership (be very careful!) and then to take it away.
    How would you like to be that person? I sure wouldn't! No matter how you
    explain it there will be hurt feelings!
    Cary Shultz, Mar 4, 2006
  7. agcastle2000

    agcastle2000 Guest

    Hi Paul,

    I thought you're based in the US.

    I agree on what you said.. sometimes security is impractical.

    The thing is that for the other Admins not be able to mess with the AD
    structure, it looks like the only choice is to remove their memberships from
    Enterprise Admins, Domain Admins and Schema Admins. Right?

    It is worth mentioning that as the Domain Admins is automatically added to
    the local group Administrators on each member workstations or servers, by
    removing the other Windows Adminstrators from Domain Admins would also remove
    their ability to administer to these machines. grrh. This is the dark side of

    This leads me to ask whether it is possible in GP to populate the local
    group Administrators with users.

    agcastle2000, Mar 4, 2006
  8. agcastle2000

    Cary Shultz Guest

    Here is where I mention Restricted Groups and here is where Paul mentions
    startup script....

    And let's not forget our friend 'cusrmgr'. I *think* that KJ would mention

    The problem with Restricted Groups is that there is one of two behaviors
    (but not really a choice). The default behavior is to flush and add the
    group that you determine. There is a fix for this that needs to be applied
    to each and every system. Then the behavior is that it will simply add to
    whatever is already there. This will prevent anyone else from being added
    that your 'local focus group' (read: local Administrators group on each PC).

    The problem with the startup script is that it does not prevent other
    users/groups from being added to your 'local focus group'.

    So, whatever works better for you is the solution that you should choose.

    Cary Shultz, Mar 4, 2006
  9. I cover restricted groups and startup script here:

    I must confess that I'm coming round to batch files and CUSRMGR or a
    VBScript and CUSRMGR...I think I'll put an article together on that...
    Paul Williams [MVP], Mar 4, 2006
  10. agcastle2000

    Cary Shultz Guest


    Nice work. I will await the article for cusrmgr.
    Cary Shultz, Mar 4, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.