Book Image

Mastering Active Directory

By : Dishan Francis
Book Image

Mastering Active Directory

By: Dishan Francis

Overview of this book

Active Directory is a centralized and standardized system that automates networked management of user data, security, and distributed resources and enables interoperation with other directories. If you are aware of Active Directory basics and want to gain expertise in it, this book is perfect for you. We will quickly go through the architecture and fundamentals of Active Directory and then dive deep into the core components, such as forests, domains, sites, trust relationships, OU, objects, attributes, DNS, and replication. We will then move on to AD schemas, global catalogs, LDAP, RODC, RMS, certificate authorities, group policies, and security best practices, which will help you gain a better understanding of objects and components and how they can be used effectively. We will also cover AD Domain Services and Federation Services for Windows Server 2016 and all their new features. Last but not least, you will learn how to manage your identity infrastructure for a hybrid-cloud setup. All this will help you design, plan, deploy, manage operations on, and troubleshoot your enterprise identity infrastructure in a secure, effective manner. Furthermore, I will guide you through automating administrative tasks using PowerShell cmdlets. Toward the end of the book, we will cover best practices and troubleshooting techniques that can be used to improve security and performance in an identity infrastructure.
Table of Contents (20 chapters)

Active Directory objects

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

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

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

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

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

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

Globally unique identifier and security identifier

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

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

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

Get-ADUser username

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

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

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

There is a misunderstanding that the GUID value is a unique value. None of the documentation say that this value is unique. They only say it is quite unlikely to have a duplicated GUID as method it used to generate 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 access or deny permissions to a user account based on their access control list (ACL). This ACL uses the SID values. So, if an object moves to a different domain without sIDHistory , it will lose its access to resources until ACL is modified. But if the system considers sIDHistory when granting access token and if the old SID value is moved over to the new domain, the user is still allowed to access the resources he/she was assigned.

Distinguished names

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

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

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

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

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

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

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

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