Active Directory

Accounts

Accounts represent the identities of security principals in an Active Directory environment. The most common type of account is a user account, which represents a person as they interact with the Windows environment. IT Ops personnel also need to regularly deal with computer accounts, group accounts, and service accounts.

User accounts

User accounts almost always represent real people in an Active Directory environment, with the caveat that some user accounts are used for services rather than traditional users signing in to their desktop computers.

In many organizations, a user account is nothing more than a username, a password, and a collection of group memberships. User accounts can contain substantial additional information, including

• First name

• Last name

• Middle initial

• Full name

• Office information

• Email address

• Web page

• Job title

• Department

• Company

• Manager

• Phone numbers (main, home, mobile, fax, pager, IP phone)

• Address

• User profile location

• Log-on script

• Home folder

• Remote desktop service profile

• Dial-in permissions

• Published certificates

• Remote Desktop Sessions settings

• Remote Control settings

You should configure important accounts to be protected from deletion by enabling the Protect From Accidental Deletion option, as shown in Figure 4-20. Unless this option is removed, the account can’t be deleted. This setting doesn’t stop an account from being removed deliberately, but it does stop the account from being deleted accidentally.

Computer accounts

Computer accounts represent the computer within Active Directory. You often move computer accounts to specific OUs and then apply group policies to those OUs as a way of configuring the computer. When you join a computer to the domain, the computer account is automatically placed in the default Computers container.

If a computer account becomes desynchronized from the domain of which it is a member and loses its trust relationship, you can repair the relationship by signing in with the local Administrator account and running the following PowerShell command:

If you don’t know the local Administrator account password but suspect that cached domain administrator credentials might be present, disconnect the computer from the network, either by physically removing the Ethernet connection or disconnecting the virtual network adapter, sign in using those credentials, and then run the PowerShell command previously mentioned. The Local Administrator Password Solution, which ensures that you don’t forget the local Administrator account password, is covered in Chapter 12.

Group accounts

Active Directory supports three different types of group account scopes: domain local, global (the default), and universal. It also supports two group types: Security and Distribution. You use security groups to control access to resources, delegate permissions, and for email distribution. Distribution groups can only be used for email distribution. If your organization uses Exchange Server, you manage distribution groups through Exchange. Best practice is to place users within global groups, add those global groups to domain local groups, and assign permissions and rights directly to the domain local groups. By default, members of the Account Operators, Domain Admins, or Enterprise Admins groups can modify the membership of groups.

Universal

A universal group can hold accounts and groups from the same forest. Universal groups are stored in the global catalog. If you change the membership of a universal group, this change replicates to all global catalog servers in the forest. Universal groups are great in single forest environments where replication traffic isn’t an issue or where there are few changes to universal group membership. Universal groups can be nested within other universal groups, or they can be added to domain local groups.

Global

Global groups can contain user accounts from their home domains. Global groups can also contain other global groups from its home domain. Global groups can be members of universal groups and domain local groups.

Domain local

Domain local groups can have universal groups, global groups, and domain local groups as members. Domain local groups can host accounts from any domain in the forest and accounts from domains in trusted forests. Domain local groups can only be added to domain local groups within their own domain. A domain local group can only be assigned rights and permissions within its own domain. Domain local groups cannot be added to global or universal groups.

Default groups

The groups listed in Table 4-2 are included in a Windows Server domain by default.

Table 4-2 Important groups

Group	Function
Access Control Assistance Operators	Members can query authorization attributes and permissions for resources on the computer.
Account Operators	Members can manage domain user and group accounts.
Administrators	Built-in administrators group. On a DC, this provides unlimited access to the computer and domain.
Allowed RODC Password Replication Group	Members can have their passwords replicated to RODCs.
Backup Operators	Members can override security restrictions to back up or restore files.
Cert Publishers	Members can publish certificates to AD DS.
Certificate Services DCOM Access	Members can connect to Certification Authorities.
Cloneable Domain Controllers	Domain controllers that can be cloned.
Cryptographic Operators	Can perform cryptographic operations.
Denied RODC Password Replication Group	Members cannot have their passwords replicated to RODCs.
Distributed COM Users	Can launch, activate, and use Distributed COM objects.
DNSAdmins	DNS administrators group.
DNSUpdateProxy	Group for DNS clients who are able to perform dynamic updates on behalf of services, such as DHCP servers.
Domain Admins	Members can administer the domain. Automatically add members of the local Administrators group on every computer in the domain. The default owner of all objects created in Active Directory.
Domain Computers	All computers that are members of the domain.
Domain Controllers	All domain controllers in the domain.
Domain Guests	Hosts the built-in domain guest account.
Domain Users	Hosts all user accounts in the domain.
Enterprise Admins	Only present in the root domain of a forest. Can make forest-wide changes, such as raising the forest functional level or adding domains.
Enterprise Key Admins	Members can perform administrative tasks on key objects at the forest level.
Enterprise Read-only Domain Controllers	Group for enterprise read-only domain controllers.
Event Log Readers	Can view the contents of event logs on the computer.
Group Policy Creator Owners	Members can create and modify GPOs.
Hyper-V Administrators	Can manage Hyper-V on the local machine.
IIS_IUSRS	Internet Information Services built-in group.
Incoming Forest Trust Builders	Members can create incoming, one-way trusts to the forest.
Key Admins	Members can perform administrative tasks on key objects at the domain level.
Network Configuration Operators	Members can configure networking features.
Performance Log Users	Members can schedule logging of performance counters and collect event traces.
Performance Monitor Users	Members can access performance counter data locally and remotely.
Pre-Windows 2000 Compatible Access	A group that exists for backward compatibility.
Print Operators	Members can manage printers deployed on domain controllers.
Protected Users	Members of this group have stricter security controls applied to their accounts.
RAS and IAS Servers	Members in this group are able to access the remote access settings of user accounts.
RDS Endpoint Servers	Servers in this group host VMs used with RemoteApp programs and personal virtual desktops.
RDS Management Servers	Servers in this group can perform administrative actions on other servers running the Remote Desktop Services role.
RDS Remote Access Servers	Servers in this group enable users of RemoteApp programs and personal virtual desktops to access resources.
Read-only Domain Controllers	Read-only domain controllers in the domain.
Remote Desktop Users	Granted the right to sign on using Remote Desktop.
Remote Management Users	Members can access WMI resources over management protocols.
Replicator	Group supporting file replication at the domain level.
Schema Admins	Root domain group. Members are authorized to make changes to the Active Directory Schema.
Server Operators	Members can administer domain member servers.
Storage Replica Administrators	Members can manage storage replicas.
Terminal Server License Servers	Members can update Active Directory information about terminal services licensing.
Users	Built-in Users group.
Windows Authorization Access Group	Have access to the computed tokenGroupGlobalAndUniversal attribute on User objects.

Service accounts

Service accounts are functionally user accounts used by services to interact with the operating system and resources on the network. By assigning rights to the service account, you can limit what the service can or cannot do.

One of the key things to remember about a service account is that it should not have the right to log on locally to a computer but should have the log on as a service right. This is important because administrators in many organizations have bad habits where they grant service accounts unnecessary rights and even go as far as to give all service accounts the same non-expiring password. Sophisticated attackers know this and use this to compromise service accounts and use them as a way to gain privileged access.

Local System

The Local System (NT AUTHORITY\SYSTEM) account is a built-in account. It has privileges equivalent to a local administrator account on the local computer. It acts with the computer account’s credentials when interacting on the network. This is the most powerful service account, and generally, you should be reluctant to assign this service account manually to a service given its extensive privileges.

Local Service

The Local Service (NT AUTHORITY\LocalService) account has the same level of privilege as user accounts that are members of the local Users group on a computer. This account has fewer local privileges than the Local System account. Any services assigned to this account access network resources as a null session without credentials. Use this account when the service doesn’t require network access or can access network resources as an anonymous user and requires only minimal privileges on the computer it is being used on.

Network Service

The Network Service (NT AUTHORITY\NetworkService) account is similar to the Local Service account in that it has privileges on the local computer equivalent to those assigned to a member of the local Users group. The primary difference is that this account interacts with the computer account’s credentials to access resources on the network.

GMSA

A group managed service account (GMSA) is a service account that is managed by the domain. This means that rather than having to update the service account’s password manually, Active Directory updates the password in line with the domain password policy. Many organizations that use regular user accounts as service accounts tend to set a static password for these accounts, which is often simple rather than complex.

Group Managed Service Accounts require the forest functional level to be Windows Server 2012 or higher. Forests at the Windows Server 2008 level support a version of a GMSA called an MSA, but this is more limited than a GMSA, with each MSA only being able to be installed on a single machine.

Prior to using GMSAs, you’ll need to create a Key Distribution Services (KDS) root key. You can do this with the following command:

You manage GMSAs using Windows PowerShell. To create a GMSA, specify the name of the account, a DNS hostname associated with the account, and the name of the security principals that are allowed to use the account. For example, to create a GMSA named MEL-SQL-GMSA for the contoso.internal domain that can be used by servers in the MEL-SQL-Servers security group, enact the following command:

To install the account on a specific server so that you can use it, run the Install-ADServiceAccount cmdlet. For example, to install the MEL-SQL-GMSA account on a server so that you can assign the account to services, enact the command:

Prior to running this command, you may need to install the RSAT ADDS Tools on the local server. You can do this by running the command:

When assigning the account to a service, you should clear the Password and Confirm Password textbox. You’ll need to append $ to the account name when configuring it as shown in Figure 4-21. Windows Server recognizes that the account is a GMSA and manages the password settings.

dMSA

A Delegated Managed Service Account (dMSA) is a new type of service account introduced in Windows Server 2025. dMSAs are tied to specific machine identities in Active Directory, ensuring that only designated devices can authenticate using the account. This binding enhances security by preventing unauthorized use of service account credentials. dMSAs benefit from automatic password management, with secrets stored exclusively on domain controllers.

When used with Credential Guard, dMSAs leverage virtualization-based security to protect secrets, mitigating risks associated with credential theft techniques like Kerberoasting.

To install and configure a dMSA, ensure that the KDS root key exists using

Create the dMSA using the following PowerShell command:

Use the following command to allow a specific computer account to interact with the dMSA password, substituting Machine$ with ComputerName$:

Configure the appropriate delegation state using the following command:

Then, on the target computer, run the following command to install the dMSA:

You can then configure a service to use the dMSA by setting the service to log on as the dMSA account in the format domain\dMSA$.

Virtual account

A virtual account is the local equivalent of a group-managed service account. Virtual accounts are supported by products such as SQL Server as an alternative to the default built-in accounts. You can create virtual service accounts by editing the properties of a service and setting the account name to NT Service\<ServiceName>.

Kerberos delegation

Kerberos constrained delegation restricts how and where application services can act on a user’s behalf. You can configure accounts so that they can be used only for specific tasks. For example, Figure 4-22 shows configuring the delegation of the account for computer SYD-B, for delegation through Kerberos, for the time service on computer SYD-A. You can configure Kerberos delegation using the Set-ADComputer, Set-ADServiceAccount, and Set-ADUser cmdlets with the PrincipalsAllowedToDelegateAccount parameter.

Kerberos policies

Kerberos policies determine how the service and user tickets are used in the Authentication function in an Active Directory domain. Like password and account lockout policy, Kerberos policy is applied at the domain level. Kerberos policies applied at the site and organizational level do not affect the resultant Kerberos policy. Kerberos policies are located in the Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Kerberos Policy node.

You can configure the following Kerberos policies:

• Enforce User Logon Restrictions Ensures that Kerberos checks every request for a session ticket, also known as a service ticket.

• Maximum Lifetime For Service Ticket Configures the maximum lifetime of a service ticket, which is also known as a session ticket. The default value for this policy is 10 hours. The value of this policy must be less than or equal to the value specified in the Maximum Lifetime For User Ticket policy.

• Maximum Lifetime For User Ticket Determines the maximum lifetime of a user ticket, also known as a ticket-granting ticket (TGT). The default value of this policy is 10 hours.

• Maximum Lifetime For User Ticket Renewal Specifies the maximum TGT renewal period. The default is seven days.

• Maximum Tolerance For Computer Clock Synchronization Specifies how much drift there can be in domain controller clocks before ticket errors occur. The default setting is five minutes.

Service principal name management

Kerberos clients use a service principal name (SPN) to identify a unique instance of a service on a given computer. If there are multiple instances of the same service hosted on computers in a domain or forest, each service requires a unique SPN. Service instances can be configured with multiple SPNs, as long as those SPNs are unique.

You can use the SetSPN command-line utility to configure SPNs for computers running Windows Server. SetSPN uses this syntax: setspn serviceclass/host:portnumber servicename. You can use SetSPN /? to see a list of all SPN switches. For example, to register the HTTP service using the standard port on a computer named MEL-DC in the contoso.com domain using a GMSA named SYD-SRVC, issue this command: