User Rights Assignments
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.