building Active Directory groups and management

e24ohm · December 2008

Ok, i have a slight issue. i am playing around with my Active Directory server, and i need some insight/tips or anything anyone can think of.

how should i develop my AD structure? what works best in the real world? Currently i have a test server (win 2003) with 5 machines. Should i simulate a company enviornment and group machiens by departments? what do i do with user accounts? Should i group them by departments as well?

If any of you are ablet to talk about it, what do you do and what works best in real world.

thank you,
E

RTmarc · December 2008

I break my company down into two trees: Corporate and Branches. Corporate is broken down by departments and the branches are broken down by their location.

Always remember, loose to tight; especially when it comes to GPOs. Loose at the top and work your way down to restrictive.

dynamik · December 2008

To be honest, I wouldn't even worry about doing things according to best practices at that point (that's not to say you shouldn't take note of them as you come across them). Just dig in and play around. You'll learn a lot by messing things up or doing it wrong.

Are those physical machines or VMs? If they're VMs, just take a snapshot or make a backup of a clean installation that you can quickly revert to when you want to start over.

Claymoore · December 2008

This could be a very long discussion, so before we discuss 'how' we organize AD, let's talk about 'why' we organize it in the first place:

1. Delegation of Rights
2. Application of Group Policy

If you are the only admin or you have a very small team then you probably don't worry about delegation and just want AD organized so Group Policy works and is easy to understand. If you have offices across the country and/or departments that have some internal IT staff (even if it's only a designated user who can reset passwords) then Rights delegation matters.

Two common ways to break up OUs are:

1. Geographically
2. Organizationally

The Geographic method has the benefit of not changing very much - the New York office will always be the New York office even if it moves to another building. This method also works well if each office has their own staff because you can easily delegate administrative tasks. However, if each office has an Accounting department you now have a link to the Accounting GPO in each OU which can be a pain to keep track of. The Organizational method makes applying group policy easier but AD has to be updated every time the company has a reorg. Also if those departments are spread across multiple offices with their own IT staff it is more difficult to delegate permissions.

That was very simplistic, but it should get you started.

aordal · December 2008

Yeah when setting it up just have fun. If you take the 70-298 design exam you'll learn the different types of OU/Domain/Forest setups and what to look for when designing the AD. For testing purposes it really doesnt matter. I personally just have a Servers OU, Users OU and Workstations OU. I have <5 objects in each, I can't imagine you'll have much more than that in a test environment.

But to answer your question, each AD is structured after the culture of the business it's being used with. Have fun!

HeroPsycho · December 2008

Powershell script to create 500 users so you can play...

http://winserverteam.org.uk/blogs/austin/archive/2007/10/22/creating-test-ad-users-with-powershell.aspx

RTmarc · December 2008

dynamik wrote:

To be honest, I wouldn't even worry about doing things according to best practices at that point (that's not to say you shouldn't take note of them as you come across them). Just dig in and play around. You'll learn a lot by messing things up or doing it wrong.

Are those physical machines or VMs? If they're VMs, just take a snapshot or make a backup of a clean installation that you can quickly revert to when you want to start over.

I agree to a point. It is best to get in there and play around and break stuff but at the same time, laying the foundation to do things according to best practices is not something to balk at.

dynamik · December 2008

RTmarc wrote:

I agree to a point. It is best to get in there and play around and break stuff but at the same time, laying the foundation to do things according to best practices is not something to balk at.

I completely agree. That's what I was trying to get at with that little disclaimer in the parentheses, but you phrased it better

blargoe · December 2008

Over the years I've come to use delegation of authority pretty heavily in AD. If you have multiple tiers of techs supporting parts of Active Directory, it's a must to shy away from the built in groups and set up groups to which you delegate permissions such as only "reset passwords" or only "join computer to the domain".

For OU structure... every company is different, like someone else said it depends on the culture. However, I think I can generally say that it's a good practice to put in new, separate OU's all Server accounts and all user accounts that are used to run services, so security and group policy for these objects can be managed separately from regular "user" and "computer" accounts for employees of the company.

e24ohm · January 2009

wow, thank you all for the insight. All of your replys have helped and made me think. That is what learning is all about.

Ok i have one more question, which is sort of related. Say i have to replace a machine in corp. environment. Total machine in environment is 5, Do i increament the machine name example: ws002 was replaced with a newer machine (ws006), or do i just replace the machine and keep the same (ws005) id and take not of the serial and/or inventory tag. Blow off the account in AD and rejoin the machine to the network?

happy holidays and happy new year.

thanks
E

royal · January 2009

You can rejoin it with the same name. Both computers and users have a password. A computer has a hidden password which associates it with the computer object in AD. A user has a known password which you use to authenticate which as associated with your user object.

After 30 days of non-usage your computer account loses its relationship with the computer object. So if you have used the computer within 30 days, you can just rejoin it to the domain and all is well. If it's been more than 30 days and you want to join it with the same name, you reset the computer account (not deleting it) and then join it. This allows you to basically tell AD that you will be rejoining this computer account and reset yourself to allow it without having to delete the computer object which removes all the ACL information and AD information about that computer.

brad- · January 2009

For our PC's, we do by Location -- then by Department

For our users, we separate OU's by job types.

Thats what we do for about a 100 employee entity, 5 offices.

building Active Directory groups and management

Comments