A Well-Designed Active Directory Model
by Rennie Araucto, MCT
Preparing to upgrade to Active Directory (AD)? Or are you one of the lucky few who will be establishing a "pristine" forest before migration? Either way, you are in for a potentially rude awakening if you have not put together a solid plan that involves a well thought-through AD model, and a thorough process for migration.
A little planning can go a long, long way, and AD is no exception. One of the many components to a successful implementation is designing an AD model. There are many nuances to this process that cannot be adequately addressed in this article, but I will outline the seven step process for putting together a well-designed AD model and if you want further information (here comes the sales plug), consider taking the 1561 Designing an AD Infrastructure course.
The key to developing an AD naming convention is to determine whether or not you have or plan to have an Internet Presence, and whether or not you have a current DNS infrastructure in place.
Your AD forest root name will be one of the following:
- A subdomain of the existing DNS name (ie. If your DNS domain name is netdesk.com, then your AD root could be ad.netdesk.com)
- The name for your DNS Domain is used for both internal resources and Internet resources. (ie. If your DNS domain name is netdesk.com, then your AD root would be netdesk.com)
- You choose a name that is different from your DNS domain name. (ie. If your DNS domain name is netdesk.com, then your AD root could be netdeskcorp.com)
When selecting your AD root name, consider all angles, including internal Internet access, DNS resolution and replication issues.
When considering the administration delegation model, consider how you can lower cost of ownership by delegating permissions to department heads and other groups that are not usually considered IT administration personnel. AD allows us to delegate permissions on a granular level. In other words, we can control rights all the way down to the attribute level. (I could assign my sister privileges to only modify the "Telephone Number" field for all user account in a specific OU. This is pretty granular.)
Consider the Who and What. Who can perform What tasks, and to which objects should they be able to perform them.
The Schema is very sensitive. Don't be cruel to it. Be mindful of who has the rights to modify it. Schema Admins is the one group you must be careful of. Whoever is in this group can alter the schema. In addition, if you are a member of Enterprise Admins or a member of the root Domain Admins, you can add yourself to the Schema Admins groups!
Consider developing a formal written policy addressing Schema modification.
Group Policy is one of my favorite aspects of Active Directory. Before designing your AD forest, get familiar with all the potential components of Group Policy. This will drive the creation of Group Policy and the creation of OUs!
Things to consider: Do you want Group Policy to be inherited? Do you want it to be filtered? Do you want it to be blocked? Become familiar with software publishing and assigning via GPOs. Learn about EFS, Domain Account Policy, Certificates, desktop configuration, scripts and folder redirection. These will all help to drive the creation of OUs and Group Policy.
Always assume you will only be using one domain. ("But I have 57 NT domains, doesn't that mean I should have the same number of domains in AD?" My answer: "Probably not.") Consider using multiple OUs. These provide just about the same amount of security and are easier to manage.
Refresh your understanding of A-G-DL-P. Leverage this model when assigning permissions to resources.
There are occasions when one domain will not be good enough for your forest model. In cases where existing one-way trusts MUST be maintained, or where Domain Account policy differs from one location to another, you may be forced into a multi-Domain model.
There are also occasions where your company may need to leverage different names for the domains. In cases where two companies merge and they want to maintain their individual identities, multiple domains are a must.
Sites are used to optimize replication and logon traffic. Users will attempt to authenticate to DCs that are within their own site first. In addition, replication within a Site occurs within 15 minutes by default. You use sites to limit replication to a defined schedule. Sites are typically mapped to the physical design of a network.
You should consider all the subnets and physical locations that exist in your environment and then map your sites to them.
There are certainly many more facets to the AD design process. What you see listed here is but a brief summary. Consider carefully your decision to move to AD, and take the 1561 class. It will save a lot of future headache and will provide you with the tools for a successful Active Directory rollout!