The Covid-19 pandemic has heightened our sense of uncertainty as humans over physical and mental health, economy, family, society, and work. Most of us have experienced long-lasting effects on our lives that we never envisioned. Some of these profound effects may drag our lives backward or forward by years. A paradigm shift hastened by the pandemic is the accelerated digital transformation of society. The lockdown rules and increased demand for secure remote work has pushed some "offline" businesses and industries into the "online" realm sooner than we thought. My nine-year-old daughter is having her piano lessons via Zoom meetings now. I never thought it was practical to learn an instrument "online" but I was proven wrong. At the beginning of the pandemic, the financial sector wasn't ready to embrace the working from home culture. But a recent survey carried out by Deloitte confirms almost three quarters (70%) of employees working in financial services rate their working from home experience as positive. (Source: https://bit.ly/3CSjC08) Twilio is a leading cloud communications and customer engagement platform. They recently surveyed over 2,500 enterprise decision makers in the United States, the United Kingdom, Germany, Australia, France, Spain, Italy, Japan, and Singapore to evaluate their views on digital transformation as a result of Covid-19. According to the survey results, "97% of enterprise decision makers believe the pandemic sped up their company's digital transformation." (Source: https://bit.ly/2ZSnTlK.) McKinsey & Company is an American worldwide management consulting firm and they recently did a survey using 900 C-level executives and senior managers representing the full range of regions, industries, company sizes, and functional specialties. According to the study, respondents confirmed their companies acted 20 to 25 times faster than expected in implementing digital transformation strategies. When it comes to remote working, companies moved 40 times faster.

Figure 1.1: Speed of responses to pandemic challenges

Source: https://mck.co/2Ykj9Fd

With the rise of digital transformation, working from home has become the new normal. Businesses have had to implement applications, services, and collaboration tools that allow remote workers to carry out their day-to-day tasks seamlessly. On this journey, the hurdle wasn't the investment or the technology.

It was the "time." This was the same for many businesses when adopting this ubiquitous nature of operations. When "time" starts to cost us money or when "time" starts to affect sales, the manufacturing process, supplies, or workforce productivity, we do not have time to evaluate all the pros and cons. We do not have time to do all the ground work. We will have to take risks. We will have to bend the rules. When we rush things, as humans, we tend to make mistakes. Some of these mistakes opened up opportunities for cyber criminals throughout 2020:

• According to iomart, large-scale data breaches increased 273% in the first quarter of 2020. (Source: https://bit.ly/3mNckFB)
• Data from the UK's Information Commissioner's Office (ICO) confirms 90% of cyber data breaches were caused by user errors. (Source: https://bit.ly/3whpgGV)
• According to RiskBased Security's 2020 Q3 report (Source: https://bit.ly/3mMxjbu), healthcare (11.5%) and IT (10.3%) are the two industries that reported the most data breaches. Also, we know these industries have been the most active industries during the pandemic.
• The report also says, when we consider all of the breaches in 2020, that 29% of those exposed passwords, 36% exposed email addresses, and 45% exposed names.

If we summarize the above findings, we can see there was a massive increase in data breaches in 2020 and the majority of those breaches were due to human error. The healthcare and IT industries have been the top targets financially motivating cyber criminals in 2020. The above data also confirms cyber criminals are mainly after identities.

Identity is the new perimeter. The perimeter defense model is no longer valid against modern identity threats. Identity and access management is the cornerstone of digital transformation. A study done by Ping Identity says 90% of IT decision makers believe identity and access management is the key enabler of digital transformation (Source: https://bit.ly/3BNw0gS). Identity and access management solutions depend on directory services such as Windows Active Directory to store/retrieve data relating to user identities. Windows Active Directory was first released on February 17, 2000, and for 21 years it has been helping organizations to manage identities. But now we have a new set of challenges.

According to FireEye's Cyber Security Predictions 2021 report (https://bit.ly/3nZBpfQ), about 95% of companies have some type of cloud presence.

So the questions are:

1. How can we allow users to use the same Active Directory user accounts to access cloud resources?
2. How can we enable a single sign-on (SSO) experience for cloud-based applications?
3. How can we protect identities when they start to appear in cloud and unsecured networks?
4. How can we maintain compliance when we start using cloud resources?
5. How can we detect/handle a potential breach?

To address the above questions, we need a distributed, highly available identity and access management solution such as Azure Active Directory. It doesn't mean Azure Active Directory is a replacement for Windows Active Directory. These are two different products with many different characteristics. But these two solutions can work together to address access and security challenges in both worlds (On-prem and the cloud). In this edition, you will find many topics and a lot of content related to hybrid identity. Also, throughout the book, content will be positioned to accentuate the importance of identity protection.

What is an Identity?

Elephants are truly fascinating creatures. Female elephants stay in their herd for life. When a baby elephant is born, young female elephants in the herd will help the mother to take care of the baby. A baby elephant usually weighs about 250 pounds and is three feet tall. In the beginning, a baby elephant can't see clearly. But it can identify its mother among the other young female elephants by touch, smell, and sound. Social insects such as ants recognize various castes in their colony based on "ant body odor." The same method is also used to recognize ants from other colonies.

When it comes to humans, we use many different ways to uniquely identify a person. In day-to-day life, we recognize people based on their name, face, voice, smell, body language, uniforms, and so on. The uniqueness of individuals describes an "identity." However, if we need to prove our identity, we need to use formal methods of identification such as a passport, driving license, and residence card. These formal methods are well recognized by many authorities. So far, we have talked about physical identity. But how can we bring this to the digital world? To do that, we need our digital identity to represent our physical identity.

As an example, when I registered with my GP for the first time, they checked a form of identification and verified my identity. Then they issued me with a unique NHS number; this unique number is the way their computer system will recognize me. When I signed up for my broadband connection, the service provider asked me to set up a unique password. This password will be used to prove my identity when I call them for support next time. Different systems, applications, and services uses different methods to verify someone's digital identity. These systems use databases and directories to store the data related to digital identities.

It is also important to remember a digital identity does not always represent a human. It can represent other entities such as devices, applications, services, groups, and organizations. Digital identities are also becoming more and more dynamic. As an example, your Facebook profile represents a digital identity. It keeps updating based on pictures you upload, posts you share, and friends you make. It is a living identity. A digital identity can get frequently updated based on attributes and access privileges. Nowadays, we can see different systems allow users to use one form of digital identity to get access. As an example, a Microsoft account can be used to access on-prem applications as well as SaaS applications. These federated digital identities provide a better consumer experience. The Active Directory service is capable of managing digital identities as well as federated digital identities.

Before we go and look into Active Directory fundamentals, I think it is better to share some of the identity and access management trends that lie ahead of us in 2021 and see how Active Directory will fit in to the picture.

In the previous two sections, I used the words "identity and access management" a few times. What exactly does identity and access management mean? Identity and access management is a solution used to regulate the "access life cycle" of a user within an organization. The main role of it is to make sure the right person has the right access to the right resources for the right reason. Identity and access management solutions mainly have four components.

1. A directory which stores user identity data (directory service)
2. A set of tools to provision, modify, and delete users and privileges
3. A service to regulate access and privileges using policies and workflows
4. A system for auditing and reporting

According to the above definition, Active Directory is not an identity and access management system. But it plays a major role in an identity and access management system. The directory element of an identity and access management system doesn't represent Microsoft Active Directory only, it could be any directory. But we know that the most commonly used directory service on the market is Microsoft Active Directory. The success of an IAM solution depends on all four pillars that I mentioned before. As I explained in the introduction, IAM is the key enabler of digital transformation. So what does the future look like for IAM in 2021 and beyond.

The Rise of Cybercrime

It's been a roller-coaster year for most of us. With the Covid-19 pandemic, uncertainty is all around us. That's changed the future for us in many ways. You may have had to reorganize your priorities and push back some of your plans years. On top of that, we have all had to do a lot to maintain our mental health. Cyber criminals are also humans. So we might think that the pandemic has also struck a blow to their activities. But it seems it hasn't. They seem to have found opportunities even during a pandemic. Instead of a reduction in cybercrime, we have seen a huge increase in the number of incidents. The FBI says it saw a 300% increase in cybercrime in 2020 (Source: https://bit.ly/3o3uguL). When it comes to the healthcare industry, we would expect some dignity as it has been a lifeline during the pandemic. But for criminals, it was just another opportunity. Verizon's Data Breach Investigations Report 2020 (https://vz.to/3CQvPCL) confirms a 58% increase in data breaches in the healthcare industry and the majority of them were financially motivated attacks. Also, these attacks are getting more sophisticated day by day. The recent Nobelium attack is a great example of that. SolarWinds Inc. is a software company that develops solutions to monitor and manage network devices, servers, storage, and applications. On December 12, 2020, they announced a sophisticated attack on their Orion platform. This affected 18,000 SolarWinds customers, including the US departments of Commerce, Defense, Energy, Homeland Security, State, and Health. This attack was one of the biggest cyber incidents the public has witnessed in years. According to Microsoft (https://bit.ly/3q6wSec), 44% of victims of this attack were in the IT industry and 18% were government institutions. This attack marked a milestone in cybercrimes due to the following reasons:

• Instead of attacking high-profile targets directly, the attackers chose a common "supplier" as the target.
• The attackers gained access to SolarWinds back in September 2019.
• The attackers did a dry run with the October 2019 version of the Orion platform to test their ability to include malicious code in a software build.
• The attackers injected malicious code into SolarWinds.Orion.Core.BusinessLayer.dll on February 20, 2020.
• SolarWinds updates with this malicious code were available to customers from March 26, 2020.
• The attackers removed malicious code from the SolarWinds environment on June 2020.
• According to a FireEye report (https://bit.ly/3ER8Isq), the initial dormant period of the attack could have been up to 2 weeks. This means even if your system had the malicious code, you wouldn't have noticed anything immediately.
• On a compromised system, attackers were able to initiate jobs such as transferring files/data to third-party servers, executing files, collecting information about the system including credentials, rebooting the server, and disabling system services.
• Once attackers had credentials, they moved laterally through on-prem systems to gain access to ADFS (Active Directory Federation Server).
• Once the attackers had privileges to create SAML tokens, they used them to access cloud services such as Microsoft 365.
• The SolarWinds attack was the first occasion when the Golden SAML attack method was used.

This particular attack taught us a few things:

• The importance of the zero trust security approach – The zero trust approach to cybersecurity is not only to prevent a breach but also to prevent lateral movement if there is a breach. We always have to assume a breach. More details about the zero trust approach will be discussed later on in this section.
• Target on-prem to gain access to cloud resources – In this attack, cyber criminals gained privileges to access the ADFS environment to create SAML tokens. These tokens allowed them to access cloud services without a password. Typically, businesses are more focused on protecting cloud resources, but this attack proves we need to think about the whole access life cycle.

All attacks have something in common. They are all after some sort of "access" to systems first.

It could be a username and password, certificate, or even an SAML token. Once attackers have initial access, then they start to laterally move until they have access to accounts with privileges, which can help them to do their tasks such as stealing data, causing disruptions, or conducting espionage. So it is a greater challenge for IAM to protect digital identities from these rising cybercrimes.

However, in the fight against cybercrime, organizations have to overcome some other challenges as well. According to the COVID-19 on Enterprise IT Security Teams Report issued by (ISC)² (https://bit.ly/3mLiJkq), organizations face the following challenges:

• About 20% of enterprises were forced to reduce their IT security operations budgets this year.
• 36.4% of IT security organizations froze hiring during the pandemic.
• 31.5% of IT security organizations reduced the work hours of engineers.
• 25.1% used temporary furlough methods to reduce operation costs.
• 21.7% of IT security organizations reduced the salary of engineers during the pandemic.
• 17.4% of IT security organizations reduced the number of staff with layoffs.

We already have a huge skill shortage in cybersecurity. Covid-19 has had a negative financial impact on some businesses. Because of that, businesses will have difficulties funding cybersecurity projects and developing cybersecurity skills in the coming years.

Zero trust security

With the Covid-19 pandemic, most businesses have not had the option of allowing their employees to work from home. We can't protect corporate data and identities appearing in unsecured home networks by using the same security approach we use in closed networks. This has created a huge opportunity for cyber criminals as most companies didn't have time to evaluate the risks involved in remote working and prepare themselves beforehand. Most companies are still "catching up" on cybersecurity risks related to remote working. According to an IBM report (https://ibm.co/3wwOSjf), remote working has increased the average cost of a data breach by $137,000. According to a survey done by Malwarebytes (https://bit.ly/3HUQWXc), 20% of their responders said they faced a security breach as a result of a remote worker. 44% confirmed they did not provide any cybersecurity training to employees that focused on the potential threats of working from home.

Interestingly, this study also confirmed that only 47% of employees are aware of the cybersecurity best practices when working from home.

The above stats show that the sudden shift to working from home creates risks for companies. This also confirms that the traditional parameter defense approach is not going to meet modern cybersecurity requirements. The best way to address this challenge is to take a Zero Trust security approach. The Zero Trust security model has three main principles:

• Verify explicitly – This means we need to verify each and every access request equally. This shouldn't change based on the network location, person, or role. In the Nobelium attack, we can clearly see that if there was explicit verification in place, it could have been prevented at many stages. Traditional security models are based on the "trust but verify" approach, but the zero-trust model takes a completely opposite approach, which is "never trust, always verify."
• Least privileges access – Almost all engineers in IT departments usually have Domain Administrator or Enterprise Administrator rights. But some of them only use it to do basic administrative tasks such as password resets. Least privilege access means users will only have privileges to do the tasks they are supposed to do. This will prevent the lateral movement of attackers and stop them from owning privileged accounts.
• Assume breach – Cyber criminals are also humans. We can't close all the doors. These criminals always find ways to get in. They change their tactics and methods from time to time. We need to assume a breach. The important questions are, if there is a breach, how can we recognize it? How fast can we recognize it? To do that, we need to have tools and services:
  • To collect various logs from systems
  • To analyze that data effectively
  • To do user behavior analytics
  • To detect anomalies

More information about the Nobelium attack is available in the following articles, which are published by Microsoft:

• https://bit.ly/3wl8fvx
• https://bit.ly/3BJfbDv
• https://bit.ly/3bI09Dx

To enforce the principles of the Zero Trust model, we need IAM solutions such as Azure Active Directory. Based on the lessons we learned from attacks such as Nobelium, more and more businesses will start to follow this security approach in the next few years.

Password-less authentication

Back in 2004 at the RSA Security Conference (San Francisco), Bill Gates said "There is no doubt that over time, people are going to rely less and less on passwords. People use the same password on different systems, they write them down, and they just don't meet the challenge for anything you really want to secure." Over the years, this statement has been proven over and over. Passwords are no longer secure. Passwords are breakable. The UK's National Cyber Security Center has done a study to examine the passwords leaked by data breaches. According to them, the number one password used is "123456."

So, if passwords are failing, what else can we do to improve security in the authentication process? Multi-factor authentication can add another layer of security into the authentication process. It can be SMS, a phone call, an OTP code, or a phone app notification to further confirm the authenticity of the access request. There are many different MFA products available on the market. However, MFA doesn't eliminate the requirement for passwords.

But now we have an option to replace traditional authentication with password-less authentication. This is basically to replace passwords with biometrics, PIN, certificates, and security keys.

Fast Identity Online (FIDO) is an open standard for password-less authentication. This allows authenticating in systems using an external security key built into a device.

Windows Hello for Business and Azure Active Directory support password-less authentication based on FIDO2 security keys.

FIDO2 is the third standard that came out of the FIDO Alliance. FIDO2 consists of a Client to Authenticator Protocol (CTAP) and the W3C standard WebAuthn. When we use FIDO2 security keys for authentication:

1. The user registers with the WebAuthn remote peer (FIDO2 server) and generates a new key pair (public and private).
2. The private key is stored in the device and is only available on the client side.
3. The public key will be registered in the web service's database.
4. After that, in the sign-in process, the system will verify the private key, which always needs to be unlocked by a user action such as a biomimetic process or a PIN.

More information about WebAuthn is available at the following links:

• https://bit.ly/3wkLW93
• https://bit.ly/3bQfamF

Over the last few years, password-less authentication has grown significantly and it will continue to do so in the coming years. According to Gartner, "By 2022, Gartner predicts that 60% of large and global enterprises, and 90% of midsize enterprises, will implement password-less methods in more than 50% of use cases—up from 5% in 2018." Azure AD now supports password-less authentication using FIDO2 keys. This can be used to authenticate into cloud resources as well as on-prem resources. I have already written some articles about the configuration of FIDO2 keys. You can access those here:

Step-by-step guide: Azure AD password-less sign-in using FIDO2 security keys: https://bit.ly/3GTjHmG.

Step-by-step guide: Enable Windows 10 password-less authentication with FIDO2 security keys (Azure AD + Microsoft Intune): https://bit.ly/3wl8wyz.

Digital ID

So far in this chapter, I have used the term "digital identity" a few times. Digital identity is a form of identification that can be used to recognize a person using digital channels. When I log in to my LinkedIn account, I use a username and password. The username and password were created when I signed up to LinkedIn. When I log in to my bank's online service portal, I use a different username and password. Both of these accounts represent my identity. Instead of using multiple digital identities, what if we can agree on one digital ID that allows you to use multiple online services such as healthcare, banking, travel, and leisure. It will reduce the complexity of proving identity. According to a study done by McKinsey Digital (https://mck.co/3bJK14p), one billion people in the world don't have any legal form of ID to prove their identity. Imagine the opportunities they are missing in their day-to-day lives.

It could be preventing them from accessing public services such as education and healthcare, it could be affecting their rights, and it could be affecting their loved ones. With the Covid-19 pandemic, more and more countries are in the process of adopting this unified digital identity concept. The UK government has already created a framework for digital identity (Source: https://bit.ly/3ENOtvz). According to the UK government, the cost of proving identity manually offline could be as high as £3.3 billion per year. The government believes "The new digital identity will not only make people's lives easier but also give a boost to the country's £149 billion digital economy by creating new opportunities for innovation, enabling smoother, cheaper, and more secure online transactions, and saving businesses time and money." (Source: https://bit.ly/3BQImER.) The US has recently introduced the Improving Digital Identity Act of 2020 (Source: https://bit.ly/3BQb5cK) to establish a government-wide approach to improving digital identity. The Digital ID & Authentication Council of Canada (DIACC) created the Pan-Canadian Trust Framework (Source: https://bit.ly/3nYg7z3), which defines the conformance criteria necessary for a digital identity ecosystem and explains how digital IDs will roll out across Canada.

As we can see above, countries around the globe are already working toward regularizing digital identity. On this journey, IAM also has a role to play. There will be new laws related to digital identity. There will be new rules to comply with. Organizations will have to find an efficient way to manage these new digital identities. More importantly, we need protection from identity theft. We can't do this only by using a legacy directory service. We need IAM solutions in place to manage the complete life cycle of a digital identity.

We can clearly see a challenging time ahead for IAM. We can't talk about IAM without talking about directory services. So this is why an on-prem directory service such as Windows Active Directory still has paramount value.

Active Directory Domain Services was first introduced to the world with Windows Server 2000. For more than 21 years, AD DS has helped organizations to manage digital identities.

However, modern access management requirements are complicated. Businesses are using more and more cloud services now. The majority of the workforce is still working from home and accessing sensitive corporate data via unsecured networks. Most software vendors are moving to the Software as a Service (SaaS) model. Cybercrimes are skyrocketing and identity protection is at stake. To address these requirements, we need to go beyond legacy access management. Azure Active Directory is a cloud-based, managed, Identity as a Service (IDaaS) provider that can provide world-class security, strong authentication, and seamless collaboration. Azure Active Directory can span on-prem identities to the cloud and provides a unified authentication and authorization platform to all resources, regardless of location. This is called hybrid identity.

Azure Active Directory is often referred to as a cloud version of AD DS, but this is completely wrong. It is like comparing an iPhone with a Samsung phone. Both can be used to make calls, take pictures, watch videos, and so on. Some apps are also available for both types of devices. But you can't replace one with another as each has its uniqueness. AD DS and Azure Active Directory are the same. They have their similarities as well as differences. Let's go ahead and compare both products based on different focus areas:

As we can see in the above comparison, we can't simply replace one solution using another. But hybrid identity with Azure AD allows organizations to revamp traditional identity management and prepare themselves for the cloud era. So, the biggest question is what does the future hold for Active Directory Domain Service on this journey?

For most companies, the cloud journey starts with SaaS applications. On the majority of occasions, it is Office 365. And not only Microsoft; in general, most software vendors are transforming their services into the SaaS model. SaaS applications support different types of authentication. If an organization is looking for a single-sign-on experience, we have two options. We can set up Active Directory Federation Service (ADFS) and configure SAML-based authentication to provide SSO. However, this comes with additional costs and administrative overheads. Instead of that, we can simply sync on-prem identities to Azure Active Directory and integrate an SaaS application with Azure Active Directory for authentication. This method gives us a few advantages:

• Fewer Changes – We do not need to make many changes in an existing on-premises environment to enable cloud-based authentication. It only requires lightweight agents, simple firewall rules, and a reliable internet connection.
• Advanced Authentication – Azure Active Directory supports modern authentication standards such as OAuth2, SAML, and WS-*.
• Advanced Identity Protection – Azure Active Directory enriched with features and services that you can use to protect identities. Azure MFA, password-less authentication, Azure PIM, Azure Identity Governance, and Conditional Access are some of the examples of that. To start using these features and services, we do not need to make drastic changes to the existing environment. We can start by protecting identities in the cloud and then slowly extend it to on-prem as required.

As we can see, it doesn't mean we need to get rid of on-prem Active Directory to use Azure Active Directory and its features. Both can work side by side to provide a unified access experience to users. Active Directory was the top choice in industry for the last 21 years and it is the most widely used directory service. If we can move everything to the cloud, yes, it has benefits but it is not practical and not as easy as it sounds. We may have rules with which we have to comply. We may have legacy business applications that can't shift to cloud services. We may have skills and security gaps to embrace cloud technologies. Therefore, hybrid identity will not be a short-term solution for most businesses. Most businesses prefer hybrid identity instead of the cloud-only method because of the flexibility.

In the Nobelium attack, cyber criminals moved laterally after the initial security breach and gained control of Active Directory Federation Services (ADFS).

This allowed attackers to forge SAML tokens and get access to cloud services. Security is one of the key focus areas for public cloud services. There are various services and features available for customers to choose from, to protect identities and data in the cloud. There has been an increase in public cloud attacks recently, but the success rate is still relatively low compared to on-prem attacks. The Nobelium attack confirms cyber criminals are now targeting on-prem services to gain access to cloud services. Identity protection is a shared responsibility between cloud service providers (CSPs) and cloud customers. Therefore, it is the customer's responsibility to protect on-prem identities from attacks. Even if there is an attack, lateral movement needs to be prevented to protect cloud services. According to the Oracle and KPMG Cloud Threat Report 2020 (https://bit.ly/3BUNAj6), 92% of responders had a cloud security readiness gap. It shows we can't protect the cloud if we can't protect an on-prem environment.

In hybrid identity, Active Directory Domain Service is responsible for managing and protecting on-prem identities. There are many things we can do to protect on-prem identities from sophisticated attacks similar to Nobelium. We can prevent lateral movement by introducing the Active Directory tier model. We can use group policies to standardize the device and user state. We can introduce Microsoft LAPS to protect local administrator accounts. We can limit privileged accounts' appearances to privileged access workstations (PAW). If we are in a hybrid environment, we can further use cloud-based solutions such as Microsoft Defender for Identity, Microsoft Defender for Endpoint, and Azure Sentinel to identify potential security risks in the environment and address those proactively.

As we can see, in hybrid identity, we can't take our eyes off on-prem Active Directory by thinking extended identities to the cloud is going to take care of identity protection. Later in this book, we will further explore the things we can do to protect identities. Before that, let's go ahead and look into some fundamentals of Active Directory.

A few years ago, I was working on an Active Directory restructuring project for a world-famous pharmaceutical company. According to the company policies, I had to travel to their headquarters to perform the project tasks. On the day of my visit, I walked into the company's reception area. After I explained who I was and why I was there, the receptionist handed me a form to fill in. The form included questions such as name, phone number, the duration of the visit, and which department I was visiting. Once I had completed the form, I handed it over to the receptionist, and she had to make a few calls to verify whether my visit was expected, and then confirm my access to different buildings with the respective department managers.

Then, she produced a magnetic card with my details on it and handed it over to me. She instructed me how to use it and which buildings I was allowed into.

The following diagram outlines this process:

Figure 1.2: Process of entering physical headquarters

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

• The form that the receptionist handed over to me contained certain questions to help her understand who I was. They were predefined questions, and I had to answer them in order to register my information in their system. Similar to this form, in a directory service, we have to provide values for specific attributes.
• Once I had submitted the form, she didn't hand over the magnetic card right away. She made a few calls to verify my identity, and also to confirm which buildings I would have access to. Then, my details were registered on the system, and it generated a magnetic card that had my photo and a barcode. 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 barcode and identification number at the same time. Similarly, in a directory service, each identity is unique. 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 card 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. Likewise, in an identity infrastructure, you need to validate your identity according to the method that the system has defined. It can be a username and password, a certificate, biometric information, and so on.
• 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 to check. Once I handed it over, he scanned it with a barcode reader and checked some information on his computer screen. Then he informed me that I was not allowed into that building, and he guided me to the correct building. This means that my information can be accessed from any building through their system in order to verify my identity and access permissions. In a similar way, in a directory, identities are saved in a central repository. This data can be accessed and verified from any system or person who has the authority.
• When I used the card in the correct buildings, it allowed me 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 or 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 every time I tapped the card at the entrance or exit. These points collected the data, and the managers could review the information at any time. Similarly, as identities are unique in a directory, it helps to identify who has done what in a system in a given period (based on authentication and authorization data).

This system acted as an authentication and authorization system. It used different protocols and standards to manage and protect the identities that were saved in a central database. This is the primary function 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; for example, sales, IT, production, and quality assurance. Apart from skills and knowledge, employers use company resources such as applications and hardware devices to reach their goals. In order to use these resources efficiently, 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 the data about users, applications, and resources is recorded in a central repository that uses authentication and authorization in order to manage resources. These are the main characteristics of a directory service.

Different service providers have different directory services; for example, Novell directory services, the Oracle directory service, and the Red Hat directory service. However, the Microsoft Active Directory service is the most commonly used directory service in the industry.

Centralized data repository

Active Directory stores the digital identities of users, applications, and resources in a multi-master database. This database is a file called ntds.dit, and is based on the 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 almost two billion objects. Users can use the digital identities that are stored in Active Directory from anywhere in the network in order to access resources. Administrators can manage the authentication and authorization of the organizational digital identities from a centralized location. Without directory services, these digital identities would be duplicated across different systems, which would add administrative overheads to managing the data.

The replication of data

There are organizations that use a single domain controller. But when it comes to complex business requirements, such as branch offices and high availability, multiple domain controllers are required (we are going to look at domain controller placement in Chapter 11, Active Directory Services Part 01). If the digital identities are managed from a centralized system, it's important that each domain controller is aware of the changes that have been made to the Active Directory database. Say a user, Jane, in the sales department, forgets her password and asks the IT department to reset it.

In 30 minutes, she's going to be working from a branch office located in a different city. The IT administrator resets her password from the headquarters' 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 replication. 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 the changes advertised by neighboring domain controllers, it is called inbound replication. The replication connections (from who and to whom) and replication schedule can be modified based on the business requirements.

High availability

High availability is important for any business-critical system in an organization. This is also applicable to domain controllers. 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 the replication of domain controllers allow users to continue with authentication and authorization from any available domain controller at any time. The Microsoft recommendation is to run at least two domain controllers to maintain the high availability of the service.

Security

Data and identity protection 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 the features of Active Directory that can secure your digital identities 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.

Auditing capabilities

Setting up advanced security policies will not be enough to protect your digital identities. Periodic audits will help you to understand new security threats. Active Directory roles come with in-built auditing capabilities. In an Active Directory setup, there can be events related to user authentication, directory service modifications, or access violation. All these events will be recorded in the event viewer under different logs.

Single sign-on (SSO)

In an organization, there can be many different applications in use. Each of these applications may have a different authentication mechanism. It will be difficult to maintain different user credentials for authentication 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 that are used by your organization. You will not need to keep typing your credentials in order to get access. Once you authenticate on a computer, the same session will be used to authenticate other Active Directory-integrated applications.

Schema modification

Any kind of database has its own structure, called the schema. This is also applicable to an Active Directory database. The Active Directory schema mainly contains two types of information.

1. A definition of every object class in Active Directory
2. A definition of every attribute in an Active Directory object

Based on the AD version, the number of object classes and the number of attributes defined in the schema can be different. 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 Component Object Model (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.

Querying and indexing

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 the user John's account, I do not need to know which branch he is in, or to which department he belongs. 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 their attributes and make them available to 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 Active Directory setup, you need to consider both components. The logical components of the Active Directory structure can change at any given time according to business requirements. But you won't be able to modify the physical components as easily as the 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 at the beginning before we move on to advanced planning.

Logical components

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 in the IT department. Everyone is bound to the company by following different operational guidelines and targets. When we design the Active Directory setup, we need to match it with the company hierarchical layout, in order to effectively manage resources and security. The logical components of Active Directory help you to 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 with them.

In the following section, we are going to explore more about logical components in the Active Directory environment.

Forests

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

The Active Directory forest can also be explained in a similar way. It represents a complete Active Directory instance. It is made of one or more domains and domain trees. We will explore what domains and domain trees are in the following sections. Each domain has its own characteristics, boundaries, and resources. 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 other 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 the Amazon; each tribe has its own name. Similarly, domains in a forest can contain any domain name:

Figure 1.3: Domains in the rebeladmin.com forest

The first domain controller in the Active Directory service deployment is important. When you create the first domain, it will also create the forest. 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. rebeladmin.com is the forest root domain. It does have another two companies: one is Rebeladmin IT with the rebeladminit.com domain name, and it provides managed IT services. The other company is My training, with the mytraining.ca domain name, and it provides IT training to professionals. rebeladminit.com and mytraining.ca are both 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 as long as you are not using the features specific to the current functional level. The forest functional level is dependent on the oldest domain controller version in the network.

For example, if the forest functional level is Windows Server 2008, it is allowed to install the domain controller inside the forest with the operating system, Windows Server 2022. But this doesn't mean it can use the features provided by Windows Directory Services 2022 until it upgrades its domain and forest functional levels. If you upgrade the forest functional level to Windows Server 2016, you can only have domain controllers running a minimum of Windows Server 2022.

The following table explains the supported Domain Controller operating systems for each functional level.

Domains

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

The Active Directory domain can also be explained in a similar way. The domain contains the logical components to achieve the administrative goals of the organization. By default, the domain becomes 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 defined security rules. 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 in order to improve its efficiency. The domain is also a partition of Active Directory. When I described the Active Directory forest, I mentioned that every domain inside the forest shared the same schema. Each of the domain controllers also has a copy of the domain partition, which 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 needs to be upgraded. The version of the domain's functional level that you can run on the domain depends on the forest's functional level. You cannot have a domain's functional level that is higher than the forest's functional level.

Domain trees

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 also the root domain. All other domains in the domain tree are called the child domains. There will be only one parent domain in a domain tree.

In some documentation, child domains are also called subdomains. When dealing with internet domains, the creation of an additional placeholder, a sub-URL, is sometimes required. For example, rebeladmin.com is the domain name that is 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 Domain Name System (DNS) record for the support.rebeladmin.com subdomain:

Figure 1.4: Subdomains in a contiguous namespace

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 to the next level in the domain tree, it shares the namespace from the preceding level. Each child domain maintains its own domain partition.

This configuration data will be replicated only to the domain controllers of 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.

Organizational units

In the preceding section, I explained how we can group objects using domains and forests. But within the organization, objects can be categorized into different groups according to 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 networks are similar. Therefore, we can create an organizational unit (OU) called sales and group all the sales department users into it. We can now apply security policies at the OU level, 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 an OU as required. An OU also helps to apply group policies to a selected group of objects. As an example, if an organization has an OU for each department, we can apply different group policies for each department by simply targeting the OU.

Once an object is assigned to an OU, it inherits the security settings and permissions that are applied to 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. OUs also help to delegate administrative control to individuals for specific tasks. Domain administrators have privileges that allow them to manage any object within the domain. But it's possible to create administrators and assign them to manage objects and resources at an OU level. For these administrators, the OU will be the security boundary. They will not be able to modify any other object outside that particular OU. I will be explaining delegated administration later in this book. OUs are container objects. They can be associated with similar or other objects. Similar to parent-child domains, OUs can also contain child OUs. These are also nested organization units.

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

Figure 1.5: Organizational unit hierarchy

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 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 offices. 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 department across the branch offices. All the child OUs inherit the permissions that are applied to 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 the Europe, Asia, and North America OUs by default. The OU hierarchy is independent. It is not going to affect any other domain's OU hierarchy. The OU can also contain objects only from the same domain.

Physical components

In the previous section, I explained the logical components of Active Directory. Now, it's time to look into the physical components. Even though the logical and physical components are equally important in Active Directory Domain Services' design, they are independent. Replication is the core feature of 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. Logical components can easily be rearranged compared to physical components.

Domain controllers

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 only be made from a specific domain controller. Since 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 operational role changes can only be modified by the designated operation master role owner (FSMO roles).

The global catalog server

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 in queries. Applications and users in one domain can query for the objects in another domain (in the same forest) via the global catalog server. All domain controllers in the domain will not be global catalog servers by default. When installing the first domain controller, it will become the global catalog server, and other domain controllers can be promoted as global catalog servers according to the business requirements. Not every domain controller in the domain needs to be a global catalog server.

More details about global catalog servers and global catalog server placement can be found in Chapter 3, Designing an Active Directory Infrastructure.

Active Directory sites

The Active Directory site defines a physical topology of the network. Sites can be separate buildings in a campus network, with the branch office in a separate city or even in a separate country. For example, the head office of Rebeladmin Corp. is located in London, UK. It runs a few domain controllers (DC01 and DC02) within its physical network. It uses IP address allocation for the network with the subnets of 192.168.148.0/24, 10.10.10.0/24 and 172.25.16.0/24. Due to 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 the IP subnets of 10.11.11.0/24 and 172.0.2.0/24:

Figure 1.6: Active Directory connection

In the preceding diagram, the two offices can be identified as two sites. This is because there are clearly two network segments. Active Directory's 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 that 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 also be used for other enterprise operations. Using AD DS sites, it's possible to perform bandwidth optimization and replication schedules for reliable replication across domain controllers.
• Service location: In an infrastructure, there can be Active Directory-integrated applications/services; 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 on the Toronto site are served by the Microsoft Exchange Server (mail server) on the Toronto site when they try to access an email, instead of passing the request to the London site.
• Authentication: When a user logs in to the domain, they need to communicate with the domain controller to gain authentication. In the preceding example, a user on the Toronto site does not need to connect to a domain controller on the London site for authentication. AD DS sites will allow you to ensure that users on the Toronto site will use the nearest domain controller for authentication. This will reduce latency and bandwidth through the site links.

More information about Active Directory sites is available in Chapter 11, Active Directory Services – Part 01.

If we need to describe a person or thing, we use different adjectives. This can include personality, ethnic background, physical appearance, or other characteristics. Most of these are not unique. For example, when you talk about a 6-foot-tall boy, there could be lots of 6-foot-tall boys in the city. But it still explains that 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 to identify some unique attributes associated with them. If it's a person, then their passport number, telephone number, or social security number will make it easier to uniquely identify them from others. If it's an object, the unique identifier could be the serial number or barcode.

Within an organization, there are many physical entities. These can be either employees or resources. In order to manage these 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 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.

In the same way that we use adjectives to describe a person or a thing, Active Directory objects use attributes to describe their nature. For example, the following screenshot shows the wizard you will get when you create a new user account by using Active Directory Users and Computers (ADUC). In the wizard, in the following screenshot (on the 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 (on the right-hand side):

Figure 1.7: Creating new objects

According to the preceding screenshot, depending on the object type, the associated attributes are also changed. 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, the attributes that are attached to each object class are defined.

Let's look at a simple scenario to understand this further. When you sign up for an online service for the first time, it will provide you with an online form to complete. At the backend, it is attached to a database. The information you provide 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 that you need to answer because the database will not be able to understand it. The database contains 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 in order to continue. But if we do not provide the last name, we can still proceed with the user account creation. Attribute values also need to be provided with an acceptable data format that is defined by the schema. Sometimes, due to 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.

Globally unique identifiers and security identifiers

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

In an Active Directory database, nearly two 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 a 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

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

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

Figure 1.8: ObjectGUID and SID as they appear in PowerShell

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 the 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 whether to access or deny permission to a user account based on the 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 the ACL is modified. But if the system considers sIDHistory when granting an access token, and if the old SID value is moved over to the new domain, the user is still allowed to access the resources they were assigned.

Distinguished names

Distinguished names in Active Directory can also be used to uniquely identify an object. 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 the province, then to the city, the street, and the house number. In 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 distinguishing names:

• organizationName (O) or organizationalUnitName (OU): Organization represents the root-level domain. The OU is where 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 components 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 distinguishing name for the user is as follows:

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

Here, 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 permitted to have the same RDN for the object within the same container.

In the previous section, you learned that the SID value 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 was changed for an object, the Distinguished Name (DN) would 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.

Active Directory server roles

There are five main Active Directory server roles. These roles are grouped together in 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)

Since Windows Server 2008, these roles can be installed and configured using Windows Server Manager. It is the same in Windows Server 2022.

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:

You can learn more about these roles from the following chapters:

• Chapter 11, Active Directory Domain Services (AD DS) – Part 01
• Chapter 12, Active Directory Domain Services (AD DS) – Part 02
• Chapter 13, Active Directory Certificate Services (AD CS)
• Chapter 14, Active Directory Federation Services (AD FS)
• Chapter 15, Active Directory Rights Management Services (AD RMS)

This is the end of the introductory chapter on Active Directory fundamentals. I am sure most of you are already aware of most of the functions of AD DS, but refreshing your knowledge about Active Directory components and their operations before we dive deep into the advanced topics wasn't in vain. In this chapter, we looked into the future of identity management, and then we covered Active Directory's hybrid identity role, Active Directory objects, GUID and SID values, and DNs.

In Chapter 2, Active Directory Domain Services 2022, you will learn about new features and enhancements to AD DS 2022, specifically about the approach to protect digital identities from modern security threats.