Windows 7 Home User Rights Assignment

As we know, attackers leverage legitimate credentials to move through systems, escalate privileges or get access to data.

Managing privileged accounts such as administrator accounts, shared accounts and service accounts is a difficult problem to solve.

Even if service account passwords are managed securely, they still remain at risk of being compromised through exploitation of services using them, lack of support for encrypted configuration files on some systems, pass-the-hash attacks, or the ability for a systems administrator account to read them in memory.  

Luckily, Windows comes with granular permissions that are easy to configure and that can help us reduce the attack surface,  improve general IT hygiene and obtain important log information when attempts to use these accounts improperly happen.

The same can be said of administrative accounts used by humans. These accounts have high levels of privileges, but should never be used to perform automated tasks, run services or be saved into configuration files, for reasons ranging from obvious security concerns to simple IT availability management.

Who hasn't seen a service crash when an administrator's password was changed?

Where to start

Looking at every single user right that can be configured in Windows can be overwhelming. Depending on the version of Windows being used, there are roughly 50 different rights, controling everything from permissions to change the system time, shut down systems or take ownership of files and other objects.

Luckily, Microsoft provides decent default configurations in Windows 2008 and later, and provides better configuration options in its Security Compliance Manager tool.

We recommend that you start your hardening efforts with the proposed values from SCM, customized for your organisation. You can also leverage well known configuration guides from organisms such as NIST, the NSA, FDCC, CIS Security and more.

Their proposed values for User Rights Assignments are not bad, but will obviously need to be customized with real groups and accounts from your environment, which no guide written by someone else could ever hope to cover.

One of the advantages of using SCM is its ability to output your configuration both in a *GPO Backup* format, easily restorable in AD, as well as a *SCAP* file, easily loaded in many vulnerability scanners and configuration auditing tools.

OU Structure

An OU structure that is well defined, hierarchical and simple will make the deployment of GPOs much easier.

This structure will be based on how systems are used in your organisation, but could look similar to this. Some organisations use a geographical breakdown, which can also be used, and would simply require different GPO links.

With such a structure, an organisation can create and use the following GPOs:

  • A server configuration baseline. This baseline should be more restrictive than permissive. Microsoft Security Compliance Manager (SCM) can be used to generate hardening GPOs for your baseline. This is applied on *Servers*. All OUs under *Servers* inherit configurations.
  • Role GPOs for different servers. Again, Microsoft SCM can be used to create those policies. Think of these policies as ways to enable the required functionality on those servers. If the baseline disables the print spooler, the Print Server Policy would enable it, for servers in this OU.
  • A similar hierarchy for workstations is also possible, and if needed, Group Filtering can be used if the OU structure is not flexible enough at your organisation and cannot be changed.

No matter what your OU structure is, remember the main goals: repeatability and ease of use. The right structure will allow you to control a great majority of parameters in as few GPOs as possible, and allow any systems administrator or security operator to easily understand the resulting configuration on servers.

User Rights to configure

Now that we have a flexible OU structure, some baseline hardening policies for our servers and workstations, we must look at which User Right Assignment will be customized further.

What we are trying to achieve with them is simple: prevent humans from logging in using ways that systems and services do, and prevent services from logging in using the ways human use.

Example: Service accounts should never be able to perform Remote Desktop Connections, and humans should not be able to log in as a batch job or service.

To perform such a configuration while retaining flexibility, we will leverage positive rights (allow), and supplement them with negative rights (deny) to explicitely block access when it might otherwise be granted by another level of privileges, such as a service account that has local administrator privileges.

To succeed at configuring these, using Active Directory Groups is essential.

For each of these critical rights, create an Active Directory group, which will be granted access. In most cases, you will be able to grant a right only to one local account or group (ex: administrators), plus one domain group.

The granularity of these groups is important. You must chose a level of granularity that will allow you to configure servers properly, while allowing for some level of customization when needed.

The two extreme levels of granularity would be:
* An extremely broad group, granting access to the same right on all servers.
* An extremely precise group, used for one right, on one server only.

As these are both impractical, due to lack of flexibility or increased complexity (and even Kerberos ticket size issues in some cases), an option that lands roughly in the middle of these two extremes is often the most appropriate: **

For each of these critical rights, create an Active Directory group, which will be granted access. In most cases, you will be able to grant a right only to one local account or group (ex: administrators), plus one domain group.

The **granularity** of these groups is important. You must chose a level of granularity that will allow you to configure servers properly, while allowing for some level of customization when needed.

The two extreme levels of granularity would be:
* An extremely broad group, granting access to the same right on all servers.
* An extremely precise group, used for one right, on one server only.

As these are both impractical, due to lack of flexibility or increased complexity (and even Kerberos ticket size issues in some cases), an option that lands roughly in the middle of these two extremes is often the most appropriate: One group per right, per server role.

Ex: A group that allows logging in locally on print servers.

Nesting

If you picked our recommended level of granularity, you will be creating roughly 10 AD groups per server role. While this seems like a lot, it can actually be automated quite easily when introducing new roles.

To keep the management overhead as low as possible, which not only helps optimizing operations but also reduces complexity and reduces the odds of human error, group nesting will be required.

Group Nesting will allow you to create "role" groups, which will themselves be members of the appropriate User Rights groups.

By creating such a structure, you will be able to easily grant access to all servers, to all servers in a role, and single server exceptions can be managed separately.

We highly encourage you to use such a structure to control which domain groups are local administrators on systems. Remove Domain Administrators, and if necessary, use one AD group per server. This will allow you to control local administrator privileges directly in AD, all the time, meaning you have a centralized database for it, that local groups will not be filled by unresolved SIDs as accounts are deleted, and more.

Since we are going to use deny rights, it is important to nest groups into the appropriate deny rights AD groups.

From this diagram, we see that granting Mario access to manage print servers only requires making him a member of the general Windows Admin group, while Luigi can only manage Print Servers, as he is a member of a more specific Print Servers Admins group.

These groups result in both of them being granted 5 rights on the servers: 3 allow, 2 deny. They can now log in locally or remotely, but are unable to start a service  or a batch with their own account.

In some cases, a level of granularity can be removed by granting the deny rights at a higher level, since they are usually broader concepts. This is especially useful for service accounts, where we mostly want to deny specific logon types, on all servers.

Nesting Service Accounts

Service Accounts can obtain privileges the same way a regular account can. The rights that will be granted will obviously be different, and will often be the opposite of what a human would receive.

As GPOs are re-applied periodically, any change in configuration will be corrected rapidly. This can lead to software being installed, looking functional and then stopping a few moments later, as the local privileges are stripped from the service account. To avoid this issue, ensure privileges required by services are well understood prior to installation. Your testing environment and Windows Security Event Log are your best friends when troubleshooting permission issues.

Exceptions

Every company, no matter how small, has at least a few IT exceptions to deal with. It could be an obvious one, such as a web server requiring access to "log on locally" due to how Windows is built, or it could be some kind of crazy service actually leveraging Remote Desktop to perform some action.

Precise exceptions can be granted with the model we've built.

Simply create an exception GPO (ex: "GPO to Grant CrazyHackJobService the right to perform a remote desktop logon"), ensure it gets applied only to a security group (ex: "Group of computers running CrazyHackJobService"), then link it on your "Servers" OU or equivalent. Make sure this GPO is applied last (on top in the GPMC interface), to override any configuration coming from other, less specific GPOs.

This will allow you to reconfigure the specific user right(s) required for this service to work properly, deploy these configurations only to specific servers and do so without having to create a special OU structure. Remember that groups are flexible, but OUs are not. A server can be in many groups, but will always be in a single OU.

Note: While applying new GPOs does not require a reboot, if you've just made a server a member of a group, a reboot might be required to refresh tokens that will then give it access to the filtered GPO.

Logging

As User Rights Assignments are linked to specific logon types, the information generated by attempted logons can be extremely useful to your security monitoring efforts.

List of Logon Types

Assume a service account's password is somehow obtained by an attacker, using a variety of methods from pass-the-hash to memory extraction or the good old "found a word document with passwords" technique. As the attacker attempts to use this account to connect to systems, the odds of an attempt being performed using one of the denied logon rights is high.

The security logs, when the username and password are correct but the logon type disallowed, are very precise, and will allow you to detect malicious activity happening with a service account quite quickly.

The same is also true for administrative accounts being used to install malicious services or scheduled tasks using domain credentials. Use these logs to your advantage.

Example prompt of a user "EPaw" attempting an interactive logon where not allowed:

Associated log entry:

Conclusion

Without spending any extra money on tools, by using this technique, customized to your environment, you will not only have reduced the attack surface of your Windows environment, but you will force it to become self-documenting when it comes to User Rights granted to service accounts, as all the information has to be stored within Active Directory.

The additional data generated by failed attempts is now ready to be ingested by your security monitoring tools, and the next attacker who will attempt to log on using Remote Desktop to one of your servers using a service account will have to be noisier and work harder.

If all this configuration and refactoring of the placement of your systems seems too difficult, remember you can start small, configuring only a few settings on existing systems, while you apply a more complex set of rules on newly provisioned systems.

Links

Security Compliance Manager (SCM)

Group Policy Management Console (GPMC)

Advanced Group Policy Management (AGPM)

Sysinternals Process Monitor

Center for Internet Security (CIS)

The United States Government Configuration Baseline (USGCB)

Microsoft SCCM / Desired Configuration Management (DCM)

How to Add or Remove Users and Groups from "User Rights Assignment" in Windows


   Information

User Rights Assignment policies determines which users or groups have logon rights or privileges on the computer. This will show you how to add (assign) or remove users and groups for each User Rights Assignment policy in Vista, Windows 7, or Windows 8.

You must be logged in as an administrator to be able to do the steps in this tutorial.

   Note

If you remove a user or group, then that user or group will no longer be able to perform the policy on the computer.

If you add a user or group, then that user or group will now be able to perform the policy on the computer.

For more information about each specific user rights policy, see: User Rights

   Warning

This tutorial is not for a beginner to try.

I would highly recommend that you create a restore point before making changes to the User Rights Assignment. This way if you make a mistake and lock yourself, a user, or a group out of a policy that you didn't want to, you will be able to do a system restore at boot and select the restore point to undo the mistake.






OPTION ONE
Through Local Security Policy
1. Open the Local Security Policy window, expand Local Policies in the left pane, and select User Rights Assignment. (see screenshot below)

2. In the right pane of User Rights Assignment, double click on a listed Policy (ex: Shut down the system) that you wanted to add or remove a user or group, then go to step 3 and/or 4 below. (see screenshot above)

3. To Remove a User or Group from a User Rights Assignment Policy
A) Select (highlight) a listed user(s) and/or group(s) that you wanted to remove from the policy, then click on the Remove button. (see screenshot below)
NOTE:You can press and hold the CTRL key to select more than one listed user (user account name) and/or group.

B) Click on Apply. (see screenshot below)

C) Go to step 4 or 5 for what you would like to do.
4. To Add a User or Group to a User Rights Assignment Policy
A) Click on the Add User or Group button. (see screenshot above)

B) Click on the Advanced button. (see screenshot below)

C) Click on the Object Types button. (see screenshot below)

D) Check only the Users and Groups boxes, and click on OK. (see screenshot below)

E) Click on the Find Now button. (see screenshot below)

F) In the bottom pane under Search results, select the user(s) and/or group(s) that you wanted to add to the policy, then click on OK. (see screenshot below)
NOTE:You can press and hold the CTRL key to select more than one listed user (user account name) and/or group.

G) Click on OK. (see screenshot below)

H) Click on Apply. (see screenshot below)

5. When finished, click on OK. (see screenshots below steps 3B and 4H)

6. Close the Local Security Policy window. (see screenshot below step 1)



OPTION TWO
Using an Elevated Command Prompt
1. If you have not already, click on the Download button below to download the ntrights.zip file originally from within the Windows Server 2003 Resource Kit Tools.


A) Open the downloaded .zip file, and extract (drag and drop) the ntrights.exe file to your desktop.

B) Right click on the ntrights.exe file, click on Properties, General tab, and click on the Unblock button if available.
NOTE:If you do not have a Unblock button under the General tab, then the file is already unblocked and you can continue on to step 1C.

C) Right click on the ntrights.exe file and click on Move.

D) Open Windows Explorer and navigate to and open the C:\Windows\System32 folder, then Paste the ntrights.exe file to move it here.

E) If prompted, click on Continue and Yes to approve moving the ntrights.exe file into the System32 folder, then close the Windows Explorer window.
2. Open an elevated command prompt, and do step 3 and/or 4 below.

3. To Remove a User or Group from a User Rights Assignment Policy
A) In the elevated command prompt, type the command below for what user or group that you would like to remove from what policy, and press Enter.
NOTE:See blue note box below step 4.
ntrights -U "User or Group" -R PolicyConstantName
For example:If I wanted to remove the standard users group "Users" from being able to "Shut down the system", then I would type the command below.

ntrights -U "Users" -R SeShutdownPrivilege
B) Go to step 4 or 5 for what you would like to do.
4. To Add a User or Group to a User Rights Assignment Policy
A) In the elevated command prompt, type the command below for what user or group that you would like to add to what policy, and press Enter.
NOTE:See blue note box below step 4.
ntrights -U "User or Group" +R PolicyConstantName
For example:If I wanted to add the standard users group "Users" to be able to "Shut down the system", then I would type the command below.

ntrights -U "Users" +R SeShutdownPrivilege
   Note

Substitute User or Group in the command with actual name of the user account or group within quotes.

Substitute PolicyConstantName in the command for the actual Constant Name at the link below for the Group Policy Name that you wanted to add or remove a user or group.

User Rights




5. When finished, close the elevated command prompt.
That's it,
Shawn






One thought on “Windows 7 Home User Rights Assignment

Leave a Reply

Your email address will not be published. Required fields are marked *