Understanding Active Directory objects

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.

There is a misunderstanding that the GUID value is a unique value. None of the documentation says that this value is unique. They only say it is quite unlikely to have a duplicated GUID as the method used to generate it is complex.

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:

PowerShell cmdlets	Description
Install-WindowsFeature AD-Domain-Services	This cmdlet will install the AD DS role. Please note this will only install the AD DS role on the server. This is further explained in Chapter 6, Migrating to Active Directory 2022
Install-WindowsFeature AD FS-Federation	This cmdlet will install the AD FS role.
Install-WindowsFeature ADLDS	This cmdlet will install AD LDS.
Install-WindowsFeature ADRMS	This cmdlet will install AD RMS. This role has two subfeatures, which are AD Rights Management Server and Identity Federation Support. If required, these individual roles can be installed using Install-WindowsFeature ADRMS, ADRMS-Server, ADRMS-Identity, or Install-WindowsFeature ADRMS -IncludeAllSubFeature. It will install all the subfeatures.
Install-WindowsFeature AD-Certificate	This cmdlet will install AD CS. This role has six subroles, which are certification authority (ADCS-Cert-Authority), Certificate Enrollment Policy Web Service (ADCS-Enroll-Web-Pol), Certificate Enrollment Web Service (ADCS-Enroll-Web-Svc), Certification Authority Web Enrollment (ADCS-Web-Enrollment), Network Device Enrollment Service (ADCS-Device-Enrollment), and Online Responder (ADCS-Online-Cert). These subfeatures can be added individually or together.

The Get-WindowsFeature command will list all the roles and subfeatures that are available, along with the names that can be used with PowerShell to install the roles. When you install the roles, it is important to add -IncludeManagementTools as management tools, as the role will not be installed by default.

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)