BLOG

Best Practices when Deploying an Active Directory

Setting up a perfect Active Directory (AD) that will stand the test of time is not as easy as it sounds. Not only do you have to think about the current state of the organization but you also need to plan for future changes. To help you get started I’ll be going through the basics about setting up an Active Directory.

What is Active Directory – Server Academy

Establish a plan and stick to it

First of all, take your time and set out a proper plan. A lot of people dive in headfirst when setting up their Active Directory despite a clear plan, path or objective. We suggest that you take some time beforehand to map out the current state of your IT-environment. How many users and machines do you have? How many different departments are there? What are their different needs?

Having the answer to these types of questions will make the rest of the process much easier. While you are at it, take some time and try to map the needs for the future. You might not be able to predict exactly how big your Active Directory will be in the future, but you can try to put some governance in place to dictate the structure nonetheless.

Keep it simple

Before setting up your Active Directory, remember to keep things simple. The Active Directory is designed to be flexible and consists of numerous settings, object types and components. Even though these functions can prove useful, keeping your Active Directory as simple as possible will help improve overall efficiency. It will also make the troubleshooting process easier if problems arise.

Hardware set up

Now, let’s move on to the hardware. The backbone of the Active Directory are the domain controllers. The primary responsibility of the domain controllers are to authenticate and validate user access on the network. To ensure service in a timely fashion it is critical to accommodate redundancy by deploying a sufficient number of domain controllers.

Memory Space

An important attribute of the Active Directory domain controllers are their memory space. It’s usually recommended to provide twice as much memory as the AD database size on the disk. This is however quite excessive as only a fraction of the AD database will be used frequently. To provide less memory can in many cases be more efficient since it allows the memory to only cache the most frequently accessed parts of the AD.

With enough memory, the Active Directory server is far less dependent on disk access and the system’s performance is vastly improved. The result is a faster, problem free authentication for users.

The organization and location of the AD files are also important since spreading out the disk access ensures that AD data files, AD data recovery files and operating system files are not fighting over the same spindle. The best results will be achieved if the AD folder is located onto a different physical volume from the AD log folder and the operating system files.

Management plan

A management plan has to be established before starting up the domain controllers. A management plan lays out the responsibilities of the AD and whose job it is to take care of them. Questions that need to be adressed are: Who will administrate the Active Directory? Will it be managed by a single person or a team? Will responsibilities be divided by domains or organizational units?

Naming conventions

Predetermined standards and routines should guide the creation and modification of objects. This means having a pre-established policy or guideline that AD managers know by heart. Standardizing the names of AD objects will make troubleshooting much easier.

Let’s go through some popular naming convention choices for some common objects in the AD.

Users

Let’s take the user “Tom Johnsson” as an example. One of the most popular options is taking the first letter of the first name + last name, resulting in the username: tjohnsson. It works well and is pretty easy to understand, but you may run into some problems when another coworker with identical initials needs a username. Therefore it can be beneficial to use the full first and last name leading to the user name tom.johnsson. However, if several Tom Johnssons are hired to the organization the initials of their middle names can be added to the username (tom.b.johnsson) to separate them. Overall avoid using numbers and department names on user accounts as these are confusing and subject to change.

Groups

There are many ways to name your groups but a tip is to follow this template:
Department + resource + group type + permissions.

Start off with the department name. This could be HR=HR, Marketing = MR or Legal = LE. Then add a short name describing what the group is used for. Then add a prefix for the type of the group, i.e. if it’s a Domain local = L, Global = G or Universal = U.

Let’s take an example. The helpdesk staff need rights to reset passwords. The name of the security group would be: Helpdesk-PasswordReset-G

Computers, servers and other Active Directory objects

Simple structures should apply for other objects in the AD and could be structured as:

Type + department/ location code + asset#

Type refers to resource type, some naming examples are:

W = Workstation, L = Laptop, P = Printer, S = Server and so on.

The department or location of the object can be named as follows:

HR = Human Resources, MR = Marketing or SWE = Sweden.

The name of the object can conclude with a number, as you will probably have several laptops and printers in the same department or location.

The result of the naming convention can look like this:

Laptop in the HR department asset# 1235 will get the name L-HR-1235.

More Architecture Tips

Separate users and computers
According to a Microsoft best practice, avoid lumping users and computers into the same Organizational Unit (OU).

Create an OU for security groups
In order to quickly access security groups you can create an OU for this purpose.

Create an OU for servers
As servers often have group policies that only apply to them, adding them to their own OU simplifies the process of applying policies.

Add descriptions to Active Directory objects
Even with a proper naming convention, it can still be hard to understand the use for certain groups, users and so on. Make it a habit to always add a description to your objects. But please avoid putting any passwords or other sensitive information in the descriptions.

Summary

If you are interested in investigating how your own Active Directory is set up, vScope and the Active Directory Documentation pack can help. You can quickly gain insight into the setup of your environment, connections between users and groups and much more. Combined with the Active Directory Optimization & Security pack you can transform and improve your AD. All of these Report Packs can be found in vScope Directory that can be licensed on vScope Inventory & Discovery.

If you still have an urge to dig deeper I can recommend the books Active Directory: Designing, Deploying, and Running Active Directory and Mastering Active Directory.