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.