Active Directory! Help!
What the heck is Active Directory (AD) anyway? I know the first time I was learning about Active Directory it scared the crap out of me.
I felt like an ant under the foot of an snotty nosed fifth grader. The sheer weight of the system was crushing.
That’s why in this guide I’m going slice through the confusion and help you understand Active Directory in detail.
After reading this series you’ll know:
- The purpose of Active Directory (why do we even have it?)
- How Active Directory is structured
- All about objects and why we need them
- How to install Active Directory and joining our first PC to our Domain Controller.
There’s a lot to cover and I know this can be a boring topic. But I promise if you stick with me you’ll really understand everything you need to get going with this wonderful tool.
You might even laugh a few times while learning lol.
Let’s talk about why we even need Active Directory.
Let’s say you’re a motivated, entrepreneur. You borrowed a bunch of cash from your rich relatives and maxed out all your credit cards with a massive cash advance so you could start your dream company:
Keeping smelly feet fresh with special odor resistant socks.
You decide to call your company SmocksSocks because your last name is Smocks and you like the alliteration. Your company name also sounds like Spock and since you like Star Trek too it’s a fortuitous coincidence.
After registering your company you realize you’re going to need a SQL Server 2012 database to store all your orders and invoices. You’re also going to need a Microsoft Exchange Server to handle email for your employees. Finally, you want a File Server so the various departments can exchange files on the corporate local area network (LAN).
What’s the point?
Without Active Directory, you would have to setup unique accounts on each server. So users would need a separate Exchange Server account, SQL Server account and File Server account. This would be a headache for your to manage and a pain in the butt for your users.
Think about it: Each account could have its own settings for password complexity and expiration dates. Furthermore, if you grow the company to the point where you need to connect various vendor and partner networks, what’s to stop those guys from having their own unique account requirements?
With Active Directory in Windows Server 2012 R2, you can have users authenticate to a single server, the Windows 2012 server, and then using a technology called Kerberos, the server creates a ticket that vouches for that users rights and privileges on the network.
The user would have a Single-Sign On (SSO) which would let him connect to all the resources in your company that you’ve granted him permission to access. Active Directory gives you one account for everything in your company.
You could also setup a trust relationship with your partner’s Active Directory setup so that you can create a single user account in your Windows 2012 server and automatically grant that user access to authorized resources on the partners network too. There’s no need for duplicate accounts. Active Directory makes management a heck of a lot easier and more efficient.
That’s really the chief reason for using Active Directory. You can also make anything searchable. So physical resources such as printers and file servers will show up in a global catalog.
Alright now that you have that background under your belt, let me show you Active Directory is structured.
The Sensible Structure of Active Directory
So what exactly is Active Directory?
Do you want the long answer or short answer?
Ahh, I know you have errands to run, interviews to go on and women to date so I’ll be brief:
Active Directory is a file.
Yup, ultimately Active Directory is a NT Directory Services file called NTDS.DIT. Any users, groups and computers you add to Active Directory ultimately end up in this file. It’s just a database of all your objects. (I’ll talk about objects in a bit)
Here are some more Active Directory facts:
- It’s based on the Lightweight Directory Access Protocol (LDAP) which is an open, vendor neutral protocol for managing network resources.
- AD relies on tickets instead of passwords. This is how it can authenticate users without transmitting passwords through the network. The ticket is what gives users access to various resources in the domain.
- AD doesn’t live on an island. In fact, if you can have multiple synchronized Active Directory servers, called Domain Controllers all exchanging information with each other. The synchronization piece is really important because if one server has one set of details for user Elmo and the other server has a different set of details for that same user then poor Elmo might not be able to access the corporate network.
- Active Directory is a communal creature. If it were a person, he would be the most gregarious guy at the cocktail party. AD loves to interact with other domains (and groups of domains called Forests). You can setup such interactions called Trusts and Federations.
Looking at the Topology
Every Active Directory server must have a domain. When you go to fixedbyvonnie.com/about, fixedbyvonnie.com is called the domain name of the website. In the same way, Active Directory needs a domain name but the difference is that it doesn’t need to be internet facing. You just need a way for internal hosts to access the domain controller. Usually the name reflects the company name. It can be anything, even an invalid domain name that ends in .local or .iamthebest.
So here’s the deal:
Since you’re a creative entrepreneur with a peculiar penchant for fresh socks, you’re going to name your Active Directory Domain Controller smocksocks.com.
Incidentally, as you probably already guessed, DNS is built into Active Directory which is why it uses the DNS naming convention.
You always need at least a single domain with at least one domain controller but you can always setup more.
For example, you can have smocksocks.com as your parent domain and research.smocksocks.com and labs.smocksocks.com as your two child domains. All these domains would live in the same management space so they would be considered a forest.
The interesting thing about forests is that even a single domain is considered a forest.
So smocksocks.com is a forest even though it is just a single domain and any branches you create off the parent domain become child domains in that forest. Just think of the forest as the totality of your Active Directory infrastructure.
So let’s say the accretion rate of your employees doubles every month, revenue is surging and your company is getting courted by big investors on Wall Street.
After many sleepless nights, you decide that given the amount of free cash flow you have and the trajectory where you want to take the company, it makes sense to buy out your competitor: StinkyUnderwearz.com.
They specialize in selling funky undies as pranks and practical jokes. The company is doing well and you wisely decide to buy it.
So here’s the thing: StinkyUnderwearz also has an Active Directory forest with its own set of objects and resources.
Is there a way to merge Stinky into your Socks?
Smocksocks and StinkyUnderwearz.com can become one with Trust Relationships. You can setup a trust relationship between both forests so that all resources are shared. Or if you wanted to, you could setup a Federation which would implicitly trust not only the parent domains but any and all child domains in each forest. So a user in Smocksocks.com with the correct permissions could access any child domain in StinkyUnderwearz without having to create a new account.
The object of your desire
I’ve got news for you:
Active Directory is utterly impotent without objects.
You need objects to make Active Directory useful. Thank God understanding and creating objects is super easy.
There are five main types of objects you need to be cognizant of:
- Site Links
Users are exactly what they sound like: User accounts. You can a user account for Elmo and set permissions to specific resources. Elmo can then use that account to access all the resources you’ve allowed in the forest. All he needs is that one account to start being productive.
Groups are convenient “folders” for Users. So you can grant users access based on group memberships. You could create the Active Directory Group object, give it a name like “Legal” and the dump all the lying loonies from the legal department in there.
Computers can appear as objects when you join workstations to your domain controller.
Users, Groups and Computers are the triumvirate of Active Directory. This is probably what you’ll spend most of your time configuring and using. As your Smocksocks organization burgeons, you’ll soon discover that there are simply too many users and groups to manage. So Active Directory lets you create Organizational Units (OU’s) which are like super containers for objects. They make it easier to find things and generally keep you from losing your mind.
Before we finish up I should discuss two other objects:
Sites and Site Links.
So here’s the scenario:
Business is booming. After the media coverage from the StinkyUnderwearz merger and acquisition, Wall Street is overvaluing your company and your stock prices are ballooning.
You decide now is a prime time to open a branch office so after months of arduous research you land on Atlanta, Georgia.
Why? Because you love Georgia peaches.
So you open a small office there and setup a Windows Server 2012 computer running Active Directory. Since the network subnet for your Atlanta office is different than your New York City office, Active Directory sees both cities as two different Sites.
A Site is just an IP range and the Site Link is the Wide Area Network (WAN) that connects both locations. Both Sites and Site Links are represented as objects in Active Directory.
The main reason you would create two sites rather than just dumping all your Atlanta objects into your New York domain controller is to cut down on replication traffic.
The Bottom Line
So that my friend is Active Directory in a nutshell.
In the next guide I’m going to walk you through installing Active Directory on a Windows Server 2012 R2 machine. We’ll configure our server roles, setup Active Directory Domain Services, Promote our server to a Domain Controller and a whole lot more.
I’ll see you tomorrow.