You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# Secure user-based service accounts in Active Directory
19
19
20
-
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).
20
+
On-premises user accounts were 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).
21
21
22
-
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.
22
+
You can investigate moving your service an Azure service account, such as a managed identity or a service principal.
23
23
24
-
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.
24
+
Learn more:
25
25
26
-
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.
26
+
*[What are managed identities for Azure resources?](../managed-identities-azure-resources/overview.md)
27
+
*[Securing service principals in Azure Active Directory](service-accounts-principal.md)
28
+
29
+
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.
30
+
31
+
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.
27
32
28
33
## Benefits and challenges
29
34
30
-
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.
35
+
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.
31
36
32
-
The challenges associated with the use of on-premises user accounts are summarized in the following table:
37
+
The challenges of on-premises user accounts are summarized in the following table:
33
38
34
39
| Challenge | Mitigation |
35
40
| - | - |
36
-
| 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. |
37
-
| 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. |
38
-
|||
39
-
41
+
| Password management is manual and leads to weaker security and service downtime| - Ensure regular password complexity and that changes are governed by a process that maintains strong passwords</br> - Coordinate password changes with a service password, which helps reduce service downtime|
42
+
| 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 |
40
43
41
44
## Find on-premises user accounts used as service accounts
42
45
43
-
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.
44
-
45
-
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.”
46
+
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.
46
47
47
-
You can use some of the following criteria to find these service accounts. However, this approach might not find all accounts, such as:
48
+
Use some of the following criteria to find service accounts. However, this approach might not find accounts:
48
49
49
-
*Accounts that are trusted for delegation.
50
-
*Accounts with service principal names.
51
-
*Accounts with passwords that are set to never expire.
50
+
*Trusted for delegation
51
+
*With service principal names
52
+
*With passwords that never expire
52
53
53
-
To find the on-premises user accounts you've created for services, you can run the following PowerShell commands.
54
+
To find the on-premises user accounts used for services, run the following PowerShell commands:
To find accounts that have service principal names:
64
+
To find accounts with service principal names:
64
65
65
66
```PowerShell
66
67
67
68
Get-ADUser -Filter * -Properties servicePrincipalName | where {$_.servicePrincipalName -ne $null}
68
69
69
70
```
70
71
71
-
To find accounts with passwords that are set to never expire:
72
+
To find accounts with passwords that never expire:
72
73
73
74
```PowerShell
74
75
75
76
Get-ADUser -Filter * -Properties PasswordNeverExpires | where {$_.PasswordNeverExpires -eq $true}
76
77
77
78
```
78
79
79
-
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.
80
+
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.
80
81
81
-
## Assess the security of on-premises user accounts
82
+
## Assess on-premises user account security
82
83
83
-
You can assess the security of on-premises user accounts that are being used as service accounts by using the following criteria:
84
+
Use the following criteria to assess the security of on-premises user accounts used as service accounts:
84
85
85
-
*What is the password management policy?
86
-
*Is the account a member of any privileged groups?
87
-
*Does the account have read/write permissions to important resources?
86
+
*Password management policy
87
+
*Accounts with membership in privileged groups
88
+
*Read/write permissions for important resources
88
89
89
90
### Mitigate potential security issues
90
91
91
-
Potential security issues and their mitigations for on-premises user accounts are summarized in the following table:
92
+
See the following table for potential on-premises user account security issues and their mitigations:
92
93
93
94
| Security issue | Mitigation |
94
95
| - | - |
95
-
| 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. |
96
-
| 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. |
97
-
| 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. |
98
-
|||
96
+
| 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 |
97
+
| 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|
98
+
| 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 undesirable access levels |
99
99
100
+
## Secure account types
100
101
101
-
## Move to more secure account types
102
-
103
-
Microsoft doesn't recommend that you use on-premises user accounts as service accounts. For any service that uses this type of account, assess whether it can instead be configured to use a gMSA or an sMSA.
104
-
105
-
Additionally, evaluate whether the service itself could be moved to Azure so that more secure service account types can be used.
102
+
Microsoft doesn't recommend use of on-premises user accounts as service accounts. For services that use this account type, assess if it can be configured to use a gMSA or an sMSA. In addition, evaluate if you can move the service to Azure to enable use of safer account types.
106
103
107
104
## Next steps
108
105
109
-
To learn more about securing service accounts, see the following articles:
106
+
To learn more about securing service accounts:
110
107
111
-
*[Introduction to on-premises service accounts](service-accounts-on-premises.md)
108
+
*[Securing on-premises service accounts](service-accounts-on-premises.md)
112
109
*[Secure group managed service accounts](service-accounts-group-managed.md)
113
110
*[Secure standalone managed service accounts](service-accounts-standalone-managed.md)
0 commit comments