Active Directiory® |
A Definitive Guide
Active Directory® has been the leading directory service for the past two decades, and it’s seemingly here to stay, in spite of Microsoft’s moves with Azure® Active Directory. So, understanding Active Directory (AD) and how to use it in the current identity and access management (IAM) landscape is critical. Of course, the quest to understanding Active Directory is no easy feat. We get that, so we’ve put together this definitive guide that will walk you through Active Directory fundamentals like why you should even consider using it, what it is, and how to get started.
Why Should I Care About Active Directory?
Active Directory is often the backing source of truth for identity management and helps organizations remain efficient, secure, and centralized. With modern organizations relying more heavily on their IT systems to remain competitive and successful, the role that Active Directory plays is only getting more important. When you add in the fact that identity theft is the top vector used to successfully breach a company and steal confidential data, you have yet another reason why AD is critical. Ultimately, AD not only benefits IT admins by making it easier for them to secure their networks, but it also benefits end-users by simplifying their access to Microsoft® backed IT resources.
Being able to centralize all resources on a network is powerful. It allows you to make a change and have that change instantly affect all of the resources you want it to. The alternative is making the desired change manually in each resource. If you have a small environment with a handful of resources and users, this may not seem like a big deal. The moment you surpass more than a handful of employees, a centralized environment can go a long way in helping you stay sane when it comes to tasks like resetting passwords, troubleshooting, and onboarding new hires.
A centralized environment also helps you eliminate shadow IT by giving you more visibility and control over who has access to what, what digital tools are actually being used, and how resources can be accessed. After all, if you’re not in control, that means end-users are. Letting users have control is not ideal because they will always prioritize convenience over security and unknowingly put the company’s digital kingdom at risk. Active Directory helps combat this by putting the control in IT admins’ hands while providing end-users with convenient access to their digital assets.
A centralized database of users, systems, applications, and other resources is a necessity for a company’s security posture. From password policies to the ability to dictate role-based access to resources, there’s a lot you can do to lock down your IT environment. Further, centralized user management means you can deprovision a terminated employee in a few clicks and suspend a pair of compromised credentials just as quickly.
We briefly touched on this in the centralized section, but Active Directory provides efficiency gains for IT admins and end-users. Because everything is centralized, IT admins can optimize processes to the point where they can spend less time on managing their environment and spend more time on mission-critical tasks.
Thanks to how it’s built, AD also makes it really easy for end-users to get access to the Microsoft-centric tools they use to get work done. While this is dependent on the tooling and integrations you are using, often times all a user has to do is log in to their workstation, and they have immediate access to their on-prem and cloud-based digital assets. This makes it a lot easier for them to simply focus on getting work done.
What is Active Directory?
Now that you have an idea of why AD is important to your organization’s success, what is Active Directory? The simplest way to think about Active Directory is to think of it as an information database and configuration management platform that is used as the source of truth to authorize, authenticate, and audit access to IT resources that AD is configured to control. Active Directory’s logical structure organizes this information, and if you can understand core concepts like AD’s logical structure, you’re well on your way to knowing just enough about AD to be dangerous.
Before we dive into Active Directory basics like objects and trees, we need to clarify something. Active Directory has been around for a long time. As such, it has evolved a great deal since it was first released with Windows® 2000 Server in 1999. When Microsoft released Windows Server 2008, they significantly evolved and updated Active Directory: It became an umbrella term for a portfolio of technologies used to carry out IAM on a Windows domain network. So today, when someone refers to centrally managing users and systems in their environment using AD, they’re really talking about Active Directory Domain Services® (which is configured to run on a domain controller by enabling the server role; thus it is also commonly referred to as the domain controller). This is the role we will be focusing on throughout this guide, and Active Directory will be used interchangeably with Active Directory Domain Services and Domain Controller (DC).
Core Active Directory Concepts
Below you’ll find explanations on key Active Directory concepts like objects, forests, Group Policy Objects (GPOs), and many others. Comprehending these components is a great way to start your quest in understanding Active Directory. We’ll start this section off with looking at key concepts related to Active Directory’s logical structure, and then we’ll end with explaining a core feature.
The smallest container or atomic unit in AD is an object. An object is any resource that is on the IT network, and users, groups, computers, printers, files, and applications are all possible objects. Additionally, each object has a set of required and optional attributes that describe the object, like what it is and where it’s located in the office.
Organizational units (OUs) are a way to organize a logical group of objects within a domain (see next section for definition). OUs are often used to denote specific departments, locations, teams, or functions. For example, when used to denote specific locations, you would have a United States OU, a Canada OU, a Netherlands OU, and so on. Each OU would hold all of the users that work in that location. Then, policies can be scoped to these specific OUs, which can include printer and drive mappings and security settings.
Not only do organizational units help organize objects, but they also enable IT admins to leverage the Just Enough Administration (JEA) model. The JEA model follows the principle of least privilege, meaning full access to a domain is only granted in a situation that requires that level of access. This means that someone in the Netherlands office could manage the objects within the Netherlands OU, but they wouldn't be able to do so for objects that exist outside of this OU. This can be incredibly helpful for IT admins because they can easily delegate certain tasks (like onboarding) to personnel at the Netherlands office while maintaining security. Plus, , the Netherlands location gains more autonomy in managing their users and access to resources.
Objects in Active Directory reside in an Active Directory domain. Access to this domain is gated by physical access to the network which the domain controller (defined in an upcoming section) lives on. Additionally, a domain defines the administrative boundary and the rules or security policies that all objects within the domain are subject to follow.
It’s important to note that a domain in Active Directory is different from a DNS domain. A DNS domain defines the name resolution between endpoints on a local network and their IP addresses on that particular network. Alternatively, an Active Directory domain is the network that a domain controller broadcasts DNS domain services on, and devices connected to this domain at the network layer rely on the domain controller for a number of services.
Active Directory can be configured to support more than one domain and to support subdomains (also called child domains). When Active Directory is configured to support a domain and subdomain, such as “microsoft.com” and “azure.microsoft.com” (known as a contiguous DNS namespace) this creates a tree. Alternatively, an organization can have Active Directory domains that do not share the same name, such as “microsoft.com” and “github.com”. This creates multiple trees, which are collectively referred to as a forest when the two trees are managed within the same domain. We’ll discuss trees and forests in greater detail in the coming sections.
Domain Name Service (DNS) is the naming system we use on the internet; microsoft.com is an example of a domain name. Microsoft decided to build Active Directory services on DNS by using DNS to translate host names to IP addresses in Active Directory. This lets humans search for resources using names instead of IP addresses.
A domain controller is a Windows server that runs Active Directory Domain Services (AD DS). As soon as the AD DS role is added to a Windows Server, that server gets promoted to a domain controller. Windows servers without this role are often referred to as member servers within the domain environment. Remember, Active Directory used to be one solution that carried out the same functions as AD DS. So today, Active Directory, domain controllers, and Active Directory Domain Services are often used interchangeably.
So what does a domain controller do? For end-user authentication, each domain controller holds a replicated copy of the Active Directory database. When a change occurs in the Active Directory database, each domain controller updates its copy of the database. A domain controller will then use this database to authenticate users to the network and use it to determine what users can or cannot access. A domain always has at least one domain controller.
A group of domains that use the same DNS namespace make a tree. In a tree, the first domain that is created is called the root domain (or parent domain) and any domains created after within the same namespace are referred to as subdomains (or child domains). See figure 1 for a visual representation.
So why would you need to have separate domains? You would add a subdomain to a root domain anytime a group of users and resources needed to follow a different set of security policies, required segregated network connectivity, or needed separate domains for legal reasons. For instance, let’s use Amazon as an example for this. Amazon offers many different services; from their cloud computing offering with AWS® to their online shopping platform, they do a lot. AWS, for instance, probably requires different security policies than their online shopping platform. As such, you would create a subdomain for the AWS service called aws.amazon.com, with amazon.com being the root domain. We demonstrate this in Figure 1 as well. Then all you have to do is configure the subdomain according to the necessary requirements.
By default, a transitive trust relationship is created between all domains in a tree. This means users in amazon.com can access resources in advertising.amazon.com (as long as they have the right to access the resources) and vice versa. If transitive trust is unnecessary, there’s also the option to create explicit trust, which means users in amazon.com can access resources in aws.amazon.com, but the users in aws.amazon.com wouldn’t be able to access resources in the amazon.com domain.
Additionally, an organization can have multiple trees. This occurs when they have multiple domains that don’t share the same DNS namespace. A couple of common scenarios for this would include examples like: when a company creates a new business that is part of the same entity but has a separate DNS namespace or when an organization acquires a company. Amazon created quite a few different entities that still fall under the Amazon umbrella. Audible is one example that has their own domain, but they are considered an Amazon Company. Remember when Amazon acquired Whole Foods? That's an example of a company acquisition. Like Figure 1 demonstrates, if they were both using Active Directory they would have one tree with all of the amazon.com domains and another tree with all of the wholefoods.com domains. They would start sharing the same schema, global catalog, logical structure, and directory configuration while they each had their own Active Directory database.
A forest is the top most logical container in Active Directory. It is a collection of root domains (or multiple trees) that share the same schema and global catalog. The first root domain created determines the configuration and schema for a forest. Just like domains within a tree have a trust relationship, all domains within a forest have a trust relationship as well. Automatically, it is a transitive trust relationship.
While not best practice, you can run into situations where you have multiple forests. Take a look at Figure 2 for a visual representation of what multiple forests looks like. In this case, each forest has its own schema, global catalog, configuration partition, etc. If you would like forests to share resources, you can manually create a transitive trust relationship at the forest level by establishing it between the root domains. If you need to share access to web-based applications, consider looking into Active Directory Federation Services® (AD FS). AD FS makes it possible for users in one forest to use their existing AD identities to access web-based applications that are in another Active Directory forest. If AD FS wasn’t in place, there would be a lot of back and forth between the IT admins in each organization to set up the necessary user accounts. Additionally, the authentication process would be cumbersome for end-users, and they would have another set of credentials to remember.
However, creating multiple forests should not be a decision you come to lightly. Ideally, you stick to having a single forest as much as possible because it’s a simpler solution in the long term and is typically considered best practice. When you have more than one forest, managing your schema becomes more complex.
A global catalog acts as an index for an entire Active Directory forest, and it stores key information about every object in a forest. This lets IT admins and users find and access a resource regardless of which domain it is located in, as long as they have the right to access it. Without a global catalog, end-users would have to know exactly which domain the resource is located in order to find it. When a server becomes a domain controller, the global catalog server, by default, is added too. If you only have one domain controller (not best practice), then you definitely want to add a global catalog to it. When you have multiple domain controllers, you can choose which domain controllers have a global catalog and which ones don’t. In general, it’s ideal to have a global catalog on each domain controller. Doing so will streamline network traffic and make it faster for people to find what they’re looking for.
The schema is the overarching data model that dictates how information is structured in Active Directory. Another way to think about it is it that it is the blueprint that lays the groundwork for what resources can be added to the directory and what information is needed when they’re added to Active Directory. The schema also determines where the data resides in the database and how people can access that information if they need it programmatically. It also makes it possible for AD to know where the data is so that it can access the information.
Group Policy is a feature in Active Directory that lets you apply settings and enforce policies on managed resources at various levels of granularity. With Group Policy Objects (GPOs), you can determine who has administrator rights, disable outdated protocols, and prevent users from accessing system settings. You can also use GPOs to centrally deploy updates, patches, and software; to centrally enforce password policies like how long and complex they need to be; to streamline the process of setting up new users on the network; and that’s really the tip of the iceberg of how beneficial and impactful GPOs can be for your IT environment. It’s one reason why Active Directory is the go-to directory service, and it’s one of the most sought-after features in Active Directory.
11 Tips on How to Effectively Get Started with Active Directory
Getting started with Active Directory can seem daunting, but if you follow the 11 tips below, you’ll get a handle on Active Directory in no time. While these tips offer some practical advice on how to successfully get started with Active Directory, it is highly recommended that you take the time to skim (if not read) the documentation and training material that is available on this core piece of technology. The material provides the in-depth information that is needed to truly become an Active Directory master.
Tip 1: Take your time on gathering information and analyzing your requirements
There’s a high probability that Active Directory will already be running at most of the places you work. It’s been around that long. On the off chance you get to set it up from the ground up, it’s important that you take the time to think about why you are implementing Active Directory and if it is the right fit for your organization’s IT needs. You should have clear business and technical goals that are driving the decision to do so. Below are a few prompts you can use to start thinking about this from a business and technical perspective.
Gathering Information on Your Business Goals:
- What priorities does your company have? Will an Active Directory implementation push the company closer and faster to reaching those priorities or get in the way?
- What IT resources does your company need to secure?
- Are there plans to significantly change your technology stack in the future? Like moving everything to the cloud?
- What are the plans for growth? Which departments will likely have the most aggressive hiring plans?
- Are there any laws or regulations you’ll need to comply with?
- What security requirements/needs does your organization have?
- How much does the company spend (in both people-power and money) to provide IT services to the company? Will Active Directory optimize this spending?
- What business processes does the company use to conduct its daily operations? How does the IT infrastructure support those processes?
Gathering Information on Your Technical Environment:
- What kind of digital tools are people using to get work done? Are there mostly Windows systems? What kind of applications are they using?
- Given a choice, what kind of tools do employees actually want to use to complete their work?
- Are the digital tools hosted on local servers, or are they cloud-based?
- What systems do you need Active Directory to integrate with? Can it support those?
- What does your existing network topology look like?
- How many users work remotely, work from home, or work part time?
- Are there any existing directories?
Tip 2: Plan your domain structure and stick to it
As your organization grows and changes, it can be tempting to change your Active Directory structure (such as user/group naming conventions). This is not recommended. Instead, when you design your Active Directory architecture, try and account for any future growth or other company plans that could impact your directory service design.
Tip 3: Keep it Simple
Just because you can do something in AD doesn’t mean you should. Wherever possible, just try to keep things simple. In the long run, sticking to simplicity will improve efficiency and make the troubleshooting process easier whenever problems arise. For example, if there’s an opportunity to organize your objects in 3 OUs instead of 5, do it. Additionally, don’t go crazy with nesting OUs within OUs. Creating a complex OU hierarchy will lead to confusion and may lead to issues when configuring and deploying policies. So aim for simplicity as much as you can.
Tip 4: Make sure to plan how you’re going to manage AD
There’s a lot that goes on in the background to keep Active Directory running seamlessly every day—enough that it requires at least a full-time, dedicated person to run AD and more personnel if you have a larger organization. As such, you need to have a plan in place for how you’re going to do this. Try and have an answer for these questions:
- Who will administer AD?
- Will it be one person, or will it be an entire team?
- How will responsibilities be divided if it’s an entire team?
Tip 5: Thoroughly test your AD environment before deploying it to the company
Before you go live with your new AD implementation, make sure you test it. Doing so will help you catch any bugs or errors that would otherwise disrupt someone’s workday, if not everyone’s workday.
Tip 6: Use dedicated domain controllers
Don’t be cheap and try to have a domain controller that also acts as a file server and mail server. Adding additional roles to a domain controller can affect the server’s performance, reduce security, and complicate the process of backing up or restoring the server.
Tip 7: Have at least two domain controllers and two DNS servers
Domain controllers are at the heart of authenticating and authorizing users to the tools they need to get work done. They are also what generally serves up DNS services, a service AD is completely dependent on. If you only have one of each and they fail, AD will stop working. When AD stops working, everybody in your company stops working too because they can’t access their resources. To best avoid this single point of failure, have at least two domain controllers and two DNS servers.
Tip 8: Avoid placing all of your virtualized domain controllers on a single host server
Similar to tip 7, you want to avoid having all of your virtualized domain controllers in one host server because this also creates a single point of failure. If that single host server fails for whatever reason, all of your domain controllers will fail too. So try to disperse your virtual domain controllers across at least two host servers.
Speaking of failing infrastructure, make sure on-prem hardware in your IT environment is stored in a secure, climate-controlled place. This can go a long way in preventing a hardware failure on your end. After all, in this day and age, any network downtime comes at a very high cost.
Tip 9: Place at least one domain controller and one global catalog server in each site
If your Active Directory instance includes multiple sites, consider having a local domain controller and global catalog server at each one. This will make it easier and faster for users at each site to authenticate and find the resources they need. Sometimes, a site doesn’t have enough users to justify the cost of having its own DC server. This will slow performance, but what you can do instead is designate a DC wherever your other AD hardware is kept and then make sure the WAN connection between the site and the domain controller is reliable.
Tip 10: Ensure your AD server complies with the necessary compliance regulations
Compliance regulations like PCI, HIPAA, and others have requirements on how data is stored, how data is accessed, who has access to certain types of data, and many other regulations that your AD server will have to meet. Not meeting compliance requirements can result in fines and other legal action.
Tip 11: Tightly control who has access to your domain and who is an admin
It is a best security practice to employ principles of least privilege where your Active Directory domain is concerned (giving someone just the right amount of access that they need to do their job and nothing more). By limiting who has access to a domain, you significantly reduce the attack surface for intruders. The same goes for how many people have admin rights. Limit the number of people who have admin rights to as few as possible.
Active Directory in 2019
Despite being 20 years old, Active Directory is still a strong contender in the directory services space in 2019. But, 20 years is a long time in any industry, especially in the technology world, and a lot has changed. Although it shines in the IAM space, Active Directory has its moments where its age is apparent. For organizations shifting to the cloud and adopting heterogeneous infrastructure, they’ve felt the challenges of having an on-prem homogenous directory service like Active Directory. We’ll explore both sides of this coin, and we’ll start by taking a look at where AD shines.
AD is a powerful directory service even in 2019. It is the defacto directory for managing a traditional network with a defined perimeter domain. If you mainly use Microsoft technology and are largely on-prem, Active Directory is a great way to secure and optimize user and system management in your organization. You’ll gain the benefits of centralization, security, and efficiency that are mentioned near the beginning of this piece.
The Shift to the Cloud
Cloud technology has taken off in the last ten years, and it has enabled organizations to make great improvements in their productivity, time to market, and IT cost savings. So, it should come as no surprise that the cloud is now a key component in most companies' IT strategy. In fact, a 2019 RightScale survey reported that 94 percent of respondents use the cloud in some way.
Sadly, Active Directory gets in the way of an all-cloud strategy because it wasn’t designed for a cloud-forward world. AD requires on-prem connectivity, and it’s not the easiest to integrate with cloud technology. For example, it often requires costly and complex networking to connect cloud-hosted domain controllers with an online resource.
Microsoft has released Azure® Active Directory®, but it is not a cloud replacement to Active Directory. Instead, it can be used in conjunction with Active Directory to connect AD identities to Microsoft’s cloud services like Azure and Office 365™. Consequently, organizations have had to keep one foot on-prem and one in the clouds, minimizing the digital transformation and the benefits of adopting the cloud in their company.
The Move to Heterogeneous Infrastructure
While there are plenty of organizations that are still Windows-based, many are taking a more heterogeneous approach to their technology and allowing employees to work from the operating system that they are most comfortable and productive on. In one study from Ponemon, 47 percent of IT professionals surveyed reported a top challenge in cloud migration is the complexity and diversity of IT systems and technology.
Microsoft hasn’t adapted AD to natively integrate with non-Microsoft tools like Mac® and Linux® systems, web-based applications, and other modern IT resources. As a result, IT organizations have had to resort to manual management of said resources, no management, or add on third party tools. With any of those options, IT admins have had to relinquish some of the ease, security, and efficiency they once had with AD when tasked with managing mixed environments.
Tips for Overcoming the Challenges
As it became clear that these changes in the IT landscape were here to stay, solutions started to emerge to help address some of these difficulties with Active Directory.
When web-based applications started to sky-rocket in use, single sign-on providers emerged to help connect Active Directory to this new technology. If web-based applications are the only new tool to have made their way to your IT environment, an SSO solution can be a great way to simplify users access to them.
Identity bridges are another handy tool that you can add on to Active Directory to gain better control over resources like Mac systems. They can be expensive, and they’re not the smoothest piece of technology, but they are a step up from manually managing resources or not managing them at all.
Cloud Identity Bridges
Cloud identity bridges take the concept of an identity bridge and make it more powerful. A cloud identity bridge will integrate with Active Directory and extend AD identities to non-Windows IT resources. What sets a cloud identity bridge apart from an identity bridge is that a cloud identity bridge will also have the capability to act as an identity provider, independent of AD. In other words, a cloud identity bridge can act as your sole identity management solution because it’s not dependent on AD to be the identity provider.
A cloud identity bridge is great for those who need to hang onto their AD instance for a while longer but may want to move to an entirely cloud-based identity management solution. Not only will they have their cloud AD replacement nailed down, but in the meantime they will also be able to connect AD identities to any non-Microsoft resources they have in the mix like Mac and Linux systems, web-based applications, Samba file servers, VPN and WiFi networks, and more.
Cloud-based Identity Provider
Of course, some organizations are ready to eliminate Active Directory from their IT environment. If that sounds like you, you can use an Active Directory migration utility to fully migrate to a cloud-based identity provider and skip the AD integration. A cloud-based identity provider can authorize, authenticate, and audit access to virtually any IT resource regardless of platform, provider, and location because it leverages web-based, cloud-forward protocols. You’ll still be able to continue managing your Microsoft-based tools, but you’ll gain the ability to centrally manage non-Windows resources too—all from the cloud, all from one solution.
Congrats! Now, you know so much more about Active Directory than when you first started reading. You are aware that Active Directory impacts how fast everyone is able to work and whether or not they are doing so securely. You also have a better idea on how information is organized in Active Directory and how to successfully get started using AD. Lastly, you are walking away familiar with the advantages and challenges with using Active Directory in 2019 and how to overcome its difficulties.
In all honesty, your quest toward knowing Active Directory has just begun. There are many more mountains of knowledge that you will have to ascend if you are interested in mastering this technology. The good news is if you keep on persisting, you’ll get there! If you’re ready to continue the quest, read this ultimate FAQ on Active Directory. Interested in talking to someone about what you read? Contact us, and we’ll gladly help you in any way we can.