diff --git a/windows/keep-secure/active-directory-accounts.md b/windows/keep-secure/active-directory-accounts.md
index 8acc3ea048..a667953174 100644
--- a/windows/keep-secure/active-directory-accounts.md
+++ b/windows/keep-secure/active-directory-accounts.md
@@ -573,27 +573,20 @@ If the administrators in your environment can sign in locally to managed servers
- **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 Overview](http://technet.microsoft.com/library/hh831440.aspx).
--
-
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 the domain by using [KB 932455](http://support.microsoft.com/kb/932455) if the account that joins the workstations to the domain does not already have permissions to join computers to the domain.
+ > **Note** You might have to delegate permissions to join the domain by using [KB 932455](http://support.microsoft.com/kb/932455) if the account that joins the workstations to the domain does not already have permissions to join computers to the domain.
-
-
- 
+ 
3. Close Active Directory Users and Computers.
@@ -601,13 +594,13 @@ In this procedure, the workstations are dedicated to domain administrators. By s
5. Right-click the new OU, and > **Create a GPO in this domain, and Link it here**.
- 
+ 
6. Name the GPO, and > **OK**.
7. Expand the GPO, right-click the new GPO, and > **Edit**.
- 
+ 
8. Configure which members of accounts can log on locally to these administrative workstations as follows:
@@ -626,7 +619,7 @@ In this procedure, the workstations are dedicated to domain administrators. By s
5. Click **Add User or Group**, type **Administrators**, and > **OK**.
- 
+ 
9. Configure the proxy configuration:
@@ -634,7 +627,7 @@ In this procedure, the workstations are dedicated to domain administrators. By s
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 > **OK**.
- 
+ 
10. Configure the loopback processing mode to enable the user Group Policy proxy setting to apply to all users on the computer as follows:
@@ -691,22 +684,17 @@ In this procedure, the workstations are dedicated to domain administrators. By s
-
-
- **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.
-
-
+ > **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 > **Properties**.
- 
+ 
2. On each profile, ensure that the firewall is enabled and that inbound connections are set to **Block all connections**.
- 
+ 
3. Click **OK** to complete the configuration.
@@ -744,11 +732,11 @@ For this procedure, do not link accounts to the OU that contain workstations for
3. Right-click **Group Policy Objects**, and > **New**.
- 
+ 
4. In the **New GPO** dialog box, name the GPO that restricts administrators from signing in to workstations, and > **OK**.
- 
+ 
5. Right-click **New GPO**, and > **Edit**.
@@ -762,7 +750,7 @@ For this procedure, do not link accounts to the OU that contain workstations for
3. Click **Add User or Group**, click **Browse**, type **Domain Admins**, and > **OK**.
- 
+ 
**Note**
You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
@@ -784,7 +772,7 @@ For this procedure, do not link accounts to the OU that contain workstations for
3. Click **Add User or Group** > **Browse**, type **Domain Admins**, and > **OK**.
- 
+ 
**Note**
You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
@@ -797,7 +785,7 @@ For this procedure, do not link accounts to the OU that contain workstations for
6. Click **Add User or Group** > **Browse**, type **Domain Admins**, and > **OK**.
- 
+ 
**Note**
You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
@@ -810,11 +798,11 @@ For this procedure, do not link accounts to the OU that contain workstations for
1. Right-click the workstation OU, and then > **Link an Existing GPO**.
- 
+ 
2. Select the GPO that you just created, and > **OK**.
- 
+ 
10. Test the functionality of enterprise applications on workstations in the first OU and resolve any issues caused by the new policy.
@@ -837,7 +825,7 @@ It is a best practice to configure the user objects for all sensitive accounts i
As with any configuration change, test this enabled setting fully to ensure that it performs correctly before you implement it.
-
+
## Secure and manage domain controllers
diff --git a/windows/keep-secure/active-directory-security-groups.md b/windows/keep-secure/active-directory-security-groups.md
index c3856faf75..195b7371a2 100644
--- a/windows/keep-secure/active-directory-security-groups.md
+++ b/windows/keep-secure/active-directory-security-groups.md
@@ -986,7 +986,7 @@ This security group has not changed since Windows Server 2008.
Members of the Cloneable Domain Controllers group that are domain controllers may be cloned. In Windows Server 2012 R2 and Windows Server 2012, you can deploy domain controllers by copying an existing virtual domain controller. In a virtual environment, you no longer have to repeatedly deploy a server image that is prepared by using sysprep.exe, promote the server to a domain controller, and then complete additional configuration requirements for deploying each domain controller (including adding the virtual domain controller to this security group).
-For more information, see [Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)](introduction_to_active_directory_domain_services__ad_ds__virtualization__level_100__original).
+For more information, see [Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)](https://technet.microsoft.com/en-us/library/hh831734.aspx).
This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
@@ -2602,7 +2602,7 @@ Depending on the account’s domain functional level, members of the Protected U
The Protected Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
-This group was introduced in Windows Server 2012 R2. For more information about how this group works, see [Protected Users Security Group](protected_users_security_group).
+This group was introduced in Windows Server 2012 R2. For more information about how this group works, see [Protected Users Security Group](https://technet.microsoft.com/en-us/library/dn466518.aspx).
The following table specifies the properties of the Protected Users group.
diff --git a/windows/keep-secure/local-accounts.md b/windows/keep-secure/local-accounts.md
index e76d606feb..34d0c40d1e 100644
--- a/windows/keep-secure/local-accounts.md
+++ b/windows/keep-secure/local-accounts.md
@@ -71,40 +71,13 @@ The default Administrator account cannot be deleted or locked out, but it can be
The default Administrator account is initially installed differently for Windows Server operating systems, and the Windows client operating systems. The following table provides a comparison.
-Default restriction
-Windows Server operating systems
-Windows client operating systems
-Administrator account is disabled on installation
-
-No
-
-Yes
-
-Administrator account is set up on first sign-in
-
-Yes
-
-No, keep disabled
-
-Administrator account is used to set up the local server or client computer
-
-Yes
-
-No, use a local user account with **Run as administrator** to obtain administrative rights
-
-Administrator account requires a strong password when it is enabled
-
-Yes
-
-Yes
-
-Administrator account can be disabled, locked out, or renamed
-
-Yes
-
-Yes
-
-
+| Default restriction | Windows Server operating systems | Windows client operating systems |
+|---------------------|----------------------------------|----------------------------------|
+| Administrator account is disabled on installation | No | Yes |
+| Administrator account is set up on first sign-in | Yes | No, keep disabled |
+| Administrator account is used to set up the local server or client computer | Yes | No, use a local user account with **Run as administrator** to obtain administrative rights |
+| Administrator account requires a strong password when it is enabled | Yes | Yes |
+| Administrator account can be disabled, locked out, or renamed | Yes | Yes |
In summary, for Windows Server operating systems, the Administrator account is used to set up the local server only for tasks that require administrative rights. The default Administrator account is set up by using the default settings that are provided on installation. Initially, the Administrator account is not associated with a password. After installation, when you first set up Windows Server, your first task is to set up the Administrator account properties securely. This includes creating a strong password and securing the **Remote control** and **Remote Desktop Services Profile** settings. You can also disable the Administrator account when it is not required.
diff --git a/windows/keep-secure/security-identifiers.md b/windows/keep-secure/security-identifiers.md
index 1997d5b2d1..a4c77231a6 100644
--- a/windows/keep-secure/security-identifiers.md
+++ b/windows/keep-secure/security-identifiers.md
@@ -21,7 +21,7 @@ A security identifier (SID) is used to uniquely identify a security principal or
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.
+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.
@@ -37,7 +37,7 @@ The operating system generates a SID that identifies a particular account or gro
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.
+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
@@ -125,7 +125,7 @@ When a new domain user or group account is created, Active Directory stores the
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.
+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.
@@ -205,7 +205,7 @@ The SECURITY\_NT\_AUTHORITY (S-1–5) predefined identifier authority produ
| 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.
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*-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.
Cert Publishers are authorized to publish certificates for User objects in Active Directory.|
@@ -265,7 +265,7 @@ The following table provides examples of domain-relative RIDs that are used to f
| DOMAIN_ALIAS_RID_REPLICATOR | 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 | 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
+## 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.
@@ -276,4 +276,4 @@ The following table describes changes in SID implementation in the Windows opera
## See also
-- [Access Control Overview](https://technet.microsoft.com/en-us/library/dn408189.aspx)
+- [Access Control Overview](access-control.md)
diff --git a/windows/keep-secure/service-accounts.md b/windows/keep-secure/service-accounts.md
index 3fecf693d7..3996bebaf3 100644
--- a/windows/keep-secure/service-accounts.md
+++ b/windows/keep-secure/service-accounts.md
@@ -26,7 +26,7 @@ This topic contains information about the following types of service accounts:
- [Group managed service accounts](#bkmk-groupmanagedserviceaccounts)
-- [Virtual service accounts](#bkmk-virtualserviceaccounts)
+- [Virtual accounts](#bkmk-virtualserviceaccounts)
### Standalone managed service accounts