Design Active Directory as a database

This tip was submitted by member Carol Miller.

Most administrators, unless they also have exposure to and a knowledge of databases, may find Active Directory very cumbersome, complex and difficult to work with. Many administrators may not be able to manage Active Directory to it's full potential; instead being satisfied to do only the basics and use only the most minimal of features within the console.

Active Directory can be a very powerful yet easy tool to work with if approached in the correct fashion. Firstly, realize that the Active Directory is a database -- A relational database in fact. One that controls, keeps track of and monitors the objects within it. The only difference between the Active Directory and say, SQL Server, is the nature of the objects that it controls.

To properly plan your Active Directory structure, you must use the same principles that apply to a well-designed database. Firstly, know your company's needs. What is more important -- flexibility, control or security? Once this is established, determine how to physically and then virtually organize the objects.

The physical location of an object is obvious -- is it in Los Angeles or Toronto? The virtual aspect is much more difficult and largely depends upon how management will control it. It could fall under the control of the Los Angeles supervisor or the Seattle supervisor, contrary to its physical location.

Start by drawing

Requires Free Membership to View

out a rough schematic (on paper,) of what is perceived to be your structure based on the following: Security, physical location, virtual location, and management control. Then address the issues of scalability, delegation and movement within the Active Directory. Don't forget to address these issues within one domain, across trusted domains and across entire forests if necessary.

Once the structure is defined, address the issue of schema changes. If schema changes are to be required, do them as early in the deployment planning as possible. If Group Polices are required, structure them in such a way that they are loaded early in the boot up or log on for a computer or user. Avoid multiple layers of Group Policies that are performance pigs when loading and a nightmare to troubleshoot.

Keep the structure as 'thin' as possible. Create a document showing all the GPOs and where they apply. If a user is moved from one OU to another, will his/her GPO still apply? You need to address these kinds of issues. Name the objects within the Active Directory structure in such a way that they are easily attributed to their parent container or domain.

Keeping a well working database is simple, if planning is done and maintenance performed regularly. Treat your Active Directory deployment in a similar fashion, and you'll be well ahead of the game.

This was first published in February 2003

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.