deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-15 10:23:37 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
Paolo Matarazzo
2022-11-22 14:28:02 -05:00
parent e6f312445c
commit 3032b04c25
14 changed files with 210 additions and 393 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -1,19 +1,12 @@
---
title: Access Control Overview (Windows 10)
description: Access Control Overview
title: Access Control Overview
description: Description of the access controls in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer.
ms.prod: windows-client
author: paolomatarazzo
ms.author: paoloma
ms.reviewer: sulahiri
manager: aaroncz
ms.collection:
- M365-identity-device-management
ms.topic: article
ms.localizationpriority: medium
ms.date: 07/18/2017
ms.date: 11/22/2022
appliesto:
- ✅ <b>Windows 10</b>
- ✅ <b>Windows Server 2016</b>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
ms.technology: itpro-security
---
@ -21,89 +14,66 @@ ms.technology: itpro-security
This topic for the IT professional describes access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing.
## <a href="" id="bkmk-over"></a>Feature description
## Feature description
Computers that are running a supported version of Windows can control the use of system and network resources through the interrelated mechanisms of authentication and authorization. After a user is authenticated, the Windows operating system uses built-in authorization and access control technologies to implement the second phase of protecting resources: determining if an authenticated user has the correct permissions to access a resource.
Shared resources are available to users and groups other than the resource’s owner, and they need to be protected from unauthorized use. In the access control model, users and groups (also referred to as security principals) are represented by unique security identifiers (SIDs). They are assigned rights and permissions that inform the operating system what each user and group can do. Each resource has an owner who grants permissions to security principals. During the access control check, these permissions are examined to determine which security principals can access the resource and how they can access it.
Shared resources are available to users and groups other than the resource's owner, and they need to be protected from unauthorized use. In the access control model, users and groups (also referred to as security principals) are represented by unique security identifiers (SIDs). They are assigned rights and permissions that inform the operating system what each user and group can do. Each resource has an owner who grants permissions to security principals. During the access control check, these permissions are examined to determine which security principals can access the resource and how they can access it.
Security principals perform actions (which include Read, Write, Modify, or Full control) on objects. Objects include files, folders, printers, registry keys, and Active Directory Domain Services (AD DS) objects. Shared resources use access control lists (ACLs) to assign permissions. This enables resource managers to enforce access control in the following ways:
- Deny access to unauthorized users and groups
- Set well-defined limits on the access that is provided to authorized users and groups
- Deny access to unauthorized users and groups
- Set well-defined limits on the access that is provided to authorized users and groups
Object owners generally grant permissions to security groups rather than to individual users. Users and computers that are added to existing groups assume the permissions of that group. If an object (such as a folder) can hold other objects (such as subfolders and files), it is called a container. In a hierarchy of objects, the relationship between a container and its content is expressed by referring to the container as the parent. An object in the container is referred to as the child, and the child inherits the access control settings of the parent. Object owners often define permissions for container objects, rather than individual child objects, to ease access control management.
This content set contains:
- [Dynamic Access Control Overview](dynamic-access-control.md)
- [Security identifiers](security-identifiers.md)
- [Security Principals](security-principals.md)
- [Local Accounts](local-accounts.md)
- [Active Directory Accounts](active-directory-accounts.md)
- [Microsoft Accounts](microsoft-accounts.md)
- [Service Accounts](service-accounts.md)
- [Active Directory Security Groups](active-directory-security-groups.md)
## <a href="" id="bkmk-app"></a>Practical applications
- [Dynamic Access Control Overview](dynamic-access-control.md)
- [Security identifiers](security-identifiers.md)
- [Security Principals](security-principals.md)
- [Local Accounts](local-accounts.md)
- [Active Directory Accounts](active-directory-accounts.md)
- [Microsoft Accounts](microsoft-accounts.md)
- [Service Accounts](service-accounts.md)
- [Active Directory Security Groups](active-directory-security-groups.md)
## Practical applications
Administrators who use the supported version of Windows can refine the application and management of access control to objects and subjects to provide the following security:
- Protect a greater number and variety of network resources from misuse.
- Provision users to access resources in a manner that is consistent with organizational policies and the requirements of their jobs.
- Enable users to access resources from a variety of devices in numerous locations.
- Update users’ ability to access resources on a regular basis as an organization’s policies change or as users’ jobs change.
- Account for a growing number of use scenarios (such as access from remote locations or from a rapidly expanding variety of devices, such as tablet computers and mobile phones).
- Identify and resolve access issues when legitimate users are unable to access resources that they need to perform their jobs.
- Protect a greater number and variety of network resources from misuse.
- Provision users to access resources in a manner that is consistent with organizational policies and the requirements of their jobs.
- Enable users to access resources from a variety of devices in numerous locations.
- Update users' ability to access resources on a regular basis as an organization's policies change or as users' jobs change.
- Account for a growing number of use scenarios (such as access from remote locations or from a rapidly expanding variety of devices, such as tablet computers and mobile phones).
- Identify and resolve access issues when legitimate users are unable to access resources that they need to perform their jobs.
## Permissions
Permissions define the type of access that is granted to a user or group for an object or object property. For example, the Finance group can be granted Read and Write permissions for a file named Payroll.dat.
By using the access control user interface, you can set NTFS permissions for objects such as files, Active Directory objects, registry objects, or system objects such as processes. Permissions can be granted to any user, group, or computer. It is a good practice to assign permissions to groups because it improves system performance when verifying access to an object.
For any object, you can grant permissions to:
- Groups, users, and other objects with security identifiers in the domain.
- Groups and users in that domain and any trusted domains.
- Local groups and users on the computer where the object resides.
- Groups, users, and other objects with security identifiers in the domain.
- Groups and users in that domain and any trusted domains.
- Local groups and users on the computer where the object resides.
The permissions attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key. Some permissions, however, are common to most types of objects. These common permissions are:
- Read
- Modify
- Change owner
- Delete
- Read
- Modify
- Change owner
- Delete
When you set permissions, you specify the level of access for groups and users. For example, you can let one user read the contents of a file, let another user make changes to the file, and prevent all other users from accessing the file. You can set similar permissions on printers so that certain users can configure the printer and other users can only print.
When you need to change the permissions on a file, you can run Windows Explorer, right-click the file name, and click **Properties**. On the **Security** tab, you can change permissions on the file. For more information, see [Managing Permissions](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770962(v=ws.11)).
**Note**  
Another kind of permissions, called share permissions, is set on the Sharing tab of a folder's **Properties** page or by using the Shared Folder Wizard. For more information see [Share and NTFS Permissions on a File Server](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754178(v=ws.11)).
> [!NOTE]
> Another kind of permissions, called share permissions, is set on the Sharing tab of a folder's **Properties** page or by using the Shared Folder Wizard. For more information see [Share and NTFS Permissions on a File Server](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc754178(v=ws.11)).
### Ownership of objects
@ -115,7 +85,6 @@ Inheritance allows administrators to easily assign and manage permissions. This
## User rights
User rights grant specific privileges and sign-in rights to users and groups in your computing environment. Administrators can assign specific rights to group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as signing in to a system interactively or backing up files and directories.
User rights are different from permissions because user rights apply to user accounts, and permissions are associated with objects. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. There is no support in the access control user interface to grant user rights. However, user rights assignment can be administered through **Local Security Settings**.
@ -124,15 +93,10 @@ For more information about user rights, see [User Rights Assignment](/windows/de
## Object auditing
With administrator's rights, you can audit users' successful or failed access to objects. You can select which object access to audit by using the access control user interface, but first you must enable the audit policy by selecting **Audit object access** under **Local Policies** in **Local Security Settings**. You can then view these security-related events in the Security log in Event Viewer.
For more information about auditing, see [Security Auditing Overview](../../threat-protection/auditing/security-auditing-overview.md).
## See also
- For more information about access control and authorization, see [Access Control and Authorization Overview](/previous-versions/windows/it-pro/windows-8.1-and-8/jj134043(v=ws.11)).
- For more information about access control and authorization, see [Access Control and Authorization Overview](/previous-versions/windows/it-pro/windows-8.1-and-8/jj134043(v=ws.11)).

253
windows/security/identity-protection/access-control/local-accounts.md
View File

@ -1,71 +1,35 @@
---
title: Local Accounts (Windows 10)
title: Local Accounts
description: Learn how to secure and manage access to the resources on a standalone or member server for services or users.
ms.prod: windows-client
author: paolomatarazzo
ms.author: paoloma
ms.reviewer: sulahiri
manager: aaroncz
ms.date: 22/11/2022
ms.collection:
- M365-identity-device-management
- highpri
ms.topic: article
ms.localizationpriority: medium
ms.date: 06/17/2022
appliesto:
- ✅ <b>Windows 10</b>
- ✅ <b>Windows 11</b>
- ✅ <b>Windows Server 2016</b>
- ✅ <b>Windows Server 2019</b>
- ✅ <b>Windows Server 2022</b>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016 and later</a>
ms.technology: itpro-security
---
# Local Accounts
This reference article for IT professionals describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server.
This article describes the default local user accounts for Windows operating systems, and how to manage the built-in accounts on a member or standalone workstation/server.
## <a href="" id="about-local-user-accounts-"></a>About local user accounts
## About local user accounts
Local user accounts are stored locally on the server. These accounts can be assigned rights and permissions on a particular server, but on that server only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
Local user accounts are stored locally on the device. These accounts can be assigned rights and permissions on a particular device, but on that device only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
This article describes the following:
## Default local user accounts
- [Default local user accounts](#sec-default-accounts)
The *default local user accounts* are built-in accounts that are created automatically when the operating system is installed. The default local user accounts can't be removed or deleted and don't provide access to network resources.
- [Administrator account](#sec-administrator)
Default local user accounts are used to manage access to the local device's resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the *Users* folder. The Users folder is located in the Local Users and Groups folder in the local *Computer Management* Microsoft Management Console (MMC). *Computer Management* is a collection of administrative tools that you can use to manage a single local or remote device.
- [Guest Account](#sec-guest)
Default local user accounts are described in the following sections. Expand each section for more information.
- [HelpAssistant account (installed by using a Remote Assistance session)](#sec-helpassistant)
- [DefaultAccount](#defaultaccount)
- [Default local system accounts](#sec-localsystem)
- [How to manage local accounts](#sec-manage-accounts)
- [Restrict and protect local accounts with administrative rights](#sec-restrict-protect-accounts)
- [Enforce local account restrictions for remote access](#sec-enforce-account-restrictions)
- [Deny network logon to all local Administrator accounts](#sec-deny-network-logon)
- [Create unique passwords for local accounts with administrative rights](#sec-create-unique-passwords)
For information about security principals, see [Security Principals](security-principals.md).
## <a href="" id="sec-default-accounts"></a>Default local user accounts
The default local user accounts are built-in accounts that are created automatically when you install Windows.
After Windows is installed, the default local user accounts can't be removed or deleted. In addition, default local user accounts don't provide access to network resources.
Default local user accounts are used to manage access to the local server’s resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see [How to manage local accounts](#sec-manage-accounts) later in this article.
Default local user accounts are described in the following sections.
### <a href="" id="sec-administrator"></a>Administrator account
<br>
<details>
<summary><b>Administrator</b></summary>
The default local Administrator account is a user account for the system administrator. Every computer has an Administrator account (SID S-1-5-*domain*-500, display name Administrator). The Administrator account is the first account that is created during the Windows installation.
@ -99,7 +63,10 @@ In this case, Group Policy can be used to enable secure settings that can contro
>
> - Even when the Administrator account has been disabled, it can still be used to gain access to a computer by using safe mode. In the Recovery Console or in safe mode, the Administrator account is automatically enabled. When normal operations are resumed, it is disabled.
### <a href="" id="sec-guest"></a>Guest account
</details>
<br>
<details>
<summary><b>Guest</b></summary>
The Guest account is disabled by default on installation. The Guest account lets occasional or one-time users, who don't have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it's a security risk. For this reason, it's a best practice to leave the Guest account disabled, unless its use is entirely necessary.
@ -113,8 +80,11 @@ When enabling the Guest account, only grant limited rights and permissions. For
In addition, the guest user in the Guest account shouldn't be able to view the event logs. After the Guest account is enabled, it's a best practice to monitor the Guest account frequently to ensure that other users can't use services and other resources. This includes resources that were unintentionally left available by a previous user.
## <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed with a Remote Assistance session)
</details>
<br>
<details>
<summary><b>HelpAssistant</b></summary>
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.
@ -124,9 +94,9 @@ HelpAssistant is the primary account that is used to establish a Remote Assistan
The SIDs that pertain to the default HelpAssistant account include:
- SID: S-1-5-&lt;domain&gt;-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note: In Windows Server 2008, Remote Desktop Services is called Terminal Services.
- 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: In Windows Server 2008, Remote Desktop Services is called Terminal Services.
- SID: S-1-5-&lt;domain&gt;-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.
- 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 isn't installed by default. You must install Remote Assistance before it can be used.
@ -145,7 +115,11 @@ For details about the HelpAssistant account attributes, see the following table.
|Safe to move out of default container?|Can be moved out, but we don't recommend it.|
|Safe to delegate management of this group to non-Service admins?|No|
### DefaultAccount
</details>
<br>
<details>
<summary><b>DefaultAccount</b></summary>
The DefaultAccount, also known as the Default System Managed Account (DSMA), is a built-in account introduced in Windows 10 version 1607 and Windows Server 2016.
The DSMA is a well-known user account type.
@ -169,10 +143,10 @@ Today, Xbox automatically signs in as Guest account and all apps run in this con
All the apps are multi-user-aware and respond to events fired by user manager.
The apps run as the Guest account.
Similarly, Phone auto logs in as a “DefApps” account, which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.
Similarly, Phone auto logs in as a *DefApps* account, which is akin to the standard user account in Windows but with a few extra privileges. Brokers, some services and apps run as this account.
In the converged user model, the multi-user-aware apps and multi-user-aware brokers will need to run in a context different from that of the users.
For this purpose, the system creates DSMA.
For this purpose, the system creates DSMA.
#### How the DefaultAccount gets created on domain controllers
@ -182,25 +156,37 @@ If the domain was created with domain controllers running an earlier version of
#### Recommendations for managing the Default Account (DSMA)
Microsoft doesn't recommend changing the default configuration, where the account is disabled. There's no security risk with having the account in the disabled state. Changing the default configuration could hinder future scenarios that rely on this account.
</details>
## <a href="" id="sec-localsystem"></a>Default local system accounts
## Default local system accounts
### SYSTEM
The SYSTEM account is used by the operating system and by services running under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM account’s user rights. It's an internal account that doesn't show up in User Manager, and it can't be added to any groups.
<br>
<details>
<summary><b>SYSTEM</b></summary>
The *SYSTEM* account is used by the operating system and by services running under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The SYSTEM account was designed for that purpose, and Windows manages the SYSTEM account's user rights. It's an internal account that doesn't show up in User Manager, and it can't be added to any groups.
On the other hand, the SYSTEM account does appear on an NTFS file system volume in File Manager in the **Permissions** portion of the **Security** menu. By default, the SYSTEM account is granted Full Control permissions to all files on an NTFS volume. Here the SYSTEM account has the same functional rights and permissions as the Administrator account.
> [!NOTE]
> To grant the account Administrators group file permissions does not implicitly give permission to the SYSTEM account. The SYSTEM account's permissions can be removed from a file, but we do not recommend removing them.
### NETWORK SERVICE
</details>
<br>
<details>
<summary><b>NETWORK SERVICE </b></summary>
The NETWORK SERVICE account is a predefined local account used by the service control manager (SCM). A service that runs in the context of the NETWORK SERVICE account presents the computer's credentials to remote servers. For more information, see [NetworkService Account](/windows/desktop/services/networkservice-account).
</details>
<br>
<details>
<summary><b>LOCAL SERVICE</b></summary>
### LOCAL SERVICE
The LOCAL SERVICE account is a predefined local account used by the service control manager. It has minimum privileges on the local computer and presents anonymous credentials on the network. For more information, see [LocalService Account](/windows/desktop/services/localservice-account).
</details>
## <a href="" id="sec-manage-accounts"></a>How to manage local user accounts
## How to manage local user accounts
The default local user accounts, and the local user accounts you create, are located in the Users folder. The Users folder is located in Local Users and Groups. For more information about creating and managing local user accounts, see [Manage Local Users](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731899(v=ws.11)).
@ -221,11 +207,11 @@ The simplest approach is to sign in to your computer with a standard user accoun
The other approaches that can be used to restrict and protect user accounts with administrative rights include:
- Enforce local account restrictions for remote access.
- Enforce local account restrictions for remote access.
- Deny network logon to all local Administrator accounts.
- Deny network logon to all local Administrator accounts.
- Create unique passwords for local accounts with administrative rights.
- Create unique passwords for local accounts with administrative rights.
Each of these approaches is described in the following sections.
@ -274,57 +260,57 @@ The following table shows the Group Policy and registry settings that are used t
3. In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
![local accounts 1.](images/localaccounts-proc1-sample1.png)
![local accounts 1.](images/localaccounts-proc1-sample1.png)
4. In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and &gt; **OK** where *gpo\_name* is the name of the new GPO. The GPO name indicates that the GPO is used to restrict local administrator rights from being carried over to another computer.
![local accounts 2.](images/localaccounts-proc1-sample2.png)
![local accounts 2.](images/localaccounts-proc1-sample2.png)
5. In the details pane, right-click &lt;**gpo\_name**&gt;, and &gt; **Edit**.
![local accounts 3.](images/localaccounts-proc1-sample3.png)
![local accounts 3.](images/localaccounts-proc1-sample3.png)
6. Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by following these steps:
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\, and &gt; **Security Options**.
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\, and &gt; **Security Options**.
2. Double-click **User Account Control: Run all administrators in Admin Approval Mode** &gt; **Enabled** &gt; **OK**.
2. Double-click **User Account Control: Run all administrators in Admin Approval Mode** &gt; **Enabled** &gt; **OK**.
3. Double-click **User Account Control: Admin Approval Mode for the Built-in Administrator account** &gt; **Enabled** &gt; **OK**.
3. Double-click **User Account Control: Admin Approval Mode for the Built-in Administrator account** &gt; **Enabled** &gt; **OK**.
7. Ensure that the local account restrictions are applied to network interfaces by following these steps:
1. Navigate to Computer Configuration\\Preferences and Windows Settings, and &gt; **Registry**.
1. Navigate to Computer Configuration\\Preferences and Windows Settings, and &gt; **Registry**.
2. Right-click **Registry**, and &gt; **New** &gt; **Registry Item**.
2. Right-click **Registry**, and &gt; **New** &gt; **Registry Item**.
![local accounts 4.](images/localaccounts-proc1-sample4.png)
![local accounts 4.](images/localaccounts-proc1-sample4.png)
3. In the **New Registry Properties** dialog box, on the **General** tab, change the setting in the **Action** box to **Replace**.
3. In the **New Registry Properties** dialog box, on the **General** tab, change the setting in the **Action** box to **Replace**.
4. Ensure that the **Hive** box is set to **HKEY\_LOCAL\_MACHINE**.
4. Ensure that the **Hive** box is set to **HKEY\_LOCAL\_MACHINE**.
5. Select (**…**), browse to the following location for **Key Path** &gt; **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
5. Select (**…**), browse to the following location for **Key Path** &gt; **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
6. In the **Value name** area, type **LocalAccountTokenFilterPolicy**.
6. In the **Value name** area, type **LocalAccountTokenFilterPolicy**.
7. In the **Value type** box, from the drop-down list, select **REG\_DWORD** to change the value.
7. In the **Value type** box, from the drop-down list, select **REG\_DWORD** to change the value.
8. In the **Value data** box, ensure that the value is set to **0**.
8. In the **Value data** box, ensure that the value is set to **0**.
9. Verify this configuration, and &gt; **OK**.
9. Verify this configuration, and &gt; **OK**.
![local accounts 5.](images/localaccounts-proc1-sample5.png)
![local accounts 5.](images/localaccounts-proc1-sample5.png)
8. Link the GPO to the first **Workstations** organizational unit (OU) by doing the following:
1. Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path.
1. Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path.
2. Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
2. Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
![local accounts 6.](images/localaccounts-proc1-sample6.png)
![local accounts 6.](images/localaccounts-proc1-sample6.png)
3. Select the GPO that you created, and &gt; **OK**.
3. Select the GPO that you created, and &gt; **OK**.
9. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
@ -354,55 +340,33 @@ The following table shows the Group Policy settings that are used to deny networ
#### To deny network logon to all local administrator accounts
1. Start the **Group Policy Management** Console (GPMC).
1. Start the **Group Policy Management** Console (GPMC)
1. In the console tree, expand &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;, and then **Group Policy Objects**, where *forest* is the name of the forest, and *domain* is the name of the domain where you want to set the Group Policy Object (GPO).
1. In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
1. In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and then &gt; **OK** where *gpo\_name* is the name of the new GPO indicates that it's being used to restrict the local administrative accounts from interactively signing in to the computer
![local accounts 7.](images/localaccounts-proc2-sample1.png)
1. In the details pane, right-click &lt;**gpo\_name**&gt;, and &gt; **Edit**
![local accounts 8.](images/localaccounts-proc2-sample2.png)
1. Configure the user rights to deny network logons for administrative local accounts as follows:
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\, and &gt; **User Rights Assignment**
1. Double-click **Deny access to this computer from the network**
1. Select **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**
1. Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local accounts as follows:
1. Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then select **User Rights Assignment**
1. Double-click **Deny log on through Remote Desktop Services**
1. Select **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**
1. Link the GPO to the first **Workstations** OU as follows:
- Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path
- Right-click the **Workstations** OU, and &gt; **Link an existing GPO**
- Select the GPO that you created, and &gt; **OK**
1. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
1. Create links to all other OUs that contain workstations.
1. Create links to all other OUs that contain servers.
2. In the console tree, expand &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;, and then **Group Policy Objects**, where *forest* is the name of the forest, and *domain* is the name of the domain where you want to set the Group Policy Object (GPO).
> [!NOTE]
> You might have to create a separate GPO if the user name of the default Administrator account is different on workstations and servers.
3. In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
4. In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and then &gt; **OK** where *gpo\_name* is the name of the new GPO indicates that it's being used to restrict the local administrative accounts from interactively signing in to the computer.
![local accounts 7.](images/localaccounts-proc2-sample1.png)
5. In the details pane, right-click &lt;**gpo\_name**&gt;, and &gt; **Edit**.
![local accounts 8.](images/localaccounts-proc2-sample2.png)
6. Configure the user rights to deny network logons for administrative local accounts as follows:
1. Navigate to the Computer Configuration\\Windows Settings\\Security Settings\\, and &gt; **User Rights Assignment**.
2. Double-click **Deny access to this computer from the network**.
3. Select **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**.
7. Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local accounts as follows:
1. Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then select **User Rights Assignment**.
2. Double-click **Deny log on through Remote Desktop Services**.
3. Select **Add User or Group**, type **Local account and member of Administrators group**, and &gt; **OK**.
8. Link the GPO to the first **Workstations** OU as follows:
1. Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path.
2. Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
3. Select the GPO that you created, and &gt; **OK**.
9. Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
10. Create links to all other OUs that contain workstations.
11. Create links to all other OUs that contain servers.
> [!NOTE]
> You might have to create a separate GPO if the user name of the default Administrator account is different on workstations and servers.
### <a href="" id="sec-create-unique-passwords"></a>Create unique passwords for local accounts with administrative rights
### Create unique passwords for local accounts with administrative rights
Passwords should be unique per individual account. While it's true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.
@ -410,19 +374,6 @@ Passwords that are left unchanged or changed synchronously to keep them identica
Passwords can be randomized by:
- Purchasing and implementing an enterprise tool to accomplish this task. These tools are commonly referred to as "privileged password management" tools.
- Configuring [Local Administrator Password Solution (LAPS)](https://www.microsoft.com/download/details.aspx?id=46899) to accomplish this task.
- Creating and implementing a custom script or solution to randomize local account passwords.
## <a href="" id="dhcp-references"></a>See also
The following resources provide additional information about technologies that are related to local accounts.
- [Security Principals](security-principals.md)
- [Security Identifiers](security-identifiers.md)
- [Access Control Overview](access-control.md)
- Purchasing and implementing an enterprise tool to accomplish this task. These tools are commonly referred to as "privileged password management" tools
- Configuring [Local Administrator Password Solution (LAPS)](https://www.microsoft.com/download/details.aspx?id=46899) to accomplish this task
- Creating and implementing a custom script or solution to randomize local account passwords