With this chapter, we are moving towards the third part of this book, which focuses on the Active Directory server roles. There are mainly five Active Directory server roles:
- Active Directory Domain Services (AD DS)
- Active Directory Lightweight Directory Services (AD LDS)
- Active Directory Federation Services (AD FS)
- Active Directory Rights Management Services (AD RMS)
- Active Directory Certificate Services (AD CS)
We have already looked into many Active Directory components, features, and capabilities, but we are not quite done yet. This chapter is mainly focused on covering AD DS and the AD LDS related topics such as the following:
- AD LDS overview
- Active Directory replication
- Active Directory sites
- Active Directory database maintenance
- Read-only domain controllers in action
- AD DS backup and recovery
When we talk about Active Directory, we refer to it as a single service, but AD DS is attached to many other components as well. DNS, group policies, and the SYSVOL folder replication are a few example. Each of these components need to operate well in order to run a healthy Active Directory environment. It doesn't come easy; it involves investment on resources, time, and skills. In the Active Directory service, the core values are centralized identity management, authentication, and authorization capabilities. All these extra components make it easy to archive its core values, but at same time, it also opens up risks such as dependencies and security. The failure or compromise of these components/services will make impact on the entire Active Directory infrastructure.
Microsoft Windows Core and Nano Servers also count as operating systems. These don't have fancy GUIs or sparkly applications running. But they are still doing the job of an operating system. It allows users to build them from scratch according to their requirements. It also increases the server up time (less updates), reliability, performance, and security. Soon after Microsoft released the first Active Directory version, IT engineers, application developers, IT professional start requesting a cut down version of AD DS with pure LDAP capabilities. They wanted to eliminate all these dependencies and management requirements, so they could focus on application development upon core AD functions. After Windows Server 2003, Microsoft released Active Directory Application Mode (ADAM), which allowed administrators to run cut down version of Active Directory without group policies, file replication, and so on. It can run on a desktop computer or a member server similar to any other Windows service. Simultaneously, it was providing all the core values of the Active Directory service. With Windows Server 2008, Microsoft renamed it Active Directory Lightweight Directory Services and allowed users to install the role using Server Manager. This version provided more control and visibility to administrators to deploy and manage LDS instances. This was continued with all the AD DS versions after that and was included in Windows Server 2016 too.
Less dependencies, and less management of LDS extended its operation capabilities and in the following sections, I have listed several scenarios where we can use LDS.
This is the area that has benefited most from AD LDS capabilities. Application developments involve lots of experiments, tests, and demo systems. If these applications are Active Directory integrated, it is obvious that they need to be developed and tested within the Active Directory environment. During the process, it may be required to build many test environments. If it's full-blown AD DS instances, it will take resources, time, and efforts to deploy and maintain it. AD LDS allows you to run multiple instances of it within the same system independently. Each instance will have its own schema, and engineers can maintain the instance for each application test environments. Even it looks like cut down version and gives the same AD DS authentication and management capabilities so that engineers can easily adopt it. Since AD LDS instance allows to run on a desktop or server version of the operating system, it does have less prerequisites. Therefore, applications can also release with integrated LDS; for example, not every business runs Active Directory. Even though application functions are based on Active Directory features, it is still not easy to convince that everyone should have the Active Directory environment in order to run the application. Instead of this, the application installation can have an integrated LDS instance, and it will install it in the guest system as part of the installation process.
Nowadays, hosted applications, Software as a Service (SaaS), are a common business operation mode for lots of businesses. These services are normally deployed in the perimeter or in a public network. These applications also can have authentication requirements. But it is not recommended to install AD DS in the perimeter or public network. In such a situation, it is recommended to deploy AD FS to provide the federated access. But it still needs additional resources and skills to deploy and maintain. Instead of this, we can set up the AD LDS instance inside the perimeter/public network and provide the directory-enabled authentication service to applications. It doesn't have any connection with LAN or the other LDS instance in the perimeter network and provides a secured environment by design.
Most of the Active Directory integrated applications also require schema modifications. After this, the application will store certain datasets in the Active Directory database. If it's multiple applications, Active Directory schema and data continues to grow, it will make a significant impact on Active Directory replication. Especially if it's via slow links. Instead of storing data in Active Directory database, additional datasets of applications can be stored in LDS instance. It will still use AD DS for authentication. Additional datasets stored in the LDS instance will not replicate to any other domain controllers.
There can be environments and applications, which use legacy X.500 based directory services that like to migrate to AD DS. In such scenarios, AD LDS can be used as a middle man, which also can support X.500 ba...