Domain Policy User Rights Assignment

Home / Windows 7

Configuring Security Policies

Use of Group Policy to help provide your network with a safe and secure computing environment. Malicious individuals are forever devising new means of invading your network to steal and corrupt data, prevent your network from functioning, and disrupt business activities. Group Policy enables you to configure security policy settings that help to ensure that uninvited users are kept away from sensitive parts of your network, and if they do gain access, you can use auditing tools to determine which resources they've managed to access or unsuccessfully attempted to access. This tutorial focuses on the use of Group Policy to create and enforce a secure computing environment that protects your computers and data from whatever the bad guys might attempt to throw at you.

Group Policy contains an entire series of policy settings found under the Security Settings subnode in both the Computer Configuration and User Configuration sections. This tutorial looks primarily at the policy settings contained under the Local Policies sub-subnode beneath Security Settings. Found here are audit policies, which enable you to track access to and use of resources on the network; user rights assignments, which determine which users and groups can perform various system-based activities; and security options, which include a long list of security-related policies. We also take a look at policies that govern the use of User Account Control (UAC), which prompts users for administrative credentials before permitting potentially harmful actions such as installing software at the local computer.

Configuring User Rights Assignment

You can use Group Policy to manage security settings quite effectively on a Windows Server 2012 R2 network. An enhanced range of security options is available, with settings designed for both user and computer configuration. Microsoft continues to expand the available range of security policies, compared to those included with previous versions of Windows Server.

User rights are defined as a default set of capabilities assigned to built-in domain local groups that define what members of these groups can and cannot do on the network. They consist of privileges and logon rights.

You can manage these predefined user rights from the Computer Configuration\ Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment node in the Group Policy Management Editor. Use the following procedure.

  1. Open the Group Policy Management Editor focused on an appropriate Group Policy object.
  2. Navigate to the Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment node and select this node. The details pane shows a series of predefined user rights. When focused on the Default Domain Controllers Policy GPO, you see a default set of user rights assignments.
  3. To modify the assignment of any right, right-click it and select Properties. As shown for the Back up files and directories user right, the Properties dialog box displays the built-in groups that are granted this right by default.
    The Back up files and directories Properties dialog box displays the groups that are granted this right by default, and it enables you to modify this assignment if required.
  4. To grant this right to another user or group, click Add User or Group. In the Add User or Group dialog box that appears, type or browse to the required user or group. Then click OK. To remove a user or group, select it and click Remove.
  5. When finished, click OK to close the Properties dialog box. You are returned to the Group Policy Management Editor, where you can continue to configure additional user rights as needed.

Note that each user rights Properties dialog box has an Explain tab, which provides additional information about what each user right involves. Consult this tab before modifying any of the default user rights.

You can also create a new GPO and configure a series of settings in this node to be applied to a specific group, and then link the GPO to an appropriate OU and grant the required group the Read and Apply Group Policy permissions. This is an easy way to grant user rights over a subset of the domain to a junior group of employees, such as help desk technicians.

Note:
For more information on granting user rights in Active Directory Domain Services (AD DS), refer to "Assign User Rights to a Group in AD DS" at http://technet.microsoft.com/en-us/library/cc754142.aspx.

Configuring Security Options Settings

Within the Local Policies subnode of Security Settings, you have the user rights assignment already discussed, as well as audit policies, which are discussed later in this tutorial. This section introduces you to the Security Options subnode, which includes a large set of policy options, that are important in controlling security aspects of the computers to which the GPO applies. Several of the more important options that you should be familiar with are as follows:

  • Accounts:
    Block Microsoft accounts: Prevents users from using Microsoft accounts to access the computer or creating new Microsoft accounts on the computer. This setting was new to Windows 8 and Windows Server 2012 and is continued in Windows 8.1 and Windows Server 2012 R2.

  • Accounts:
    Rename administrator account: This option renames the default administrator account to a value you specify. Intruders cannot simply look for "Administrator" when attempting to crack your network.

  • Interactive logon:
    Do not display last user name: Enable this option to prevent the username of the last logged-on user from appearing in the logon dialog box, thus preventing another individual from seeing a username. This can also help to reduce lockouts.

  • Interactive logon:
    Do not require CTRL+ALT+DEL: When enabled, a user is not required to press Ctrl+Alt+Delete to obtain the logon dialog box. Disable this policy in a secure environment to require the use of this key combination. Its use prevents rogue programs such as Trojan horses from capturing usernames and passwords.

  • Interactive logon:
    Require smart card: When enabled, users must employ a smart card to log on to the computer.

  • User Account Control:
    Several policy settings determine the behavior of the UAC prompt for administrative and nonadministrative users, including behavior by applications that are located in secure locations on the computer such as %ProgramFiles% or %Windir%.
Note:
For more information on the policy settings in the Security Options subnode, refer to "Security Policy Settings Technical Overview" at http://technet.microsoft.com/en-us/library/jj966251.aspx and "Security Options" at http://technet.microsoft.com/en-us/library/jj852268.aspx.

The Security Options node also contains the following additional sets of securityrelated policies:

  • Event Log:
    Configuration options for the Event Viewer logs, including log sizes and action taken when an event log is full.

  • Restricted Groups:
    Determines who can belong to certain groups.

  • System Services:
    Enables you to configure system services properties, such as startup type, and restrict users from modifying these settings.

  • Registry:
    Enables you to control the permissions that govern who can access and edit portions of the Registry.

  • File System:
    Enables you to configure permissions on folders and files and prevent their modification.

  • Wired Network (IEEE 802.3) Policies:
    Enables you to specify the use of IEEE 802.1X authentication for network access by Windows Vista, Windows 7, Windows 8, or Windows 8.1 computers and includes the protocol to be used for network authentication.

  • Windows Firewall with Advanced Security:
    Enables you to configure properties of Windows Firewall for domain, private, and public profiles. You can specify inbound and outbound connection rules as well as monitoring settings.

  • Network List Manager Policies:
    Enables you to control the networks that computers can access and their location types such as public and private (which automatically specifies the appropriate firewall settings according to location type). You can also specify to which networks a user is allowed to connect.

  • Wireless Network (IEEE 802.11) Policies:
    Enables you to specify wireless settings, such as enabling 802.1X authentication and the preferred wireless networks that users can access.

  • Public Key Policies:
    Enables you to configure public key infrastructure (PKI) settings.

  • Software Restriction Policies:
    Enables you to specify which software programs users can run on network computers, which programs users on multiuser computers can run, and the execution of email attachments. You can also specify whether software restriction policies apply to certain groups such as administrators.

  • Network Access Protection:
    Network Access Protection (NAP) is a feature first introduced in Windows Server 2008. It enables you to define client health policies that restrict access to your network by computers that lack appropriate security configurations. The NAP policies enable you to specify settings for client user interface items, trusted servers, and servers used for enforcement of client computer security health status.

  • Application Control Policies:
    These are a set of software control policies first introduced with Windows 7 and Windows Server 2008 R2 that introduces the AppLocker feature. AppLocker provides new enhancements that enable you to specify exactly what users are permitted to run on their desktops according to unique file identities.

  • IP Security Policies on Active Directory:
    Controls the implementation of IP Security (IPsec) as used by the computer for encrypting communications over the network.

  • Advanced Audit Policy Configuration:
    First introduced in Windows Server 2008 R2 and continued in Windows Server 2012 R2, this node contains 53 new policy settings that enable you to select explicitly the actions you want to monitor and exclude actions that are of less concern. More information is provided later in this tutorial.

You can obtain additional information on many of these policy settings in the Windows Server 2012 R2 Help and Support.

Using Additional Security Configuration Tools

Windows Server 2012 R2 includes the following additional tools that are useful in configuring and maintaining the security of your AD DS network:

  • Security Configuration Wizard:
    This wizard assists you in maintaining the security of your servers and checks for vulnerabilities that might appear as server configurations change over time. You can access this wizard from the Search charm or the Administrative Tools tile on the Start screen. You can create a new security policy or perform actions on an existing security policy, including editing, applying, or rolling back the policy. This wizard is particularly useful in maintaining the security of servers hosting roles that are not installed using Server Manager, such as SQL Server and Exchange Server, as well as servers that host non-Microsoft applications. Microsoft also includes a command-line version, scwcmd.exe, which is useful in configuring Server Core computers. Using this wizard, you can configure security for the following items:
    • Server roles, features, and administrative options
    • Background services running on the server, including their startup modes
    • Network security, including rules for the Windows Server Firewall with Advanced Security snap-in
    • Registry-based settings for configuring protocols used to communicate on the network
    • Audit policy settings
  • Security Templates snap-in:
    From this snap-in, you can save a custom security policy that includes settings from the various subnodes of the Security Settings node of Computer Configuration that we discussed in the preceding sections. It is most useful in defining a security configuration for standalone servers that are not members of a domain.
  • Security Configuration and Analysis:
    This snap-in enables you to analyze and configure local computer security. You can compare security settings on the computer to those in a database created from the Security Templates snapin and view any differences that are found. You can then use this database to configure the computer's security so that it matches the database settings.

These two snap-ins are not contained in any MMC console by default; to use them you must open a blank console (type mmc from the Run dialog box or the Search charm) and add them using the Add or Remove Snap-ins dialog box shown.

Note:
For more information on these tools, refer to "Security Configuration Wizard" at http://technet.microsoft.com/en-us/library/cc754997.aspx, "Security Tools to Administer Windows Server 2012" at http://technet.microsoft.com/en-us/library/jj730960.aspx, and "Security Configuration Wizard Documentation" at http://www.microsoft.com/en-us/download/details.aspx?id=6334.

You can use the Add or Remove Snap-ins dialog box to create a Security console containing the Security Templates and Security Configuration and Analysis tools.

Password and Account Lockout Policies

As an administrator, one of your goals is to secure your network. While security is a broad area to cover, one of the tasks you have is to define a password policy and account lockout policy, both of which are configured using Group Policy Management console.

Password Policy Settings

Password Policy settings are located and can be configured under Computer Configuration\ Windows Settings\Security Settings\Account Policies\Password Policy.

When configuring a password policy, you should consider configuring the following settings:

  • Enforce password history:
    Determines the number of unique new passwords the user must use before an old password can be reused. The default is 24 passwords remembered.
  • Minimum password age:
    Defines the minimum period of time in days that a password can be used before the system requires the user to change it. The default value is 1 day.
  • Maximum password age:
    Defines the maximum period of time in days that a password can be used before the system requires the user to change it. This value must be greater than the minimum password age. The default value is 42 days. If set to 0, the password never expires.
  • Minimum password length:
    Defines the minimum number of characters (up to 14) a password must contain. The default value is 0, indicating no password is required.
  • Password must meet complexity requirements:
    Indicates whether passwords must meet complexity requirements as described in the next section.
    The default value is Enabled in Windows Server 2012 R2.
  • Store password using reversible encryption:
    Stores encrypted passwords with information used to decrypt the password. This policy setting is typically associated with custom or in-house applications that require knowing the user's password for the authentication process. Applications decrypt the stored password and process logon requests. Due to the fact that passwords can be decrypted, it is recommended to keep the default setting of Disabled unless there is a specific need that outweighs the security risk.

Password Complexity

Previous editions of Windows Server introduced the concept of strong passwords. A strong password is a password comprised of at least eight characters including a combination of letters, numbers, and symbols. Strong passwords help protect accounts, especially administrative accounts, from being compromised by unauthorized users.

In legacy versions of Windows Server, strong passwords could be enforced throughout the organization through a password policy that was applied to the entire domain. A password policy could be applied to the domain using a domain-based GPO that specified password requirements for the domain. To configure strong passwords, Microsoft created the Passwords must meet complexity requirements Group Policy setting. The password complexity setting prevents users from employing simple, easy-to-guess passwords by enforcing the following requirements with respect to creating passwords:

  • Passwords may not contain user account name or display name.
  • Passwords must contain characters from three of the following categories:
    • Uppercase letters A-Z
    • Lowercase letters a-z
    • Base 10 digits 0-9
    • Non-alphanumeric characters, also known as special characters such as !,@,#,$

Account Lockout Policy

As with previous versions of Windows Server, domain controllers keep track of logon attempts. By configuring Account Lockout Policy settings, you can control what happens when unauthorized access attempts occur. Account Lockout Policy settings are configured under Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy. You can configure the following settings for the entire domain:

  • Account lockout duration:
    Specifies the number of minutes an account is locked before automatically being unlocked by the system. A value of 0 specifies that the account will be locked until an administrator intervenes and unlocks the account. By default, account lockout durations are undefined.
  • Account lockout threshold:
    Defines the number of failed logon attempts that causes the user account to be locked out.
  • Reset account lockout counter after:
    Specifies the number of minutes that must pass after the account is locked before the account logon counter is reset to 0. This setting is not defined by default.

Fine-Grained Password Policy

With the release of more recent editions of Windows Server, Microsoft has created a concept known as a fine-grained password policy. Also included in Windows Server 2012 R2, fine-grained password policies enable you to configure different password policies and lockout settings (as discussed previously) that can be applied to specific users or groups within a domain. If you recall, previously these were applied to the entire domain. Fine-grained password policies are particularly helpful in the following scenarios:

  • A group of users, such as administrators, require a different, perhaps more complex password policy than the rest of the users.
  • Different departments, such as Legal or Human Resources, require stronger password policies than the rest of the organization.
  • Your company has merged or acquired a new company with different password policy requirements.

Fine-grained password policies use an object class defined in the AD DS schema known as a Password Settings object (PSO). The PSO holds attributes for the finegrained password and account lockout policy settings. Password settings are stored in a Password Settings Container (PSC) located under the default System container in the domain.

Note:
For more information, refer to "Password Policy" at http://technet.microsoft.com/en-us/library/hh994572.aspx, "Account Lockout Policy" at http://technet.microsoft.com/en-us/library/hh994563.aspx, and "AD DS: Fine-Grained Password Policies" at http://technet.microsoft.com/en-us/library/056a73ef-5c9e-44d7-acc1-4f0bade6cd75.aspx.

[Next....Auditing of Active Directory Services]

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”:

  1. 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.
  2. 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. 
  3. 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.
  4. 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…
  5. 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.

References

  1. https://technet.microsoft.com/en-us/library/dn221963(v=ws.11).aspx
  2. https://www.root9b.com/newsroom/network-credential-management-pyramids-delegation

Leave a Comment

(0 Comments)

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