Having a basic understand of Active Directory is a quint essential skill for any IT professional, and anyone that has gone out job hunting knows that most employers ask for some experience on Active Directory.
That said, I’ll try my best to explain Active Directory as simply. Brace yourself, because I will use a lot of analogies.
So before I go on explaining what Active Directory is, I need to explain why we need it for. Why was it invented? And why is it used by so many companies out there that they want people to know this. For this, we must understand authentication.
Authentication is the process of verifying your identity before you are allowed to use a resource.
When you enter your password before using your computer, and your computer allows you to continue, that’s a successful authentication. Authentication happens in real life as well, such as when you use your passport to come into a foreign country.
In this article, we are concerned with two types of authentication – LOCAL vs CENTRAL.
Think of the following scenario: you’ve just bought a Windows laptop from your favorite electronics store. When you take it home and turn it on, it guides you through the process of entering your personal information and creating a USERNAME and PASSWORD. Then you use this user name and this password to log in and use the computer. All is cool…
Now, let us pretend your laptop is stolen and you never get it back, so you have to end up buying another one. When you turn on this new laptop, the username and the password you created to use your previous laptop WILL NOT work on your new laptop. This is because of LOCAL AUTHENTICATION. Your new computer has an internal database where it stores usernames and passwords for users of that computer only, therefore it doesn’t have the username and password of the laptop that was stolen from you.
Think of it as car keys — your keys are only LOCAL to your car, and no other. If you wanted to get on other cars, you need other keys.
So what if instead of every device having a internal database, we have one central, godly database all devices to go when needing to authenticate a user? This is CENTRAL AUTHENTICATION.
Now think of this scenario: you are an Army chief warrant officer and head of IT in the command. You need to enable all of the infantry soldiers to use their ID number to open doors in the HQ, turn on their vehicles, use army equipment, punch in their Usere and even fire their weapons.
So if we were to use local authentication to make this happen, this means every single device and object that requires authentication to use has to have a local database containing ID numbers. If Pvt. John Doe wants to fire his gun, his gun must recognize his ID number, compare it to its internal database and let him use it. But having a local, internal database for every single thing has some problems…
• Maintaining all databases synchronized and updated – Say Pvt. Jane Doe, who was recently attached to her unit, is being shot at. Her M4 jams and she needs to use a fellow soldier’s M4…but the local database on her mate’s M4 is not updated with her ID number and therefore it won’t fire. And such is the case for her mate’s other equipment as well…
• It is a security issue to have so many copies of a database around — again, every rifle out there has a local database with the ID numbers of every soldier authorized to fire it. If one rifle falls into the wrong hands, they could obtain that list of IDs and do wrong with it. Even worse, they can reverse engineer the authentication method, steal one of the IDs and forge it so they can escalate privileges with one of these IDs.
Active Directory is a “central” database containing people’s information that will be used to authenticate them. In this case, every soldier’s information will reside in Active Directory – and every Usere any soldier wants to fire his or her rifle, the rifle will consult Active Directory to ensure the person pulling the trigger is in fact a soldier.
Active Directory also has computers and other resources in its database, and besides authentication, it can also do AUTHORIZATION. To keep things simple, I will not go over those.
In a more realistic example, many organizations and businesses use Active Directory to store employee information. Employees that want to use company resources must authenticate to Active Directory before going any further. IT administrators use Active Directory to maintain order in the organization. More specifically, it is an all-Usere favorite way to enforce the AAA protocol. The AAA protocol stands for Authentication, Authorization and Accounting.
Authentication – as we just discussed, it is the process of verifying someone’s identity before proceeding.
Authorization – is the process of verifying whether the authenticated person is AUTHORIZED to use the resource.
Accounting – is the process of documenting the authenticated and authorized person has accessed the resource.
So Active Directory has some core components. First and foremost, every Active Directory structure has to one a domain controller. A domain controller a server that takes care of managing Active Directory, including hosting its database and handling the authorization, authentication and accounting mechanisms. Domain controllers typically run Windows Server 2003, although more and more we’re starting to see companies transition to Windows Server 2008 R2.
To make a server a domain controller, it must have Active Directory Domain Services installed as a role, as the screenshot below demonstrates.

So now that we understand what Active Directory is used for and the problems that it solves when it comes to implementing the AAA protocol, we should now become familiar with the inner structure of Active Directory, which are forests and domains.
Ever thought why an e-mail address has the “@website.com” suffix? Well, domains KIND OF have something to do with it but I don’t want to deviate too much off subject. Back in the 60s, computers could only send messages to users of its OWN system. So once they developed the technology to send messages between systems, they used @ sign next to the system name to differentiate users and systems. So it would kind of look like this User@SystemA is sending a message to User@SystemB.
So in general IT terminology, a domain is a collection of resources. Let’s say you were the founder of Facebook and you started with 100 employees and 100 computers, 1 website and 1 email server. All of those resources would belong inside Facebook.com. That is the domain name.
In Active Directory terminology, things are a little different. Using the same example above, your Facebook.com would be the FOREST name, or top-level domain. Why is this? Because Active Directory lets you create domains inside domains and a collection of domains is called a FOREST. Let’s say you expand Facebook to Europe and EU law requires you to have all European employees records physically stored in Europe, not in the US. So with Active Directory, you can create a domain inside Facebook.com and call it Europe. Facebook.com – then assign servers, computers and users inside this “Europe” domain, and the domain controller for the European domain would be physically stored in Europe. Problem solved.
Graphically speaking, this is what a Forest looks like. The domains inside the forest reflect company departments, not geographical locations.

Active Directory Forest with Domains and sub-domains inside of it. From personal experience, I’ve seen companies create their domains based off geographical locations rather than organizational departments, but I guess it all depends on how big the organization is.
Another tool that is very popular with managing Active Directory is a snap-in called ACTIVE DIRECTORY USERS AND COMPUTERS.

Active Directory Users and Computers with Advanced Features turned on
As we can see on the screenshot above, we are basically looking at what is inside the ZAP.com domain. In AD terminology, those folders under “zap.com” are known as Organizational Units, or OUs. The ones you see are the default OUs created by Active Directory.
OUs are very, very, very important and an extremely essential part of Active Directory. As discussed earlier, an Active Directory administrator has the option of splitting his organization in geographical locations, departments or even both. This is because of OUs. OUs are nested inside domains.
You can create a domain in your forest that is reserved only for employees of a certain location, and within that domain, create OUs that are for each department or each area inside that location. In this example, I’m going to create a domain for my MIAMI employees inside ZAP.com.
Once the domain has been created, from Users and Computers, I can just change domains. I’m currently in the ZAP.com domain and I’m going to go to MIAMI.zap.com – which is a domain within ZAP.com

I am now inside MIAMI.ZAP.COM – a domain created only for MIAMI employees of ZAP corporation. Now, let’s create OUs for every location in MIAMI where there is a ZAP office.

Locations within MIAMI site
So now I’ve created 5 OUs for each of my Miami sites of ZAP corporation (Kendall, Hialeah, Coral Gables, Brickell, Sunrise). But they are empty? Aren’t we forgetting what OUs are for??

So I have created four more OUs inside of Kendall: one for users, one for computers (my users will be using), one for servers and one for groups. Now you may be asking yourself, why are you creating groups? What are groups for?
Groups in Active Directory allow you to implement the AAA protocol a lot easier. Quick example: my Kendall office has 3 Marketing and 2 Research and Development employees working in there, so I will create two more OUs inside Users – Marketing and R&D.

Now, I want to create the users inside the Marketing and R&D OUs.

Cool…so to demonstrate what groups are for, let’s pretend the company has a file server where all of the Kendall work documents are stored.

Miami, Kendall, File Server

Inside the Kendall File server showing the file folders
We want to make sure the users in R&D department can only read documents in the R&D folder. So if Bob Dole from Marketing goes into the file server, he will NOT be able to access the R&D folder since he is not in the R&D department. For this, I have to create a group that grants access to R&D users only.

Group created…now it’s Usere to add R&D people into the group.

Voila! Note the name of the group – it is always important to be very descriptive of what the group is for on it’s name. Now users from R&D OU have been added to the group that lets them in the R&D folder in the file server.
Now we have to go to the file server and bind the folder to the group we’ve just created.

Boom! there it is…it’s showing that for the R&D folder, anyone that belongs inside the “full-control-R&D-file-server group” is allowed and has full control of the documents inside.
So basically, OUs let us be more granular with the organization – and place users, computers, groups in them. They let us organize things in a certain way so we can then apply policies and protocols to the OUs.
The reason why things are so complex (and cumbersome for some) is due to business needs. As you just saw, different groups and locations have different business needs, and Active Directory allows an administrator to provide to these business needs. Even though this has been a pretty lengthy article, believe it or not this is a very skimmed and speedy introduction to Active Directory, and I’ve skipped a lot of other terms.
The best way to learn Active Directory is to use it. Plain and simple, but one of the issues with getting hands on experience on Active Directory is finding a job where entry-level IT professionals are allowed to touch it, which are not too many (most job openings out there require you to have experience already).
So if you do not have experience in AD you but want hands on experience, I suggest doing a couple of things:
• Read books and articles about Active Directory. Even articles like these help (I hope!)
• Install a copy of Windows Server on a virtual machine on your computer. You can download a free copy off Technet (if you have a Technet subscription).
• If you have an entry-level IT job, talk to your senior administrators. Ask them to show you the ropes. I know some of them are stingy and don’t like to teach or show anything, but others will. Show that you want to learn and don’t be scared not to know.
• Watch YouTube videos and training nuggets on Active Directory Domain Services and basics. Again, I know a lot of people do a better of at explaining AD than I do.

Understanding Active Directory
Active Directory is an implementation of Internet standard directory and naming protocols. It uses a database engine for transactional support and supports a variety of application programming interface standards.
This section covers:
• Securing Active Directory
• Access control in Active Directory
• Active Directory naming
• Directory data store
• Directory access protocol
• User and computer accounts
• Object names
• Organizational units
• Active Directory server roles
• Active Directory clients
• Understanding Domains and Forests
• Understanding Groups
• Understanding Trusts
• Understanding Sites and Replication
• Understanding the Global Catalog
• Interoperating with DNS and Group Policy
• Understanding Schema

Send your feedbacks

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s