windows-itpro-docs/windows/keep-secure/create-global-objects.md
Jan Backstrom f046a5fec0 tagging update
change W10 to w10 (lower case), add security pagetype to various
2016-05-26 17:07:01 -07:00

93 lines
4.4 KiB
Markdown
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: Create global objects (Windows 10)
description: Describes the best practices, location, values, policy management, and security considerations for the Create global objects security policy setting.
ms.assetid: 9cb6247b-44fc-4815-86f2-cb59b6f0221e
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
author: brianlic-msft
---
# Create global objects
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Create global objects** security policy setting.
## Reference
This 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 do not have this user right.
A global object is an object that is created to be used by any number of processes or threads, even those not started within the users session. Remote Desktop Services uses global objects in its processes to facilitate connections and access.
Constant: SeCreateGlobalPrivilege
### Possible values
- User-defined list of accounts
- Default accounts listed below
### Best practices
- Do not assign any user accounts this right.
### Location
Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\User Rights Assignment
### Default values
By default, members of the Administrators group have this right, as do Local Service and Network Service accounts on the supported versions of Windows. Service is included for backwards compatibility with earlier versions of Windows.
The following table lists the actual and effective default policy values. Default values are also listed on the policys property page.
| Server type or GPO | Default value |
| - | - |
| Default Domain Policy | Not Defined |
| Default Domain Controller Policy | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Stand-Alone Server Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Domain Controller Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Member Server Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
| Client Computer Effective Default Settings | Administrators<br/>Local Service<br/>Network Service<br/>Service|
 
## Policy management
A restart of the device is not required for this policy setting to take effect.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Settings are applied in the following order through a Group Policy Object (GPO), which will overwrite settings on the local computer at the next Group Policy update:
1. Local policy settings
2. Site policy settings
3. Domain policy settings
4. OU policy settings
When a local setting is greyed out, it indicates that a GPO currently controls that setting.
## Security considerations
This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
### Vulnerability
>**Caution:**  A user account that is given this user right has complete control over the system, and it can lead to the system being compromised. We highly recommend that you do not assign this right to any user accounts.
 
Windows examines a user's access token to determine the level of the user's privileges. Access tokens are built when users log on to the local device or connect to a remote device over a network. When you revoke a privilege, the change is immediately recorded, but the change is not reflected in the user's access token until the next time the user logs on or connects. Users with the ability to create or modify tokens can change the level of access for any currently logged on account. They could escalate their privileges or create a denial-of-service (DoS) condition.
### Countermeasure
Do not assign the **Create a token object** user right to any users. Processes that require this user right should use the Local System account, which already includes it, instead of a separate user account with this user right assigned.
### Potential impact
None. Not Defined is the default domain policy configuration.
## Related topics
- [User Rights Assignment](user-rights-assignment.md)