In Active Directory (AD) environments, you can use Group Policy Objects (GPOs) to configure user rights. By using GPOs, you can easily enforce consistent user rights policies across all computers in the domain or organizational unit (OU). This capability makes it easier to manage and maintain user access control over time. But when granted to users who should not have them or when configured incorrectly, certain user rights can pose an AD security risk. Here’s what you need to know to protect AD—and your environment—from risky user rights.
What are user rights?
User rights are permissions that control user actions on a computer system. These rights differ from standard file and folder permissions and apply to specific user actions. User rights include (but are not limited to):
Allow log on locally: Allows users to log on to a computer locally
Change the system time: Allows users to change the system time on a computer
Shut down the system: Allows users to shut down the computer
Debug programs: Allows users to debug programs running on the computer
Manage auditing and security log: Allows users to view and manage security logs on a computer
Take ownership of files or other objects: Allows users to take ownership of files or other objects on a computer
Load and unload device drivers: Allows users to load or unload device drivers on a computer
Back up files and directories: Allows users to back up files and directories on a computer
Restore files and directories: Allows users to restore backed-up files and directories on a computer
Allow log on through Remote Desktop Services: Allows users to manage remote access to a computer
Using GPOs to configure user rights
To configure user rights using a GPO, first create or edit a GPO that applies to the users or computers that you want to configure. You need to link the GPO to the relevant domain or OU level. Then, you can use the Group Policy Editor application to specify the user rights that you want to assign. (A similar process applies to configuring GPO logon scripts, as discussed in a previous AD Security 101 post.)
To configure user rights:
Open Group Policy Editor.
Go to the Computer Configuration section.
Select Windows Settings.
Select Security Settings.
Go to the Local Policies section.
Select User Rights Assignment.
Select the user right that you want to configure.
Add the users or groups that should be granted that right.
For example, to grant a user the right to log on locally to a specific computer, select the Allow log on locally user right and then add the user to the list of allowed users.
Risky user rights and AD security
How can user rights pose a security risk? Consider the following example.
Suppose the Debug programs user right is granted to a user who does not need it. That user—or an attacker who manages to gain access to that user’s credentials—can use this right to:
Debug a system process that runs as an elevated user
Inject malicious code
Gain system-level access
Access sensitive data or processes that they would not normally have access to
Disable security features or anti-malware tools on the system
Similarly, if the Change system time user right is granted to a user who should not have the right, that user (or an attacker) can modify the system time and cause issues with time-sensitive applications or services.
Additional potentially risky user rights include:
Log on as a service
Allow log on locally
Act as part of the operating system
To determine which user rights are assigned to a user in AD, you can open the right for editing in the Group Policy Management Console (GPMC). Another option is to use GPO command-based tools (CLI or PowerShell) to check GPOs and their respective settings, including user rights assignments.
However, large organizations with thousands or more user objects and OUs can have tens or hundreds of GPOs, each containing multiple accumulated (and often overlapping) settings. For example, a domain-level GPO might assign specific user rights to one set of users or groups, while another OU-level GPO might add other user rights to some of those same users or groups.
As your AD environment evolves and changes over time, the complexity of the GPOs assigned to domain, sites, or OUs typically also increases. All these assignments gradually become more difficult to manage, making it challenging to determine which setting applies to which user.
Protecting AD from risky user rights
To mitigate the risks associated with a user right:
Verify that the right is granted only to users who require it for specific tasks.
Carefully monitor all users who are assigned the right.
Protect sensitive processes so that they cannot be debugged by unauthorized users.
To ease the task of continuously assessing your AD security posture—including potentially risky user rights—you can use tools such as Purple Knight or Semperis Directory Services Protector (DSP). When executed in your environment, these tools enumerate and parse all GPOs, determine whether any non-well-known SID has been assigned a “strong” non-default user right, and generate a clear report of these details. You can examine these findings to determine which unnecessary user rights to remove from the GPOs in your environment.
Using Purple Knight to secure risky user rights
Figure 1 shows a Purple Knight report indicating the assignment of a dangerous GPO-granted user right.
Figure 1. Purple Knight report of risky user right
The report shows the severity of risk, describes the likelihood of compromise, lists the users who are assigned the right, and suggests remediation measures.
Using DSP to secure risky user rights
Figure 2 shows a DSP report indicating the assignment of a dangerous user right.
Figure 2. Semperis DSP report of risky user right
This report includes the same details as the Purple Knight report. With DSP, you also gain remediation capabilities, including custom alerts and automatic rollback of malicious changes, to help you mitigate the risk.
Keep tabs on risky user rights
After mitigating any risky user rights assignments, you should re-scan the AD environment to determine whether additional changes are required. You should continue to perform periodic scans of your AD to verify that no unauthorized changes are made to these settings.