Last time, I talked about the importance and effects that Restricted Group settings can have on your network. Another powerful group policy setting that system administrators can employ is User Rights Assignments. What are User Rights Assignments? These settings define who can log on to a system and what method they can use to log on. Most users think that when logging on to a system, you generally are sitting at a keyboard, typing in your username and password. However, there are many other ways that domain logons can occur.
One example is an administrator using a command line terminal to connect to a remote machine. This logon is governed by the “Access to this computer from the network” User Right Assignment. Another way an account can log on to the domain is through system services like Microsoft Exchange, or it can be granted the ability to use Remote Desktop Protocol (RDP). Along with these types of logons, User Rights Assignments can grant powers to accounts when they log on. Some of these powers include the privilege to shut down a machine, change system time, or, more dangerously, debug programs or “Act as part of the operating system”.
As always, Microsoft’s Technet has a wonderful article on each of the User Rights Assignments.1 In this post, I want to cover a handful of User Rights Assignments settings that can help mitigate possible avenues of lateral movement. I encourage you to read through every setting, although this can be done in multiple sittings. To start off, let’s go over “Sam’s General Rules for User Rights Assignments”:
- User Rights Assignments are used to limit logon and privileges on systems. I believe that an aggressive attacker is going to completely compromise a system if they get the chance. User Rights Assignments can slow down that process for advanced enemies or thwart attempts by unexperienced hackers. However, I believe the greater value is seen in how other machines interact with the compromised system. Just like Restricted Groups, User Rights Assignments will deny logon attempts that don’t meet the outlined criteria. If configured correctly, the non-compromised hosts will not allow a user to move from the infected machine to them based off their User Rights Assignments.
- Do not allow users access to User Rights Assignments if they don’t need the access. This is kind of a no-brainer, but I still feel the need to say it. If there is no need to grant a user a certain privilege, then don’t. Some of the settings in User Rights Assignments are highly dangerous and can offer your enemies an easy step forward in their campaign if they compromise a host. For service accounts, ask for documentation from the vendor of what User Rights Assignments the accounts need, and challenge them if it seems what they are requesting doesn’t feel right.
- If possible, do not assign users directly to configurations. This will save you from updating the Group Policy Object too frequently. Just like with Restricted Groups, create an active directory security group, and apply that to the Group Policy Object settings.
- Test everything you create. These settings can cripple your network, or even initiate a self-inflicted Denial of Service (DOS). I made the mistake of adding Domain Computers to the “Deny access to this computer from the network” on my Domain Controller. Thankfully, it was in my test lab, and I was just playing around. BUT, all my machines stopped processing Group Policy Objects. I wonder why…
- Just like file permissions, if a user meets the criteria for both an “allow logon” and a “deny logon”, the “deny” will override the “allow”.
Now that we have covered some general guidelines, I want to talk specifically about three configurations that should be set up on every system throughout your domain.
Allow/Deny Log on Locally
These two settings define who can physically sit at a keyboard and log on to a machine. For the most part on workstations, you will not need to touch the “allow” settings. By default, everyone should have logon rights to all workstations; there is no need to waste resources adjusting this configuration. However, you may want to fine tune it for your servers. I personally would configure the “allow” setting only for the groups that have a need to log on to the server.
Furthermore, I would configure the “deny” setting for all your sensitive groups that don’t belong on workstations. For example, is there any reason for a Domain Admin to log on to a workstation? In my book, no. Domain Admins should only log on to the domain controllers and authorized systems used to help administer the domain (Privileged Access Workstations or Jump Servers). Specifically denying this logon will ensure that a domain administrator doesn’t accidentally start scattering their credentials all over the network. Also, this can help prevent users that hold privileges at different administrative levels from accidentally logging on to a system that they shouldn’t be accessing. Let’s say that a user is a member of “Domain Administrators” and “Print Server Administrators”, and you have your User Rights Assignment perfectly configured (domain admins can only log on to domain administrating systems). The Print Servers will still deny any logon attempt, thus preventing a potential adversary from stealing domain administrator credentials that could be used to compromise another system. This can help enforce the tier styled delegation model I mentioned in my previous article.2
Allow/Deny log on through Remote Desktop Services
Just like the local logon, this User Rights Assignment governs who can connect a system through RDP. The strategy here follows the same method as before. Only grant this privilege to those that need it, and specifically deny access to your sensitive groups.
Allow/Deny Access to this Computer from the Network
Once again, the strategy doesn’t change here. (I think there is a pattern to these User Rights Assignments.) Allow only those who need remote network access to a system, and explicitly deny those groups that are of high value to the network. These settings govern who can interact with a system remotely.
There are a number of ways that I can affect a system without logging on to the machine locally or through a remote desktop. If I don’t have this right granted to me or if I am specifically denied, then I cannot affect another system unless I have some highly-advanced exploits at my disposal. But like my example from before, blindly configuring this can cut off your machines from the network and the legit administrators that need to fix them.
I hope I provided you with enough information to start adding another layer to your credential defenses. Again, I see the value of User Rights Assignments as a means to have systems defend themselves from infected machines.
In my next post, I will be discussing the benefits of Microsoft LAPS (or local password rotation capabilities).
Until next time.
Warning #1: "...services require user rights in Windows security policies..."
This warning message indicates that domain group policy objects (GPOs) are restricting which rights are assigned to virtual service accounts.
To learn more see If user rights are missing.
Warning #2: "...cannot read the user rights that are specified..."
This warning message indicates that the installer may not be able to determine whether the correct rights are assigned to virtual service accounts in domain GPOs.
To learn more see If user rights cannot be determined.
Note: You must be a domain administrator, or coordinate with your domain administrator, to make changes to the affected domain GPOs.
If you are upgrading Endpoint Protection Manager from a previous version, the warning might prompt you to add Endpoint Protection Manager services to policies. Click Try Again to review the policies again during the installation.
You must log in as a domain administrator to use this option. If you do not log in as a domain administrator, you can either cancel the installation and log back in with domain administrator credentials, or you can continue with the installation and update the policies after the upgrade is completed.
To perform some of the steps below, you must install Group Policy Management Console (GPMC) on the machine where you install Endpoint Protection Manager. For more information see, Install the GPMC on Microsoft.com.
If user rights are missing
Perform the following tasks to successfully complete the Endpoint Protection Manager installation:
- Identify the service accounts, user rights assignments, and domain GPOs you need to modify
- Change the domain policies and propagate them to the computer
- Recheck the policies or restart the services for Endpoint Protection Manager
There will be additional log entries in one of the following log locations depending on when the warning message appears:
- New installations:
Note: if you do not see the log file in this folder, search for the log file by name.
- Configuration wizard:
- Upgrade wizard:
SEPM_Installation_Folder represents the installation folder for Endpoint Protection Manager. By default, this folder is C:\Program Files (x86)\Symantec\Symantec Endpoint Protection Manager (64-bit operating system) or C:\Program Files\Symantec\Symantec Endpoint Protection Manager (32-bit operating system).
From the alert message, make note of the missing service accounts. With the alert window active, press Control-C to copy the text of the message, which you can then paste it into a document. If you encounter this message in the configuration wizard or the upgrade wizard, click Show Details to get more information.
- The virtual service accounts
- The domain GPOs
- The user rights assignments required
For example, the alert message may read:
Group policy setting SeServiceLogonRight in 'New Group Policy Object-testB' does not contain [NT SERVICE\semsrv, NT SERVICE\semwebsrv, NT SERVICE\SQLANYs_sem5, NT SERVICE\semapisrv]
Note: In this example, the user rights appear in green, the domain GPOs in blue, and the virtual service accounts in red.
The required user rights are as follows:
- SeAssignPrimaryTokenPrivilege (Replace a process level token): Required by NT SERVICE\semwebsrv only while installing Endpoint Protection Manager with a Microsoft SQL Server database using Windows authentication.
- SeServiceLogonRight (Logon as a service): Required by all services. (NT SERVICE\SQLANYs_sem5 is not required if you install Endpoint Protection Manager with a Microsoft SQL Server database.)
You must ensure that for the GPOs listed, all of the accounts listed are present in all of the user rights assignments mentioned. For new installations, you can refer to the table above for more information about required rights needed for either database type to avoid additional warnings after configuration.
Note: When you install Endpoint Protection Manager for the first time, its services are not yet present on the computer. Therefore, virtual accounts that correspond to Endpoint Protection Manager services are not active yet. For a new installation, you can click Continue in the alert that appears during installation. Another warning appears at the end of the configuration wizard, so you can update domain policies using the steps below after configuration finishes.
Make the appropriate changes to the necessary domain GPOs with the Group Policy Management Console on your Active Directory server, or work with your domain administrator to make these changes. See Create and Edit a Group Policy Object on Microsoft.com to learn how to edit group policies.
To update the domain policy, follow these steps:
Note: These steps are for the Windows Server 2012 Server Manager. Other versions of Windows may vary slightly.
- Open Group Policy Management Console (GPMC).
- Locate the policy name mentioned in the alert box.
Typically, it appears under the node Group Policy Objects, under your domain tree.
- Right-click the policy, and then click Edit to open the Group Policy Editor for this policy.
- Browse to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.
This lists all of the user assignments.
- Locate the user rights mentioned in the alert, and add the accounts mentioned in the alert.
These accounts are created locally on the Endpoint Protection Manager computer after configuration or upgrade finishes. However, they are virtual service accounts without predetermined SIDs, so you can add them to domain GPOs before they are created on the Endpoint Protection Manager computer.
- Click OK.
Note: After you update domain policies, ensure that the Endpoint Protection Manager computer receives and applies them.
- On the Endpoint Protection Manager computer, open an elevated command prompt (run cmd.exe as Administrator), and enter the following command:
This command refreshes all domain policies on this computer.
III. Recheck the policies or restart the services for Endpoint Protection Manager
- If you see the warning during installation and the Endpoint Protection Manager installer is paused at the Warning pane, click Try Again. If the installer previously rolled back, launch it again.
Note: if you click Continue, the installer ignores the warnings. You still need to correct the user rights in the domain policies for the installation to work correctly.
- If you see the warning during configuration or during an upgrade, click Finish to start Endpoint Protection Manager. The changes you make ensure that Endpoint Protection Manager runs reliably. If necessary, you can restart the Endpoint Protection Manager services using the Service Control Manager.
- As an additional verification, you can also reconfigure Endpoint Protection Manager after you apply the group policies on the Endpoint Protection Manager computer. The Management Server Configuration Wizard reviews the updated policies again.
You must ensure that you see the message "Configuration Completed" without any warnings in the final panel before you click Finish.
If user rights cannot be determined
When Endpoint Protection Manager cannot read the domain policies, it does not provide the missing user rights in the alert message. In this instance, you (or your domain administrator) should manually inspect the domain policies based on the user rights assignments guidelines provided above, and ensure all required rights apply to Endpoint Protection Manager services.
If you are satisfied that the domain policies meet the appropriate criteria, click OK to continue with the installation, and then ignore the subsequent warning messages during the configuration or upgrade wizard.
How to check domain policies manually
You can manually check for the presence of required accounts and privileges before you begin a new installation or upgrade.
To check domain policies manually, follow these steps:
- Log on to the Endpoint Protection Manager computer using domain admin credentials.
- Open a command prompt (cmd.exe) and enter the following command:
This command writes the results of the command to a new file, gpresult.xml, at the root of the C: drive.The Endpoint Protection Manager installer uses this command to retrieve the Windows domain policies. If this command fails, then the domain policy check fails during installation.
- Open C:\gpresult.xml and search for the privileges listed in the requirements noted above, under Cause.
If you find the privileges, then the domain GPOs do not enforce them. You do not need to make a change to domain GPOs.
If you do not find the privileges, but do not contain any of the Endpoint Protection Manager accounts, then you must add them into the corresponding policy.
To determine which domain policy to modify, follow these steps:
- Open the gpresult.xml file.
- Navigate down the following XML tree to where you previously found the required privilege, to the Identifier tag:
Where PrivilegeName is SeServiceLogonRight or SeAssignPrimaryTokenPrivilege.
- Note the value given within the Identifier tag. For example:
- Navigate the following XML tree, to the Identifier tag:
- Search for the identifier value found in Step 2.
- Navigate up the tree to the Name tag, which encloses the name of the policy you must modify.
- You can now open the Group Policy Management Console (GPMC) and add the Endpoint Protection Manager accounts with the required privileges, as noted above.
For more information, see the following Microsoft technical articles: