Active Directory Part 2 – Deep Dive

Active Directory is considered to be the foundation or backbone of IT environments for most organizations. It was designed by Microsoft as a ‘directory service’ for managing Windows domains, network resources, network-wide settings, and policies. AD is centralized, meaning it can manage domain resources such as users, computers, and file shares from a central database. This database is called the ‘Data Store‘. More specifically, it’s a file called NTDS.dit that is stored on a Windows Server file system in this directory: ‘%SystemRoot%\NTDS\‘. A Windows Server that manages NTDS.dit and is running AD is called a ‘Domain Controller’. The actual service, or ‘role’, running on the server is called ‘Active Directory Domain Services’ (AD DS).

Active Directory’s secondary (but equal) job is identity management. It is responsible for authenticating and authorizing users (or other ‘Security Principals’) to directory resources while also managing their privileges to those resources. It does this while also performing Single Sign-On (SSO). SSO is a way for users to log in one time and still access more than one resource on the network with specific permissions. The protocals AD uses for authentication and authorization include Kerberos, LDAP’s authentication mechanism, or NTLM authentication. (The last one being the least secure).

Without Active Directory, computers wouldn’t be able to connect to domains, and would instead use ‘Workgroups’ to manage network resources. Workgroups are primitive in that administrators would have to manage each computers’ security and settings locally, because there is no centralized system to work from. Since they are designed to operate in a peer-to-peer network model, Workgroups can only work in local networks. This makes administrative control over multiple networks more difficult.

The last blog post (Part 1) was a walk-through on how to set up AD inside of a homelab environment. This post will go into more detail on how Active Directory works ‘under the hood’ by explaining its structure and components. I intend to use this blog post in the future as a personal ‘cheat sheet’ or reference on the topic of Active Directory. I will also include a few example ‘tasks’ that an IT administrator may perform on the job at the end of this blog post.

Domains, Trees, Forests, and Trusts

Windows Domains

A domain is simply a network structure where the authentication of “Security Principals”, such as user accounts and computers, is managed on a central server called a ‘domain controller’. These domain controllers can be replicated and act as a cluster of domain controllers for the same ‘domain’. Domains also act as a boundary for how policies are applied to objects within said domain. This means that if a policy is placed upon a group of users or computers, that policy gets applied within that one domain. Domains are frequently referred to by their “domain name” (such as ‘domainname.com’).

Trees

A tree is a collection of domains with one domain being the ‘root domain’. Root domains have a parent-child trust relationship with the other domains in the tree by sharing a namespace. This gives Active Directory its hierarchical structure. For example, we have a root domain called ‘mycompany.local’. You may need to create child domains from this domain for satellite offices of your company in different states. These child domains could be called ‘ga.mycompany.local’ and ca.mycompany.local’ for the states Georgia and California respectively. Each one of these domains will have their own ‘Domain Administrator‘ account to manage them.

Forests

Forests are groupings of trees and domains. They are the highest level of domain groupings an administrator can create. While domains within a tree must share the same namespace, forests connect trees and domains that have different namespaces. A real life example would be if a company acquisitioned another company and needed to connect both of their domains/trees together. They would have different namespaces but could still merge under a forest.

A forest is always created by default when installing Active Directory for the first time, so there will always be a forest. Domains within a forest share a few components such as a common schema, an Enterprise Admins group, and a common ‘Global Catalog’. A GC is essentially a domain controller that stores a copy of all objects in a forest.

With just single domains, the highest level user account would have been part of the ‘Domain Administrators‘ security group. Now that we have trees and forests, ‘Enterprise Administrators‘ exist in order to manage entire groups of domains.

Trust Relationships

The chains that bind domains into trees and forests are trust relationships. They are a way of establishing secure authentication and communication between Active Directory domains, trees, and forests. Trust can be characterized in two different ways: one-way vs two-way, or transitive vs non-transitive.

‘One-way‘ trusts allow for simple one-sided relationship between two domains. For example, Domain A trusts Domain B. Therefore, users in Domain B can access resources in Domain A, but not the other way around. The second kind of trust relationship is called a ‘two-way‘ trust. This is a ‘bi-directional’ and mutual relationship between two domains or trees.

Transitivity of trusts goes beyond one way or two-way relationships. A transitive trust can extend a one-way or two-way trust relationship beyond just two domains. An example of this would be: Domain A trusts Domain B. Domain B trusts Domain C. Therefore, Domain A trusts Domain C and all three domains trust each other. The opposite of this would be a non-transitive trust. These kinds of trusts do not allow a domains or forests to trust each other through a ‘middle man’. Trust is limited between the two entities and nothing beyond that.

Below are some of the few trust ‘types’ commonly found in Active Directory:

Parent-Child Trusts

When new sub-domains are attached to ‘root’ domains, a ‘parent-child’ relationship is formed along with the ‘tree’ structure. Parent-child trusts are two-way and transitive. This allows objects in a child domain to authenticate to the parent domain and vice versa.

Tree-root Trusts

‘Tree-root’ trusts are similar to parent-child trusts. Instead of connecting domains and creating trees, they connect the the root domain of a forest to a root domain of a new tree in order to extend a forest. These trusts are also both transitive and two-way.

Cross-link Trusts

Sometimes connecting two domains within the same forest with their own special trust can speed up authentication. This is known as a ‘cross-link’ or ‘shortcut’ trust. They can be manually configured to be one-way or two-way, but they are usually one-way and transitive.

Forest Trusts

Trust relationships between forests are called ‘forest trusts’. Forest trusts allow administrators to link resources and objects across multiple forests, and they are transitive by default. They are considered transitive because objects in a child domain of one forest can authenticate into the second forest. This type of trust relationship is commonly used in corporate acquisitions and mergers. The diagram below shows an example of two forest trust relationships between three forests.

External Trusts

An ‘external’ trust connects two domains in separate forests where their respective forests are not connected by a forest trust. External trusts are non-transitive and can be either one-way or two-way.

Protocols

Active Directory utilizes a variety of protocols for both authentication and communication between domain objects. The most important ones used in AD are explained in the next few sections.

DNS

DNS, or ‘Domain Name System’, is a vital service in an Active Directory environment. AD would not be able to function without it because DNS is required to locate anything inside of a network. In the most basic terms, DNS is used to resolve hostnames to IP addresses, acting like a phone book for the network. It is used in pretty much any kind of network environment, not just Active directory. In an Active Directory environment though, there are all kinds of nodes such as servers, computers, printers, etc, that need to locate and communicate with each other. Most importantly, they all need to be able to locate and communicate with the domain controller. Records of services that are available in a network are maintained by Active Directory using service records (or SRV). With these records, clients are able to locate any service or resource they need within a domain, tree, or forest. DNS uses both TCP and UDP port 53, but UDP is used by default.

MSRPC

MSRPC is like RPC, but Microsoft’s version of it. RPC, in the most simple terms possible, is a way for one computer program to run a function or process on a completely different computer over the network. Windows machines use MSRPC to access other systems in AD with four main RPC interfaces: lsarpc, netlogon, samr, and drsuapi. Each interface is used for specific tasks. For example, netlogon is required to authenticate users or services in the domain.

LDAP

Lightweight Directory Access Protocol, or LDAP, is a standardized protocol that allows for the access and management of directory information/services over a network. In more simpler terms, LDAP is like a ‘language’ that systems need to know in order to ‘speak’ to a directory service like Active Directory. A good parallel comparison is HTTP and web servers. Applications need to know the LDAP ‘language’ to talk to AD, just like they need to know HTTP to talk to an Apache or Nginx server.

The other main use for LDAP is authentication to Active Directory. Clients can use LDAP by utilizing a collection of ‘operation requests’. The operation used for authentication is called ‘BIND’. The ‘BIND’ operation establishes the authentication state for the client’s session. There are two kinds of bind requests:

1. Simple Bind: Client may use a simple username and password to authenticate directory to the LDAP server or Domain Controller. Anonymous authentication is sometimes supported.
2. SASL Bind: SASL, (or the Simple Authentication and Security Layer), is a framework that allows other authentication methods (like Kerberos or TLS certificates) to be “plugged” into the LDAP authentication process. Offloading the authentication method provides an extra layer of security.

Standard plaintext LDAP uses port 389, while LDAP over SSL/TLS (or LDAPS) uses port 636.

Kerberos

Kerberos is an open standard protocol for authentication that is maintained by MIT. It is used for many services such as NFS or Samba, but Microsoft maintains its own implementation of Kerberos for Active Directory. It is frequently used as the main method of authentication for AD, as it is more robust than NTLM and LDAP. Unlike the other two methods, Kerberos does not actually transmit passwords over the network. Instead, this protocol relies on a third-party server that produces and grants ‘tickets’ to clients which they can pass to services. This third party server is called the “Key Distribution Center” (KDC). Furthermore, the KDC is made up of two components that perform different roles: the Authentication Server and the Ticket Granting Service. How the KDC and its components work together in an AD environment is explained in the steps below.

Kerberos Authentication Steps:

1. User logs in, generates a ‘authentication service request’ (or AS_REQ), and encrypts it with its own hashed (NTLM) password. The AS-REQ is then sent to the authentication server in the KDC.
2. The Authentication Server knows the user’s password hash (shared secret), so it is able to decrypt the request after verifying the user’s identity. The KDC then generates and sends the client a “Ticket Granting Ticket” (TGT).
3. The client passes the TGT to the Ticket Granting Server in order to request a Ticket Granting Service Ticket. This request is also called a ‘TGS_REQ’ or TGS request.
4. If the TGT is valid, the TGS sends back the TGS ticket which is encrypted with the NTLM hash of the requested service. This is also called the ‘TGS_REP’ or TGS reply.
5. The client then sends a Service Request, or ‘AP_REQ’, to the target service. The AP_REQ is made up of the encrypted TGS ticket created by the KDC.
6. The service recieves the AP_REQ and is able to decrypt the TGS ticket as it was encrypted by its own password. The server responds with an encrypted timestamp which the client can decrypt. This finally allows the client and server to be mutually authenticated with an encrypted communication session.

Kerberos is also different from NTLM and LDAP in that it offers SSO, or ‘Single Sign-On’. Users are only required to authenticate to the KDC one time every few hours, and the KDC is able to grant tickets for any resource that user is authorized to use.

Lastly, Kerberos runs port 88 for both TCP and UDP.

NTLM Authentication

The NTLM protocol is one the main authentication methods used in Active Directory. Variations of it have existed since the late 1980s. NTLM first started out as a simple hash called LAN Manager hash, or LM hash. It uses an old, and now insecure, algorithm called DES to hash passwords to store in the SAM and NTDS.dit databases. Passwords were limited to 14 ASCII characters, which are not case sensitive (converted to uppercase), and are also split into two 7 character chunks. These attributes made password cracking LM hashes are extremely easy. LM has been discontinued and is disabled on most Windows operating systems.

After the LM hash, came the NT hash. Sometimes incorrectly called the “NTLM hash”, the NT hash is what more modern Windows operating systems use to store passwords. NT improves upon LM by using MD4 instead of DES. It also uses Unicode instead of ASCII for a wider range of characters, while also being case sensitive. NT hashes do not split the password into two chunks, but are able to hash whole passwords that are greater than 14 characters.

Finally, we can talk about the NTLM protocol (A.K.A. Net-NTLM). The first version, NTLMv1, performs a challenge-response protocol to authenticate a client using both its NT hash and LM hash. Below are the steps of the challenge-response process:

1. Client sends a negotiation message to the server containing its username.
2. Server sends back an 8-byte challenge message to verify the client’s identity.
3. The client responds with an “authenticate” message. This is computed using the sent ‘challenge’ value, the NT hash, and LM hash. Then it’s encrypted with DES.
4. Lastly, the server validates and sends a validation message to the client if everything checks out.

Net-NTLMv2 improves upon v1 and is the most current NTLM protocol in Active Directory. Version 2 uses stronger encryption algorithm (HMAC-MD5). Two responses are sent back to the challenging server instead of one. Both responses include a 16-byte HMAC-MD5 hash of the server challenge, a challenge the client generates, and a HMAC-MD5 hash of the user’s NT hashed password. The responses differ in that the second response also includes a timestamp, a 8-byte random nonce value, and the domain name.

AD Objects

AD DS Schema

Before we talk about AD Objects, we should first mention the “Schema”. The Active Directory Schema is almost like a ‘blueprint’ (or set of rules) of an enterprise network. The Schema defines the ‘class’ or type of object that can exist in the AD database. It also lists the corresponding attributes associated with those object classes. An example of a class would be the class ‘computer’, and the object ‘PC1’ would be an instance of the class ‘computer’. An attribute of the object ‘PC1’ would be its actual name “PC1”. Attributes to the class ‘user’ would be something like ‘First Name’, ‘Last Name’, ’email address’, etc.

Security Principals

One more thing needs to be mentioned before talking about objects: Security Principals. A security principal is any object that needs to be authenticated, such as a user or service account, by either the Windows operating system or Active Directory. These are not exclusive to Active Directory. Windows computers that are not connected to AD also manage local security principals through the Security Accounts Manager (or SAM). While local security principals are used to manage access to the local computer’s resources, security principals in AD are used to manage access to domain resources. All security principals have their own unique identifiers called “security identifiers” (SIDs). When a security principal is authenticated, the system creates a token containing its own SID, or the SID of a group that the user is a member of. SIDs can only be used once in a domain, even if the security principal that owned it before has been deleted.

Another type of identifier is the 128-bit hexadecimal “Global Unique Identifier” (GUID). These are assigned to all types of objects, whether these objects are ‘security principals’ or not. They are “globally unique”, meaning they are unique to the entire forest, rather than just a domain. SIDs on the other hand are only unique to a single domain.

Users

User objects are accounts that humans use to authenticate to the domain. They are considered ‘leaf objects’, which means they are objects that can’t contain other objects inside of them (like the very ends of a ‘tree’ branch). User objects are also security principals. Therefore, they each get their own SID and GUID. Users have attributes such as ‘First Name’, ‘Last Name’, or ’email address’. These attributes are defined by the Schema.

Computers

By joining computers to the Active Directory network, users can be given permissions to log into any computer on the network. This is all done without having to manage accounts locally on each individual computer. Computers are leaf objects too. Like users, they are also ‘security principals’, so they get assigned both SIDs and GUIDs.

Security Groups

The ‘group’ or ‘security group’ object in Active Directory are not leaf objects. Rather, they are ‘container objects’. This means they can contain other objects such as users and computers within them. Security groups are a way to manage permissions or access over domain resources. For example, if a file share should only be accessed by the HR department of an organization, users and computers placed in the “Human Resources” group would be granted that access through the group permissions.

Organizational Units

Another type of container object are Organizational Units, or OUs. These containers are mostly used for delegating tasks to certain users, such as being able to reset passwords for another group of users within a certain OU. OUs can contain other OUs within them to create nest OUs. They can also be used for applying Group Policies over groups of users and computers. (I will go into Group Policy in more detail later in this post.)

Other Objects

• Shared Folders
  • Not only can multiple users share a single computer on AD, but they can also share a folder. This is done with a file sharing protocol called SMB.
  • Shared folder objects can have very strict access control applied to them.
  • Shared folders are not security principals, so they only have GUIDs and no SIDs.
  • They also have attributes such as the name, file location, and access rights.
• Printers
  • Printers are a physical resource that need to be shared in most office spaces. Being able to share them over the network saves employees a lot of time and effort.
  • They are leaf objects.
  • Printers are not security principals, which means they do not have a SID but they do get assigned a GUID.
• Contacts
  • These objects represent external users.
  • Contain attributes like first name, last name, email, telephone, etc.
  • Leaf objects.
  • Not security principals, so no SIDs but they do have GUIDs.
• Foreign Security Principals
  • Represents security principals that belong to a foreign but trusted domain or forest.
  • The FSP object is really just a placeholder that contains the SID of the real foreign object.
  • Created automatically when an object such as a user, computer, or group from an external forest is added to a group existing in the current forest.
• Built-in
  • A container that contains default groups and users that get created when AD gets installed.

Types of Accounts

There are two ways accounts can be stored: locally or domain-joined.

Local User Accounts

Local user accounts are specific to an individual server or workstation, allowing access only to that particular host. They can be granted rights either individually or through group membership, but these permissions are limited to the standalone system and cannot extend across a domain. Here are some default accounts that are local to every windows system:

• Administrator: This account has full control over every file or resource on a Windows machine.
• SYSTEM: Also known as NT Authority\SYSTEM. This is THE default account on every Windows host. It is the account the operating system uses to perform its functions. SYSTEM has the highest permissions possible, and is sometimes compared to the ‘root’ account on Linux.
• Guest: Allows ‘guest’ users to log in with very limited permissions. It has no password and disabled by default.
• Network Service and Local Service: These two are used to run Windows Services. Network Service has more privileges for connecting to remote services.

Custom local accounts are usually only created on machines that are not connected to a domain.

Domain-Joined Accounts

Domain user accounts, on the other hand, have broader capabilities, as they are managed through the domain and can access shared resources like file servers, printers, and file shares. Unlike local accounts, domain accounts allow users to log in from any host within the domain.

Common Active Directory Tasks

Creating New Organizational Units

The way organizational units are set up can look different from one network to the next. From what I have read, OU creation should be based on how group policy objects need to be assigned to specific AD objects. For example, maybe the OU labeled “HR Department” needs a group policy object made specifically for delegating resources that only “HR” needs to access. It’s also best practice to try to keep your OU structure as simple as possible. Complex structures may be difficult to reverse or change in the future.

In my homelab, I make up a fake scenario where my organization needs an organizational unit for its main office branch. So I created an OU named ‘Main Branch. To do this, I opened the ‘Active Directory Users and Computers’ tool.

Server manager > ‘Tools’ tab > ‘Active Directory Users and Computers’.

Then I right clicked on my domain, clicked ‘New’, and clicked ‘Organizational Unit’ (shown below).

I named it ‘Main Branch’.

The main consensus I found in sysadmin forums and YouTube tutorials is that user accounts and computers should always be kept in separate OUs. Therefore, I created two OUs for each group.

Next, I moved the one computer I had connected to AD from the ‘Computers’ container to the ‘Domain Computers’ organizational unit I had just created.

Now I need some users for the Domain Users OU.

Creating User Accounts

Creating new user accounts is a common task for admins that work with Active Directory. To create a new user, right click on the OU that you want to store the user in, and click New > User.

Next, fill in the user’s basic information. Note that it’s also important to follow a specific naming convention for usernames. It also gives you the option to choose which domain to assign it to, so make sure you assign the correct one.

Example: flast@domain.local (first initial, last name, all lowercase).

Now set the password and set the password policy. (Password policies should really be managed by Group Policy Objects but we can also do it here).

After that, review the user information and click finish.

Now we can see the new user in the OU and we can finally log in a computer using an actual domain user.

Below is a screenshot of the computer ‘WS-01’ where I logged in using my new domain user account.

Resetting Passwords

One task admins will definitely encounter daily is password resets. People forget passwords all the time, so it’s important for every entry level IT professional to know how to reset them properly.

Steps:

1. In the “User and Computers” tool, use the search feature to search the users name.
2. When you find the user, right click and check the user’s properties to verify that is the correct user. You can ask the owner to repeat their username to you to verify it’s correct. You never want to reset the wrong user.
3. Set up a temporary password for the user and check the box that forces the owner to change it at next logon.
4. Send the temporary password through a secure communication channel. This is usually done through email.
5. The user should now be able to create a new password for their account.

Managing Groups and Memberships

Groups are a little different from Organizational Units. As I mentioned before, OUs are meant for organizing the directory to deploy Group Policy Objects (GPOs). It’s common to create OUs for an organization’s departments or office branches. Groups are mainly used for assigning rights and permissions to User and Computer objects.

To create a group in Active Directory, first open the “Active Directory Users and Computers” settings. Then right click the Organizational Unit or existing Group that the new group will live in. In my case, that is the “Domain Users” OU I created before. Hover over “New” and click “Group”. A “New Object” window should appear.

Types of Groups

When creating a group, you will be prompted to choose a group type. There are actually two types of groups that can be created. Security groups and Distribution groups.

• Security Groups: These are the groups we mostly think about in Active Directory. They are for assigning rights and permissions to a collection of objects. Any user or computer inside of a group will inherit the rights and permissions of that group.
• Distribution Groups: These groups have a completely different role. They are used by email systems, like Exchange, to send emails to groups of email recipients. They work kind of like mailing lists.

Group Scope

You will also be prompted to choose the group’s scope. You get three choices: Domain Local, Global, or Universal.

• Domain Local Groups: This group scope is limited to the domain where the group exists. It is mostly used to assign permissions to resources within the same domain. It can include members from the same domain AND members from other domain within the forest.
• Global Groups: This scope can give members of a group access to resources in a different domain, as well as the same domain (as long as their in the same forest). Global groups can only contain members from the same domain.
• Universal Groups: This scope extend across multiple domains within the same forest, as well as some domains inside trusted forests. Members can be included from any domain from the same forests. The caveat for using universal groups is that they have to be replicated to the Global Catalog. This can increase traffic within the network.

In my case, I chose to name the group “IT”, chose the “Security” type, and chose “Global” for the scope.

Adding Users to a Group

Groups need members. Here’s how to add a user to the group we just created:

1. Right-click on the group you want to add a user to. Click Properties. Then click on the “Members” tab and click the “Add…” button.
2. Under “Enter Object Names”, enter the user’s full name or username. Then click “Check Names”, which should autocomplete the entry. Then click “Okay”.
3. Click “Apply” to the Properties window, then “Okay”.
4. Your user should now be part of the new group.

Disabling Accounts

Just like creating new users, removing a user’s access to the network is also an important day-to-day job for a domain administrator. Whenever an employee gets terminated or quits, their access to the network needs to be revoked in order to prevent security risks. Although the employee is gone, it is also important to not delete the user object for reasons such as auditing, data retention, or even the chance of that employee getting rehired. The best option is to simply disable the account for a certain amount of time, rather than delete it.

Steps to disable user accounts:

1. Create a new organizational unit called “Disabled Users”.
2. Find the user you want to disable, right-click on it, and click on “Disable Account”. An alert window should appear and say that the account is disabled.
3. Finally, move the disabled account out of its original OU, and into the newly created “Disabled Users” OU. You can simply drag it, or you can right-click and choose the “Move” option.

At this point, the user should not be able to log in anymore. If they try, they would see the message shown below.

Group Policy Objects

Group Policy is a tool that helps IT administrators manage user and computer settings across a network. Think of it as a way to enforce rules or configurations for multiple devices at once, like setting up default wallpapers, blocking certain applications, or managing security settings. It works by linking ‘Group Policy Objects‘ (GPOs) to Organizational Units, which then apply those settings to the users or computers in those OUs. This makes it super efficient for handling large networks because you don’t have to configure settings on each device individually. It’s all centralized.

Creating and Linking Group Policy Objects

Tools like PowerShell and Command Prompt (CMD) are powerful command line interfaces that IT administrators utilize to perform their duties. It’s important that the correct users have access to those tools, but for other types of users (non-IT accounts), access to these tools maybe introduce risks to the network. Employees in the Sales department should not be making their own changes or running scripts on their workstations. Their accounts could also be compromised through phishing campaigns or other methods. That is why tools like PS and CMD should be disabled for most users in a domain.

The problem is, there may be hundreds or even thousands of users in a domain that will require changes in their settings. Making these changes one by one would be daunting, so that is where Group Policy comes in.

In my lab, I went ahead and created a few more organizational units representing some of the ‘made-up’ organization’s departments: Sales, Legal, Management, and Security. I also created new users for each department.

Let’s say I was assigned a task to disable both PowerShell and Command Prompt for all users in the Sales Department. To do this, I first need to open the ‘Group Policy Management’ tool. Using the Server Manager, click on the ‘Tools’ tab, then click ‘Group Policy Management’ in the drop-down menu.

Once GPM is open, navigate to the organizational unit where the Group Policy Object needs to be applied.

For me that’s Forest > Domains > (my domain) > “Main Branch” OU > “Domain Users” OU > “Sales” OU.

Right click on the OU, and select “Create a GPO in this domain and Link it here“.

Name the GPO whatever you like, maybe “Disable PowerShell and CMD”. Then click OK.

Next, right-click the GPO and select “Edit”. This opens the Group Policy Management Editor.

Navigate to: User Configuration > Policies > Administrative Templates > System. Then double-click on “Prevent access to the command prompt”.

Select “Enabled”, and in the “Options:” section, set “Disable the command prompt script processing also?” question to “Yes”. Click “Apply” and then “OK”.

Now we disable PowerShell by adding the policy called “Don’t run specified Windows applications“. It should be located in the same place as the last one:

User Configuration > Policies > Administrative Templates > System

Again, once you find it, double-click on it and select “Enabled”. Under “Options”, click the “Show…” button and add the following entries:

• powershell.exe
• powershell_ise.exe

After that, click “OK” and then apply the settings like last time. Now the GPO should be linked automatically, but you can also do this manually for other OUs by right-clicking the OU and clicking “Link an existing GPO…“.

Group Policy Objects do not take effect immediately. It could take anywhere between 30 to 120 minutes for that to happen. You can force a Group Policy Update by entering this command in CMD as the Domain Administrator:

gpupdate /force

Finally, we can test our new GPO by booting a workstation and logging into an affected user.

After logging into a user account in “Sales”, I tried to open Command Prompt and got this message:

PowerShell also does not open at all. Therefore, I can say that this Group Policy Object did its job.

Order of Precedence

Sometimes multiple Group Policy Objects will be influencing the same setting. This conflict forces one GPO to take precedence over (or ‘write-over’) the rest, based on a specific “Order of Precedence“:

1. Local Group Policy (least significant)
   • Local GPOs are the “first applied” GPOs and are least important.
   • These are configured locally on each Windows computer, and are usually only used if not connected to the domain.
   • They are only applied if there are no other applicable GPOs that are considered “more important”.
2. Site Policy
   • Next, Site GPOs will write-over Local GPOs, as they are considered more “important” or “significant”.
3. Domain Group Policy
   • GPOs applied and linked to the domain.
   • They take precedence over Local and Site GPOs.
4. Organization Unit (Parent)
   • GPOs applied and linked to an OU.
   • Over-write domain, site, and local GPOs.
5. Sub-Organizational Unit (Child)
   • GPOs applied to sub-OUs will take precedence over any GPO applied to its “Parent” OU.
6. Enforced GPOs (Most Significant)
   • Most significant ‘level’.
   • Any GPO with the “Enforce” option checked will take precedence over anything else.
   • This means that if a ‘Local’ GPO is ‘enforced’, it can take precedence over GPOs in “more significant” levels, as long as they are not “enforced”. If two GPOs from different levels are set to “enforced”, then their precedence revert back to the previous rules.

Other Factors for Precedence

If two GPOs are both enforced and linked in the same ‘level’ (making them tied), then these could be possible tie breakers:

• Computer vs User GPOs
  • GPOs under the ‘User Configuration’ category are more significant and take precedence.
  • ‘Computer Configuration’ GPOs are less significant.
• Blocked Inheritance Option
  • If an OU has the “blocked inheritance” option checked, then any GPO applied to a higher level (like the domain) will not take effect.
  • Blocked inheritance still gets canceled out if a GPO is “enforced” in the parent OU, domain, site, or local levels.

End of Part 2

Well, this post ended up being much longer than I intended at first, and I have not even scratched the surface of this topic. If I ever do a Part 3, it will most likely be about using PowerShell scripting to automate tasks in AD. Active Directory is one of the most important tools in the IT industry, so at the very least, getting familiar with it is a step in the right direction for any student or aspiring systems admin.