Update service-accounts-user-on-premises.md

Author: v-edmckillop

articles/active-directory/fundamentals/service-accounts-user-on-premises.md

@@ -17,86 +17,80 @@ ms.collection: M365-identity-device-management
 
 # Secure user-based service accounts in Active Directory
 
-Using on-premises user accounts is the traditional approach to helping secure services that run on Windows. Use these accounts as a last resort when group managed service accounts (gMSAs) and standalone managed service accounts (sMSAs) aren't supported by your service. For information about selecting the best type of account to use, see [Introduction to on-premises service accounts](service-accounts-on-premises.md). 
+On-premises user accounts was the traditional approach to help secure services running on Windows. Today, use these accounts if group managed service accounts (gMSAs) and standalone managed service accounts (sMSAs) aren't supported by your service. For information about the account type to use, see [Securing on-premises service accounts](service-accounts-on-premises.md). 
 
-You might also want to investigate whether you can move your service to use an Azure service account such as a managed identity or a service principal. 
+You can investigate moving your service an Azure service account, such as a managed identity or a service principal. See, [What are managed identities for Azure resources?](../managed-identities-azure-resources/overview.md)
 
-You can create on-premises user accounts to provide a security context for the services and permissions that the accounts require to access local and network resources. On-premises user accounts require manual password management, much like any other Active Directory user account. Service and domain administrators are required to observe strong password management processes to help keep these accounts secure.
+You can create on-premises user accounts to provide security for services and permissions the accounts use to access local and network resources. On-premises user accounts require manual password management, like other Active Directory (AD) user accounts. Service and domain administrators are required to maintain strong password management processes to help keep accounts secure.
 
-When you create a user account as a service account, use it for a single service only. Name it in a way that makes it clear that it's a service account and which service it's for. 
+When you create a user account as a service account, use it for one service. Use a naming convention that clarifies it's a service account, and the service it's related to. 
 
 ## Benefits and challenges
 
-On-premises user accounts can provide significant benefits. They're the most versatile account type for use with services. User accounts used as service accounts can be controlled by all the policies that govern normal user accounts. But you should use them only if you can't use an MSA. Also evaluate whether a computer account is a better option. 
+On-premises user accounts are a versatile account type. User accounts used as service accounts are controlled by policies governing user accounts. Use them if you can't use an MSA. Evaluate whether a computer account is a better option. 
 
-The challenges associated with the use of on-premises user accounts are summarized in the following table:
+The challenges of on-premises user accounts are summarized in the following table:
 
 | Challenge | Mitigation |
 | - | - |
-| Password management is a manual process that can lead to weaker security and service downtime.| <li>Make sure that password complexity and password changes are governed by a robust process that ensures regular updates with strong passwords.<li>Coordinate password changes with a password update on the service, which will help reduce service downtime. |
-| Identifying on-premises user accounts that are acting as service accounts can be difficult. | <li>Document and maintain records of service accounts that are deployed in your environment.<li>Track the account name and the resources to which they're assigned access.<li>Consider adding a prefix of "svc-" to all user accounts that are used as service accounts. |
-| | |
-
+| Password management is manual and leads to weaker security and service downtime| - Ensure regular password complexity and changes are governed by a process that maintains strong passwords</br> - Coordinate password changes with a service password, which helps reduce service downtime|
+| Identifying on-premises user accounts that are service accounts can be difficult | - Document service accounts deployed in your environment</br> - Track the account name and the resources they can access</br> - Consider adding the prefix svc- to user accounts used as service accounts |
 
 ## Find on-premises user accounts used as service accounts
 
-On-premises user accounts are just like any other Active Directory user account. It can be difficult to find such accounts, because no single attribute of a user account identifies it as a service account. 
-
-We recommend that you create an easily identifiable naming convention for any user account that you use as a service account. For example, you might add "svc-" as a prefix and name the service “svc-HRDataConnector.”
+On-premises user accounts are like other AD user accounts. It can be difficult to find the accounts, because no user account attribute identifies it as a service account. We recommend you create a naming convention for user accounts uses as service accounts. For example, add the prefix svc- to a service name: svc-HRDataConnector.
 
-You can use some of the following criteria to find these service accounts. However, this approach might not find all accounts, such as:
+Use some of the following criteria to find service accounts. However, this approach might not find accounts:
 
-* Accounts that are trusted for delegation.  
-* Accounts with service principal names.  
-* Accounts with passwords that are set to never expire.
+* Trusted for delegation 
+* With service principal names 
+* With passwords that never expire
 
-To find the on-premises user accounts you've created for services, you can run the following PowerShell commands.
+To find the on-premises user accounts used for services, run the following PowerShell commands:
 
-To find accounts that are trusted for delegation:
+To find accounts trusted for delegation:
 
 ```PowerShell
 
 Get-ADObject -Filter {(msDS-AllowedToDelegateTo -like '*') -or (UserAccountControl -band 0x0080000) -or (UserAccountControl -band 0x1000000)} -prop samAccountName,msDS-AllowedToDelegateTo,servicePrincipalName,userAccountControl | select DistinguishedName,ObjectClass,samAccountName,servicePrincipalName, @{name='DelegationStatus';expression={if($_.UserAccountControl -band 0x80000){'AllServices'}else{'SpecificServices'}}}, @{name='AllowedProtocols';expression={if($_.UserAccountControl -band 0x1000000){'Any'}else{'Kerberos'}}}, @{name='DestinationServices';expression={$_.'msDS-AllowedToDelegateTo'}}
 
 ```
 
-To find accounts that have service principal names:
+To find accounts with service principal names:
 
 ```PowerShell
 
 Get-ADUser -Filter * -Properties servicePrincipalName | where {$_.servicePrincipalName -ne $null}
 
 ```
 
-To find accounts with passwords that are set to never expire:
+To find accounts with passwords that never expire:
 
 ```PowerShell
 
 Get-ADUser -Filter * -Properties PasswordNeverExpires | where {$_.PasswordNeverExpires -eq $true}
 
 ```
 
-You can also audit access to sensitive resources, and archive audit logs to a security information and event management (SIEM) system. By using systems such as Azure Log Analytics or Microsoft Sentinel, you can search for and analyze and service accounts.
+You can audit access to sensitive resources, and archive audit logs to a security information and event management (SIEM) system. By using Azure Log Analytics or Microsoft Sentinel, you can search for and analyze service accounts.
 
-## Assess the security of on-premises user accounts
+## Assess on-premises user account security
 
-You can assess the security of on-premises user accounts that are being used as service accounts by using the following criteria:
+Use the following criteria to assess the security of on-premises user accounts used as service accounts:
 
-* What is the password management policy?  
-* Is the account a member of any privileged groups?  
-* Does the account have read/write permissions to important resources?
+* Password management policy
+* Accounts with membership in privileged groups
+* Read/write permissions for important resources
 
 ### Mitigate potential security issues
 
-Potential security issues and their mitigations for on-premises user accounts are summarized in the following table:
+See the following table for potential on-premises user account security issues and their mitigations:
 
 | Security issue | Mitigation |
 | - | - |
-| Password management.| <li>Ensure that password complexity and password change are governed by a robust process that includes regular updates and strong password requirements.<li>Coordinate password changes with a password update to minimize service downtime. |
-| The account is a member of privileged groups.| <li>Review group memberships.<li>Remove the account from privileged groups.<li>Grant the account only the rights and permissions it requires to run its service (consult with service vendor). For example, you might be able to deny sign-in locally or deny interactive sign-in. |
-| The account has read/write permissions to sensitive resources.| <li>Audit access to sensitive resources.<li>Archive audit logs to a SIEM (Azure Log Analytics or Microsoft Sentinel) for analysis.<li>Remediate resource permissions if an undesirable level of access is detected. |
-| | |
-
+| Password management| - Ensure password complexity and password change are governed by regular updates and strong password requirements</br> - Coordinate password changes with a password update to minimize service downtime |
+| The account is a member of privileged groups| - Review group membership</br> - Remove the account from privileged groups</br> - Grant the account rights and permissions to run its service (consult with service vendor)</br> - For example, deny sign-in locally or interactive sign-in|
+| The account has read/write permissions to sensitive resources| - Audit access to sensitive resources</br> - Archive audit logs to a SIEM: Azure Log Analytics or Microsoft Sentinel</br> - Remediate resource permissions if you detect an undesirable access levels |
 
 ## Move to more secure account types