 G'day viewers, my name is Oren Thomas. I'm a principal hybrid cloud advocate at Microsoft. This video provides an overview of user rights assignment policies. In this video, I will summarize the functionality of each of the different user rights assignment policies and discuss recommended settings. User rights assignment is one of those meat and potatoes features of the operating system that we all have a cursory understanding of but rarely think about in depth. As someone who talks about IT Pro topics, I'm interested in covering core roles and features that have been around forever but don't get much attention. This video is based on the documentation linked in the description. Listening to or watching this video should give you a high level overview of the subject allowing you to have a conceptual map of the territory which will allow you to zero in on what you need to know if you choose to dive into more detail later. User rights include log on rights and permissions. Log on rights control who is authorized to log on to a device and how they can log on. User rights permissions control access to computer and domain resources and they can override permissions that have been set on specific objects. User rights are managed in group policy under the user rights assignment item. Each user right has a constant name and a group policy name associated with it. The constant names are used when referring to the user right in log events. You can configure the user rights assignment settings in the following location within the group policy management console under computer configuration, backslash windows settings, backslash security settings, backslash local policies, backslash user rights assignment. There are 45 user rights assignment policies. The access credential manager as a trusted caller policy setting is used by credential manager during backup and restore. No accounts should have this privilege because it's assigned only to the win log on service. Saved credentials of users may be compromised if this privilege is given to other entities. Don't modify this policy setting from the default. The access this computer from the network policy setting determines which users can connect to the device from the network. This capability is required by many network protocols including server message block, SMB, base protocols, net bios, common internet file system, CIFS and component object model plus, con plus users, devices and service accounts gain or lose that access this computer from the network user right by being explicitly or implicitly added or removed from a security group that has been granted this user right. For example, a user account or a machine account may be explicitly added to a custom security group or a building security group or it may be implicitly added by windows to a computed security group such as domain users, authenticated users or enterprise domain controllers. By default, user accounts and machine accounts are granted that access this computer from the network user right when computed groups such as authenticated users. And for domain controllers, the enterprise domain controllers group are defined in the default domain controllers group policy object. On desktop devices or member service grant this right only to users and administrators. On domain controllers, grant this right only to authenticated users, enterprise domain controllers and administrators. On failover clusters, make sure this right is granted to authenticated users. This setting includes the everyone group to ensure backward compatibility. Upon windows upgrade, after you've verified that all users and groups are correctly migrated, you should remove the everyone group and use the authenticated users group instead. The act is part of the operating system. Policy setting determines whether a process can assume the identity of any user and thereby gain access to the resources that the user is authorized to access. Typically, only low level authentication services require this user right. Potential access isn't limited to what is associated with the user by default. The calling process may request that arbitrary extra privileges be added to the access token. The calling process may also build an access token that doesn't provide a primary identity for auditing in the system event logs. If a service requires this user right, configure the service to sign in by using the local system account which inherently includes this user right. You should not create a separate user account and assign this user right to it but instead use the local system account. The add workstations to domain policy determines which users can add a device to a specific domain. For it to take effect, the policy must be assigned so that it applies to at least one domain controller. A user who is assigned this user right can add up to 10 workstations to the domain. Adding a machine account to the domain allows the device to participate in active directory based networking. Configure this setting so that only authorized members of the IT team are allowed to add devices to the domain. The adjust memory quotas for a process policy determines who can change the maximum memory that can be consumed by a process. This privilege is useful for system tuning on a group or user basis. This user right is defined in the default domain controller GPO and in the local security policy of workstations and servers. Restrict the adjust memory quotas for a process user right to only users who require the ability to adjust memory quotas to perform their jobs. If this user right is necessary for a user account on a specific computer, it can be assigned to a local machine account instead of to a domain account. The allow log on locally policy determines which users can start an interactive session on the device. Users must have this user right to log on over a remote desktop services session that is running on a Windows based member device or domain controller. You should note that users who do not have this right are still able to start a remote interactive session on the device if they have the allow log on through remote desktop services right. By default, the members of the following groups have this right on workstations and servers, administrators, backup operators, users. By default, the members of the following groups have this right on domain controllers. Account operators, administrators, backup operators, enterprise domain controllers, print operators, server operators. You should restrict this user right to legitimate users who must log on to the console of the device. If you selectively remove default groups, you can limit the abilities of users who are assigned to specific administrative roles in your organization. The allow log on through remote desktop services policy determines which users or groups can access the sign in screen of a remote device through a remote desktop services connection. It's possible for a user to establish a remote desktop services connection to a particular server but not be able to sign into the console of that same server. By default, members of the administrators group have this right on domain controllers, workstations and servers. The remote desktop's users group also has this right on workstations and servers. To control who can open a remote desktop services connection and sign into the device, add users to or remove users from the remote desktop users group. The backup files and directories policy determines which users can bypass file and directory, registry and other persistent object permissions for the purposes of backing up the system. This user right is effective only when an application attempts access through the NTFS backup application API. Otherwise, standard file and directory permissions apply. This user right is similar to granting the following permissions to the user or group you selected on all files and folders on the system. Traverse folder slash execute file, list folder slash read data, guide attributes, guide extended attributes, guide permissions, default security principles that have this right on workstations and servers are administrators and backup operators. Default security principles that have this right on domain controllers are administrators, backup operators and server operators. You should restrict the backup files and directories user right to members of the IT team who must backup organizational data as part of their daily job responsibilities because there's no way to be sure that a user is backing up data, stealing data or copying data to be distributed only assign this user right to trusted users. If your backup software runs under specific service accounts, only these accounts and not the IT staff should have the user right to backup files and directories. The bypass traverse checking policy determines which users or a process that acts on behalf of the user's account have permission to navigate an object path in the NTFS file system or in the registry without being checked for the traverse folder special access permission. This user right doesn't allow the user to list the contents of a folder. It only allows the user to traverse folders to access permitted files or subfolders. Domain controller effective default settings grant this right to the following security principles. Administrators, authenticated users, everyone, local service, network service, pre-Windows 2000 compatible access. Member server effective default settings grant this right to the following security principles. Administrators, backup operators, users, everyone, local service, network service. Use access based enumeration when you want to prevent users from seeing any folder or file to which they don't have access. Use the default settings of this policy in most cases. If you change the settings, verify your intent through testing. The change the system time policy setting determines which users can adjust the time on the device's internal clock. This right allows the computer user to change the date and time associated with records in the event logs, database transactions and the file system. This right is also required by the process that performs time synchronization. This setting doesn't impact the user's ability to change the time zone or other display characteristics of the system time. By default, members of the administrators and local service groups have this right on workstations and servers. Members of the administrators, server operators and local service groups have this right on domain controllers. You should restrict the change the system time user right to users with a legitimate need to change the system time. Remember that the automatic time synchronization process should keep the clocks aligned with an existing time source. The change the time zone policy determines which users can adjust the time zone that is used by the device for displaying the local time, which includes the device's system time plus the time zone offset. Effective default settings grant this to administrators and users. The create a page file policy determines which users can create and change the size of a page file. It determines whether users can specify a page file size for a particular drive in the performance options box located on the advanced tab of the system properties dialog box or through using internal APIs. Windows designates a section of the hard drive as virtual memory known as the page file or more specifically as page file dot sys. It's used to supplement the computer's RAM to improve performance for frequently used programs and data. Although the file is hidden from browsing, you can manage it using the system settings. By default, members of the administrators group have this right. When a user signs into the local device or connects to a remote device through a network, Windows builds the user's access token. Then the system examines the token to determine the level of the user's privileges. When you revoke a privilege, the change is immediately recorded but the change isn't reflected in the user's access token until the next time the user logs on or connects. The create a token object policy determines which accounts a process can use to create a token and which accounts it can then use to gain access to local resources when the process uses IntiCreateToken or other token creation APIs. This user right is used internally by the operating system. Unless it's necessary, don't assign this user right to a user, group or process other than local system. A global object is an object that can be used by any number of processes or threads. Even those processes or threads not started within the user session. Remote desktop services uses global objects in its processes to facilitate connections and access. The create global objects policy setting determines which users can create global objects that are available to all sessions. Users can still create objects that are specific to their own session if they don't have this user right. By default, members of the administrators group have this right as do local service and network service accounts. The create permanent shared objects user right determines which accounts can be used by processes to create a directory object by using the object manager. Directory objects include active directory objects, files and folders, printers, registry keys, processes and threads. Users who have this capability can create permanent shared objects including devices, semaphores and mutexes. This user right is useful to kernel mode components that extend the object namespace because components that are running in kernel mode inherently have this user right assigned to them. It is not necessary to specifically assign it. Do not assign this right to any users. Users who have the create permanent shared objects user right could create new shared objects and expose sensitive data to the network. By default, local system is the only account that has this right. The create symbolic links user right determines if users can create a symbolic link from the device they're logged onto. A symbolic link is a file system object that points to another file system object that is called the target. Symbolic links are transparent to users. The links appear as normal files or directories and they can be acted upon by the user or application in exactly the same manner. Symbolic links are designed to aid in migration and application compatibility with UNIX operating systems. Microsoft has implemented symbolic links to function just like UNIX links. Only trusted users should get this user right. Symbolic links can expose security vulnerabilities in applications that aren't designed to handle them. By default, members of the administrators group have this right. The debug programs, policy setting determines which users can attach to or open any process, even a process they do not own. Developers who are debugging their own applications do not need this user right. Developers who are debugging new system components need this user right. This user right provides access to sensitive and critical operating system components. Assign this user right only to trusted users to reduce security vulnerabilities. By default, members of the administrators group have this right. The deny access to this computer from the network setting determines which users are prevented from accessing a device over the network. Because all Active Directory domain services programs use a network logon for access, be extremely careful if you choose to assign this user right on domain controllers. By default, this setting is assigned to the desk account on domain controllers and on standalone servers. The deny logon as a batch job policy setting determines which accounts are prevented from logging on by using a batch queue tool to schedule and start jobs automatically in the future. The ability to sign in by using a batch queue tool is needed for any account that is used to start scheduled jobs with the task scheduler. Deny logon as a batch job prevents administrators or operators from using their personal accounts to schedule tasks. Domain admin accounts shouldn't be using their credentials to run scheduled jobs. Creating specific accounts to run these tasks or using service accounts helps with business continuity when that person transitions to other positions or responsibilities. The deny logon as a service policy setting determines which users are prevented from logging on to the service applications on a device. A service is an application type that runs in the system background without a user interface. It provides core operating system features such as web serving, event logging, file serving, printing, cryptography, and error reporting. This right might be assigned on member server computers to sensitive accounts such as the default domain administrator account or members of the domain admins group when securing accounts in that group. Domain admin accounts shouldn't be configured to a service accounts. Use group manage service accounts and assign minimum privileges to those accounts. The deny logon locally policy setting determines which users are prevented from logging on directly at the device's console. You should assign the deny logon locally user right to the local desk account to restrict access by potentially unauthorized users. Test your modifications to this policy setting in conjunction with the allow logon locally policy setting to determine if the user account is subject to both policies. This right might be assigned on member server computers to sensitive accounts such as the default domain administrator account or members of the domain admins group when securing accounts in that group. You should use local administrator password solution if you need to gain local administrator access to a domain member computer. The deny logon through remote desktop services policy setting determines which users are prevented from logging onto the device through a remote desktop connection through remote desktop services. It's possible for a user to establish a remote desktop connection to a particular server but not be able to sign into the console of that server. To control, you can open a remote desktop connection and sign into the device, add the user account to or remove user accounts from the remote desktop users group. This right might be assigned on member server computers to sensitive accounts such as the default domain administrator account or members of the domain admins group when securing accounts in that group. You should implement local administrator password solution if you need to provide and use local administrator access to a domain member computer. To enable computer and user accounts to be trusted for delegation, policy setting determines which users can set the trusted for delegation setting on a user or computer object. Security account delegation enables connection to multiple servers and each server change retains the authentication credentials of the original client. Delegation of authentication is a capability that client and server applications use when they have multiple tiers. It allows a public facing service to use client credentials to authenticate to an application or database service. For this configuration to be possible, the client and the server must run under accounts that are trusted for delegation. Only administrators who have the enabled computer and user accounts to be trusted for delegation credential can set up delegation. Domain admins and enterprise admins have this credential. The user or machine object that is granted this right must have right access to the account control flags. The server process running on a device or under a user context that is trusted for delegation can access resources on another computer by using the delegated credentials of a client. However, the client account must have right access to the account control flags on the object. There's no reason to assign this user right to anyone on member servers and workstations that belong to a domain because it has no meaning in those contexts. It's only relevant on domain controllers and standalone devices. The force shut down from a remote system, security setting determines which users are allowed to shut down a device from a remote location on the network. This setting allows members of the administrator's group or specific users to manage computers for tasks such as a restart from a remote location. You should explicitly restrict this user right to members of the administrator's group or other assigned roles that require this capability. The generate security audits policy setting determines which accounts can be used by a process to generate audit records in the security event log. The local security authority subsystem service, ELSARS, writes events to the log. You can use the information in the security event log to trace unauthorized device access because the audit log can potentially be an attack vector if an account is compromised. Ensure that only the local service and network service accounts have the generate security audits user right assigned to them. Impersonation is the ability of a thread to run in a security context that is different from the context of the process that owns the thread. Impersonation is designed to meet the security requirements of client server applications. When running in a client security context, a service is the client to some degree. One of the services threat uses an access token representing the client's credentials to obtain access to the objects to which the client has access. The primary reason for impersonation is to cause access checks to be performed against the client's identity. Using the client's identity for access checks can cause access to be either restricted or expanded depending on what the client has permission to do. The impersonate a client after authentication, policy setting determines which programs are allowed to impersonate a user or another specified account and act on behalf of the user. If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect, for example, by RPC or named pipes to a service that they have created to impersonate that client. Such an action could elevate the unauthorized user's permissions to administrative or system levels. Services that are started by the service control manager have the built-in service group added by default to their access tokens. Con servers that are started by the common infrastructure and configured to run under a specific account also have the service group added to their access tokens. As a result, these processes are assigned this user right when they are started. By default, this setting is administrators, local service, network service and service on domain controllers and standalone service. Users do not usually need to have this user right assigned. A user can impersonate an access token if any of the following conditions exist. The access token that is being impersonated is for this user. The user in this session logged onto the network with explicit credentials to create the access token. The requested level is less than impersonate such as anonymous or identifier. The increase a process working set policy setting determines which users can increase or decrease the size of the working set of a process. The working set of a process is the set of memory pages currently visible to the process in physical RAM. These pages are resident and they're available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process. By default, standard users have this right. You should make users aware that adverse performance issues may occur if they modify this security setting. The increased scheduling priority policy setting determines which user accounts can increase the base priority class of a process. It is not a privileged operation to increase relative priority within a priority class. This user right is not required by administrative tools that are supplied with the operating system but it might be required by software development tools. Specifically, this security setting determines which accounts can use a process with right property access to another process to increase the run priority that is assigned to the other process. A user with this privilege can change the scheduling priority of a process through the task manager user interface. You should retain the default value as the only accounts responsible for controlling process scheduling priorities already have these rights. The load and unload device drivers policy setting determines which users can dynamically load and unload device drivers. This user right isn't required if assigned driver for the new hardware already exists in the driver store on the device. Device drivers run as highly privileged code. Windows supports the plug and play specifications that define how a computer can detect and configure newly added hardware and then automatically install the device driver. Prior to plug and play, users needed to manually configure devices before attaching them to the computer. If you are old enough to remember setting IRQ settings through jumpers, then you know what I'm talking about. Plug and play allows a user to plug in the hardware, then Windows searches for an appropriate device driver package and automatically configures it to work without interfering with other devices. It works most of the time. Sometimes you have hardware so old that there is not a current device driver, which is why a lot of people are still running Windows server operating systems that are legally allowed to vote. Because device driver software runs as if it's a part of the operating system with unrestricted access to the entire computer, it's critical that only known and authorized device drivers be permitted. By default, this setting is administrators and print operators on domain controllers and administrators on standalone servers. Because of the potential security risk, don't assign this user right to any user, group, or process that you don't want to take over the system. The block pages in memory policy setting determines which accounts can use a process to keep data in physical memory, which prevents the computer from paging the data to virtual memory on a disk. Thereby, the amount of memory that Windows can reclaim under pressure is limited. This limitation could lead to performance degradation. Normally, an application running on Windows can negotiate for more physical memory and in response to the request, the application begins to move the data from RAM, such as the data cache to a disk. When the pageable memory is moved to a disk, more RAM is free for the operating system to use. You might be able to come up with a reason why data shouldn't be written to the disk, but when you can bitlock that encrypt storage, the chances that memory contents might be recovered from a disk by an attacker are lower. The logon as a batch job policy setting determines which accounts can sign in by using a batch queue tool, such as the task scheduler service. When you use the add scheduled task wizard to schedule a task to run under a particular user name and password, that user is automatically assigned the logon as a batch job user right. When the schedule time arrives, the task scheduler service logs on the user as a batch job instead of as an interactive user, and the task runs in the user security context. Members of the local administrators group have this right by default. Use discretion when assigning this right to specific users for security reasons. The default settings are sufficient in most cases. Also consider using separate accounts with specially crafted reduce privileges for scheduled tasks if necessary. The logon as a service policy determines which service accounts can register a process as a service. Running a process under a service account circumvents the need for human intervention. By default, this setting is network service on domain controllers and standalone servers. You should minimize the number of accounts that are granted this user right. The Manage Auditing and Security Log allows a user who is assigned this user right to view and clear the security log in Event Viewer. This policy determines which users can specify object access audit options for individual resources, such as files, active directory objects, and registry keys. These objects specify their system access control lists. Generally, assigning this user right to groups other than administrators isn't necessary. The Modify and Object label privilege determines which user accounts can modify the integrity label of objects, such as files, registry keys, or processes owned by other users. Processes running under a user account can modify the label of an object owned by the user to a lower level without this privilege. The integrity label is used by the Windows Integrity Controls WIC feature. WIC keeps lower integrity processes from modifying higher integrity processes by assigning one of six possible labels to objects on the system. Although similar to NTFS file and folder permissions, which are discretionary controls on objects, the WIC integrity levels are mandatory controls that are put in place and enforced by the operating system. The following list describes the integrity levels from lowest to highest. Untrusted is the default assignment for processes that are logged on anonymously. Low is the default assignment for processes that interact with the internet. Medium is the default assignment for standard user accounts and any object that isn't explicitly designated with a lower or higher integrity level. High is the default assignment for administrative accounts and processes that request to run using administrative rights. System is the default assignment for Windows kernel and core services. Installer is used by setup programs to install software. It's important that only trusted software is installed on computers because objects that are assigned the installer integrity level can install, modify, and uninstall all other objects. Anyone with a modify and object label user right can change the integrity level of a file or process so that it becomes elevated or decreased to a point where it can be deleted by lower integrity processes. Either of these states effectively circumvents the protection that is offered by Windows integrity controls and makes your system vulnerable to attacks by militia software. If militia software is set with an elevated integrity level such as trusted installer or system, administrator accounts don't have sufficient integrity levels to delete the program from the system. In that case, use of the modify and object label right is mandated so that the object can be relabeled. However, the relabeling must occur by using a process that is at the same or a higher level of integrity than the object that you're attempting to relabel. Do not give any group this right. If necessary, implement it for a constrained period of time to a trusted individual when they need to respond to a specific organizational need. The modify firmware environment values security setting determines who can modify firmware environment values. Firmware environment values are settings that are stored in the non-volatile RAM of non-EX86 based computers. The effect of the setting depends on the processor. On EX86 based computers, the only firmware environment value that can be modified by assigning this user right is the last known good configuration setting which should only be modified by the system. The exact setting for firmware environment values is determined by the boot firmware. The location of these values is also specified by the firmware. For example, on a UEFI based system, NVRAM contains firmware environment values that specify system boot settings. On all computers, this user right is required to install or upgrade windows. By default, this setting is administrators on domain controllers and on standalone servers. The perform volume maintenance tasks, policy setting determines which users can perform volume or disk management tasks such as defragmenting an existing volume, creating removing volumes and running the disk cleanup tool. Use Culsion when assigning this user right. Users with this user right can explore disks and extend files into memory that contains other data. When the extended files are opened, the user might be able to read and modify the acquired data. By default, this setting is administrators on domain controllers and on standalone servers. The profile single process policy setting determines which users can view as sample performance of an application process. Typically, you don't need this user right to use the performance reporting tools included in the operating system. However, you do need this user right if the system's monitor components are configured to collect data through Windows Management Instrumentation, WMI. By default, this setting is configured for administrators on domain controllers and on standalone servers. This right shouldn't be granted to individual users. It should be granted only for trusted applications that monitor other programs. The profile system performance security setting determines which users can use Windows performance monitoring tools to monitor the performance of system processors. By default, this setting is administrators and NTService backslash WDI service host on domain controllers and on standalone servers. The replace a process level token policy setting determines which parent processors can replace the access token that is associated with a child process. Specifically, the replace a process level token setting determines which user accounts can call the create process as user API so that one service can start another. An example of a process that uses this user right is task scheduler where the user right is extended to any processes that can be managed by task scheduler. An access token is an object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account that is associated with the process or thread. With this user right, every child process that runs on behalf of this user account would have its access token replaced with the process level token. For member servers, ensure that only the local service and network service accounts have the replace a process level token user right. The restore files and directories setting determines which users can bypass file, directory, registry and other persistent object permissions when they restore backed up files and directories. And it determines which users can set valid security principles as the owner of an object. Granting this user right to an account is similar to granting the account the following permissions to all files and folders on the system. Traverse folder slash execute file and write. Users with this user right can override registry settings, hide data and gain ownership of system objects so only assign this user right to trusted users. By default, this right is granted to the administrators, backup operators and server operators groups on domain controllers and to the administrators and backup operators groups on standalone servers. But shut down the system security policy setting determines if a user who is logged on locally to a device can shut down windows. Shutting down domain controllers makes them unable to do things like process sign in requests, process group policy settings and answer LDAP queries. Shutting down domain controllers that have been assigned operations master roles which are also known as flexible single master operations or FISMO roles can disable key domain functionality. For example, processing sign in requests for new passwords, which are done by the primary domain controller, PDC emulator master. The shut down the system user right is required to enable hibernation support to set the power management settings and to cancel a shutdown. By default, this setting is administrators, backup operators, server operators and print operators on domain controllers and administrators and backup operators on standalone servers. You may wish to change these default settings to comply with recommended practice. Ensure that only administrators and backup operators have the shut down the system user right on member servers and that only administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that their delegated tasks won't be negatively affected. The synchronized directory service data, policy setting determines which users and groups have authority to synchronize all directory service data regardless of the protection for objects and properties. This privilege is required to use LDAP directory synchronization services. Domain controllers have this user right inherently because the synchronization process runs in the context of the system account on domain controllers. Ensure that no accounts are assigned the synchronized directory service data user right. Only domain controllers need this privilege which they inherently have. Take ownership of files, other objects, policy setting determines which users can take ownership of any secureable object in the device including active directory objects, NTFS files and folders, printers, registry keys, services, processors and threads. Every object has an owner whether the object resides in an NTFS volume or active directory database. The owner controls how permissions are set on the object and to whom permissions are granted. By default, the owner is the person who or the process that created the object. Owners can always change permissions to objects even when they're denied all access to the object. By default, this setting is administrators on domain controllers and on standalone servers. Assigning this user right can be a security risk because owners of objects have full control of them only assign this user right to trusted users. A trusted user is one who you know will not steal from or try to as your arc enable your stash of Tim Tans in the staff fridge. This video summarized the functionality of each of the different user rights assignment policies and discussed recommended settings. User rights assignment is one of those meat and potatoes features of the operating system that we all have a cursory understanding of but rarely think about in depth. Hopefully, listening to or watching this video should have provided you a high level overview of the subject allowing you to have a conceptual map of the territory which will allow you to zero in on what you need to know if you choose to dive later into the documentation linked in the video's description. I hope you found this video useful and informative. My name is Oren Thomas. You can find me at aka.ms slash oren and if you've got any questions or feedback drop a comment below.