Welcome to the world of managing identities! Doesn't it sound fun? As system administrators, system engineers, and infrastructure engineers, we spend a significant amount of time every day managing identities in organizations. These identities can be user accounts, applications, or other resources. Over 15 years, Microsoft Active Directory has maintained its premier position in the market by helping organizations build their identity infrastructures. As a directory service, it stores an organization's identity data in a central repository and allows us to arrange it in a hierarchical organizational structure to satisfy the business' needs.

Over the years, Microsoft has been releasing a new version of Active Directory with new features and enhancements. For the last 12 years, I have worked on thousands of different Active Directory-related projects and answered lots of questions through my blog. For me, it's straightforward: providing a feature-rich product is not enough to maintain a secure, efficient, and reliable identity infrastructure. Just two Christmases ago, I gave a pack of watercolors to my little girl, Selena, as her present. I still remember the excitement in her eyes and how much fun it was trying different colors on a canvas and her Christmas dress. In the end, it was just a bunch of lines and color patches. This Christmas too, I (Santa) gave her a new drawing pad and watercolor pack. Now she knows how to draw different objects and place them nicely on the canvas and make something meaningful. It is practice, creativity, and guidance that have helped her do it. This book is meant to equip you with knowledge using in-depth analysis and best practices in order to use the Microsoft Active Directory service and its components in a secure, efficient way to address modern identity infrastructure requirements.

Even though this book is more for administrators and engineers who have basic knowledge of Active Directory, it is not a bad idea to re-read and refresh your memory about the building blocks of the Microsoft Active Directory service before we dive into advanced topics. In this chapter, you will learn the following:

• Benefits of using Active Directory
• Understanding Active Directory components
• Understanding Active Directory objects
• Active Directory server roles

A few years ago, I was working on an Active Directory restructuring project for a world-famous pharmaceutical company. According to the company policy, I had to travel to their headquarters to perform the project tasks. So, on a rare sunny English morning, I walked into the company's reception area. After I explained who I am and why I was there, the nice lady at the reception, Linda, handed me a set of forms to fill in. They asked for my personal details, such as name, phone number, how long I will be there, and in which department. Once I filled out the forms, I handed them over to Linda, and she had to make a few calls to verify whether my visit was expected and confirm my access to different buildings with the respective department managers. Then she made a card with my details and handed it over to me. She instructed me on how to use it and which buildings I was allowed into.

When you think about this process, you'll find that it contains the functions of a directory service:

• The forms that Linda handed over to me contained certain questions to help her understand who the person was. They were predefined questions and I had to answer them in order to register my information in their system.
• Once I submitted the forms, she didn't hand over the electronic card right away. She made calls to verify my identity and also confirm which buildings I would have access to. Then, my details were registered with the system, and it generated an electronic card that had my photo and a bar code. With that, I became a part of their system, and that particular card was my unique identity within their organization. There would be no other visitor with the same bar code and identification number at the same time.
• If I needed to get access to buildings, I needed to tap the card at the entrance. Could I use my name or any other cards to get through? No! The locking system of the building doors only recognized me if I presented the correct card. So, having a unique identity in their system was not enough; I needed to present it in the correct way to get the required access.
• I went to another building and tried to tap the card. Even when I used it correctly, the doors wouldn't open. The guard in the building asked for my card. Once I handed it over, he scanned it with a bar code reader and checked some information on his computer screen. Then he informed me that I was not allowed into that building and guided me to the correct building. This means that my information can be accessed from any building through their system to verify my identity and access permissions.
• When I used the card in the correct buildings, it allowed me to step in. In the system, it first verified my identity and then checked whether I was authorized to work in that facility. If I was authorized, the system allowed access; if not, it rejected my request to enter.
• When I entered and left the building, I did not have to record my time. But the managers in that department knew how many hours I had worked as my check-in and check-out times had been recorded in the system and they could review the information anytime.

This system acts as an authentication and authorization system. It uses different protocols and standards to manage and protect identities saved in a central database. This is the primary need of a directory service.

Every organization has its own organizational structure. The most common way is to group roles, assets, and responsibilities into different departments, such as sales, IT, production, and quality assurance. Apart from skills and knowledge, employers use company resources such as applications and hardware devices to achieve company goals. In order to use these resources efficiency, it's important to have some kind of access control in place. The resources should be available for the required users at the required time. This is very easy if all this data about users, applications, and resources is recorded in a central repository and uses authentication and authorization to manage resources. This is how the directory service was born. Different service providers have different directory services, for example, the Novell directory services, Oracle directory service, and Red Hat directory service. The Microsoft Active Directory service is the most commonly used directory service in modern enterprises.

Active Directory stores the identity information of users, applications, and resources in a multi-master database. This database is a file called ntds.dit. This database is based on Joint Engine Technology (JET) database engine. The data in this database can be modified using any alternative domain controller. The Active Directory database can store some 2 billion objects. Users can use the identity data stored in Active Directory from anywhere in the network in order to access resources. Administrators can manage authentication and authorization of the organizational identities from a centralized location. Without directory services, identities would be duplicated across different systems and add administrative overhead to manage.

There are organizations that use a single domain controller. But when it comes to complex business requirements such as branch offices, redundancy, it is required that they have multiple domain controllers (we are going to look at domain controller placement later in a different chapter). If the identities are managed from a centralized system, it's important that each domain controller be aware of the changes that have been made to the Active Directory database. Say, user Jane in the sales department forgets her password and requests the IT department to reset it. In 30 minutes' time, she's going to be working from a branch office located in a different city. The IT administrator resets her password from the headquarter's domain controller, DC01. In order to have a successful login from the branch office, this change to the directory needs to be replicated over to the domain controller in the branch office, DC05. Microsoft Active Directory has two types of replications. If a domain controller advertises the changes made on that particular domain controller to neighboring domain controllers, it is called outbound replication. If a domain controller accepts changes advertised by neighboring domain controllers, it called inbound replication. The replication connections (from who and to whom) and replication schedule can be modified based on the business requirements.

High availability is important for any business-critical system in an organization. This is applicable to domain controllers too. On other systems, in order to implement high availability, we need to make software or hardware changes. With built-in fault-tolerance capabilities, Active Directory domain controllers do not need additional changes. A multi-master database and replication of domain controllers allow users to continue with authentication and authorization from any available domain controller at any time.

Data and identity security are very important in modern businesses. We are living in a world where identity is the new perimeter. A significant portion of this book is focused on how to use Active Directory features to secure your identity infrastructures from emerging threats. Active Directory allows you to use different authentication types, group policies, and workflows to protect the resources in your network. Even applications benefit from these technologies and methodologies to secure the identities used within applications. This helps administrators build different security rules based on departments and groups in order to protect data and workloads. It also forces individuals to follow organizational data- and network-security standards.

Setting up advanced security policies will not be enough to protect your identity infrastructure. Periodic audits will help you understand new security threats. Active Directory allows you to capture and audit events occurring in your identity infrastructure. They can be related to user authentication, directory service modifications, or access violation. It also helps you collect data from a centralized location, which will help you troubleshoot authentication and authorization issues users may have.

In an organization, there are different applications in use. Each of these applications has a different authentication mechanism. It will be difficult to maintain different user credentials to authenticate on different applications. Most application vendors now support integration with Active Directory for authentication. This means that with Active Directory credentials, you can authenticate on different systems and applications used by your organization. You will not need to keep typing your credentials to get access. Once you authenticate on a computer, the same session will be used to authenticate other Active Directory integrated applications.

Any kind of database has its own structure, called schema. This is also applicable to an Active Directory database. This schema describes all objects in Active Directory. By knowing the schema, you can modify or extend it. This is important for the development of Active Directory integrated applications. Microsoft publishes Active Directory Service Interfaces (ADSI) with a set of COM interfaces, and it can be used to access Active Directory service features from different network providers. Application developers can use it to develop their application to be Active Directory-integrated and publish it to the directory. Users can search for the service through Active Directory, and applications can access Active Directory objects as required.

By maintaining a central data repository, Active Directory also allows users and applications to query objects and retrieve accurate data. If I need to find user John's account, I do not need to know which branch he is in or what department he belongs to. With a simple Active Directory query, I will be provided with information about the user account. In a manner similar to when we add a new object to the directory, objects will publish its attributes and make it available for users and applications for queries.

These are some of the main capabilities of the Active Directory service, and these features will be explained in detail in later chapters, including how to plan, implement, and maintain them within your identity infrastructure.

Active Directory components can be divided into two main categories:

• Logical components
• Physical components

When you design your identity infrastructure, you need to consider both components. Logical components of the Active Directory structure can change at any given time according to business requirements. But you won't be able to easily modify the physical components compared to logical components. The placement of these components will define the efficiency, security, reliability, and manageability of your identity infrastructure. So, it's crucial that we get it right in the beginning before we move on to advanced identity infrastructure planning.

Each business has its own hierarchical organization layout. It may contain multiple branch offices, multiple groups of companies, and many different departments. Each of these components in the business carries out different operations. Operations in the sales department are completely different from the IT department. Everyone is bound to the company by following different operational guidelines and targets. When we design the identity infrastructure, we need to match it with the company hierarchical layout in order to manage resource and security effectively. Logical components of the Active Directory help you structure the identity infrastructure by considering design, administration, extensibility, security, and scalability.

The Active Directory logical structure contains two types of objects. Objects can be either container objects or leaf objects. Container objects can be associated with other objects in the logical structure. Leaf objects are the smallest components in the logical structure. They will not have any other child objects associated.

Amazon is the world's largest rain forest. There are different animal species, and more than 400 tribes live in there. Each of these animal species is different from each other. Reptiles, mammals, snakes, fish all have different characteristics and we can group each of them by considering their characteristics. Tribes living in the forest also have their own language, culture, and boundaries. But all these animals and tribes share one forest. They use food, water, and other resources from the Amazon forest to survive. Amazon forests have well-defined boundaries. Another forest in 100 miles from an Amazon forest is not called an Amazon forest. Its name and boundaries are unique.

The Active Directory forest also can be explained in a similar way. The Active Directory forest represents a complete Active Directory instance. It is made of one or more domain and domain trees. I will be explaining what domain and domain trees are in detail later in this chapter. Each domain has its own characteristics, boundaries, and resources allocated. But at the same time, it shares a common logical structure, schema, and directory configuration within the forest. Similarly, tribes have a relationship with the forest and different tribes, and domains in the Active Directory forest will have a two-way trust relationship. Different tribes in the Amazon forest aren't named after Amazon. Each tribe have its own name. Similarly, domains in a forest can contain any domain name:

The first domain controller in the Active Directory service deployment is important. When you create the first domain, it will create the forest as well. Then, the first domain will become the forest root domain. A domain tree contains its own root domain. But forests can contain multiple root domains.

In the previous diagram, Rebeladmin Corp. is an IT solution provider. The rebeladmin.com is the forest root domain. It does have another two companies: one is Rebeladmin IT with the domain name rebeladminit.com, and it provides managed IT services. The other company is My training, with the domain name mytraining.ca, and it provides IT training to professionals. The rebeladminit.com and mytraining.ca both are root domains in their own domain trees. Both domains in the forest will trust each other with two-way transitive trust.

When Microsoft releases a new Active Directory service version, new features are bound to the forest and domain functional levels. If you want to use Active Directory Domain Services 2016 forest level features, your directory's Active Directory forest should use the Windows Server 2016 forest functional level. Before Windows Server 2012 R2, forest functional level upgrades were one-way. Now it is possible to roll back to the lower forest functional level if required. This is if the forest function level is lower it allowed to add the latest domain controller version. For example, if the forest function level is Windows Server 2008, it is allowed to install the domain controller inside the forest with the operating system Windows Server 2016. But this doesn't mean it can use features provided by Windows Directory Services 2016 until it upgrades its domain and forest functional levels. If you upgrade the forest function level to Windows Server 2016, you can have only domain controllers running a minimum of Windows Server 2016.

Referring back to my example about the Amazon forest, we can say there are more than 400 tribes living in the Amazon forest. Each of these tribes is unique in certain ways. Each tribe has a different language and culture. Each tribe has its own territory to do their hunting, farming, and fishing. Each tribe know its boundaries and does not cross others' boundaries as that can lead to a war between tribes. Each tribe has its own tools and methods for hunting and farming. Also, each tribe has different groups assigned for different tasks. Some are good at hunting, some are good at farming, and some are good at cooking. All their contribution help them survive and grow as a tribe.

The Active Directory domain too can be explained in a similar way. The domain contains the logical components to achieve administrative goals in the organization. By default, the domain become the security boundary for the objects inside it. Each object has its own administrative goals. Individuals in tribes have different identities and responsibilities, but all of them are part of the tribe and the forest. In the same way, all the objects in the domain are part of a common database. Also, everyone in the tribe still needs to follow some of the common rules. Objects in the domain are also controlled by the security rules defined. These security rules are only applicable within that particular domain and are not valid for any object outside the domain boundaries. A domain also allows you to set smaller administrative boundaries within the organization. In the previous section, I explained that a forest can contain multiple domains. Managing a forest is difficult as its administrative boundary is large, but the domain allows you to set smaller administrative targets. Active Directory is divided into multiple partitions to improve efficiency. The domain is also a partition of Active Directory. When I described the Active Directory forest, I had mentioned that every domain inside the forest shared the same schema. Each of the domain controllers also has a copy of the domain partition, and it is shared only by the domain controllers within the same domain tree. All the information about objects in that particular domain is saved in that domain partition. This ensures that only the required data is replicated across the domain trees and forests:

The Active Directory domain's functional levels define the Active Directory capabilities. With every new version of the directory services, new features are added to the domain's functional level. In order to use the features within the domain, the domain functional level need to be upgraded. The version of domain function level you can run on the domain depends on the forest functional level. You cannot have a domain functional level higher than the forest functional level.

I am 33 years old and am living in the UK with my daughter and wife. My parents are still living in Sri Lanka, where you can find sunshine all year and white beaches. After our wedding, I moved into new a house, but that didn't mean I was not a part of the family anymore. I am still the son of my parents. I carry my father's surname. I also inherit traditions and characteristics from my parents. My children will have their own families one day, but in the end, we all are part of the same family tree. A domain tree is a collection of domains that reflects the organization's structure. My parents and I are bound by a parent-child relationship. It is obviously different from other kinds of relationships. Similarly, domains inside the domain tree have a parent-child relationship. The first domain in the domain tree is called the parent domain. This is the root domain as well. All other domains in the domain tree are called the child domain. There will be only one parent domain in a domain tree.

In some documentations, the child domain is also called a subdomain. When dealing with internet domains, sometimes, it is required to create additional place holder, a sub URL. For example, rebeladmin.com is the domain name used for the website and organization needed to host another website in order to maintain support requests. But it needs to use the same contiguous namespace. To do that, we can create another folder in the domain root and create a DNS record for the support.rebeladmin.com subdomain:

An Active Directory forest, can contain non-contiguous domain names. But within the domain tree, it will share the same contiguous namespace. In the previous example, rebeladmin.com is the parent domain for the domain tree. It has two child domains, it.rebeladmin.com and sales.rebeladmin.com. As you can see, it shares the same rebeladmin.com namespace. Similarly, when it goes down in the next level in the domain tree, it shares the namespace from the preceding level. Each of the child domain maintains its own domain partition. This configuration data will be replicated only to the domain controllers in the same child domain. When the child domain is introduced to the domain tree, it will automatically create a trust relationship with the parent domain. If two child domains on different domain trees want to authenticate, authenticated traffic must pass through the forest root domains.

In the preceding section I explained, how we can group the objects using domains and forests. But within the organization, objects can be categorized into different groups considering the operations, organizational structure, geographical locations, or roles and responsibilities. As an example, organizations have multiple departments. We can convert each of these departments into child domains and group each of the department objects. But the child domain needs a separate domain controller as it will have a separate domain partition. Isn't there a better way to group these objects within the domain? That's where organizational units come in. Organizational units help group objects on a smaller scale within the domain. The most common way is to group objects that have similar security and administrative requirements together. For example, there are more than 50 users in the sales department. The sales department uses common shared folders and printers. Their security requirements for data and network are similar. We can create an organizational unit (OU) called sales and group and put all the sales department users into it. We can apply security policies to the OU level now instead of the user level.

When deploying a domain controller, it creates a default OU structure to segment the most common object types, such as users, computers, and domain controllers. The administrator can add, remove, and delete OU as required.

Once an object is assigned to an OU, it inherits security settings and permissions applied on the OU level. If the same object is moved to a different OU, then it will apply the settings from the new OU and discard the settings that were applied from the previous OU. Organization units also help delegate administrative control to individuals for specific tasks. Domain administrators have privileges to manage any objects within the domain. But it's possible to create administrators and assign them to manage objects and resources on an organization level. For these administrators, the OU will be the security boundary. They will not be able to modify any other objects outside that particular OU. I will be explaining delegated administration later in this book. Organizational units are container objects. They can be associated with similar or other objects. Similar to the domain parent-child relationship, OUs also can contain child OUs. These are also called nested organization units.

OUs also can contain object types such as users, groups, contacts, computers, organizational units, and printers:

In the previous example, Rebeladmin Corp. has a Sales department. In the OU hierarchy, the first thing you need to do is create an OU called Sales department. All the regional offices too have their own sales department. Most of the security and administrative requirements for objects in the sales department are the same. But creating OUs based on geographical areas will allow domain administrators to delegate control over those objects to individuals or groups in the regional office. Also, if a specific security policy needs to be applied to a regional office sales department, it can be applied on a relevant OU level rather than applying it to the entire Sales departments across the branch offices. All the child OUs inherit the permissions applied from its parent OU by default. In the previous example, individuals or groups who have permission to control Sales department objects have control over the objects in Europe, Asia, and North America OUs by default. The OU hierarchy is independent. It is not going to affect any other domain OU hierarchy. The OU also can contain objects from the same domain only.

In the previous section, I explained the logical components of the Active Directory. Now it's time to look into the physical components. Even though logical and physical components are equally important in the Active Directory Domain Service design, they are independent. Replication is the core feature of the Active Directory Domain Services. If a system has multiple domain controllers, changes made in one domain controller should be replicated to others. Physical component placement can affect Active Directory replications in certain ways. Logically, components can be easily rearranged compared to physical components.

The domain controller is a computer that runs a Windows Server operating system and holds the Active Directory Domain Services role. It can be either a physical server or a virtual server.

The domain controller holds the directory partition that will be replicated to the other domain controllers in the same domain. The domain can have any number of domain controllers. The number of domain controllers is dependent on the enterprise's size, geographical placement, and network segmentation. In Windows NT, it uses multiple domain controllers but it maintains a single-master schema.. This means that directory changes can be made from a specific domain controller only. After Windows 2000, there has been support for the multi-master mode. Any object-level changes made in one domain controller will be replicated to all other domain controllers (directory service-related). That said, some of the Active Directory-related operations role changes can be modified by the designated operation master role owner (FSMO roles) only.

The global catalog server holds the full writable copy of objects in its host domain and the partial copy of the objects in other domains in the same forest. The partial replica contains a copy of every object in the forest and the most commonly used attributes used by queries. Applications and users in one domain can query for the objects in another domain (same forest) via the global catalog server. All domain controllers in the domain will not be a global catalog server by default. When installing the first domain controller, it will become the global catalog server, and other domain controllers can promote them as global catalog servers according to business requirements. Every domain controller in the domain does not need to be a global catalog server.

The AD DS site defines a physical topology of the network. Sites can be separate buildings in a campus network and branch office in a separate city or even in a separate country. As an example, Rebeladmin Corp. has its head office located in London office, UK. It is running a few domain controllers (DC01 and DC02) within its physical network. It uses IP address allocation for the network with subnets 192.168.148.0/24, 10.10.10.0/24 and 172.25.16.0/24. Due to the business requirements, the company opened a branch office in Toronto, Canada. It got its own domain controllers (DC03 and DC04) running, but logically, it is in the same Active Directory forest and domain. Both networks are interconnected with a leased line. The Canada network uses IP subnets 10.11.11.0/24 and 172.0.2.0/24:

In the preceding diagram, the two offices can be called the two sites. This is because it is clearly two network segments. The Active Directory logical design does not really consider physical network segmentation. Since they are in the same domain and forest, DC01 to DC04 should replicate changes to each other in order to maintain a healthy identity infrastructure.

Mainly, there are three benefits we can identify:

• Replication: In a typical AD DS setup, all domain controllers are set to replicate changes between each other assuming all are connected via fast network links. But in the real world, they're not. Sometimes, connections between two sites are 256 kbps or 512 kbps. The same links will be used for other enterprise operations as well. Using AD DS sites, it's possible to perform bandwidth optimization and replication schedule changes for reliable replication across domain controllers.
• Service location: In the Active Directory setup, there are other services integrated that help in company operations, for example, Active Directory certificate services and exchange services. Using sites and the subnet setup, we can point users to the nearest server for the services. So, users in the Toronto site are severed by the Microsoft Exchange Server (mail server) in Toronto site when they try to access an email instead of passing the request to the site in London.
• Authentication: When a user logs in to the domain, they need to communicate with the domain controller for authentication. In the preceding example, a user on the Toronto site does not need to connect to a domain controller in the London site for authentication. AD DS sites will allow you to ensure that users in the Toronto site will use the nearest domain controller for authentication. This will reduce latency and bandwidth through the site links.

If we need to describe a person or thing, we use different adjectives. This can include personality, ethical background, physical appearance, or characteristics. Most of these are not unique. For example, when you talk about a 6-feet boy, there can be lots of 6-feet boys in the city. But it still explains the person that we're trying to describe is definitely not a girl. If we need to uniquely identify a person or thing, we need some unique attributes associated with them. If it's a person, the passport number, telephone number, or national insurance number will make the person unique from others. If it's a thing, the serial number or bar code associated with it makes it unique.

Within an organization, there are many physical entities. These can be either employees or resources. In order to manage those using Active Directory Domain Services, each of these physical entities needs to be presented to Active Directory. Active Directory will understand these entities as objects.

In Active Directory, there are two types of objects. Container objects can store other objects in the Active Directory. The domain itself is an example of a container object. The organizational unit is also a container object. Leaf objects cannot store other objects in Active Directory. A service account is an example of a leaf object.

As we use adjectives to describe a person or a thing, Active Directory objects needs attributes to describe their nature. For example, the following screenshot shows the wizard you will get when you create a new user account. In the wizard, in the following screenshot (left-hand side), First name, Last name, Full name, and User logon name are attributes. In the same way, when you create a computer account, it needs a Computer name attribute to describe it (right-hand side):

According to the preceding screenshot, depending on the object type, the associated attributes are changed as well. Also, it doesn't matter if you create one user object or hundreds of user objects in Active Directory; you still need to use the exact same attributes to describe the object you are creating. This is because each of the objects is attached to an object class. Within the Active Directory schema, it is defined which attributes are attached to each object class. When you sign up for the online service, the first time, it will provide you an online form to fill. At the backend, it is attached to a database. The information you provided will be recorded in the database for future use. If you need to sign up for the service, you must provide the answers to the questions that are asked. You cannot change the questions you need to answer because the database will not be able to understand it. The database got a table designed with columns, rows, and data types to store the data that will be captured from the form. Similarly, object class attributes are defined by a schema. Active Directory does have different types of object classes. Users, groups, computers, printers, and domain controllers are examples of object classes.

Some of these attributes are mandatory for object classes. For example, in user account creation, User logon name must be provided to continue. But if we do not provide the Last name, we can still proceed with user account creation. Attribute values also need to be provided with an acceptable data format that is defined by the schema. Sometimes, due to the operational requirements, organizations may require custom attributes. By modifying the Active Directory schema, it is possible to add additional attributes to the object classes. This will be demonstrated further in Chapter 7, Managing Active Directory Objects.

In a city or organization, there can be multiple people with the same name. But their passport number or national insurance number will be unique to them. So, in order to identify a person or thing accurately from a similar group, we need to consider the unique value associated.

In the Active Directory database, nearly 2 billion objects can be stored. How will it uniquely identify each and every object? Every time we create an object in Active Directory, it will be assigned with one or two unique values. If it is a user or group object, it will receive a globally unique identifier (GUID) and security identifier (SID). The GUID value will be saved in the objectGUID attribute in each object and the SID value will be saved in the objectSid attribute in each object.

In order to view the GUID and SID values for the user account, the following PowerShell command can be run from the domain controller:

Get-ADUser username

The username can be replaced by the actual username of the user.

In the following figure, ObjectGUID lists the GUID value and SID lists the SID value associated with the user account:

ObjectGUID is a 128-bit value and is applied to each and every object in Active Directory. This value is not just for the particular Active Directory domain. It is valid globally as well. Once a GUID is assigned to an object, it will be there until the object is deleted from the directory. Modifying or moving objects will not change the value of the GUID. The ObjectGUID attribute value will be published to global catalog servers. If an application in a domain needs to search for a user object, the best method will be to query using ObjectGUID as it will give an accurate result.

The SID value for an object is unique within its domain. The SID values associated with the user will be changed if the user object is migrated to another domain. An SID value assigned by one domain will not be accepted by another domain. As soon as a user object is migrated to another domain, a new SID value will be generated. Then, the old SID value will be saved in the sIDHistory attribute. This attribute can contain multiple values. When the system creates a Kerberos ticket for user authentication, it will consider a new SID value and all other SID values listed in the sIDHistory attribute. sIDHistory is important, especially in Active Directory restructuring. The resources in the domain decide access or deny permissions to a user account based on their access control list (ACL). This ACL uses the SID values. So, if an object moves to a different domain without sIDHistory , it will lose its access to resources until ACL is modified. But if the system considers sIDHistory when granting access token and if the old SID value is moved over to the new domain, the user is still allowed to access the resources he/she was assigned.

Distinguished names in Active Directory can also be used to identify an object uniquely. This is very similar to the way your postal address works. A postal address uses a hierarchical path to uniquely identify you. Starting from the country, it goes to province then to the city, street, and house number. The same way, using the full path to the object within the directory will help you uniquely identify an object.

There are three types of Active Directory naming attributes that have been used to generate distinguished names:

• organizationName (O) or organizationalUnitName (OU): Organization represents the root-level domain. The organization unit refers to the OU in which the object is located.
• domainComponent (DC): This is the naming attribute for the domain and the DNS. If the DNS name for the domain is rebeladmin.com, the domain component for it will be DC=rebeladmin,DC=com.
• commonName (CN): This refers to the objects and containers within the directory.

In the previous screenshot, when the query for the domain user is returned, the distinguished name for the user is as follows:

CN=Dishan Francis,CN=Users,DC=rebeladmin,DC=com

There, DC=rebeladmin,DC=com represents the domain name, CN=Users represents the user container, and at the end, CN=Dishan Francis represents the actual object name.

The relative distinguished name (RDN) is a unique value within its parent container. For the preceding example, the RDN for the object is CN=Dishan Francis. Active Directory allows you to have the same RDN for multiple objects within the directory, but all of them need to be in separate containers. It is not allowed to have the same RDN for the object within the same container.

In the previous section, you learned that the SID values for the object will not be changed unless it's migrated to a different domain controller. Changing values in the object will not modify the SID value. But if the hierarchical path got changed for an object, DN will be changed. For example, if you move a user object from one OU to another, the DN value for the user object will be changed.

There are five main Active Directory server roles. These roles are grouped together as the required Active Directory environment in order to set up and configure Active Directory server roles:

• Active Directory Domain Services (AD DS)
• Active Directory Federation Services (AD FS)
• Active Directory Lightweight Directory Services (AD LDS)
• Active Directory Rights Management Services (AD RMS)
• Active Directory Certificate Services (AD CS)

After Windows Server 2008, these roles can be installed and configured using Windows Server Manager. It is the same in Windows Server 2016:

Each of these server roles can also be installed and configured using PowerShell. The following PowerShell cmdlets can be used to install Active Directory server roles:

In the previous sections in this chapter, I explained what Active Directory and its components are. As a recap, I would like to list down some key points about AD DS:

• AD DS can manage an organization's resources in a secure, efficient manner, and it helps organize objects in a hierarchical structure.
• The Active Directory forest is an identity infrastructure security boundary and the forest can contain multiple domains with their own directory partitions.
• The Active Directory domain maintains a multi-master database to store data about objects and replicate it with other domain controllers in the domain. Any writable domain controller in the domain can add, modify, or delete objects from the Active Directory database, and other domain controllers will be aware of these changes.
• The organizational unit will be used to arrange objects in Active Directory in a hierarchical structure. It is also used to delegate permissions for administrative tasks.

With Windows Server 2008, Microsoft introduced a new type of domain controller called read-only domain controller (RODC). It allows organizations to have domain controllers in locations where data security and network security cannot be guaranteed.

Domain controllers contain a writable copy of the AD DS database. It is replicated among all the domain controllers in the same domain, but the read-only domain controller will have a read-only AD DS database.

This feature is useful in a branch network. Not every branch office of an organization can afford a fully blown network with a high-speed leased line, protected data center facility, and IT staff. If it's an Active Directory environment and if the branch office needs to be connected to the corporate environment, engineers will need to deploy the domain controller in the branch office network too. But if the branch office has limited connection to a corporate network, less IT resources, and poor physical data and network security, it can be a greater security threat to corporate networks by deploying a domain controller in that network. But deploying RODC will guarantee that the identity infrastructure security from such threats and users in the branch office will still be able to use the fast and reliable authentication and authorization capabilities of AD DS.

RODC holds a copy of Active Directory objects and attributes from writable domain controllers, except the account passwords. If any changes need to be done in objects, they need to be done in a writable domain controller. Sometimes, the branch office may host applications that need write capabilities to the directory services. These requests will be pointed to the writable domain controller instead of RODC.

AD FS allows you to share identities between trusted identity infrastructures based on a claim-based authorization (CBA) mechanism. Modern day organization workloads are complicated. Application service providers have shifted most of their applications to the cloud (SaaS). Also, organizations share web-based systems and applications between them for the operations. Almost all these systems need some kind of authentication and authorization process to allow users to access the applications or systems. This makes the identity infrastructure requirements complicated.

Rebeladmin Corp. is a manufacturing company. Northwood industrial is a partner company of Rebeladmin Corp. Rebeladmin Corp. has a web-based content management system to track sales leads, orders, and projects. As a partner company, sales users from Northwood industrial like to access this system. Both companies use their own identity infrastructures. An easy way to do this is to set up an Active Directory forest trust between two organizations. But that is an administration and security nightmare. If Rebeladmin Corp. has many partners, will it be practical to have a forest trust each and every organization? It also adds additional operational cost to facilitate secure communications links between organizations. It is only one application the partner company wants to access, but providing trust will open up additional security threats to the Rebeladmin Corp infrastructure. AD FS allows you to provide access to protected applications without any of these hazels. It will trust identities from completely different identity infrastructures and pass identity information as claims to the organization that hosts the applications. Then, the company that hosts the application will map these claims to claims that the application understands and make the authorization decisions. The important point here is that this process will be done with minimum changes to the infrastructure. Both organizations will keep maintaining their own identity infrastructures. Communication will happen only via an HTTPS protocol, and there will be no need to open up additional firewall ports between the organization's networks.

In normal scenarios, if you share a web-based system or application between two identity infrastructures, the partner organizations need to provides the two credentials. One credential is to authenticate it to their own infrastructure, and the second one is to authenticate it to the remote infrastructure. AD FS will allow users to have a single sign-on experience to the application.

Organizations today use more and more web-based applications. Some are for their own operations, and some are client-focused. If these are Active Directory-integrated applications, opening them to public internet can create security threats. AD FS can also be used to provide multi-factor authentication to web-based applications. AD FS can be hosted in demilitarized zone (DMZ) in the network, and it will be the only public-facing interface for the applications. Once users successfully have .

There are four AD FS role services:

• Federation service: The federation servers' hosted federation service will route authentication requests from identities in another identity infrastructure using a federated web single sign-on or from clients through the internet using the web single sign-on design method. These design options will be explained in detail in Chapter 13, Active Directory Federation Services.
• Federation Service Proxy: Federation proxy servers can be places in DMZ (the perimeter network segment) and forward claims to the federation service located in a secure network. This adds an additional layer of security for web-based applications.
• Claims-aware agent: AD FS uses claim to create trust between two identity infrastructures. The claims-aware agent can be used in the application web server to allow queries for AD FS claims. Then, the application will use claims in the AD FS security token to make the authorization decision.
• Windows Token-based Agent: This agent is to be installed on a web server that hosts Windows token-based application. It will convert the AD FS security token into the Windows access token, and the application will make an authorization decision based on that.

These federation roles can be installed on separate servers based on the organization's federation requirements.

My little girl Selena went to McDonald's more than average last month as she wanted to collect all kinds of different furby connect toys included in kids' meals. But when we go to McDonald's, we can't buy just the toy. Whether you're hungry or not, you still need to buy the kids' meal to get the toy.

Some applications require a directory-enabled environment to operate. But there is no need to be in a fully blown Active Directory environment. Microsoft developed AD LDS to enable data storage and retrieval for directory-enabled applications without the dependencies required for AD DS. When we deploy AD DS, it keeps its own directory partition and the schema inherited from the forest. If we need an additional directory partition, it is required that you deploy another domain or child domain, but AD LDS allows you to maintain an independent schema with each AD LDS instance. You can also host multiple AD LDS instances on one computer.

AD DS and AD LDS both are builds based on the same core directory service technologies. AD LDS does not need to depend on the Active Directory domain or forest setup. But in an AD DS environment, AD LDS can use AD DS for authentication.

AD RMS help organizations protect sensitive data getting unauthorized access.

Let's say Peter received a document that contains some sensitive data about company stock prices. Peter sends it to Liam. We know this should be a confidential conversation between Peter and Liam. How can we verify that this data has not been passed on to another user? What if someone gets a printed copy of this document? What if Liam edits this and adds some false information? Using AD RMS, you can prevent this kind of misuse of confidential corporate data. AD RMS can be used to encrypt managed identities and apply authorization policies to your files, emails, and presentations. This will prevent files from being copied, forwarded, or printed from unauthorized people. This also allows file expiration, and it will prevent users from viewing the data of a document over a period of time.

AD RMS contain two roles services:

• Active Directory Rights Management Server: This installs the AD RMS server service that requires you to protect the content in organization.
• Identity Federation Support: AD RMS service also supports integration with AD FS services. It will allow you to protect content between two organizations without setting up AD RMS in both infrastructures. This role service helps integrate AD RMS with AD FS.

AD CS helps organizations build public key infrastructure (PKI) in an easy, cost-effective way. Digital certificates issued by the certification authority can be used to authenticate users, computers, and devices. The certification authority is responsible for receiving certificate requests, verifying certificate requests, and issuing, renewing, and revoking certificates.

There are six role services for AD CS:

• Certification authority (CA): Mainly, there are two types of CAs. Microsoft named them root and subordinate CA. The placement of these on a network will be dependent on the PKI design. CA is responsible for issuing certificates to users, computers, and devices. It will also manage the validity of certificates.
• Certification Authority Web Enrollment: This is a web interface that connects to CA in order to allow users to submit certificate requests, retrieve issued certificates, and download the certificate chain.
• Online Responder: This will receive and respond to individual user requests to verify the status of digital certificates.
• Network Device Enrollment Service: This service allows non-domain joined network devices to obtain certificates.
• Certificate Enrollment Web Service: This role service works with Certificate Enrollment Policy Web Service and allows users and computers to perform certificate enrollment using HTTPS. It also allows certificate enrollment for domain computers or devices that are not connected to the domain and computers or devices that are not part of the domain.
• Certificate Enrollment Policy Web Service: This publishes the certificate enrollment policy information to users and computers.

This is the end of the introductory chapter on Active Directory fundamentals. I am sure most of you are already aware about most of the functions of AD DS. But refreshing your knowledge about Active Directory components and their operations before we deep dive into the advanced topics wasn't in vain. In this chapter, we also covered Active Directory objects, GUID and SID values, and DN. Later, I explained the Active Directory server roles and their core values.

In the next chapter, you will learn about new features and enhancements to AD DS 2016, specifically about the new approach to protect identities from modern security threats.