deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-14 14:27:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #6906 from MicrosoftDocs/main

Browse Source 
Publish 08/05/2022 3:30 PM PT
This commit is contained in:
Angela Fleischmann 2022-08-05 16:40:16 -06:00 committed by GitHub
commit 012729d4e1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
10 changed files with 42 additions and 3435 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
.openpublishing.redirection.json
View File

@ -6507,8 +6507,8 @@
},
{
"source_path": "windows/access-protection/access-control/dynamic-access-control.md",
"redirect_url": "/windows/security/identity-protection/access-control/dynamic-access-control",
"redirect_document_id": false
"redirect_url": "/windows-server/identity/solution-guides/dynamic-access-control-overview",
"redirect_document_id": true
},
{
"source_path": "windows/access-protection/access-control/local-accounts.md",
@ -19589,6 +19589,46 @@
"source_path": "windows/whats-new/contribute-to-a-topic.md",
"redirect_url": "https://github.com/MicrosoftDocs/windows-itpro-docs/blob/public/CONTRIBUTING.md#editing-windows-it-professional-documentation",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/security-identifiers.md",
"redirect_url": "/windows-server/identity/ad-ds/manage/understand-security-identifiers",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/security-principals.md",
"redirect_url": "/windows-server/identity/ad-ds/manage/understand-security-principals",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/active-directory-accounts.md",
"redirect_url": "/windows-server/identity/ad-ds/manage/understand-default-user-accounts",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/microsoft-accounts.md",
"redirect_url": "/windows-server/identity/ad-ds/manage/understand-microsoft-accounts",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/service-accounts.md",
"redirect_url": "/windows-server/identity/ad-ds/manage/understand-service-accounts",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/active-directory-security-groups.md",
"redirect_url": "/windows-server/identity/ad-ds/manage/understand-security-groups",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/special-identities.md",
"redirect_url": "/windows-server/identity/ad-ds/manage/understand-special-identities-groups",
"redirect_document_id": false
},
{
"source_path": "windows/security/identity-protection/access-control/dynamic-access-control.md",
"redirect_url": "/windows-server/identity/solution-guides/dynamic-access-control-overview",
"redirect_document_id": false
}
]
}

16
windows/security/TOC.yml
View File

@ -323,24 +323,8 @@
- name: Access Control Overview
href: identity-protection/access-control/access-control.md
items:
- name: Dynamic Access Control Overview
href: identity-protection/access-control/dynamic-access-control.md
- name: Security identifiers
href: identity-protection/access-control/security-identifiers.md
- name: Security Principals
href: identity-protection/access-control/security-principals.md
- name: Local Accounts
href: identity-protection/access-control/local-accounts.md
- name: Active Directory Accounts
href: identity-protection/access-control/active-directory-accounts.md
- name: Microsoft Accounts
href: identity-protection/access-control/microsoft-accounts.md
- name: Service Accounts
href: identity-protection/access-control/service-accounts.md
- name: Active Directory Security Groups
href: identity-protection/access-control/active-directory-security-groups.md
- name: Special Identities
href: identity-protection/access-control/special-identities.md
- name: User Account Control
href: identity-protection/user-account-control/user-account-control-overview.md
items:

621
windows/security/identity-protection/access-control/active-directory-accounts.md
View File

@ -1,621 +0,0 @@
---
title: Active Directory Accounts (Windows 10)
description: Active Directory Accounts
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection:
- M365-identity-device-management
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 08/23/2019
---
# Active Directory Accounts
**Applies to**
- Windows Server 2016
Windows Server operating systems are installed with default local accounts. In addition, you can create user accounts to meet the requirements of your organization. This reference topic for the IT professional describes the Windows Server default local accounts that are stored locally on the domain controller and are used in Active Directory.
This reference topic does not describe default local user accounts for a member or standalone server or for a Windows client. For more information, see [Local Accounts](local-accounts.md).
## About this topic
This topic describes the following:
- [Default local accounts in Active Directory](#sec-ad-default-accounts)
- [Administrator account](#sec-administrator)
- [Guest account](#sec-guest)
- [HelpAssistant account (installed with a Remote Assistance session)](#sec-helpassistant)
- [KRBTGT account](#sec-krbtgt)
- [Settings for default local accounts in Active Directory](#sec-account-settings)
- [Manage default local accounts in Active Directory](#sec-manage-local-accounts)
- [Restrict and protect sensitive domain accounts](#sec-restrict-protect-accounts)
- [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
- [Create dedicated workstation hosts without Internet and email access](#task2-admin-workstations)
- [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
- [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
- [Secure and manage domain controllers](#sec-secure-manage-dcs)
## <a href="" id="sec-ad-default-accounts"></a>Default local accounts in Active Directory
Default local accounts are built-in accounts that are created automatically when a Windows Server domain controller is installed and the domain is created. These default local accounts have counterparts in Active Directory. These accounts also have domain-wide access and are completely separate from the default local user accounts for a member or standalone server.
You can assign rights and permissions to default local accounts on a particular domain controller, and only on that domain controller. These accounts are local to the domain. After the default local accounts are installed, they are stored in the Users container in Active Directory Users and Computers. It is a best practice to keep the default local accounts in the User container and not attempt to move these accounts, for example, to a different organizational unit (OU).
The default local accounts in the Users container include: Administrator, Guest, and KRBTGT. The HelpAssistant account is installed when a Remote Assistance session is established. The following sections describe the default local accounts and their use in Active Directory.
Primarily, default local accounts do the following:
- Let the domain represent, identify, and authenticate the identity of the user that is assigned to the account by using unique credentials (user name and password). It is a best practice to assign each user to a single account to ensure maximum security. Multiple users are not allowed to share one account. A user account lets a user sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
- Authorize (grant or deny) access to resources. After a user’s credentials have been authenticated, the user is authorized to access the network and domain resources based on the user’s explicitly assigned rights on the resource.
- Audit the actions that are carried out on a user account.
In Active Directory, default local accounts are used by administrators to manage domain and member servers directly and from dedicated administrative workstations. Active Directory accounts provide access to network resources. Active Directory User accounts and Computer accounts can represent a physical entity, such as a computer or person, or act as dedicated service accounts for some applications.
Each default local account is automatically assigned to a security group that is preconfigured with the appropriate rights and permissions to perform specific tasks. Active Directory security groups collect user accounts, computer accounts, and other groups into manageable units. For more information, see [Active Directory Security Groups](active-directory-security-groups.md).
On an Active Directory domain controller, each default local account is referred to as a security principal. A security principal is a directory object that is used to secure and manage Active Directory services that provide access to domain controller resources. A security principal includes objects such as user accounts, computer accounts, security groups, or the threads or processes that run in the security context of a user or computer account. For more information, see [Security Principals](security-principals.md).
A security principal is represented by a unique security identifier (SID).The SIDs that are related to each of the default local accounts in Active Directory are described in the sections below.
Some of the default local accounts are protected by a background process that periodically checks and applies a specific security descriptor. A security descriptor is a data structure that contains security information that is associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the default local accounts or groups is overwritten with the protected settings.
This security descriptor is present on the AdminSDHolder object. If you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object to ensure that it is applied consistently. Be careful when making these modifications, because you are also changing the default settings that are applied to all of your protected accounts.
## <a href="" id="sec-administrator"></a>Administrator account
The Administrator account is a default account that is used in all versions of the Windows operating system on every computer and device. The Administrator account is used by the system administrator for tasks that require administrative credentials. This account cannot be deleted or locked out, but the account can be renamed or disabled.
The Administrator account gives the user complete access (Full Control permissions) of the files, directories, services, and other resources that are on that local server. The Administrator account can be used to create local users, and assign user rights and access control permissions. Administrator can also be used to take control of local resources at any time simply by changing the user rights and permissions. Although files and directories can be protected from the Administrator account temporarily, the Administrator account can take control of these resources at any time by changing the access permissions.
**Account group membership**
The Administrator account has membership in the default security groups as described in the Administrator account attributes table later in this topic.
The security groups ensure that you can control administrator rights without having to change each Administrator account. In most instances, you do not have to change the basic settings for this account. However, you might have to change its advanced settings, such as membership in particular groups.
**Security considerations**
After installation of the server operating system, your first task is to set up the Administrator account properties securely. This includes setting up an especially long, strong password, and securing the Remote control and Remote Desktop Services profile settings.
The Administrator account can also be disabled when it is not required. Renaming or disabling the Administrator account makes it more difficult for malicious users to try to gain access to the account. However, even when the Administrator account is disabled, it can still be used to gain access to a domain controller by using safe mode.
On a domain controller, the Administrator account becomes the Domain Admin account. The Domain Admin account is used to sign in to the domain controller and this account requires a strong password. The Domain Admin account gives you access to domain resources.
> [!NOTE]
> When the domain controller is initially installed, you can sign in and use Server Manager to set up a local Administrator account, with the rights and permissions you want to assign. For example, you can use a local Administrator account to manage the operating system when you first install it. By using this approach, you can set up the operating system without getting locked out. Generally, you do not need to use the account after installation. You can only create local user accounts on the domain controller, before Active Directory Domain Services is installed, and not afterwards.
When Active Directory is installed on the first domain controller in the domain, the Administrator account is created for Active Directory. The Administrator account is the most powerful account in the domain. It is given domain-wide access and administrative rights to administer the computer and the domain, and it has the most extensive rights and permissions over the domain. The person who installs Active Directory Domain Services on the computer creates the password for this account during the installation.
**Administrator account attributes**
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-500|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|N/A|
|Default member of|Administrators, Domain Admins, Enterprise Administrators, Domain Users. Note that the Primary Group ID of all user accounts is Domain Users. <br/><br/>Group Policy Creator Owners, and Schema Admins in Active Directory<br/><br/>Domain Users group|
|Protected by ADMINSDHOLDER?|Yes|
|Safe to move out of default container?|Yes|
|Safe to delegate management of this group to non-service administrators?|No|
## <a href="" id="sec-guest"></a>Guest account
The Guest account is a default local account that has limited access to the computer and is disabled by default. By default, the Guest account password is left blank. A blank password allows the Guest account to be accessed without requiring the user to enter a password.
The Guest account enables occasional or one-time users, who do not have an individual account on the computer, to sign in to the local server or domain with restricted rights and permissions. The Guest account can be enabled, and the password can be set up if needed, but only by a member of the Administrator group on the domain.
**Account group membership**
The Guest account has membership in the default security groups that are described in the following Guest account attributes table. By default, the Guest account is the only member of the default Guests group, which lets a user sign in to a server, and the Domain Guests global group, which lets a user sign in to a domain.
A member of the Administrators group or Domain Admins group can set up a user with a Guest account on one or more computers.
**Security considerations**
Because the Guest account can provide anonymous access, it is a security risk. It also has a well-known SID. For this reason, it is a best practice to leave the Guest account disabled, unless its use is required and then only with restricted rights and permissions for a very limited period of time.
When the Guest account is required, an Administrator on the domain controller is required to enable the Guest account. The Guest account can be enabled without requiring a password, or it can be enabled with a strong password. The Administrator also grants restricted rights and permissions for the Guest account. To help prevent unauthorized access:
- Do not grant the Guest account the [Shut down the system](/windows/device-security/security-policy-settings/shut-down-the-system) user right. When a computer is shutting down or starting up, it is possible that a Guest user or anyone with local access, such as a malicious user, could gain unauthorized access to the computer.
- Do not provide the Guest account with the ability to view the event logs. After the Guest account is enabled, it is a best practice to monitor this account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
- Do not use the Guest account when the server has external network access or access to other computers.
If you decide to enable the Guest account, be sure to restrict its use and to change the password regularly. As with the Administrator account, you might want to rename the account as an added security precaution.
In addition, an administrator is responsible for managing the Guest account. The administrator monitors the Guest account, disables the Guest account when it is no longer in use, and changes or removes the password as needed.
For details about the Guest account attributes, see the following table.
**Guest account attributes**
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-501|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|None|
|Default member of|Guests, Domain Guests|
|Protected by ADMINSDHOLDER?|No|
|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
## <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed with a Remote Assistance session)
The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.
HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the user’s invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
**Security considerations**
The SIDs that pertain to the default HelpAssistant account include:
- SID: S-1-5-`<domain>`-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note that, in Windows Server 2008, Remote Desktop Services are called Terminal Services.
- SID: S-1-5-`<domain>`-14, display name Remote Interactive Logon. This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
For details about the HelpAssistant account attributes, see the following table.
**HelpAssistant account attributes**
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-13 (Terminal Server User), S-1-5-`<domain>`-14 (Remote Interactive Logon)|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|None|
|Default member of|Domain Guests<p>Guests|
|Protected by ADMINSDHOLDER?|No|
|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
## <a href="" id="sec-krbtgt"></a>KRBTGT account
The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.
KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.
Windows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.
### KRBTGT account maintenance considerations
A strong password is assigned to the KRBTGT and trust accounts automatically. Like any privileged service accounts, organizations should change these passwords on a regular schedule. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. The password for a domain trust account is used to derive an inter-realm key for encrypting referral tickets.
Resetting the password requires you either to be a member of the Domain Admins group, or to have been delegated with the appropriate authority. In addition, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.
After you reset the KRBTGT password, ensure that event ID 9 in the (Kerberos) Key-Distribution-Center event source is written to the System event log.
### Security considerations
It is also a best practice to reset the KRBTGT account password to ensure that a newly restored domain controller does not replicate with a compromised domain controller. In this case, in a large forest recovery that is spread across multiple locations, you cannot guarantee that all domain controllers are shut down, and if they are shut down, they cannot be rebooted again before all of the appropriate recovery steps have been undertaken. After you reset the KRBTGT account, another domain controller cannot replicate this account password by using an old password.
An organization suspecting domain compromise of the KRBTGT account should consider the use of professional incident response services. The impact to restore the ownership of the account is domain-wide and labor intensive an should be undertaken as part of a larger recovery effort.
The KRBTGT password is the key from which all trust in Kerberos chains up to. Resetting the KRBTGT password is similar to renewing the root CA certificate with a new key and immediately not trusting the old key, resulting in almost all subsequent Kerberos operations will be affected.
For all account types (users, computers, and services)
- All the TGTs that are already issued and distributed will be invalid because the DCs will reject them. These tickets are encrypted with the KRBTGT so any DC can validate them. When the password changes, the tickets become invalid.
- All currently authenticated sessions that logged on users have established (based on their service tickets) to a resource (such as a file share, SharePoint site, or Exchange server) are good until the service ticket is required to re-authenticate.
- NTLM authenticated connections are not affected
Because it is impossible to predict the specific errors that will occur for any given user in a production operating environment, you must assume all computers and users will be affected.
> [!IMPORTANT]
> Rebooting a computer is the only reliable way to recover functionality as this will cause both the computer account and user accounts to log back in again. Logging in again will request new TGTs that are valid with the new KRBTGT, correcting any KRBTGT related operational issues on that computer.
For information about how to help mitigate the risks associated with a potentially compromised KRBTGT account, see [KRBTGT Account Password Reset Scripts now available for customers](https://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/).
### Read-only domain controllers and the KRBTGT account
Windows Server 2008 introduced the read-only domain controller (RODC). The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different KRBTGT account and password than the KDC on a writable domain controller when it signs or encrypts ticket-granting ticket (TGT) requests. After an account is successfully authenticated, the RODC determines if a user's credentials or a computer's credentials can be replicated from the writable domain controller to the RODC by using the Password Replication Policy.
After the credentials are cached on the RODC, the RODC can accept that user's sign-in requests until the credentials change. When a TGT is signed with the KRBTGT account of the RODC, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.
### KRBTGT account attributes
For details about the KRBTGT account attributes, see the following table.
|Attribute|Value|
|--- |--- |
|Well-Known SID/RID|S-1-5-`<domain>`-502|
|Type|User|
|Default container|CN=Users, DC=`<domain>`, DC=|
|Default members|None|
|Default member of|Domain Users group. Note that the Primary Group ID of all user accounts is Domain Users.|
|Protected by ADMINSDHOLDER?|Yes|
|Safe to move out of default container?|Can be moved out, but we do not recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
## <a href="" id="sec-account-settings"></a>Settings for default local accounts in Active Directory
Each default local account in Active Directory has a number of account settings that you can use to configure password settings and security-specific information, as described in the following table.
**Settings for default local accounts in Active Directory**
|Account settings|Description|
|--- |--- |
|User must change password at next logon|Forces a password change the next time that the user logs signs in to the network. Use this option when you want to ensure that the user is the only person to know his or her password.|
|User cannot change password|Prevents the user from changing the password. Use this option when you want to maintain control over a user account, such as for a Guest or temporary account.|
|Password never expires|Prevents a user password from expiring. It is a best practice to enable this option with service accounts and to use strong passwords.|
|Store passwords using reversible encryption|Provides support for applications that use protocols requiring knowledge of the plaintext form of the user’s password for authentication purposes.<br/><br/>This option is required when using Challenge Handshake Authentication Protocol (CHAP) in Internet Authentication Services (IAS), and when using digest authentication in Internet Information Services (IIS).|
|Account is disabled|Prevents the user from signing in with the selected account. As an administrator, you can use disabled accounts as templates for common user accounts.|
|Smart card is required for interactive logon|Requires that a user has a smart card to sign on to the network interactively. The user must also have a smart card reader attached to their computer and a valid personal identification number (PIN) for the smart card.<br/><br/>When this attribute is applied on the account, the effect is as follows:<li>The attribute only restricts initial authentication for interactive logon and Remote Desktop logon. When interactive or Remote Desktop logon requires a subsequent network logon, such as with a domain credential, an NT Hash provided by the domain controller is used to complete the smartcard authentication process<li>Each time the attribute is enabled on an account, the account’s current password hash value is replaced with a 128-bit random number. This invalidates the use of any previously configured passwords for the account. The value does not change after that unless a new password is set or the attribute is disabled and re-enabled.<li>Accounts with this attribute cannot be used to start services or run scheduled tasks.|
|Account is trusted for delegation|Lets a service running under this account perform operations on behalf of other user accounts on the network. A service running under a user account (also known as a service account) that is trusted for delegation can impersonate a client to gain access to resources, either on the computer where the service is running or on other computers. For example, in a forest that is set to the Windows Server 2003 functional level, this setting is found on the Delegation tab. It is available only for accounts that have been assigned service principal names (SPNs), which are set by using the setspn command from Windows Support Tools. This setting is security-sensitive and should be assigned cautiously.|
|Account is sensitive and cannot be delegated|Gives control over a user account, such as for a Guest account or a temporary account. This option can be used if this account cannot be assigned for delegation by another account.|
|Use DES encryption types for this account|Provides support for the Data Encryption Standard (DES). DES supports multiple levels of encryption, including Microsoft Point-to-Point Encryption (MPPE) Standard (40-bit and 56-bit), MPPE standard (56-bit), MPPE Strong (128-bit), Internet Protocol security (IPSec) DES (40-bit), IPSec 56-bit DES, and IPSec Triple DES (3DES).<div class="alert"> **Note:** DES is not enabled by default in Windows Server operating systems starting with Windows Server 2008 R2, nor in Windows client operating systems starting with Windows 7. For these operating systems, computers will not use DES-CBC-MD5 or DES-CBC-CRC cipher suites by default. If your environment requires DES, then this setting might affect compatibility with client computers or services and applications in your environment. For more information, see [Hunting down DES in order to securely deploy Kerberos](/archive/blogs/askds/hunting-down-des-in-order-to-securely-deploy-kerberos)</div>|
|Do not require Kerberos preauthentication|Provides support for alternate implementations of the Kerberos protocol. Because preauthentication provides additional security, use caution when enabling this option. Note that domain controllers running Windows 2000 or Windows Server 2003 can use other mechanisms to synchronize time.|
## <a href="" id="sec-manage-local-accounts"></a>Manage default local accounts in Active Directory
After the default local accounts are installed, these accounts reside in the Users container in Active Directory Users and Computers. Default local accounts can be created, disabled, reset, and deleted by using the Active Directory Users and Computers Microsoft Management Console (MMC) and by using command-line tools.
You can use Active Directory Users and Computers to assign rights and permissions on a given local domain controller, and that domain controller only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a computer, such as backing up files and folders or shutting down a computer. In contrast, an access permission is a rule that is associated with an object, usually a file, folder, or printer, that regulates which users can have access to the object and in what manner.
For more information about creating and managing local user accounts in Active Directory, see [Manage Local Users](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731899(v=ws.11)).
You can also use Active Directory Users and Computers on a domain controller to target remote computers that are not domain controllers on the network.
You can obtain recommendations from Microsoft for domain controller configurations that you can distribute by using the Security Compliance Manager (SCM) tool. For more information, see [Microsoft Security Compliance Manager](/previous-versions/tn-archive/cc677002(v=technet.10)).
Some of the default local user accounts are protected by a background process that periodically checks and applies a specific security descriptor, which is a data structure that contains security information that is associated with a protected object. This security descriptor is present on the AdminSDHolder object.
This means, when you want to modify the permissions on a service administrator group or on any of its member accounts, you are also required to modify the security descriptor on the AdminSDHolder object. This approach ensures that the permissions are applied consistently. Be careful when you make these modifications, because this action can also affect the default settings that are applied to all of your protected administrative accounts.
## <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect sensitive domain accounts
Restricting and protecting domain accounts in your domain environment requires you to adopt and implement the following best practices approach:
- Strictly limit membership to the Administrators, Domain Admins, and Enterprise Admins groups.
- Stringently control where and how domain accounts are used.
Member accounts in the Administrators, Domain Admins, and Enterprise Admins groups in a domain or forest are high-value targets for malicious users. It is a best practice to strictly limit membership to these administrator groups to the smallest number of accounts in order to limit any exposure. Restricting membership in these groups reduces the possibility that an administrator might unintentionally misuse these credentials and create a vulnerability that malicious users can exploit.
Moreover, it is a best practice to stringently control where and how sensitive domain accounts are used. Restrict the use of Domain Admins accounts and other administrator accounts to prevent them from being used to sign in to management systems and workstations that are secured at the same level as the managed systems. When administrator accounts are not restricted in this manner, each workstation from which a domain administrator signs in provides another location that malicious users can exploit.
Implementing these best practices is separated into the following tasks:
- [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
- [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
- [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
- [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
Note that, to provide for instances where integration challenges with the domain environment are expected, each task is described according to the requirements for a minimum, better, and ideal implementation. As with all significant changes to a production environment, ensure that you test these changes thoroughly before you implement and deploy them. Then stage the deployment in a manner that allows for a rollback of the change in case technical issues occur.
### <a href="" id="task1-separate-admin-accounts"></a>Separate administrator accounts from user accounts
Restrict Domain Admins accounts and other sensitive accounts to prevent them from being used to sign in to lower trust servers and workstations. Restrict and protect administrator accounts by segregating administrator accounts from standard user accounts, by separating administrative duties from other tasks, and by limiting the use of these accounts. Create dedicated accounts for administrative personnel who require administrator credentials to perform specific administrative tasks, and then create separate accounts for other standard user tasks, according to the following guidelines:
- **Privileged account**. Allocate administrator accounts to perform the following administrative duties only:
- **Minimum**. Create separate accounts for domain administrators, enterprise administrators, or the equivalent with appropriate administrator rights in the domain or forest. Use accounts that have been granted sensitive administrator rights only to administer domain data and domain controllers.
- **Better**. Create separate accounts for administrators that have reduced administrative rights, such as accounts for workstation administrators, and accounts with user rights over designated Active Directory organizational units (OUs).
- **Ideal**. Create multiple, separate accounts for an administrator who has a variety of job responsibilities that require different trust levels. Set up each administrator account with significantly different user rights, such as for workstation administration, server administration and domain administration, to let the administrator sign in to given workstations, servers and domain controllers based strictly on his or her job responsibilities.
- **Standard user account**. Grant standard user rights for standard user tasks, such as email, web browsing, and using line-of-business (LOB) applications. These accounts should not be granted administrator rights.
> [!IMPORTANT]
> Ensure that sensitive administrator accounts cannot access email or browse the Internet as described in the following section.
### <a href="" id="task2-admin-workstations"></a>Create dedicated workstation hosts without Internet and email access
Administrators need to manage job responsibilities that require sensitive administrator rights from a dedicated workstation because they do not have easy physical access to the servers. A workstation that is connected to the Internet and has email and web browsing access is regularly exposed to compromise through phishing, downloading, and other types of Internet attacks. Because of these threats, it is a best practice to set these administrators up by using workstations that are dedicated to administrative duties only, and not provide access to the Internet, including email and web browsing. For more information, see [Separate administrator accounts from user accounts](#task1-separate-admin-accounts).
> [!NOTE]
> If the administrators in your environment can sign in locally to managed servers and perform all tasks without elevated rights or domain rights from their workstation, you can skip this task.
- **Minimum**. Build dedicated administrative workstations and block Internet access on those workstations including web browsing and email. Use the following ways to block Internet access:
- Configure authenticating boundary proxy services, if they are deployed, to disallow administrator accounts from accessing the Internet.
- Configure boundary firewall or proxy services to disallow Internet access for the IP addresses that are assigned to dedicated administrative workstations.
- Block outbound access to the boundary proxy servers in the Windows Firewall.
The instructions for meeting this minimum requirement are described in the following procedure.
- **Better**. Do not grant administrators membership in the local Administrator group on the computer in order to restrict the administrator from bypassing these protections.
- **Ideal**. Restrict workstations from having any network connectivity, except for the domain controllers and servers that the administrator accounts are used to manage. Alternately, use AppLocker application control policies to restrict all applications from running, except for the operating system and approved administrative tools and applications. For more information about AppLocker, see [AppLocker](/windows/device-security/applocker/applocker-overview).
The following procedure describes how to block Internet access by creating a Group Policy Object (GPO) that configures an invalid proxy address on administrative workstations. These instructions apply only to computers running Internet Explorer and other Windows components that use these proxy settings.
> [!NOTE]
> In this procedure, the workstations are dedicated to domain administrators. By simply modifying the administrator accounts to grant permission to administrators to sign in locally, you can create additional OUs to manage administrators that have fewer administrative rights to use the instructions described in the following procedure.
**To install administrative workstations in a domain and block Internet and email access (minimum)**
1. As a domain administrator on a domain controller, open Active Directory Users and Computers, and create a new OU for administrative workstations.
2. Create computer accounts for the new workstations.
> [!NOTE]
> You might have to delegate permissions to join computers to the domain if the account that joins the workstations to the domain does not already have them. For more information, see [Delegation of Administration in Active Directory](https://social.technet.microsoft.com/wiki/contents/articles/20292.delegation-of-administration-in-active-directory.aspx).
![Active Directory local accounts](images/adlocalaccounts-proc1-sample1.gif)
3. Close Active Directory Users and Computers.
4. Start the **Group Policy Management** Console (GPMC).
5. Right-click the new OU, and &gt; **Create a GPO in this domain, and Link it here**.
![Active Directory's local accounts](images/adlocalaccounts-proc1-sample2.png)
6. Name the GPO, and &gt; **OK**.
7. Expand the GPO, right-click the new GPO, and &gt; **Edit**.
![Active Directory (AD) local accounts](images/adlocalaccounts-proc1-sample3.png)
8. Configure which members of accounts can log on locally to these administrative workstations as follows:
1. Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**.
2. Double-click **Allow log on locally**, and then select the **Define these policy settings** check box.
3. Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
4. Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
> [!IMPORTANT]
> These instructions assume that the workstation is to be dedicated to domain administrators.
5. Click **Add User or Group**, type **Administrators**, and &gt; **OK**.
![AD local accounts](images/adlocalaccounts-proc1-sample4.png)
9. Configure the proxy configuration:
1. Navigate to User Configuration\\Policies\\Windows Settings\\Internet Explorer, and &gt; **Connection**.
2. Double-click **Proxy Settings**, select the **Enable proxy settings** check box, type **127.0.0.1** (the network Loopback IP address) as the proxy address, and &gt; **OK**.
![AD's local accounts](images/adlocalaccounts-proc1-sample5.png)
10. Configure the loopback processing mode to enable the user Group Policy proxy setting to apply to all users on the computer as follows:
1. Navigate to Computer Configuration\\Policies\\Administrative Templates\\System, and &gt; **Group Policy**.
2. Double-click **User Group Policy loopback policy processing mode**, and &gt; **Enabled**.
3. Select **Merge Mode**, and &gt; **OK**.
11. Configure software updates as follows:
1. Navigate to Computer Configuration\\Policies\\Administrative Templates\\Windows Components, and then click **Windows Update**.
2. Configure Windows Update settings as described in the following table.
|Windows Update Setting|Configuration|
|--- |--- |
|Allow Automatic Updates immediate installation|Enabled|
|Configure Automatic Updates|Enabled4 - Auto download and schedule the installation0 - Every day 03:00|
|Enable Windows Update Power Management to automatically wake up the system to install scheduled updates|Enabled|
|Specify intranet Microsoft Update service location|Enabled `http://<WSUSServername> http://<WSUSServername>` Where `<WSUSServername>` is the DNS name or IP address of the Windows Server Update Services (WSUS) in the environment.|
|Automatic Updates detection frequency|6 hours|
|Re-prompt for restart with scheduled installations|1 minute|
|Delay restart for scheduled installations|5 minutes|
> [!NOTE]
> This step assumes that Windows Server Update Services (WSUS) is installed and configured in the environment. You can skip this step if you use another tool to deploy software updates. Also, if the public Microsoft Windows Update service only is used on the Internet, then these administrative workstations no longer receive updates.
12. Configure the inbound firewall to block all connections as follows:
1. Right-click **Windows Firewall with Advanced Security LDAP://path**, and &gt; **Properties**.
![Local accounts for Active Directory](images/adlocalaccounts-proc1-sample6.png)
2. On each profile, ensure that the firewall is enabled and that inbound connections are set to **Block all connections**.
![Local accounts for an AD](images/adlocalaccounts-proc1-sample7.png)
3. Click **OK** to complete the configuration.
13. Close the Group Policy Management Console.
14. Install the Windows operating system on the workstations, give each workstation the same names as the computer accounts assigned to them, and then join them to the domain.
### <a href="" id="task3-restrict-admin-logon"></a>Restrict administrator logon access to servers and workstations
It is a best practice to restrict administrators from using sensitive administrator accounts to sign in to lower-trust servers and workstations. This restriction prevents administrators from inadvertently increasing the risk of credential theft by signing in to a lower-trust computer.
> [!IMPORTANT]
> Ensure that you either have local access to the domain controller or that you have built at least one dedicated administrative workstation.
Restrict logon access to lower-trust servers and workstations by using the following guidelines:
- **Minimum**. Restrict domain administrators from having logon access to servers and workstations. Before starting this procedure, identify all OUs in the domain that contain workstations and servers. Any computers in OUs that are not identified will not restrict administrators with sensitive accounts from signing-in to them.
- **Better**. Restrict domain administrators from non-domain controller servers and workstations.
- **Ideal**. Restrict server administrators from signing in to workstations, in addition to domain administrators.
> [!NOTE]
> For this procedure, do not link accounts to the OU that contain workstations for administrators that perform administration duties only, and do not provide Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
**To restrict domain administrators from workstations (minimum)**
1. As a domain administrator, open the Group Policy Management Console (GPMC).
2. Open **Group Policy Management**, and expand *&lt;forest&gt;*\\Domains\\`<domain>`, and then expand to **Group Policy Objects**.
3. Right-click **Group Policy Objects**, and &gt; **New**.
![Local account's representation - Active Directory](images/adlocalaccounts-proc2-sample1.png)
4. In the **New GPO** dialog box, name the GPO that restricts administrators from signing in to workstations, and &gt; **OK**.
![Local account's representation - AD](images/adlocalaccounts-proc2-sample2.png)
5. Right-click **New GPO**, and &gt; **Edit**.
6. Configure user rights to deny logon locally for domain administrators.
7. Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**, and perform the following:
1. Double-click **Deny logon locally**, and &gt; **Define these policy settings**.
2. Click **Add User or Group**, click **Browse**, type **Enterprise Admins**, and &gt; **OK**.
3. Click **Add User or Group**, click **Browse**, type **Domain Admins**, and &gt; **OK**.
![An Active Directory's local accounts](images/adlocalaccounts-proc2-sample3.png)
> [!NOTE]
> You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
4. Click **OK** to complete the configuration.
8. Configure the user rights to deny batch and service logon rights for domain administrators as follows:
> [!NOTE]
> Completing this step might cause issues with administrator tasks that run as scheduled tasks or services with accounts in the Domain Admins group. The practice of using domain administrator accounts to run services and tasks on workstations creates a significant risk of credential theft attacks and therefore should be replaced with alternative means to run scheduled tasks or services.
1. Double-click **Deny logon as a batch job**, and &gt; **Define these policy settings**.
2. Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
3. Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
![An AD's local accounts](images/adlocalaccounts-proc2-sample4.png)
> [!NOTE]
> You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
4. Double-click **Deny logon as a service**, and &gt; **Define these policy settings**.
5. Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
6. Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
![Local accounts for AD](images/adlocalaccounts-proc2-sample5.png)
> [!NOTE]
> You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
9. Link the GPO to the first Workstations OU.
Navigate to the *&lt;forest&gt;*\\Domains\\`<domain>`\\OU Path, and then:
1. Right-click the workstation OU, and then &gt; **Link an Existing GPO**.
![Local accounts representation for an Active Directory](images/adlocalaccounts-proc2-sample6.png)
2. Select the GPO that you just created, and &gt; **OK**.
![Active Directory's local accounts' presentation](images/adlocalaccounts-proc2-sample7.png)
=======
![Active Directory local accounts 13](images/adlocalaccounts-proc2-sample6.png)
2. Select the GPO that you just created, and &gt; **OK**.
![Active Directory local accounts 14](images/adlocalaccounts-proc2-sample7.png)
10. Test the functionality of enterprise applications on workstations in the first OU and resolve any issues caused by the new policy.
11. Link all other OUs that contain workstations.
However, do not create a link to the Administrative Workstation OU if it is created for administrative workstations that are dedicated to administration duties only, and that are without Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations).
> [!IMPORTANT]
> If you later extend this solution, do not deny logon rights for the **Domain Users** group. The **Domain Users** group includes all user accounts in the domain, including Users, Domain Administrators, and Enterprise Administrators.
### <a href="" id="task4-disable-account-delegation"></a>Disable the account delegation right for sensitive administrator accounts
Although user accounts are not marked for delegation by default, accounts in an Active Directory domain can be trusted for delegation. This means that a service or a computer that is trusted for delegation can impersonate an account that authenticates to them to access other resources across the network.
For sensitive accounts, such as those belonging to members of the Administrators, Domain Admins, or Enterprise Admins groups in Active Directory, delegation can present a substantial risk of rights escalation. For example, if an account in the Domain Admins group is used to sign in to a compromised member server that is trusted for delegation, that server can request access to resources in the context of the Domain Admins account, and escalate the compromise of that member server to a domain compromise.
It is a best practice to configure the user objects for all sensitive accounts in Active Directory by selecting the **Account is sensitive and cannot be delegated** check box under **Account options** to prevent these accounts from being delegated. For more information, see [Setting for default local accounts in Active Directory](#sec-account-settings).
As with any configuration change, test this enabled setting fully to ensure that it performs correctly before you implement it.
![An Active Directory local accounts' presentation](images/adlocalaccounts-proc3-sample1.png)
## <a href="" id="sec-secure-manage-dcs"></a>Secure and manage domain controllers
It is a best practice to strictly enforce restrictions on the domain controllers in your environment. This ensures that the domain controllers:
1. Run only required software
2. Required software is regularly updated
3. Are configured with the appropriate security settings
One aspect of securing and managing domain controllers is to ensure that the default local user accounts are fully protected. It is of primary importance to restrict and secure all sensitive domain accounts, as described in the preceding sections.
Because domain controllers store credential password hashes of all accounts in the domain, they are high-value targets for malicious users. When domain controllers are not well managed and secured by using restrictions that are strictly enforced, they can be compromised by malicious users. For example, a malicious user could steal sensitive domain administrator credentials from one domain controller, and then use these credentials to attack the domain and forest.
In addition, installed applications and management agents on domain controllers might provide a path for escalating rights that malicious users can use to compromise the management service or administrators of that service. The management tools and services, which your organization uses to manage domain controllers and their administrators, are equally important to the security of the domain controllers and the domain administrator accounts. Ensure that these services and administrators are fully secured with equal effort.
## See also
- [Security Principals](security-principals.md)
- [Access Control Overview](access-control.md)

1431
windows/security/identity-protection/access-control/active-directory-security-groups.md
View File

File diff suppressed because it is too large Load Diff

140
windows/security/identity-protection/access-control/dynamic-access-control.md
View File

@ -1,140 +0,0 @@
---
title: Dynamic Access Control Overview (Windows 10)
description: Learn about Dynamic Access Control and its associated elements, which were introduced in Windows Server 2012 and Windows 8.
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 04/19/2017
ms.reviewer:
---
# Dynamic Access Control Overview
**Applies to**
- Windows Server 2016
This overview topic for the IT professional describes Dynamic Access Control and its associated elements, which were introduced in Windows Server 2012 and Windows 8.
Domain-based Dynamic Access Control enables administrators to apply access-control permissions and restrictions based on well-defined rules that can include the sensitivity of the resources, the job or role of the user, and the configuration of the device that is used to access these resources.
For example, a user might have different permissions when they access a resource from their office computer versus when they are using a portable computer over a virtual private network. Or access may be allowed only if a device meets the security requirements that are defined by the network administrators. When Dynamic Access Control is used, a user’s permissions change dynamically without additional administrator intervention if the user’s job or role changes (resulting in changes to the user’s account attributes in AD DS). For more detailed examples of Dynamic Access Control in use, see the scenarios described in [Dynamic Access Control: Scenario Overview](/windows-server/identity/solution-guides/dynamic-access-control--scenario-overview).
Dynamic Access Control is not supported in Windows operating systems prior to Windows Server 2012 and Windows 8. When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes.
Features and concepts associated with Dynamic Access Control include:
- [Central access rules](#bkmk-rules)
- [Central access policies](#bkmk-policies)
- [Claims](#bkmk-claims)
- [Expressions](#bkmk-expressions2)
- [Proposed permissions](#bkmk-permissions2)
### <a href="" id="bkmk-rules"></a>Central access rules
A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy.
If one or more central access rules have been defined for a domain, file share administrators can match specific rules to specific resources and business requirements.
### <a href="" id="bkmk-policies"></a>Central access policies
Central access policies are authorization policies that include conditional expressions. For example, let’s say an organization has a business requirement to restrict access to personally identifiable information (PII) in files to only the file owner and members of the human resources (HR) department who are allowed to view PII information. This represents an organization-wide policy that applies to PII files wherever they are located on file servers across the organization. To implement this policy, an organization needs to be able to:
- Identify and mark the files that contain the PII.
- Identify the group of HR members who are allowed to view the PII information.
- Add the central access policy to a central access rule, and apply the central access rule to all files that contain the PII, wherever they are located amongst the file servers across the organization.
Central access policies act as security umbrellas that an organization applies across its servers. These policies are in addition to (but do not replace) the local access policies or discretionary access control lists (DACLs) that are applied to files and folders.
### <a href="" id="bkmk-claims"></a>Claims
A claim is a unique piece of information about a user, device, or resource that has been published by a domain controller. The user’s title, the department classification of a file, or the health state of a computer are valid examples of a claim. An entity can involve more than one claim, and any combination of claims can be used to authorize access to resources. The following types of claims are available in the supported versions of Windows:
- **User claims**   Active Directory attributes that are associated with a specific user.
- **Device claims**   Active Directory attributes that are associated with a specific computer object.
- **Resource attributes**  Global resource properties that are marked for use in authorization decisions and published in Active Directory.
Claims make it possible for administrators to make precise organization- or enterprise-wide statements about users, devices, and resources that can be incorporated in expressions, rules, and policies.
### <a href="" id="bkmk-expressions2"></a>Expressions
Conditional expressions are an enhancement to access control management that allow or deny access to resources only when certain conditions are met, for example, group membership, location, or the security state of the device. Expressions are managed through the Advanced Security Settings dialog box of the ACL Editor or the Central Access Rule Editor in the Active Directory Administrative Center (ADAC).
Expressions help administrators manage access to sensitive resources with flexible conditions in increasingly complex business environments.
### <a href="" id="bkmk-permissions2"></a>Proposed permissions
Proposed permissions enable an administrator to more accurately model the impact of potential changes to access control settings without actually changing them.
Predicting the effective access to a resource helps you plan and configure permissions for those resources before implementing those changes.
## Additional changes
Additional enhancements in the supported versions of Windows that support Dynamic Access Control include:
### Support in the Kerberos authentication protocol to reliably provide user claims, device claims, and device groups.
By default, devices running any of the supported versions of Windows are able to process Dynamic Access Control-related Kerberos tickets, which include data needed for compound authentication. Domain controllers are able to issue and respond to Kerberos tickets with compound authentication-related information. When a domain is configured to recognize Dynamic Access Control, devices receive claims from domain controllers during initial authentication, and they receive compound authentication tickets when submitting service ticket requests. Compound authentication results in an access token that includes the identity of the user and the device on the resources that recognize Dynamic Access Control.
### Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.
Every domain controller needs to have the same Administrative Template policy setting, which is located at **Computer Configuration\\Policies\\Administrative Templates\\System\\KDC\\Support Dynamic Access Control and Kerberos armoring**.
### Support in Active Directory to store user and device claims, resource properties, and central access policy objects.
### Support for using Group Policy to deploy central access policy objects.
The following Group Policy setting enables you to deploy central access policy objects to file servers in your organization: **Computer Configuration\\Policies\\ Windows Settings\\Security Settings\\File System\\Central Access Policy**.
### Support for claims-based file authorization and auditing for file systems by using Group Policy and Global Object Access Auditing
You must enable staged central access policy auditing to audit the effective access of central access policy by using proposed permissions. You configure this setting for the computer under **Advanced Audit Policy Configuration** in the **Security Settings** of a Group Policy Object (GPO). After you configure the security setting in the GPO, you can deploy the GPO to computers in your network.
### Support for transforming or filtering claim policy objects that traverse Active Directory forest trusts
You can filter or transform incoming and outgoing claims that traverse a forest trust. There are three basic scenarios for filtering and transforming claims:
- **Value-based filtering**  Filters can be based on the value of a claim. This allows the trusted forest to prevent claims with certain values from being sent to the trusting forest. Domain controllers in trusting forests can use value-based filtering to guard against an elevation-of-privilege attack by filtering the incoming claims with specific values from the trusted forest.
- **Claim type-based filtering**  Filters are based on the type of claim, rather than the value of the claim. You identify the claim type by the name of the claim. You use claim type-based filtering in the trusted forest, and it prevents Windows from sending claims that disclose information to the trusting forest.
- **Claim type-based transformation**  Manipulates a claim before sending it to the intended target. You use claim type-based transformation in the trusted forest to generalize a known claim that contains specific information. You can use transformations to generalize the claim-type, the claim value, or both.
## <a href="" id="software-requirements-"></a>Software requirements
Because claims and compound authentication for Dynamic Access Control require Kerberos authentication extensions, any domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows to support authentication from Dynamic Access Control-aware Kerberos clients. By default, devices must use domain controllers in other sites. If no such domain controllers are available, authentication will fail. Therefore, you must support one of the following conditions:
- Every domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows Server to support authentication from all devices running the supported versions of Windows or Windows Server.
- Devices running the supported versions of Windows or that do not protect resources by using claims or compound identity, should disable Kerberos protocol support for Dynamic Access Control.
For domains that support user claims, every domain controller running the supported versions of Windows server must be configured with the appropriate setting to support claims and compound authentication, and to provide Kerberos armoring. Configure settings in the KDC Administrative Template policy as follows:
- **Always provide claims**   Use this setting if all domain controllers are running the supported versions of Windows Server. In addition, set the domain functional level to Windows Server 2012 or higher.
- **Supported**   When you use this setting, monitor domain controllers to ensure that the number of domain controllers running the supported versions of Windows Server is sufficient for the number of client computers that need to access resources protected by Dynamic Access Control.
If the user domain and file server domain are in different forests, all domain controllers in the file server’s forest root must be set at the Windows Server 2012 or higher functional level.
If clients do not recognize Dynamic Access Control, there must be a two-way trust relationship between the two forests.
If claims are transformed when they leave a forest, all domain controllers in the user’s forest root must be set at the Windows Server 2012 or higher functional level.
A file server running a server operating system that supports Dyamic Access Control must have a Group Policy setting that specifies whether it needs to get user claims for user tokens that do not carry claims. This setting is set by default to **Automatic**, which results in this Group Policy setting to be turned **On** if there is a central policy that contains user or device claims for that file server. If the file server contains discretionary ACLs that include user claims, you need to set this Group Policy to **On** so that the server knows to request claims on behalf of users that do not provide claims when they access the server.
## See also
- [Access control overview](access-control.md)

186
windows/security/identity-protection/access-control/microsoft-accounts.md
View File

@ -1,186 +0,0 @@
---
title: Microsoft Accounts (Windows 10)
description: Microsoft Accounts
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 10/13/2017
ms.reviewer:
---
# Microsoft Accounts
**Applies to**
- Windows 10
This topic for the IT professional explains how a Microsoft account works to enhance security and privacy for users, and how you can manage this consumer account type in your organization.
Microsoft sites, services, and properties, as well as computers running Windows 10, can use a Microsoft account as a means of identifying a user. Microsoft account was previously called Windows Live ID. It has user-defined secrets, and consists of a unique email address and a password.
When a user signs in with a Microsoft account, the device is connected to cloud services. Many of the user's settings, preferences, and apps can be shared across devices.
## <a href="" id="bkmk-benefits"></a>How a Microsoft account works
The Microsoft account allows users to sign in to websites that support this service by using a single set of credentials. Users' credentials are validated by a Microsoft account authentication server that is associated with a website. The Microsoft Store is an example of this association. When new users sign in to websites that are enabled to use Microsoft accounts, they are redirected to the nearest authentication server, which asks for a user name and password. Windows uses the Schannel Security Support Provider to open a Transport Level Security/Secure Sockets Layer (TLS/SSL) connection for this function. Users then have the option to use Credential Manager to store their credentials.
When users sign in to websites that are enabled to use a Microsoft account, a time-limited cookie is installed on their computers, which includes a triple DES encrypted ID tag. This encrypted ID tag has been agreed upon between the authentication server and the website. This ID tag is sent to the website, and the website plants another time-limited encrypted HTTP cookie on the user’s computer. When these cookies are valid, users are not required to supply a user name and password. If a user actively signs out of their Microsoft account, these cookies are removed.
**Important**  
Local Windows account functionality has not been removed, and it is still an option to use in managed environments.
### How Microsoft accounts are created
To prevent fraud, the Microsoft system verifies the IP address when a user creates an account. A user who tries to create multiple Microsoft accounts with the same IP address is stopped.
Microsoft accounts are not designed to be created in batches, such as for a group of domain users within your enterprise.
There are two methods for creating a Microsoft account:
- **Use an existing email address**.
Users are able to use their valid email addresses to sign up for Microsoft accounts. The service turns the requesting user's email address into a Microsoft account. Users can also choose their personal passwords.
- **Sign up for a Microsoft email address**.
Users can sign up for an email account with Microsoft's webmail services. This account can be used to sign in to websites that are enabled to use Microsoft accounts.
### How the Microsoft account information is safeguarded
Credential information is encrypted twice. The first encryption is based on the account’s password. Credentials are encrypted again when they are sent across the Internet. The data that is stored is not available to other Microsoft or non-Microsoft services.
- **Strong password is required**.
Blank passwords are not allowed.
For more information, see [How to help keep your Microsoft account safe and secure](https://support.microsoft.com/account-billing/how-to-help-keep-your-microsoft-account-safe-and-secure-628538c2-7006-33bb-5ef4-c917657362b9).
- **Secondary proof of identity is required**.
Before user profile information and settings can be accessed on a second supported Windows computer for the first time, trust must established for that device by providing secondary proof of identity. This can be accomplished by providing Windows with a code that is sent to a mobile phone number or by following the instructions that are sent to an alternate email address that a user specifies in the account settings.
- **All user profile data is encrypted on the client before it is transmitted to the cloud**.
User data does not roam over a wireless wide area network (WWAN) by default, thereby protecting profile data. All data and settings that leave a device are transmitted through the TLS/SSL protocol.
**Microsoft account security information is added**.
Users can add security information to their Microsoft accounts through the **Accounts** interface on computers running the supported versions of Windows. This feature allows the user to update the security information that they provided when they created their accounts. This security information includes an alternate email address or phone number so if their password is compromised or forgotten, a verification code can be sent to verify their identity. Users can potentially use their Microsoft accounts to store corporate data on a personal OneDrive or email app, so it is safe practice for the account owner to keep this security information up-to-date.
## <a href="" id="bkmk-msaccountintheenterprise"></a>The Microsoft account in the enterprise
Although the Microsoft account was designed to serve consumers, you might find situations where your domain users can benefit by using their personal Microsoft account in your enterprise. The following list describes some advantages.
- **Download Microsoft Store apps**:
If your enterprise chooses to distribute software through the Microsoft Store, your users can use their Microsoft accounts to download and use them on up to five devices running any version of Windows 10, Windows 8.1, Windows 8, or Windows RT.
- **Single sign-on**:
Your users can use Microsoft account credentials to sign in to devices running Windows 10, Windows 8.1, Windows 8 or Windows RT. When they do this, Windows works with your Microsoft Store app to provide authenticated experiences for them. Users can associate a Microsoft account with their sign-in credentials for Microsoft Store apps or websites, so that these credentials roam across any devices running these supported versions.
- **Personalized settings synchronization**:
Users can associate their most commonly used operating-system settings with a Microsoft account. These settings are available whenever a user signs in with that account on any device that is running a supported version of Windows and is connected to the cloud. After a user signs in, the device automatically attempts to get the user's settings from the cloud and apply them to the device.
- **App synchronization**:
Microsoft Store apps can store user-specific settings so that these settings are available to any device. As with operating system settings, these user-specific app settings are available whenever the user signs in with the same Microsoft account on any device that is running a supported version of Windows and is connected to the cloud. After the user signs in, that device automatically downloads the settings from the cloud and applies them when the app is installed.
- **Integrated social media services**:
Contact information and status for your users’ friends and associates automatically stay up-to-date from sites such as Hotmail, Outlook, Facebook, Twitter, and LinkedIn. Users can also access and share photos, documents, and other files from sites such as OneDrive, Facebook, and Flickr.
### Managing the Microsoft account in the domain
Depending on your IT and business models, introducing Microsoft accounts into your enterprise might add complexity or it might provide solutions. You should address the following considerations before you allow the use of these account types in your enterprise:
- [Restrict the use of the Microsoft account](#bkmk-restrictuse)
- [Configure connected accounts](#bkmk-cfgconnectedaccounts)
- [Provision Microsoft accounts in the enterprise](#bkmk-provisionaccounts)
- [Audit account activity](#bkmk-audit)
- [Perform password resets](#bkmk-passwordresets)
- [Restrict app installation and usage](#bkmk-restrictappinstallationandusage)
### <a href="" id="bkmk-restrictuse"></a>Restrict the use of the Microsoft account
The following Group Policy settings help control the use of Microsoft accounts in the enterprise:
- [Block all consumer Microsoft account user authentication](#block-all-consumer-microsoft-account-user-authentication)
- [Accounts: Block Microsoft accounts](#accounts-block-microsoft-accounts)
#### Block all consumer Microsoft account user authentication
This setting controls whether users can provide Microsoft accounts for authentication for applications or services.
If this setting is enabled, all applications and services on the device are prevented from using Microsoft accounts for authentication.
This applies both to existing users of a device and new users who may be added.
However, any application or service that has already authenticated a user will not be affected by enabling this setting until the authentication cache expires.
It is recommended to enable this setting before any user signs in to a device to prevent cached tokens from being present.
If this setting is disabled or not configured, applications and services can use Microsoft accounts for authentication.
By default, this setting is **Disabled**.
This setting does not affect whether users can sign in to devices by using Microsoft accounts, or the ability for users to provide Microsoft accounts via the browser for authentication with web-based applications.
The path to this setting is:
Computer Configuration\Administrative Templates\Windows Components\Microsoft account
#### Accounts: Block Microsoft accounts
This setting prevents using the **Settings** app to add a Microsoft account for single sign-on (SSO) authentication for Microsoft services and some background services, or using a Microsoft account for single sign-on to other applications or services.
There are two options if this setting is enabled:
- **Users can’t add Microsoft accounts** means that existing connected accounts can still sign in to the device (and appear on the Sign in screen). However, users cannot use the **Settings** app to add new connected accounts (or connect local accounts to Microsoft accounts).
- **Users can’t add or log on with Microsoft accounts** means that users cannot add new connected accounts (or connect local accounts to Microsoft accounts) or use existing connected accounts through **Settings**.
This setting does not affect adding a Microsoft account for application authentication. For example, if this setting is enabled, a user can still provide a Microsoft account for authentication with an application such as **Mail**, but the user cannot use the Microsoft account for single sign-on authentication for other applications or services (in other words, the user will be prompted to authenticate for other applications or services).
By default, this setting is **Not defined**.
The path to this setting is:
Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
### <a href="" id="bkmk-cfgconnectedaccounts"></a>Configure connected accounts
Users can connect a Microsoft account to their domain account and synchronize the settings and preferences between them. This enables users to see the same desktop background, app settings, browser history and favorites, and other Microsoft account settings on their other devices.
Users can disconnect a Microsoft account from their domain account at any time as follows: In **PC settings**, tap or click **Users**, tap or click **Disconnect**, and then tap or click **Finish**.
**Note**  
Connecting Microsoft accounts with domain accounts can limit access to some high-privileged tasks in Windows. For example, Task Scheduler will evaluate the connected Microsoft account for access and fail. In these situations, the account owner should disconnect the account.
### <a href="" id="bkmk-provisionaccounts"></a>Provision Microsoft accounts in the enterprise
Microsoft accounts are private user accounts. There are no methods provided by Microsoft to provision Microsoft accounts for an enterprise. Enterprises should use domain accounts.
### <a href="" id="bkmk-audit"></a>Audit account activity
Because Microsoft accounts are Internet-based, Windows does not have a mechanism to audit their use until the account is associated with a domain account. But this association does not restrict the user from disconnecting the account or disjoining from the domain. It is not possible to audit the activity of accounts that are not associated with your domain.
### <a href="" id="bkmk-passwordresets"></a>Perform password resets
Only the owner of the Microsoft account can change the password. Passwords can be changed in the [Microsoft account sign-in portal](https://login.live.com).
### <a href="" id="bkmk-restrictappinstallationandusage"></a>Restrict app installation and usage
Within your organization, you can set application control policies to regulate app installation and usage for Microsoft accounts. For more information, see [AppLocker](/windows/device-security/applocker/applocker-overview) and [Packaged Apps and Packaged App Installer Rules in AppLocker](/windows/device-security/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker).
## See also
- [Managing Privacy: Using a Microsoft Account to Logon and Resulting Internet Communication](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj884082(v=ws.11))
- [Access Control Overview](access-control.md)

331
windows/security/identity-protection/access-control/security-identifiers.md
View File

@ -1,331 +0,0 @@
---
title: Security identifiers (Windows 10)
description: Security identifiers
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection:
- M365-identity-device-management
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 04/19/2017
---
# Security identifiers
**Applies to**
- Windows 10
- Windows 11
- Windows Server 2016
- Windows Server 2019
This topic for the IT professional describes security identifiers and how they work in regards to accounts and groups in the Windows operating system.
## What are security identifiers?
A security identifier (SID) is used to uniquely identify a security principal or security group. Security principals can represent any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account.
Each account or group, or process running in the security context of the account, has a unique SID that is issued by an authority, such as a Windows domain controller. It is stored in a security database. The system generates the SID that identifies a particular account or group at the time the account or group is created. When a SID has been used as the unique identifier for a user or group, it can never be used again to identify another user or group.
Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the SIDs for any groups the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and World SIDs identify a group that includes all users. Well-known SIDs have values that remain constant across all operating systems.
SIDs are a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
The content in this topic applies to computers that are running the supported versions of the Windows operating system as designated in the **Applies To** list at the beginning of this topic.
## How security identifiers work
Users refer to accounts by using the account name, but the operating system internally refers to accounts and processes that run in the security context of the account by using their security identifiers (SIDs). For domain accounts, the SID of a security principal is created by concatenating the SID of the domain with a relative identifier (RID) for the account. SIDs are unique within their scope (domain or local), and they are never reused.
The operating system generates a SID that identifies a particular account or group at the time the account or group is created. The SID for a local account or group is generated by the Local Security Authority (LSA) on the computer, and it is stored with other account information in a secure area of the registry. The SID for a domain account or group is generated by the domain security authority, and it is stored as an attribute of the User or Group object in Active Directory Domain Services.
For every local account and group, the SID is unique for the computer where it was created. No two accounts or groups on the computer ever share the same SID. Likewise, for every domain account and group, the SID is unique within an enterprise. This means that the SID for an account or group that is created in one domain will never match the SID for an account or group created in any other domain in the enterprise.
SIDs always remain unique. Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts. For example, if a user with a user account in a Windows domain leaves her job, an administrator deletes her Active Directory account, including the SID that identifies the account. If she later returns to a different job at the same company, an administrator creates a new account, and the Windows Server operating system generates a new SID. The new SID does not match the old one; so none of the user's access from her old account is transferred to the new account. Her two accounts represent two completely different security principals.
## Security identifier architecture
A security identifier is a data structure in binary format that contains a variable number of values. The first values in the structure contain information about the SID structure. The remaining values are arranged in a hierarchy (similar to a telephone number), and they identify the SID-issuing authority (for example, “NT Authority”), the SID-issuing domain, and a particular security principal or group. The following image illustrates the structure of a SID.
![Security identifier architecture.](images/security-identifider-architecture.jpg)
The individual values of a SID are described in the following table.
| Comment | Description |
| - | - |
| Revision | Indicates the version of the SID structure that is used in a particular SID. |
| Identifier authority | Identifies the highest level of authority that can issue SIDs for a particular type of security principal. For example, the identifier authority value in the SID for the Everyone group is 1 (World Authority). The identifier authority value in the SID for a specific Windows Server account or group is 5 (NT Authority). |
| Subauthorities | >Holds the most important information in a SID, which is contained in a series of one or more subauthority values. All values up to, but not including, the last value in the series collectively identify a domain in an enterprise. This part of the series is called the domain identifier. The last value in the series, which is called the relative identifier (RID), identifies a particular account or group relative to a domain. |
The components of a SID are easier to visualize when SIDs are converted from a binary to a string format by using standard notation:
```
S-R-X-Y1-Y2-Yn-1-Yn
```
In this notation, the components of a SID are represented as shown in the following table.
| Comment | Description |
| - | - |
| S | Indicates that the string is a SID |
| R | Indicates the revision level |
| X | Indicates the identifier authority value |
| Y | Represents a series of subauthority values, where *n* is the number of values |
The SID's most important information is contained in the series of subauthority values. The first part of the series (-Y1-Y2-Y*n*-1) is the domain identifier. This element of the SID becomes significant in an enterprise with several domains, because the domain identifier differentiates SIDs that are issued by one domain from SIDs that are issued by all other domains in the enterprise. No two domains in an enterprise share the same domain identifier.
The last item in the series of subauthority values (-Y*n*) is the relative identifier. It distinguishes one account or group from all other accounts and groups in the domain. No two accounts or groups in any domain share the same relative identifier.
For example, the SID for the built-in Administrators group is represented in standardized SID notation as the following string:
```
S-1-5-32-544
```
This SID has four components:
- A revision level (1)
- An identifier authority value (5, NT Authority)
- A domain identifier (32, Builtin)
- A relative identifier (544, Administrators)
SIDs for built-in accounts and groups always have the same domain identifier value: 32. This value identifies the domain **Builtin**, which exists on every computer that is running a version of the Windows Server operating system. It is never necessary to distinguish one computer's built-in accounts and groups from another computer's built-in accounts and groups because they are local in scope. They are local to a single computer, or in the case of domain controllers for a network domain, they are local to several computers that are acting as one.
Built-in accounts and groups need to be distinguished from one another within the scope of the **Builtin** domain. Therefore, the SID for each account and group has a unique relative identifier. A relative identifier value of 544 is unique to the built-in Administrators group. No other account or group in the **Builtin** domain has a SID with a final value of 544.
In another example, consider the SID for the global group, Domain Admins. Every domain in an enterprise has a Domain Admins group, and the SID for each group is different. The following example represents the SID for the Domain Admins group in the Contoso, Ltd. domain (Contoso\\Domain Admins):
```
S-1-5-21-1004336348-1177238915-682003330-512
```
The SID for Contoso\\Domain Admins has:
- A revision level (1)
- An identifier authority (5, NT Authority)
- A domain identifier (21-1004336348-1177238915-682003330, Contoso)
- A relative identifier (512, Domain Admins)
The SID for Contoso\\Domain Admins is distinguished from the SIDs for other Domain Admins groups in the same enterprise by its domain identifier: 21-1004336348-1177238915-682003330. No other domain in the enterprise uses this value as its domain identifier. The SID for Contoso\\Domain Admins is distinguished from the SIDs for other accounts and groups that are created in the Contoso domain by its relative identifier, 512. No other account or group in the domain has a SID with a final value of 512.
## Relative identifier allocation
When accounts and groups are stored in an account database that is managed by a local Security Accounts Manager (SAM), it is fairly easy for the system to generate a unique relative identifier for each account and in a group that it creates on a stand-alone computer. The SAM on a stand-alone computer can track the relative identifier values that it has used before and make sure that it never uses them again.
In a network domain, however, generating unique relative identifiers is a more complex process. Windows Server network domains can have several domain controllers. Each domain controller stores Active Directory account information. This means that, in a network domain, there are as many copies of the account database as there are domain controllers. In addition to this, every copy of the account database is a master copy. New accounts and groups can be created on any domain controller. Changes that are made to Active Directory on one domain controller are replicated to all other domain controllers in the domain. The process of replicating changes in one master copy of the account database to all other master copies is called a multimaster operation.
The process of generating unique relative identifiers is a single-master operation. One domain controller is assigned the role of relative identifier (RID) master, and it allocates a sequence of relative identifiers to each domain controller in the domain. When a new domain account or group is created in one domain controller's replica of Active Directory, it is assigned a SID. The relative identifier for the new SID is taken from the domain controller's allocation of relative identifiers. When its supply of relative identifiers begins to run low, the domain controller requests another block from the RID master.
Each domain controller uses each value in a block of relative identifiers only once. The RID master allocates each block of relative identifier values only once. This process assures that every account and group created in the domain has a unique relative identifier.
## Security identifiers and globally unique identifiers
When a new domain user or group account is created, Active Directory stores the account's SID in the **ObjectSID** property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that is unique not only in the enterprise, but also across the world. GUIDs are assigned to every object that is created by Active Directory, not only User and Group objects. Each object's GUID is stored in its **ObjectGUID** property.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that is published in the global catalog. Searching the global catalog for a User object GUID produces results if the user has an account somewhere in the enterprise. In fact, searching for any object by **ObjectGUID** might be the most reliable way of finding the object you want to locate. The values of other object properties can change, but the **ObjectGUID** property never changes. When an object is assigned a GUID, it keeps that value for life.
If a user moves from one domain to another, the user gets a new SID. The SID for a group object does not change because groups stay in the domain where they were created. However, if people move, their accounts can move with them. If an employee moves from North America to Europe, but stays in the same company, an administrator for the enterprise can move the employee's User object from, for example, Contoso\\NoAm to Contoso\\Europe. If the administrator does this, the User object for the account needs a new SID. The domain identifier portion of a SID that is issued in NoAm is unique to NoAm; so the SID for the user's account in Europe has a different domain identifier. The relative identifier portion of a SID is unique relative to the domain; so if the domain changes, the relative identifier also changes.
When a User object moves from one domain to another, a new SID must be generated for the user account and stored in the **ObjectSID** property. Before the new value is written to the property, the previous value is copied to another property of a User object, **SIDHistory**. This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the **ObjectSID** property, and another value is added to the list of old SIDs in **SIDHistory**. When a user signs in and is successfully authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user, including the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All these SIDs are returned to the authentication client, and they are included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token (including one of the SIDs in **SIDHistory**), can allow or deny the user access.
If you allow or deny users' access to a resource based on their jobs, you should allow or deny access to a group, not to an individual. That way, when users change jobs or move to other departments, you can easily adjust their access by removing them from certain groups and adding them to others.
However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter how many times the user's account domain changes. The **SIDHistory** property makes this possible. When a user changes domains, there is no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID, but not the new one, the old SID is still in the user's access token. It is listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.
## Well-known SIDs
The values of certain SIDs are constant across all systems. They are created when the operating system or domain is installed. They are called well-known SIDs because they identify generic users or generic groups.
There are universal well-known SIDs that are meaningful on all secure systems that use this security model, including operating systems other than Windows. In addition, there are well-known SIDs that are meaningful only on Windows operating systems.
The following table lists the universal well-known SIDs.
| Value | Universal Well-Known SID | Identifies |
| - | - | - |
| S-1-0-0 | Null SID | A group with no members. This is often used when a SID value is not known.|
| S-1-1-0 | World | A group that includes all users. |
| S-1-2-0 | Local | Users who log on to terminals that are locally (physically) connected to the system. |
| S-1-2-1 | Console Logon | A group that includes users who are logged on to the physical console. |
| S-1-3-0 | Creator Owner ID | A security identifier to be replaced by the security identifier of the user who created a new object. This SID is used in inheritable ACEs. |
| S-1-3-1 | Creator Group ID | A security identifier to be replaced by the primary-group SID of the user who created a new object. Use this SID in inheritable ACEs. |
| S-1-3-2 | Creator Owner Server | |
| S-1-3-3 | Creator Group Server | |
| S-1-3-4 | Owner Rights | A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner. |
| S-1-4 | Non-unique Authority | A SID that represents an identifier authority. |
| S-1-5 | NT Authority | A SID that represents an identifier authority. |
| S-1-5-80-0 | All Services | A group that includes all service processes configured on the system. Membership is controlled by the operating system.|
The following table lists the predefined identifier authority constants. The first four values are used with universal well-known SIDs, and the rest of the values are used with well-known SIDs in Windows operating systems designated in the **Applies To** list.
| Identifier Authority | Value | SID String Prefix |
| - | - | - |
| SECURITY_NULL_SID_AUTHORITY | 0 | S-1-0 |
| SECURITY_WORLD_SID_AUTHORITY | 1 | S-1-1 |
| SECURITY_LOCAL_SID_AUTHORITY | 2 | S-1-2 |
| SECURITY_CREATOR_SID_AUTHORITY | 3 | S-1-3 |
| SECURITY_NT_AUTHORITY | 5 | S-1-5 |
| SECURITY_AUTHENTICATION_AUTHORITY | 18 | S-1-18 |
The following RID values are used with universal well-known SIDs. The Identifier authority column shows the prefix of the identifier authority with which you can combine the RID to create a universal well-known SID.
| Relative Identifier Authority | Value | Identifier Authority |
| - | - | - |
| SECURITY_NULL_RID | 0 | S-1-0 |
| SECURITY_WORLD_RID | 0 | S-1-1 |
| SECURITY_LOCAL_RID | 0 | S-1-2 |
| SECURITY_CREATOR_OWNER_RID | 0 | S-1-3 |
| SECURITY_CREATOR_GROUP_RID | 1 | S-1-3 |
The SECURITY\_NT\_AUTHORITY (S-1-5) predefined identifier authority produces SIDs that are not universal and are meaningful only in installations of the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic. The following table lists the well-known SIDs.
| SID | Display Name | Description |
| - | - | - |
| S-1-5-1 | Dialup | A group that includes all users who are logged on to the system by means of a dial-up connection.|
| S-1-5-113 | Local account| You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named.|
| S-1-5-114| Local account and member of Administrators group | You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named. |
| S-1-5-2 | Network | A group that includes all users who are logged on by means of a network connection. Access tokens for interactive users do not contain the Network SID.|
| S-1-5-3 | Batch | A group that includes all users who have logged on by means of a batch queue facility, such as task scheduler jobs.|
| S-1-5-4 | Interactive| A group that includes all users who log on interactively. A user can start an interactive logon session by logging on directly at the keyboard, by opening a Remote Desktop Services connection from a remote computer, or by using a remote shell such as Telnet. In each case, the user's access token contains the Interactive SID. If the user signs in by using a Remote Desktop Services connection, the user's access token also contains the Remote Interactive Logon SID.|
| S-1-5-5- *X*-*Y* | Logon Session| The *X* and *Y* values for these SIDs uniquely identify a particular logon session.|
| S-1-5-6 | Service| A group that includes all security principals that have signed in as a service.|
| S-1-5-7 | Anonymous Logon| A user who has connected to the computer without supplying a user name and password.<br/>The Anonymous Logon identity is different from the identity that is used by Internet Information Services (IIS) for anonymous web access. IIS uses an actual account—by default, IUSR_ *ComputerName*, for anonymous access to resources on a website. Strictly speaking, such access is not anonymous because the security principal is known even though unidentified people are using the account. IUSR_ *ComputerName* (or whatever you name the account) has a password, and IIS logs on the account when the service starts. As a result, the IIS "anonymous" user is a member of Authenticated Users but Anonymous Logon is not.|
| S-1-5-8| Proxy| Does not currently apply: this SID is not used.|
| S-1-5-9 | Enterprise Domain Controllers| A group that includes all domain controllers in a forest of domains.|
| S-1-5-10 | Self| A placeholder in an ACE for a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal that is represented by the object.|
| S-1-5-11 | Authenticated Users| A group that includes all users and computers with identities that have been authenticated. Authenticated Users does not include Guest even if the Guest account has a password.<br/>This group includes authenticated security principals from any trusted domain, not only the current domain.|
| S-1-5-12 | Restricted Code| An identity that is used by a process that is running in a restricted security context. In Windows and Windows Server operating systems, a software restriction policy can assign one of three security levels to code: unrestricted, restricted, or disallowed. When code runs at the restricted security level, the Restricted SID is added to the user's access token.|
| S-1-5-13 | Terminal Server User| A group that includes all users who sign in to a server with Remote Desktop Services enabled.|
| S-1-5-14 | Remote Interactive Logon| A group that includes all users who log on to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.|
| S-1-5-15| This Organization| A group that includes all users from the same organization. Only included with Active Directory accounts and only added by a domain controller.|
| S-1-5-17 | IUSR| An account that is used by the default Internet Information Services (IIS) user.|
| S-1-5-18 | System (or LocalSystem)| An identity that is used locally by the operating system and by services that are configured to sign in as LocalSystem.<br/>System is a hidden member of Administrators. That is, any process running as System has the SID for the built-in Administrators group in its access token.<br/>When a process that is running locally as System accesses network resources, it does so by using the computer's domain identity. Its access token on the remote computer includes the SID for the local computer's domain account plus SIDs for security groups that the computer is a member of, such as Domain Computers and Authenticated Users.|
| S-1-5-19 | NT Authority (LocalService)| An identity that is used by services that are local to the computer, have no need for extensive local access, and do not need authenticated network access. Services that run as LocalService access local resources as ordinary users, and they access network resources as anonymous users. As a result, a service that runs as LocalService has significantly less authority than a service that runs as LocalSystem locally and on the network.|
| S-1-5-20 | Network Service| An identity that is used by services that have no need for extensive local access but do need authenticated network access. Services running as NetworkService access local resources as ordinary users and access network resources by using the computer's identity. As a result, a service that runs as NetworkService has the same network access as a service that runs as LocalSystem, but it has significantly reduced local access.|
| S-1-5-*domain*-500 | Administrator| A user account for the system administrator. Every computer has a local Administrator account and every domain has a domain Administrator account.<br/>The Administrator account is the first account created during operating system installation. The account cannot be deleted, disabled, or locked out, but it can be renamed.<br/>By default, the Administrator account is a member of the Administrators group, and it cannot be removed from that group.|
| S-1-5-*domain*-501 | Guest| A user account for people who do not have individual accounts. Every computer has a local Guest account, and every domain has a domain Guest account.<br/>By default, Guest is a member of the Everyone and the Guests groups. The domain Guest account is also a member of the Domain Guests and Domain Users groups.<br/>Unlike Anonymous Logon, Guest is a real account, and it can be used to log on interactively. The Guest account does not require a password, but it can have one.|
| S-1-5-*domain*-502| krbtgt| A user account that is used by the Key Distribution Center (KDC) service. The account exists only on domain controllers.|
| S-1-5-*domain*-512| Domain Admins| A global group with members that are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined the domain, including domain controllers.<br/>Domain Admins is the default owner of any object that is created in the domain's Active Directory by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.|
| S-1-5-*domain*-513| Domain Users| A global group that includes all users in a domain. When you create a new User object in Active Directory, the user is automatically added to this group.|
| S-1-5-*domain*-514| Domain Guests| A global group, which by default, has only one member: the domain's built-in Guest account.|
| S-1-5-*domain*-515 | Domain Computers| A global group that includes all computers that have joined the domain, excluding domain controllers.|
| S-1-5-*domain*-516| Domain Controllers| A global group that includes all domain controllers in the domain. New domain controllers are added to this group automatically.|
| S-1-5-*domain*-517 | Cert Publishers| A global group that includes all computers that host an enterprise certification authority.<br/>Cert Publishers are authorized to publish certificates for User objects in Active Directory.|
| S-1-5-*root domain*-518| Schema Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode. The Schema Admins group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.|
| S-1-5-*root domain*-519| Enterprise Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode.<br/>The Enterprise Admins group is authorized to make changes to the forest infrastructure, such as adding child domains, configuring sites, authorizing DHCP servers, and installing enterprise certification authorities.<br/>By default, the only member of Enterprise Admins is the Administrator account for the forest root domain. The group is a default member of every Domain Admins group in the forest. |
| S-1-5-*domain*-520| Group Policy Creator Owners| A global group that is authorized to create new Group Policy Objects in Active Directory. By default, the only member of the group is Administrator.<br/>Objects that are created by members of Group Policy Creator Owners are owned by the individual user who creates them. In this way, the Group Policy Creator Owners group is unlike other administrative groups (such as Administrators and Domain Admins). Objects that are created by members of these groups are owned by the group rather than by the individual.|
| S-1-5-*domain*-553| RAS and IAS Servers| A local domain group. By default, this group has no members. Computers that are running the Routing and Remote Access service are added to the group automatically.<br/>Members of this group have access to certain properties of User objects, such as Read Account Restrictions, Read Logon Information, and Read Remote Access Information.|
| S-1-5-32-544 | Administrators| A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.|
| S-1-5-32-545 | Users| A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group.|
| S-1-5-32-546 | Guests| A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.|
| S-1-5-32-547 | Power Users| A built-in group. By default, the group has no members. Power users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power users also can install programs; create, manage, and delete local printers; and create and delete file shares. |
| S-1-5-32-548| Account Operators| A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account Operators have permission to create, modify, and delete accounts for users, groups, and computers in all containers and organizational units of Active Directory except the Builtin container and the Domain Controllers OU. Account Operators do not have permission to modify the Administrators and Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.|
| S-1-5-32-549| Server Operators| Description: A built-in group that exists only on domain controllers. By default, the group has no members. Server Operators can log on to a server interactively; create and delete network shares; start and stop services; back up and restore files; format the hard disk of the computer; and shut down the computer.|
| S-1-5-32-550 | Print Operators| A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group. Print Operators can manage printers and document queues.|
| S-1-5-32-551 | Backup Operators| A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to the computer and shut it down.|
| S-1-5-32-552 | Replicators | A built-in group that is used by the File Replication service on domain controllers. By default, the group has no members. Do not add users to this group.|
|S-1-5-32-554|Builtin\Pre-Windows 2000 Compatible Access|An alias added by Windows 2000. A backward compatibility group that allows read access on all users and groups in the domain.|
|S-1-5-32-555|Builtin\Remote Desktop Users|An alias. Members in this group are granted the right to log on remotely.|
|S-1-5-32-556|Builtin\Network Configuration Operators|An alias. Members in this group can have some administrative privileges to manage configuration of networking features.|
|S-1-5-32-557|Builtin\Incoming Forest Trust Builders|An alias. Members of this group can create incoming, one-way trusts to this forest.|
|S-1-5-32-558|Builtin\Performance Monitor Users|An alias. Members of this group have remote access to monitor this computer.|
|S-1-5-32-559|Builtin\Performance Log Users|An alias. Members of this group have remote access to schedule logging of performance counters on this computer.|
|S-1-5-32-560|Builtin\Windows Authorization Access Group|An alias. Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects.|
|S-1-5-32-561|Builtin\Terminal Server License Servers|An alias. A group for Terminal Server License Servers. When Windows Server 2003 Service Pack 1 is installed, a new local group is created.|
|S-1-5-32-562|Builtin\Distributed COM Users|An alias. A group for COM to provide computer-wide access controls that govern access to all call, activation, or launch requests on the computer.|
|S-1-5-32-568|Builtin\IIS_IUSRS|An alias. A built-in group account for IIS users.|
|S-1-5-32-569|Builtin\Cryptographic Operators|A built-in local group. Members are authorized to perform cryptographic operations.|
|S-1-5-32-573|Builtin\Event Log Readers|A built-in local group. Members of this group can read event logs from local computer.|
|S-1-5-32-574|Builtin\Certificate Service DCOM Access|A built-in local group. Members of this group are allowed to connect to Certification Authorities in the enterprise.|
|S-1-5-32-575|Builtin\RDS Remote Access Servers|A built-in local group. Servers in this group enable users of RemoteApp programs and personal virtual desktops access to these resources. In Internet-facing deployments, these servers are typically deployed in an edge network. This group needs to be populated on servers running RD Connection Broker. RD Gateway servers and RD Web Access servers used in the deployment need to be in this group.|
|S-1-5-32-576|Builtin\RDS Endpoint Servers|A built-in local group. Servers in this group run virtual machines and host sessions where users RemoteApp programs and personal virtual desktops run. This group needs to be populated on servers running RD Connection Broker. RD Session Host servers and RD Virtualization Host servers used in the deployment need to be in this group.|
|S-1-5-32-577|Builtin\RDS Management Servers|A builtin local group. Servers in this group can perform routine administrative actions on servers running Remote Desktop Services. This group needs to be populated on all servers in a Remote Desktop Services deployment. The servers running the RDS Central Management service must be included in this group.|
|S-1-5-32-578|Builtin\Hyper-V Administrators|A built-in local group. Members of this group have complete and unrestricted access to all features of Hyper-V.|
|S-1-5-32-579|Builtin\Access Control Assistance Operators|A built-in local group. Members of this group can remotely query authorization attributes and permissions for resources on this computer.|
|S-1-5-32-580|Builtin\Remote Management Users|A built-in local group. Members of this group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user.|
| S-1-5-64-10| NTLM Authentication| A SID that is used when the NTLM authentication package authenticated the client|
| S-1-5-64-14 | SChannel Authentication| A SID that is used when the SChannel authentication package authenticated the client.|
| S-1-5-64-21 | Digest Authentication| A SID that is used when the Digest authentication package authenticated the client.|
| S-1-5-80 | NT Service | A SID that is used as an NT Service account prefix.|
| S-1-5-80-0 | All Services| A group that includes all service processes that are configured on the system. Membership is controlled by the operating system. SID S-1-5-80-0 equals NT SERVICES\ALL SERVICES. This SID was introduced in Windows Server 2008 R2.|
| S-1-5-83-0| NT VIRTUAL MACHINE\Virtual Machines| A built-in group. The group is created when the Hyper-V role is installed. Membership in the group is maintained by the Hyper-V Management Service (VMMS). This group requires the **Create Symbolic Links** right (SeCreateSymbolicLinkPrivilege), and also the **Log on as a Service** right (SeServiceLogonRight). |
The following RIDs are relative to each domain.
| RID |Decimal value| Identifies |
| - | - | - |
| DOMAIN_USER_RID_ADMIN | 500 | The administrative user account in a domain. |
| DOMAIN_USER_RID_GUEST| 501 | The guest-user account in a domain. Users who do not have an account can automatically sign in to this account.|
| DOMAIN_GROUP_RID_USERS | 513 | A group that contains all user accounts in a domain. All users are automatically added to this group.|
| DOMAIN_GROUP_RID_GUESTS | 514 | The group Guest account in a domain.|
| DOMAIN_GROUP_RID_COMPUTERS | 515 | The Domain Computer group. All computers in the domain are members of this group.|
| DOMAIN_GROUP_RID_CONTROLLERS | 516 | The Domain Controller group. All domain controllers in the domain are members of this group.|
| DOMAIN_GROUP_RID_CERT_ADMINS | 517 | The certificate publishers' group. Computers running Active Directory Certificate Services are members of this group.|
| DOMAIN_GROUP_RID_SCHEMA_ADMINS | 518 | The schema administrators' group. Members of this group can modify the Active Directory schema.|
| DOMAIN_GROUP_RID_ENTERPRISE_ADMINS | 519 | The enterprise administrators' group. Members of this group have full access to all domains in the Active Directory forest. Enterprise administrators are responsible for forest-level operations such as adding or removing new domains.|
| DOMAIN_GROUP_RID_POLICY_ADMINS| 520 | The policy administrators' group.|
The following table provides examples of domain-relative RIDs that are used to form well-known SIDs for local groups.
| RID | Decimal value | Identifies |
| - | - | - |
| DOMAIN_ALIAS_RID_ADMINS | 544 | Administrators of the domain.|
| DOMAIN_ALIAS_RID_USERS | 545 | All users in the domain.|
| DOMAIN_ALIAS_RID_GUESTS | 546 | Guests of the domain.|
| DOMAIN_ALIAS_RID_POWER_USERS | 547 | A user or a set of users who expect to treat a system as if it were their personal computer rather than as a workstation for multiple users.|
| DOMAIN_ALIAS_RID_BACKUP_OPS | 551 | A local group that is used to control the assignment of file backup-and-restore user rights.|
| DOMAIN_ALIAS_RID_REPLICATOR | 552 | A local group that is responsible for copying security databases from the primary domain controller to the backup domain controllers. These accounts are used only by the system.|
| DOMAIN_ALIAS_RID_RAS_SERVERS | 553 | A local group that represents remote access and servers running Internet Authentication Service (IAS). This group permits access to various attributes of User objects.|
## Changes in security identifier's functionality
The following table describes changes in SID implementation in the Windows operating systems that are designated in the list.
| Change | Operating system version | Description and resources |
| - | - | - |
| Most of the operating system files are owned by the TrustedInstaller security identifier (SID)| Windows Server 2008, Windows Vista| The purpose of this change is to prevent a process that is running as an administrator or under the LocalSystem account from automatically replacing the operating system files. |
| Restricted SID checks are implemented| Windows Server 2008, Windows Vista| When restricting SIDs are present, Windows performs two access checks. The first is the normal access check, and the second is the same access check against the restricting SIDs in the token. Both access checks must pass to allow the process to access the object. |
## Capability SIDs
Capability Security Identifiers (SIDs) are used to uniquely and immutably identify capabilities. Capabilities represent an unforgeable token of authority that grants access to resources (Examples: documents, camera, locations etc...) to Universal Windows Applications. An App that “has” a capability is granted access to the resource the capability is associated with, and one that “does not have” a capability is denied access to the resource.
All Capability SIDs that the operating system is aware of are stored in the Windows Registry in the path `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities'. Any Capability SID added to Windows by first or third-party applications will be added to this location.
## Examples of registry keys taken from Windows 10, version 1909, 64-bit Enterprise edition
You may see the following registry keys under AllCachedCapabilities:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock_Internal
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Enterprise
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_General
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Restricted
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Windows
All Capability SIDs are prefixed by S-1-15-3
## Examples of registry keys taken from Windows 11, version 21H2, 64-bit Enterprise edition
You may see the following registry keys under AllCachedCapabilities:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_DevUnlock_Internal
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Enterprise
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_General
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Restricted
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SecurityManager\CapabilityClasses\AllCachedCapabilities\capabilityClass_Windows
All Capability SIDs are prefixed by S-1-15-3
## See also
- [Access Control Overview](access-control.md)

148
windows/security/identity-protection/access-control/security-principals.md
View File

@ -1,148 +0,0 @@
---
title: Security Principals (Windows 10)
description: Security Principals
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 04/19/2017
ms.reviewer:
---
# Security Principals
**Applies to**
- Windows 10
- Windows Server 2016
This reference topic for the IT professional describes security principals in regards to Windows accounts and security groups, in addition to security technologies that are related to security principals.
## <a href="" id="w2k3tr-princ-what"></a>What are security principals?
Security principals are any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account, or the security groups for these accounts. Security principals have long been a foundation for controlling access to securable resources on Windows computers. Each security principal is represented in the operating system by a unique security identifier (SID).
The following content applies to the versions of Windows that are designated in the **Applies To** list at the beginning of this topic.
## How security principals work
Security principals that are created in an Active Directory domain are Active Directory objects, which can be used to manage access to domain resources. Each security principal is assigned a unique identifier, which it retains for its entire lifetime. Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are managed by the Security Accounts Manager (SAM) on the local computer.
### <a href="" id="bkmk-authzandac"></a>Authorization and access control components
The following diagram illustrates the Windows authorization and access control process. In this diagram, the subject (a process that is initiated by a user) attempts to access an object, such as a shared folder. The information in the user’s access token is compared to the access control entries (ACEs) in the object’s security descriptor, and the access decision is made. The SIDs of security principals are used in the user’s access token and in the ACEs in the object’s security descriptor.
**Authorization and access control process**
![authorization and access control process.](images/authorizationandaccesscontrolprocess.gif)
Security principals are closely related to the following components and technologies:
- [Security identifiers](#bkmk-sids)
- [Access tokens](#bkmk-accesstokens)
- [Security descriptors and access control lists](#bkmk-sdandacls)
- [Permissions](#bkmk-permissions)
### <a href="" id="bkmk-sids"></a>Security identifiers
Security identifiers (SIDs) provide a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
A SID is a value of variable length that is used to uniquely identify a security principal that represents any entity that can be authenticated by the system. These entities include a user account, a computer account, or a thread or process that runs in the security context of a user or computer account. Each security principal is automatically assigned a SID when it is created. The SID is stored in a security database. When a SID is used as the unique identifier for a user or group, it can never be used to identify another user or group.
Each time a user signs in, the system creates an access token for that user. The access token contains the user’s SID, user rights, and the SIDs for groups that the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and the World SIDs identify groups that includes all users. Well-known SIDs have values that remain constant across all operating systems.
### <a href="" id="bkmk-accesstokens"></a>Access tokens
An access token is a protected object that contains information about the identity and user rights that are associated with a user account.
When a user signs in interactively or tries to make a network connection to a computer running Windows, the sign-in process authenticates the user’s credentials. If authentication is successful, the process returns a SID for the user and a list of SIDs for the user’s security groups. The Local Security Authority (LSA) on the computer uses this information to create an access token (in this case, the primary access token). This includes the SIDs that are returned by the sign-in process and a list of user rights that are assigned by the local security policy to the user and to the user’s security groups.
After the LSA creates the primary access token, a copy of the access token is attached to every thread and process that executes on the user’s behalf. Whenever a thread or process interacts with a securable object or tries to perform a system task that requires user rights, the operating system checks the access token that is associated with the thread to determine the level of authorization.
There are two kinds of access tokens, primary and impersonation. Every process has a primary token that describes the security context of the user account that is associated with the process. A primary access token is typically assigned to a process to represent the default security information for that process. Impersonation tokens, on the other hand, are usually used for client and server scenarios. Impersonation tokens enable a thread to run in a security context that differs from the security context of the process that owns the thread.
### <a href="" id="bkmk-sdandacls"></a>Security descriptors and access control lists
A security descriptor is a data structure that is associated with each securable object. All objects in Active Directory and all securable objects on a local computer or on the network have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object’s security descriptor can contain two types of ACLs:
- A discretionary access control list (DACL), which identifies the users and groups who are allowed or denied access
- A system access control list (SACL), which controls how access is audited
You can use this access control model to individually secure objects and attributes such as files and folders, Active Directory objects, registry keys, printers, devices, ports, services, processes, and threads. Because of this individual control, you can adjust the security of objects to meet the needs of your organization, delegate authority over objects or attributes, and create custom objects or attributes that require unique security protections to be defined.
### <a href="" id="bkmk-permissions"></a>Permissions
Permissions enable the owner of each securable object, such as a file, Active Directory object, or registry key, to control who can perform an operation or a set of operations on the object or object property. Permissions are expressed in the security architecture as access control entries (ACEs). Because access to an object is at the discretion of the object’s owner, the type of access control that is used in Windows is called discretionary access control.
Permissions are different from user rights in that permissions are attached to objects, and user rights apply to user accounts. Administrators can assign user rights to groups or users. These rights authorize users to perform specific actions, such as signing in to a system interactively or backing up files and directories.
On computers, user rights enable administrators to control who has the authority to perform operations that affect an entire computer, rather than a particular object. Administrators assign user rights to individual users or groups as part of the security settings for the computer. Although user rights can be managed centrally through Group Policy, they are applied locally. Users can (and usually do) have different user rights on different computers.
For information about which user rights are available and how they can be implemented, see [User Rights Assignment](/windows/device-security/security-policy-settings/user-rights-assignment).
### <a href="" id="bkmk-authn"></a> Security context in authentication
A user account enables a user to sign in to computers, networks, and domains with an identity that can be authenticated by the computer, network, or domain.
In Windows, any user, service, group, or computer that can initiate action is a security principal. Security principals have accounts, which can be local to a computer or domain-based. For example, domain-joined Windows client computers can participate in a network domain by communicating with a domain controller, even when no user is signed in.
To initiate communications, the computer must have an active account in the domain. Before accepting communications from the computer, the Local Security Authority on the domain controller authenticates the computer’s identity and then defines the computer’s security context just as it would for a user’s security principal.
This security context defines the identity and capabilities of a user or service on a particular computer, or of a user, service, group or computer on a network. For example, it defines the resources (such as a file share or printer) that can be accessed and the actions (such as Read, Write, or Modify) that can be performed by a user, service, or computer on that resource.
The security context of a user or computer can vary from one computer to another, such as when a user authenticates to a server or a workstation other than the user’s primary workstation. It can also vary from one session to another, such as when an administrator modifies the user’s rights and permissions. In addition, the security context is usually different when a user or computer is operating on a stand-alone basis, in a mixed network domain, or as part of an Active Directory domain.
## <a href="" id="w2k3tr-princ-what-vblj"></a>Accounts and security groups
Accounts and security groups that are created in an Active Directory domain are stored in the Active Directory database and managed by using Active Directory tools. These security principals are directory objects, and they can be used to manage access to domain resources.
Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are stored in and managed by the Security Accounts Manager (SAM) on the local computer.
### User accounts
A user account uniquely identifies a person who is using a computer system. The account signals the system to enforce the appropriate authorization to allow or deny that user access to resources. User accounts can be created in Active Directory and on local computers, and administrators use them to:
- Represent, identify, and authenticate the identity of a user. A user account enables a user to sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
- Authorize (grant or deny) access to resources. After a user has been authenticated, the user is authorized access to resources based on the permissions that are assigned to that user for the resource.
- Audit the actions that are carried out on a user account.
Windows and the Windows Server operating systems have built-in user accounts, or you can create user accounts to meet the requirements of your organization.
### Security groups
A security group is a collection of user accounts, computer accounts, and other groups of accounts that can be managed as a single unit from a security perspective. In Windows operating systems, there are several built-in security groups that are preconfigured with the appropriate rights and permissions for performing specific tasks. Additionally, you can (and, typically, will) create a security group for each unique combination of security requirements that applies to multiple users in your organization.
Groups can be Active Directory-based or local to a particular computer:
- Active Directory security groups are used to manage rights and permissions to domain resources.
- Local groups exist in the SAM database on local computers (on all Windows-based computers) except domain controllers. You use local groups to manage rights and permissions only to resources on the local computer.
By using security groups to manage access control, you can:
- Simplify administration. You can assign a common set of rights, a common set of permissions, or both to many accounts at one time, rather than assigning them to each account individually. Also, when users transfer jobs or leave the organization, permissions are not tied to their user accounts, making permission reassignment or removal easier.
- Implement a role-based access-control model. You can use this model to grant permissions by using groups with different scopes for appropriate purposes. Scopes that are available in Windows include local, global, domain local, and universal.
- Minimize the size of access control lists (ACLs) and speed security checking. A security group has its own SID; therefore, the group SID can be used to specify permissions for a resource. In an environment with more than a few thousand users, if the SIDs of individual user accounts are used to specify access to a resource, the ACL of that resource can become unmanageably large, and the time that is needed for the system to check permissions to the resource can become unacceptable.
For descriptions and settings information about the domain security groups that are defined in Active Directory, see [Active Directory Security Groups](active-directory-security-groups.md).
For descriptions and settings information about the Special Identities group, see [Special Identities](special-identities.md).
## See also
- [Access Control Overview](access-control.md)

112
windows/security/identity-protection/access-control/service-accounts.md
View File

@ -1,112 +0,0 @@
---
title: Service Accounts (Windows 10)
description: Service Accounts
ms.prod: m365-security
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection:
- M365-identity-device-management
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 11/19/2021
---
# Service Accounts
**Applies to**
- Windows 10
- Windows Server 2016
This topic for the IT professional explains group and standalone managed service accounts, and the computer-specific virtual computer account, and it points to resources about these service accounts.
## Overview
A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service's ability to access local and network resources. The Windows operating systems rely on services to run various features. These services can be configured through the applications, the Services snap-in, or Task Manager, or by using Windows PowerShell.
This topic contains information about the following types of service accounts:
- [Standalone managed service accounts](#bkmk-standalonemanagedserviceaccounts)
- [Group-managed service accounts](#bkmk-groupmanagedserviceaccounts)
- [Virtual accounts](#bkmk-virtualserviceaccounts)
### <a href="" id="bkmk-standalonemanagedserviceaccounts"></a>Standalone managed service accounts
A managed service account is designed to isolate domain accounts in crucial applications, such as Internet Information Services (IIS), and eliminate the need for an administrator to manually administer the service principal name (SPN) and credentials for the accounts.
To use managed service accounts, the server on which the application or service is installed must be running at least Windows Server 2008 R2. One managed service account can be used for services on a single computer. Managed service accounts cannot be shared between multiple computers, and they cannot be used in server clusters where a service is replicated on multiple cluster nodes. For this scenario, you must use a group-managed service account. For more information, see [Group-Managed Service Accounts Overview](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831782(v=ws.11)).
In addition to the enhanced security that is provided by having individual accounts for critical services, there are four important administrative benefits associated with managed service accounts:
- You can create a class of domain accounts that can be used to manage and maintain services on local computers.
- Unlike domain accounts in which administrators must manually reset passwords, the network passwords for these accounts are automatically reset.
- You do not have to complete complex SPN management tasks to use managed service accounts.
- You don't have to complete complex SPN management tasks to use managed service accounts.
- Administrative tasks for managed service accounts can be delegated to non-administrators.
### Software requirements
Managed service accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
### <a href="" id="bkmk-groupmanagedserviceaccounts"></a>Group-managed service accounts
Group-managed service accounts are an extension of the standalone-managed service accounts, which were introduced in Windows Server 2008 R2. These accounts are managed domain accounts that provide automatic password management and simplified service principal name (SPN) management, including delegation of management to other administrators.
The group-managed service account provides the same functionality as a standalone managed service account within the domain, but it extends that functionality over multiple servers. When connecting to a service that is hosted on a server farm, such as Network Load Balancing, the authentication protocols that support mutual authentication require all instances of the services to use the same principal. When group-managed service accounts are used as service principals, the Windows Server operating system manages the password for the account instead of relying on the administrator to manage the password.
The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. This service was introduced in Windows Server 2012, and it does not run on previous versions of the Windows Server operating system. The Key Distribution Service shares a secret, which is used to create keys for the account. These keys are periodically changed. For a group-managed service account, the domain controller computes the password on the key that is provided by the Key Distribution Services, in addition to other attributes of the group-managed service account.
### <a href="" id="bkmk-app"></a>Practical applications
Group-managed service accounts provide a single identity solution for services running on a server farm, or on systems that use Network Load Balancing. By providing a group-managed service account solution, services can be configured for the group-managed service account principal, and the password management is handled by the operating system.
By using a group-managed service account, service administrators do not need to manage password synchronization between service instances. The group-managed service account supports hosts that are kept offline for an extended time period and the management of member hosts for all instances of a service. This provision means that you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.
Failover clusters do not support group-managed service accounts. However, services that run on top of the Cluster service can use a group-managed service account or a standalone managed service account if they are a Windows service, an App pool, a scheduled task, or if they natively support group-managed service account or standalone managed service accounts.
### <a href="" id="bkmk-soft"></a>Software requirements
Group-managed service accounts can only be configured and administered on computers running at least Windows Server 2012, but they can be deployed as a single service identity solution in domains that still have domain controllers running operating systems earlier than Windows Server 2012. There are no domain or forest functional level requirements.
A 64-bit architecture is required to run the Windows PowerShell commands that are used to administer group-managed service accounts.
A managed service account is dependent on encryption types supported by Kerberos. When a client computer authenticates to a server by using Kerberos protocol, the domain controller creates a Kerberos service ticket that is protected with encryption that the domain controller and the server support. The domain controller uses the account’s **msDS-SupportedEncryptionTypes** attribute to determine what encryption the server supports, and if there is no attribute, it assumes that the client computer does not support stronger encryption types. The Advanced Encryption Standard (AES) must always be configured for managed service accounts. If computers that host the managed service account are configured to not support RC4, authentication will always fail.
**Note**  
Introduced in Windows Server 2008 R2, the Data Encryption Standard (DES) is disabled by default. For more information about supported encryption types, see [Changes in Kerberos Authentication](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd560670(v=ws.10)).
Group-managed service accounts are not applicable in Windows operating systems prior to Windows Server 2012.
### <a href="" id="bkmk-virtualserviceaccounts"></a>Virtual accounts
Virtual accounts were introduced in Windows Server 2008 R2 and Windows 7, and are managed local accounts that provide the following features to simplify service administration:
- The virtual account is automatically managed.
- The virtual account can access the network in a domain environment.
- No password management is required. For example, if the default value is used for the service accounts during SQL Server setup on Windows Server 2008 R2, a virtual account that uses the instance name as the service name is established in the format NT SERVICE\\&lt;SERVICENAME&gt;.
Services that run as virtual accounts access network resources by using the credentials of the computer account in the format &lt;domain\_name&gt;\\&lt;computer\_name&gt;$.
For information about how to configure and use virtual service accounts, see [Service Accounts Step-by-Step Guide](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd548356(v=ws.10)).
### Software requirements
Virtual accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
## <a href="" id="bkmk-links"></a>See also
The following table provides links to other resources that are related to standalone managed service accounts, group-managed service accounts, and virtual accounts.
| Content type | References |
|---------------|-------------|
| **Product evaluation** | [What's New for Managed Service Accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831451(v=ws.11))<br>[Getting Started with Group Managed Service Accounts](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj128431(v=ws.11)) |
| **Deployment** | [Windows Server 2012: Group Managed Service Accounts - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs](https://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx) |
| **Related technologies** | [Security Principals](security-principals.md)<br>[What's new in Active Directory Domain Services](/windows-server/identity/whats-new-active-directory-domain-services) |

448
windows/security/identity-protection/access-control/special-identities.md
View File

@ -1,448 +0,0 @@
---
title: Special Identities (Windows 10)
description: Special Identities
ms.prod: m365-security
ms.technology: windows-sec
author: dansimp
ms.author: dansimp
manager: dansimp
ms.collection: M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 12/21/2021
ms.reviewer:
---
# Special Identities
**Applies to**
- Windows Server 2016 or later
This reference topic for the IT professional describes the special identity groups (which are sometimes referred to as security groups) that are used in Windows access control.
Special identity groups are similar to Active Directory security groups as listed in the users and built-in containers. Special identity groups can provide an efficient way to assign access to resources in your network. By using special identity groups, you can:
- Assign user rights to security groups in Active Directory.
- Assign permissions to security groups for the purpose of accessing resources.
Servers that are running the supported Windows Server operating systems designated in the **Applies To** list at the beginning of this topic include several special identity groups. These special identity groups do not have specific memberships that can be modified, but they can represent different users at different times, depending on the circumstances.
Although the special identity groups can be assigned rights and permissions to resources, the memberships cannot be modified or viewed. Group scopes do not apply to special identity groups. Users are automatically assigned to these special identity groups whenever they sign in or access a particular resource.
For information about security groups and group scope, see [Active Directory Security Groups](active-directory-security-groups.md).
The special identity groups are described in the following tables:
- [Anonymous Logon](#anonymous-logon)
- [Attested Key Property](#attested-key-property)
- [Authenticated Users](#authenticated-users)
- [Authentication Authority Asserted Identity](#authentication-authority-asserted-identity)
- [Batch](#batch)
- [Console Logon](#console-logon)
- [Creator Group](#creator-group)
- [Creator Owner](#creator-owner)
- [Dialup](#dialup)
- [Digest Authentication](#digest-authentication)
- [Enterprise Domain Controllers](#enterprise-domain-controllers)
- [Everyone](#everyone)
- [Fresh Public Key Identity](#fresh-public-key-identity)
- [Interactive](#interactive)
- [IUSR](#iusr)
- [Key Trust](#key-trust)
- [Local Service](#local-service)
- [LocalSystem](#localsystem)
- [MFA Key Property](#mfa-key-property)
- [Network](#network)
- [Network Service](#network-service)
- [NTLM Authentication](#ntlm-authentication)
- [Other Organization](#other-organization)
- [Owner Rights](#owner-rights)
- [Principal Self](#principal-self)
- [Proxy](#proxy)
- [Remote Interactive Logon](#remote-interactive-logon)
- [Restricted](#restricted)
- [SChannel Authentication](#schannel-authentication)
- [Service](#service)
- [Service Asserted Identity](#service-asserted-identity)
- [Terminal Server User](#terminal-server-user)
- [This Organization](#this-organization)
- [Window Manager\\Window Manager Group](#window-managerwindow-manager-group)
## Anonymous Logon
Any user who accesses the system through an anonymous logon has the Anonymous Logon identity. This identity allows anonymous access to resources, such as a web page that is published on corporate servers. The Anonymous Logon group is not a member of the Everyone group by default.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-7 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Attested Key Property
A SID that means the key trust object had the attestation property.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-6 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Authenticated Users
Any user who accesses the system through a sign-in process has the Authenticated Users identity. This identity allows access to shared resources within the domain, such as files in a shared folder that should be accessible to all the workers in the organization. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-11 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Access this computer from the network](/windows/device-security/security-policy-settings/access-this-computer-from-the-network): SeNetworkLogonRight<br> [Add workstations to domain](/windows/device-security/security-policy-settings/add-workstations-to-domain): SeMachineAccountPrivilege<br> [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege|
## Authentication Authority Asserted Identity
A SID that means the client's identity is asserted by an authentication authority based on proof of possession of client credentials.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Batch
Any user or process that accesses the system as a batch job (or through the batch queue) has the Batch identity. This identity allows batch jobs to run scheduled tasks, such as a nightly cleanup job that deletes temporary files. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-3 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Console Logon
A group that includes users who are logged on to the physical console. This SID can be used to implement security policies that grant different rights based on whether a user has been granted physical access to the console.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-2-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Creator Group
The person who created the file or the directory is a member of this special identity group. Windows Server operating systems use this identity to automatically grant access permissions to the creator of a file or directory.
A placeholder security identifier (SID) is created in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object’s current owner. The primary group is used only by the Portable Operating System Interface for UNIX (POSIX) subsystem.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-3-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Creator Owner
The person who created the file or the directory is a member of this special identity group. Windows Server operating systems use this identity to automatically grant access permissions to the creator of a file or directory. A placeholder SID is created in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the object’s current owner.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-3-0 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Dialup
Any user who accesses the system through a dial-up connection has the Dial-Up identity. This identity distinguishes dial-up users from other types of authenticated users.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-1 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Digest Authentication
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-64-21 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| none|
## Enterprise Domain Controllers
This group includes all domain controllers in an Active Directory forest. Domain controllers with enterprise-wide roles and responsibilities have the Enterprise Domain Controllers identity. This identity allows them to perform certain tasks in the enterprise by using transitive trusts. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-9 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Access this computer from the network](/windows/device-security/security-policy-settings/access-this-computer-from-the-network): SeNetworkLogonRight<br> [Allow log on locally](/windows/device-security/security-policy-settings/allow-log-on-locally): SeInteractiveLogonRight|
## Everyone
All interactive, network, dial-up, and authenticated users are members of the Everyone group. This special identity group gives wide access to system resources. Whenever a user logs on to the network, the user is automatically added to the Everyone group.
On computers running Windows 2000 and earlier, the Everyone group included the Anonymous Logon group as a default member, but as of Windows Server 2003, the Everyone group contains only Authenticated Users and Guest; and it no longer includes Anonymous Logon by default (although this can be changed, using Registry Editor, by going to the **Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa** key and setting the value of **everyoneincludesanonymous** DWORD to 1).
Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-1-0 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Access this computer from the network](/windows/device-security/security-policy-settings/access-this-computer-from-the-network): SeNetworkLogonRight</br> [Act as part of the operating system](/windows/device-security/security-policy-settings/act-as-part-of-the-operating-system): SeTcbPrivilege</br> [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege|
## Fresh Public Key Identity
A SID that means the client's identity is asserted by an authentication authority based on proof of current possession of client public key credentials.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-3 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Interactive
Any user who is logged on to the local system has the Interactive identity. This identity allows only local users to access a resource. Whenever a user accesses a given resource on the computer to which they are currently logged on, the user is automatically added to the Interactive group. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-4 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None|
## IUSR
Internet Information Services (IIS) uses this account by default whenever anonymous authentication is enabled.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-17 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Key Trust
A SID that means the client's identity is based on proof of possession of public key credentials using the key trust object.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-4 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Local Service
The Local Service account is similar to an Authenticated User account. The Local Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session with anonymous credentials. The name of the account is NT AUTHORITY\\LocalService. This account does not have a password.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-19 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Adjust memory quotas for a process](/windows/device-security/security-policy-settings/adjust-memory-quotas-for-a-process): SeIncreaseQuotaPrivilege <br>[Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege<br> [Change the system time](/windows/device-security/security-policy-settings/change-the-system-time): SeSystemtimePrivilege<br> [Change the time zone](/windows/device-security/security-policy-settings/change-the-time-zone): SeTimeZonePrivilege<br> [Create global objects](/windows/device-security/security-policy-settings/create-global-objects): SeCreateGlobalPrivilege<br> [Generate security audits](/windows/device-security/security-policy-settings/generate-security-audits): SeAuditPrivilege<br>[Impersonate a client after authentication](/windows/device-security/security-policy-settings/impersonate-a-client-after-authentication): SeImpersonatePrivilege<br> [Replace a process level token](/windows/device-security/security-policy-settings/replace-a-process-level-token): SeAssignPrimaryTokenPrivilege<br>|
## LocalSystem
This is a service account that is used by the operating system. The LocalSystem account is a powerful account that has full access to the system and acts as the computer on the network. If a service logs on to the LocalSystem account on a domain controller, that service has access to the entire domain. Some services are configured by default to log on to the LocalSystem account. Do not change the default service setting. The name of the account is LocalSystem. This account does not have a password.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-18 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## MFA Key Property
A SID that means the key trust object had the multifactor authentication (MFA) property.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-5 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Network
This group implicitly includes all users who are logged on through a network connection. Any user who accesses the system through a network has the Network identity. This identity allows only remote users to access a resource. Whenever a user accesses a given resource over the network, the user is automatically added to the Network group. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-2 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Network Service
The Network Service account is similar to an Authenticated User account. The Network Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Network Service account access network resources by using the credentials of the computer account. The name of the account is NT AUTHORITY\\NetworkService. This account does not have a password.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-20 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Adjust memory quotas for a process](/windows/device-security/security-policy-settings/adjust-memory-quotas-for-a-process): SeIncreaseQuotaPrivilege<br> [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege<br> [Create global objects](/windows/device-security/security-policy-settings/create-global-objects): SeCreateGlobalPrivilege<br> [Generate security audits](/windows/device-security/security-policy-settings/generate-security-audits): SeAuditPrivilege<br> [Impersonate a client after authentication](/windows/device-security/security-policy-settings/impersonate-a-client-after-authentication): SeImpersonatePrivilege<br> [Replace a process level token](/windows/device-security/security-policy-settings/replace-a-process-level-token): SeAssignPrimaryTokenPrivilege<br>|
## NTLM Authentication
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-64-10 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None|
## Other Organization
This group implicitly includes all users who are logged on to the system through a dial-up connection. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-1000 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Owner Rights
A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-3-4 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Principal Self
This identity is a placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Principal Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal that is represented by the object.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-10 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Proxy
Identifies a SECURITY_NT_AUTHORITY Proxy.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-8 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Remote Interactive Logon
This identity represents all users who are currently logged on to a computer by using a Remote Desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-14|
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Restricted
Users and computers with restricted capabilities have the Restricted identity. This identity group is used by a process that is running in a restricted security context, such as running an application with the RunAs service. When code runs at the Restricted security level, the Restricted SID is added to the user’s access token.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-12 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## SChannel Authentication
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-64-14 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Service
Any service that accesses the system has the Service identity. This identity group includes all security principals that are signed in as a service. This identity grants access to processes that are being run by Windows Server services. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-6 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Create global objects](/windows/device-security/security-policy-settings/create-global-objects): SeCreateGlobalPrivilege<br> [Impersonate a client after authentication](/windows/device-security/security-policy-settings/impersonate-a-client-after-authentication): SeImpersonatePrivilege<br>|
## Service Asserted Identity
A SID that means the client's identity is asserted by a service.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-18-2 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights|None|
## Terminal Server User
Any user accessing the system through Terminal Services has the Terminal Server User identity. This identity allows users to access Terminal Server applications and to perform other necessary tasks with Terminal Server services. Membership is controlled by the operating system.
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-13 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## This Organization
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-15 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| None |
## Window Manager\\Window Manager Group
| Attribute | Value |
| :--: | :--: |
| Well-Known SID/RID | S-1-5-90 |
|Object Class| Foreign Security Principal|
|Default Location in Active Directory |cn=WellKnown Security Principals, cn=Configuration, dc=\<forestRootDomain\>|
|Default User Rights| [Bypass traverse checking](/windows/device-security/security-policy-settings/bypass-traverse-checking): SeChangeNotifyPrivilege<br> [Increase a process working set](/windows/device-security/security-policy-settings/increase-a-process-working-set): SeIncreaseWorkingSetPrivilege<br>|
## See also
- [Active Directory Security Groups](active-directory-security-groups.md)
- [Security Principals](security-principals.md)
- [Access Control Overview](access-control.md)