Users and groups are, undeniably, the bread and butter of Active Directory (AD). When there is something wrong, missing, or absent in these two object types, service desk personnel will be the first to know because colleagues will ring the number for help. On the other hand, when an error is in a colleague's personal interest, due to lingering privileges or absent identity and access management (IAM) processes, don't expect a call.
It's imperative to get users right. It is estimated that 20% of all information technology (IT) costs in typical organizations are related to password resets and account lockouts. As colleagues use their accounts for authentication, any hiccup will inevitably result in a loss of productivity.
A best practice is to cooperate with the Human Resources (HR) department for user creation and user expiration. HR people know when a contract is (to be) terminated, which can help in setting up account expiration. They also know when a person is on maternity leave or taking a sabbatical. We wouldn't want to automatically delete the accounts of these people based on their apparent inactivity, right?
It's also important to get group memberships right. In most organizations, groups govern access to applications and roles and/or privileges within applications. Colleagues without the right privileges might not be productive. Colleagues with too many privileges might inadvertently cause the application to be unavailable, delete data, or have access to data they shouldn't have access to. These confidentiality, integrity, and availability issues can easily be avoided by revoking access through regular access review processes by application owners.
The following recipes are covered in this chapter:
Let's jump into the recipes. Many recipes offer a couple of ways to achieve the same goal. While using Active Directory Users and Computers (dsa.msc) is still commonplace, some administrators have discovered the benefits of using the Active Directory Administrative Center (dsac.exe) and its Windows PowerShell History Viewer to learn the underlying PowerShell cmdlets of their clicks. PowerShell can then be used to automate everything as efficiently as possible; for complex actions you have to perform three times or more, it's better to automate.
Use this recipe to create a User object.
To create a user object, sign in to a domain controller or a member server and/or device with the Remote Server Administration Tools (RSAT) for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group or the Account Operators group or with an account that is delegated to create user objects in the domain or scope of the organizational unit (OU) in which user objects are to be created.
There are four ways to create a user object:
To create a user using Active Directory Users and Computers, follow these steps:
To create a user using the Active Directory Administrative Center, follow these steps:
Use the following command to create a user object in Active Directory:
dsadd.exe user 'CN=User,CN=Users,DC=LucernPub,DC=com' -upn [email protected] -fn 'User's First Name' -ln 'User's Last Name' -display 'User' -pwd 'PasswordHere'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields to represent your user's properties.
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed:
New-ADUser -Name User -Path 'CN=Users,DC=LucernPub,DC=com' -GivenName 'User's First Name' -Surname 'User's Last Name' -sAMAccountName user
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields to represent your user's properties.
When you create a user object, some fields are automatically populated and many settings are default settings, including the User must change password at next logon setting. These settings are recommended but can be changed after creating a user, either in the UI or through commands.
A descriptive name for every user object is mandatory to ensure the user object can be identified in the graphical interface and in auditing scenarios. Many applications, including Microsoft Exchange Server, use the first, last, and/or full name to create their own default attributes and settings.
When you create a user object, the object consumes a relative identifier (RID) and Distinguished Name Tag (DNT). Pre-Windows 2000 username is usually the username people in the organization use to sign in, but userPrincipalName can also be used in most scenarios. userPrincipalName is used when modern authentication protocols are utilized.
All organizations create user accounts differently. Configuration steps may vary and may or may not include profile-, Microsoft Exchange Server-, Terminal Server-, or Microsoft 365-specific steps. When additional steps are required, a work instruction is usually present.
Use this recipe to delete a previously created user object.
To delete a user account, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group or the Account Operators group or with an account that is delegated to delete user objects in the domain or scope of the OU where the user account is to be deleted.
There are four ways to delete a user object:
To delete a user using Active Directory Users and Computers, follow these steps:
To delete a user using the Active Directory Administrative Center, follow these steps:
Use the following command to delete a user object in Active Directory:
dsrm.exe user 'CN=User,CN=Users,DC=LucernPub,DC=com'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the distinguished name (DN) of the user object to represent your user's properties.
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed to delete a user object in Active Directory:
Remove-ADUser -Identity 'CN=User,CN=Users,DC=LucernPub,DC=com'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your user's properties. Alternatively, you can specify the objectGUID, objectSid, or sAMAccountName attribute to represent the user.
When you delete a user object, the object no longer uses its RID, but the RID and the corresponding security identifier (SID) and DNT in the domain partition cannot be reused.
When you attempt to delete a user object that has the Protect from accidental deletion option enabled, you will not be able to delete the object. The option needs to be disabled before this can be done.
Many organizations are wary of deleting user objects because they fear their auditing systems may no longer be able to put a name to the RID or corresponding SID. Instead, most of them opt to disable user objects. Unfortunately, many admins forget to actually delete user objects beyond the auditing retention period, getting stuck with numerous objects that take up space in the Active Directory database, making Active Directory more complex to manage.
When the Active Directory Recycle Bin is enabled, the deleted user object emerges in the Deleted Objects container.
Refer to the following recipes for more information:
Once a few user objects have been created, a need might arise to modify one attribute for all previously created user objects. Other scopes of user objects might also apply.
Modifying one user object is as simple as double-clicking on it in Active Directory Users and Computers or in the Active Directory Administrative Center. Modifying multiple objects at once is slightly different, and there are a couple of neat tricks you can use.
To modify user objects, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group or the Account Operators group or with an account that is delegated to manage user objects in the domain or scope of the OU where the user objects reside.
There are three ways to modify user objects:
Active Directory Users and Computers is ideal when you have simple scopes for user objects to modify. Through its selection mechanisms, admins can easily select all users in an OU or container (by pressing Ctrl + A) or select all users whose names start with A manually with the Shift button.
To modify multiple users using Active Directory Users and Computers, follow these steps:
The Active Directory Administrative Center allows for filters to scope user objects that you want to modify. Filters can be used on OUs and containers. Of course, you can use the same method for selecting users as you would in Active Directory Users and Computers.
To modify a selection of users using the Active Directory Administrative Center, follow these steps:
Note
When filtering using attributes, you can use matches such as starts with, equals, does not equal, is empty, and is not empty.
The Active Directory module for Windows PowerShell can be used to select multiple user objects. Modifications can then be applied to the scope of users using the piping mechanism in PowerShell.
As an example, use the following lines of PowerShell code on a system with the Active Directory module for Windows PowerShell installed to modify Prevent from accidental deletion for all user objects whose sAMAccountName attribute starts with service_:
Get-ADUser -ldapfilter '(sAMAccountName=service_*)' | Set-ADObject -ProtectedFromAccidentalDeletion $true
Since scoping in PowerShell is more advanced, this method is best used for modifying multiple user objects throughout the Active Directory forest and to modify user objects repeatedly.
Using filters, several user objects can be modified at once.
Not all attributes can be changed when multiple user objects are selected using Active Directory Users and Computers or the Active Directory Administrative Center. Typical attributes include those that are unique to a user object, such as userPrincipalName, sAMAccountName, and securityIdentifier.
When using the Active Directory Administrative Center (dsac.exe), the Windows PowerShell History feature can be used to find modifications on one user object from the UI in PowerShell. This way, modifications behind | can be found easily. To enable the Windows PowerShell History pane, perform these actions:
After creating a user, you might find that it should live in another OU or container. This recipe describes how to move a user object.
To move a user account, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group or the Account Operators group or with an account that is delegated to create and delete user objects in the domain or scope of the OUs where user objects are to be moved.
There are four ways to move a user object:
To move a user using Active Directory Users and Computers, follow these steps:
If this is an important user object, re-enable the Protect object from accidental deletion option.
To move a user using the Active Directory Administrative Center, follow these steps:
Use the following command to move a user object in Active Directory:
dsmove.exe 'CN=User,CN=Users,DC=LucernPub,DC=com' -newparent 'OU=Organizational Unit,DC=LucernPub,DC=com'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object and a new location to represent your scenario.
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed:
Move-ADObject -Identity:'CN=User,CN=Users,DC=LucernPub,DC=com' -TargetPath:'OU=Organizational Unit,DC=LucernPub,DC=com'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object and a new location to represent your scenario.
When you move a user object in Active Directory, it will effectively fall out of the scope of the parent OU or container. Therefore, the user object that is used for this purpose must have (delegated) permissions to delete user objects in the original location of the user object. Also, the user object cannot have the Protect from accidental deletion option enabled. This option needs to be disabled to avoid permissions errors.
Use this recipe to rename a previously created user object.
To rename a user object, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group or the Account Operators group or with an account that is delegated to modify user objects in the domain or scope of the OU where the user object resides.
There are four ways to rename a user object:
To rename a user using Active Directory Users and Computers, follow these steps:
To rename a user using the Active Directory Administrative Center, follow these steps:
Use the following command to rename a user object in Active Directory:
dsmove.exe 'CN=User,CN=Users,DC=LucernPub,DC=com' -NewName 'User Account'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
Use the following lines of PowerShell code on a system with the Active Directory module for Windows PowerShell installed:
Rename-ADObject -Identity 'CN=User,CN=Users,DC=LucernPub,DC=com' -NewName 'User Account'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
When you rename a user object, you change its Canonical Name (CN), its DN, and its name attributes. When you perform this action using Active Directory Users and Computers (dsa.msc), a helpful popup allows you to change any other name-related attributes.
Even though you use the dsmove.exe command, when you rename a user object on the command line, the Protect from accidental deletion option does not come into effect like it does when you move a user object. You will not need to disable this option first to rename a user object.
When you want a person in your organization to no longer be able to sign in interactively, you can disable the corresponding user object. Likewise, when a user object is disabled, you can opt to enable/re-enable it. Use this recipe to perform both actions.
To enable or disable a user object, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group or the Account Operators group or with an account that is delegated to modify user objects in the domain or scope of the OU where the user object resides.
There are four ways to enable or disable a user object:
To enable or disable a user using Active Directory Users and Computers, follow these steps:
To enable or disable a user using the Active Directory Administrative Center, follow these steps:
Use the following command to disable a user object in Active Directory:
dsmod.exe user 'CN=User,CN=Users,DC=LucernPub,DC=com' -disabled yes
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
Use the following command to (re-)enable a user object in Active Directory:
dsmod.exe 'CN=User,CN=Users,DC=LucernPub,DC=com' -disabled no
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed to disable a user object:
Disable-ADAccount -Identity 'CN=User,CN=Users,DC=LucernPub,DC=com'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed to (re-)enable a user object:
Enable-ADAccount -Identity 'CN=User,CN=Users,DC=LucernPub,DC=com'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
When a user object is disabled, it can no longer be used to sign in.
When an account is enabled, you can use the right-click menu in Active Directory Users and Computers or use the TASKS menu in the user object's properties in the Active Directory Administrative Center to disable it. When it's disabled, you can enable it in the same menus. The two menu options are not available at the same time.
Even though interactive sign-ins are disabled when a user object is disabled, they can still be used for Kerberos constrained delegation (KCD) and other delegation scenarios that don't check whether a user object is disabled.
User accounts may get locked out. In this recipe, we will see how to find locked-out accounts.
To find locked-out user accounts, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
By default, any user object in Active Directory can be used to find locked-out accounts, as this kind of information is available to the Everyone group.
There are two ways to find locked-out users:
The Active Directory Administrative Center allows for filtering locked-out user objects. Filters can be used on OUs and containers.
To find currently locked-out user objects using the Active Directory Administrative Center, follow these steps:
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed to find locked-out user accounts:
Search-ADAccount -LockedOut -UsersOnly | Format-Table Name,LockedOut -AutoSize
Any locked users can be manually unlocked or unlocked using a piping mechanism, as shown in the next recipe.
The Default Domain Policy contains password and account lockout policies. By default, the password part of these policies is enabled, but the lockout part is not. For some organizations, this makes sense. Other organizations might consider enabling account lockout, as it prevents brute-force password attacks; when a malicious person uses the maximum number of passwords within a certain time for a user account, the user account is locked out for a specified time. All three metrics can be set in the lockout part of password and account lockout policies.
For example, when an attacker or a clumsy colleague hits a maximum of five wrong passwords attempts in 2 minutes, the user object is locked out for 30 minutes.
From Windows Server 2008 Active Directory onward, fine-grained password and account lockout policies can be used to set the metrics for a specific user object or specific groups.
To unlock the user object(s) found in this recipe, see the Unlocking a user recipe.
In many organizations with account lock-out policies enabled, the number of passwords that can be mistyped is set to a high value (such as 50), and then the lock-out period is set to indefinitely. This way, a locked-out account hinders the productivity of colleagues since they can't sign in until the account is unlocked. Manual unlocks need to be performed to enable affected colleagues to sign in again.
To modify user objects, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group, the Account Operators group, or with an account that is delegated to manage user objects in the domain or scope of the OU where the user object resides.
This recipe shows two ways to unlock a user object:
To unlock a user object using the Active Directory Administrative Center, follow these steps:
To unlock all locked-out accounts in a certain OU or container, combine the steps from the Finding locked-out accounts recipe with steps 5 through 7.
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed to unlock a user object:
Unlock-ADAccount -Identity 'CN=User,CN=Users,DC=LucernPub,DC=com'
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
To unlock all locked-out accounts throughout the Active Directory domain, combine the commands from the Finding locked-out users recipe with the preceding lines of code in the following way:
Search-ADAccount -LockedOut -UsersOnly | Unlock-ADAccount
The preceding line of PowerShell code is specifically useful in situations where accounts are locked out after a brute-force password guessing attack, once the initial attack vector has been neutralized.
Many user objects' settings can be controlled using the userAccountControl attribute.
To set the userAccountControl attribute for users, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group.
The userAccountControl attribute can be managed in the following two ways:
There are three ways to read the userAccountControl attribute for users:
To read the userAccountControl attribute for users using Active Directory Users and Computers, follow these steps:
To read the userAccountControl attribute for users using the Active Directory Administrative Center, follow these steps:
To read the userAccountControl attribute for a specific user object using Windows PowerShell, use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell:
Get-ADUser -Identity 'CN=User,CN=Users,DC=LucernPub,DC=com' -Properties userAccountControl | Format-Table name,useraccountcontrol
Replace 'CN=User,CN=Users,DC=LucernPub,DC=com' with the DN property of the user account. This line of PowerShell code returns a table with the display name of the user object and the userAccountControl attribute.
To read the userAccountControl attribute for all users using Windows PowerShell, use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell:
Get-ADUser -Filter * -Properties userAccountControl | Format-Table name,useraccountcontrol
This line of PowerShell code returns a table with the display names of all user objects and their corresponding userAccountControl attributes.
There are two ways to set the userAccountControl attribute for users:
To set the userAccountControl attribute for users using ADSI Edit, follow these steps:
To set the userAccountControl attribute for users using Windows PowerShell, use the following lines of PowerShell code on a system with the Active Directory module for Windows PowerShell. Each of the following lines of code represents setting one of the bits in the userAccountControl attribute for user objects:
Set-ADAccountControl -Identity User -Enable $false
Set-ADAccountControl -Identity User -HomedirRequired $true
Set-ADAccountControl -Identity User -PasswordNotRequired $true
Set-ADAccountControl -Identity User -CannotChangePassword $true
Set-ADAccountControl -Identity User -AllowReversiblePasswordEncryption $true
Set-ADAccountControl -Identity User -PasswordNeverExpires $true
Set-ADAccountControl -Identity User -MNSLogonAccount $true
Set-ADAccountControl -Identity User -TrustedForDelegation $true
Set-ADAccountControl -Identity User -AccountNotDelegated $true
Set-ADAccountControl -Identity User -UseDESKeyOnly $true
Set-ADAccountControl -Identity User -DoesNotRequirePreAuth $true
Set-ADAccountControl -Identity User -TrustedToAuthForDelegation $true
Within Windows PowerShell, the userAccountControl attribute is not directly changed. Instead, the major implications of changing the attribute define how to achieve this.
Many individual settings and options for user objects are stored in the userAccountControl attribute. While administrators can set these options through the UI, they can also be set by modifying the userAccountControl attribute itself.
Additionally, the userAccountControl attribute can also be used in scripts to find user objects with specific sets of values.
The userAccountControl attribute defines a lot of properties for any user and/or computer object. The value for this attribute is built up of bits; every value is a (combination of) 2x value(s):
Except for SCRIPT, LOCKOUT, TEMP_DUPLICATE_ACCOUNT, and PASSWORD_EXPIRED, all flags can be set on user objects by an administrator. NORMAL_ACCOUNT doesn't need to be set, as it is set by default on user objects.
SMARTCARD_REQUIRED isn't set this way because it requires certificates and other prerequisites. It would make for an excellent denial-of-service (DoS) attack vector if this flag could be set.
The INTERDOMAIN_TRUST_ACCOUNT, WORKSTATION_TRUST_ACCOUNT, SERVER_TRUST_ACCOUNT, and PARTIAL_SECRETS_ACCOUNT flags do not apply to user objects.
User objects can be set to automatically expire.
To set account expiration for a user object, sign in to a domain controller or a member server and/or device with RSAT for Active Directory Domain Services installed.
Sign in with an account that is a member of the Domain Admins group or the Account Operators group or with an account that is delegated to modify user objects in the domain or scope of the OU where the user object resides.
There are four ways to do this:
The two graphical tools are useful for configuring account expiration on individual accounts, although the Active Directory Administrative Center can be used to retrieve the Windows PowerShell cmdlets through the Windows PowerShell History feature.
The command-line tool is particularly useful when you want to configure a time frame (in days) for the account to live on, instead of defining an end date.
To set account expiration for a user using Active Directory Users and Computers, follow these steps:
To set account expiration for a user using the Active Directory Administrative Center, follow these steps:
Use the following command to set the days before an account expires in Active Directory:
dsmod.exe user 'CN=User,CN=Users,DC=LucernPub,DC=com' -acctexpires 90
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
Use the following line of PowerShell code on a system with the Active Directory module for Windows PowerShell installed to set account expiration for a user object:
Set-ADAccountExpiration -Identity "CN=User,OU=Organizational Unit,DC=LucernPub,DC=com" -DateTime "03/01/2027 00:00:00"
Replace DC=LucernPub,DC=com to represent your environment. Replace the other fields in the DN of the user object to represent your scenario.
User objects can be configured with expiration dates. After this moment in time, the user object can no longer be used to authenticate, including when using KCD.
After the expiration date is set, it is stored in the accountExpires attribute. The 64-bit value stored for this attribute represents the number of 100-nanosecond intervals since January 1, 1601 (Coordinated Universal Time, or UTC).
Account expiration is a good way to fill in communication gaps between HR and IT in the joiners, movers, and leavers process for IAM.
In an organization where account expiration is used, the end date of the HR contract is typically used to ensure the user object automatically expires when the person would normally leave the organization. Of course, in some organizations, a couple of days are added to allow access to the expenses system and other services the organization offers to people leaving the organization.
There are some caveats, though. For external hires who are normally hired based on project contracts, account expiration may be bothersome. Additionally, people who are on extended leave or travel beyond the end of their contract may be impacted too.
18.217.228.35