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
*[User accounts that function as service accounts](service-accounts-user-on-premises.md)
22
+
* Group-managed service accounts (gMSAs)
23
+
*[Secure group managed service accounts](service-accounts-group-managed.md)
24
+
* Standalone managed service accounts (sMSAs)
25
+
*[Secure standalone managed service accounts](service-accounts-standalone-managed.md)
26
+
* On-premises computer accounts
27
+
*[Secure on-premises computer accounts with Active Directory](service-accounts-computer.md)
28
+
* User accounts functioning as service accounts
29
+
*[Secure user-based service accounts in Active Directory](service-accounts-user-on-premises.md)
26
30
31
+
Part of service account governance includes:
27
32
28
-
It is critical to govern service accounts closely so that you can:
33
+
* Protecting them, based on requirements and purpose
34
+
* Managing account lifecycle, and their credentials
35
+
* Assessing service accounts, based on risk and permissions
36
+
* Ensuring Active Directory (AD) and Azure Active Directory (Azure AD) have no unused service accounts, with permissions
29
37
30
-
* Protect them based on their use-case requirements and purpose.
31
-
* Manage the lifecycle of the accounts and their credentials.
32
-
* Assess them based on the risk they'll be exposed to and the permissions they carry.
33
-
* Ensure that Active Directory and Azure Active Directory have no stale service accounts with potentially far-reaching permissions.
38
+
## New service account principles
34
39
35
-
## Principles for creating a new service account
36
-
37
-
When you create a service account, understand the considerations listed in the following table:
40
+
When you create service accounts, consider the information in the following table.
38
41
39
42
| Principle| Consideration |
40
43
| - |- |
41
-
| Service account mapping| Tie the service account to a single service, application, or script. |
42
-
| Ownership| Ensure that there's an owner who requests and assumes responsibility for the account. |
43
-
| Scope| Define the scope clearly, and anticipate usage duration for the service account. |
44
-
| Purpose| Create service accounts for a single, specific purpose. |
45
-
| Permissions | Apply the principle of *least permission*. To do so:<li>Never assign permissions to built-in groups, such as administrators.<li>Remove local machine permissions, where appropriate.<li>Tailor access, and use Active Directory delegation for directory access.<li>Use granular access permissions.<li>Set account expirations and location-based restrictions on user-based service accounts. |
46
-
| Monitor and audit use| Monitor sign-in data, and ensure that it matches the intended usage. Set alerts for anomalous usage. |
47
-
|||
48
-
49
-
### Set restrictions for user accounts
44
+
| Service account mapping| Connect the service account to a service, application, or script |
45
+
| Ownership| Ensure there's an account owner who requests and assumes responsibility |
46
+
| Scope| Define the scope, and anticipate usage duration|
47
+
| Purpose| Create service accounts for one purpose |
48
+
| Permissions | Apply the principle of least permission:<li>Don't assign permissions to built-in groups, such as administrators<li>Remove local machine permissions, where feasible<li>Tailor access, and use AD delegation for directory access<li>Use granular access permissions<li>Set account expiration and location restrictions on user-based service accounts |
49
+
| Monitor and audit use| <li>Monitor sign-in data, and ensure it matches the intended usage <li>Set alerts for anomalous usage |
50
50
51
-
For user accounts that are used as service accounts, apply the following settings:
51
+
### User account restrictions
52
52
53
-
*[**Account expiration**](/powershell/module/activedirectory/set-adaccountexpiration?view=winserver2012-ps&preserve-view=true): Set the service account to automatically expire at a set time after its review period, unless you've determined that the account should continue.
53
+
For user accounts used as service accounts, apply the following settings:
54
54
55
-
***LogonWorkstations**: Restrict permissions where the service account can sign in. If it runs locally on a machine and accesses only resources on that machine, restrict it from signing in anywhere else.
56
-
57
-
*[**Cannot change password**](/powershell/module/activedirectory/set-aduser): Prevent the service account from changing its own password by setting the parameter to true.
55
+
* Account expiration - set the service account to automatically expire, after its review period, unless the account can continue
56
+
* LogonWorkstations - restrict service account sign-in permissions
57
+
* If it runs locally and accesses resources on the machine, restrict it from signing in elsewhere
58
+
* Can't change password - set the parameter to **true** to prevent the service account from changing its own password
58
59
59
-
## Build a lifecycle management process
60
-
61
-
To help maintain the security of your service accounts, you must manage them from the time you identify the need until they're decommissioned.
60
+
## Lifecycle management process
62
61
63
-
For lifecycle management of service accounts, use the following process:
62
+
To help maintain service account security, manage them from inception to decommission. Use the following process:
64
63
65
-
1. Collect usage information for the account.
66
-
1. Move the service account and app to the configuration management database (CMDB).
67
-
1. Perform risk assessment or a formal review.
68
-
1. Create the service account and apply restrictions.
69
-
1. Schedule and perform recurring reviews. Adjust permissions and scopes as necessary.
70
-
1. Deprovision the account when appropriate.
64
+
1. Collect account usage information.
65
+
2. Move the service account and app to the configuration management database (CMDB).
66
+
3. Perform risk assessment or a formal review.
67
+
4. Create the service account and apply restrictions.
68
+
5. Schedule and perform recurring reviews.
69
+
6. Adjust permissions and scopes as needed.
70
+
7. Deprovision the account.
71
71
72
-
### Collect usage information for the service account
72
+
### Collect service account usage information
73
73
74
-
Collect relevant business information for each service account. The following table lists the minimum amount of information to collect, but you should collect everything that's necessary to make the business case for each account's existence.
74
+
Collect relevant information for each service account. The following table lists the minimum information to collect. Obtain what's needed to validate each account.
75
75
76
76
| Data| Description |
77
77
| - | - |
78
-
| Owner| The user or group that's accountable for the service account |
78
+
| Owner| The user or group accountable for the service account |
79
79
| Purpose| The purpose of the service account |
80
-
| Permissions (scopes)| The expected set of permissions |
81
-
| CMDB links| The cross-link service account with the target script or application and owners |
82
-
| Risk| The risk and business impact scoring, based on the security risk assessment |
83
-
| Lifetime| The anticipated maximum lifetime for enabling the scheduling of account expiration or recertification |
84
-
|||
80
+
| Permissions (scopes)| The expected permissions |
81
+
| CMDB links| The cross-link service account with the target script or application, and owners |
82
+
| Risk| The results of a security risk assessment |
83
+
| Lifetime| The anticipated maximum lifetime to schedule account expiration or recertification |
85
84
86
-
Ideally, you want to make the request for an account self-service, and require the relevant information. The owner can be an application or business owner, an IT member, or an infrastructure owner. By using a tool such as Microsoft Forms for this request and associated information, you'll make it easier to port it to your CMDB inventory tool if the account is approved.
85
+
Make the account request self-service, and require the relevant information. The owner is an application or business owner, an IT team member, or an infrastructure owner. You can use Microsoft Forms for requests and associated information. If the account is approved, use Microsoft Forms to port it to a configuration management databases (CMDB) inventory tool.
87
86
88
-
### Onboard service account to CMDB
87
+
### Service accounts and CMDB
89
88
90
-
Store the collected information in a CMDB-type application. In addition to the business information, include all dependencies on other infrastructure, apps, and processes. This central repository makes it easier to:
89
+
Store the collected information in a CMDB application. Include dependencies on infrastructure, apps, and processes. Use this central repository to:
91
90
92
-
* Assess risk.
93
-
* Configure the service account with the required restrictions.
94
-
*Understand any relevant functional and security dependencies.
95
-
* Conduct regular reviews for security and continued need.
96
-
* Contact the owners for reviewing, retiring, and changing the service account.
91
+
* Assess risk
92
+
* Configure the service account with restrictions
93
+
*Ascertain functional and security dependencies
94
+
* Conduct regular reviews for security and continued need
95
+
* Contact the owner to review, retire, and change the service account
97
96
98
-
Consider a service account that's used to run a website and has permissions to connect to one or more Human Resources (HR) SQL databases. The information stored in your CMDB for the service account, including example descriptions, is listed in the following table:
97
+
#### Example HR scenario
98
+
99
+
An example is a service account that runs a website with permissions to connect to Human Resources SQL databases. The information in the service account CMDB, including examples, is in the following table:
99
100
100
-
|Data | Example description|
101
+
|Data | Example|
101
102
| - | - |
102
-
| Owner, Deputy|John Bloom, Anna Mayers|
103
-
| Purpose| Run the HR webpage and connect to HR databases. Can impersonate end users when accessing databases. |
104
-
| Permissions, scopes| HR-WEBServer: sign in locally; run web page<br>HR-SQL1: sign in locally; read permissions on all HR databases<br>HR-SQL2: sign in locally; read permissions on Salary database only |
105
-
| Cost Center| 883944|
106
-
| Risk Assessed| Medium; Business Impact: Medium; private information; Medium |
107
-
| Account Restrictions| Log on to: only aforementioned servers; Cannot change password; MBI-Password Policy; |
103
+
| Owner, Deputy|Name, Name|
104
+
| Purpose| Run the HR webpage and connect to HR databases. Impersonate end users when accessing databases. |
105
+
| Permissions, scopes| HR-WEBServer: sign in locally; run web page<br>HR-SQL1: sign in locally; read permissions on HR databases<br>HR-SQL2: sign in locally; read permissions on Salary database only |
106
+
| Cost center| 123456|
107
+
| Risk assessed| Medium; Business Impact: Medium; private information; Medium |
108
+
| Account restrictions| Sign in to: only aforementioned servers; Can't change password; MBI-Password Policy; |
108
109
| Lifetime| Unrestricted |
109
-
| Review Cycle| Biannually (by owner, by security team, by privacy) |
110
-
|||
111
-
112
-
### Perform a risk assessment or formal review of service account usage
110
+
| Review cycle| Biannually: By owner, security team, or privacy team |
113
111
114
-
Suppose your account is compromised by an unauthorized source. Assess the risks the account might pose to its associated application or service and to your infrastructure. Consider both direct and indirect risks.
112
+
### Service account risk assessments or formal reviews
115
113
116
-
* What would an unauthorized user gain direct access to?
117
-
* What other information or systems can the service account access?
118
-
* Can the account be used to grant additional permissions?
119
-
* How will you know when the permissions change?
114
+
If your account is compromised by an unauthorized source, assess the risks to associated applications, services, and infrastructure. Consider direct and indirect risks:
120
115
121
-
After you've conducted and documented the risk assessment, you might find that the risks have an impact on:
116
+
* Resources an unauthorized user can gain access to
117
+
* Other information or systems the service account can access
118
+
* Permissions the account can grant
119
+
* Indications or signals when permissions change
122
120
123
-
* Account restrictions.
124
-
* Account lifetime.
125
-
* Account review requirements (cadence and reviewers).
121
+
After the risk assessment, documentation likely shows that risks affect account:
122
+
123
+
* Restrictions
124
+
* Lifetime
125
+
* Review requirements
126
+
* Cadence and reviewers
126
127
127
128
### Create a service account and apply account restrictions
128
129
129
-
Create a service account only after you've completed the risk assessment and documented the relevant information in your CMDB. Align the account restrictions with the risk assessment. Consider the following restrictions when they're relevant to your assessment:
130
-
131
-
* For all user accounts that you use as service accounts, define a realistic, definite end date. Set the date by using the **Account Expires** flag. For more information, see [Set-ADAccountExpiration](/powershell/module/activedirectory/set-adaccountexpiration).
132
-
133
-
* Login to the [LogonWorkstation](/powershell/module/activedirectory/set-aduser).
* Account creation in an [organizational unit location](/windows-server/identity/ad-ds/plan/delegating-administration-of-account-ous-and-resource-ous) that ensures management only for allowed users.
138
-
139
-
* Setting up and collecting auditing [that detects changes](/windows/security/threat-protection/auditing/audit-directory-service-changes) to the service account, and [service account use](https://www.manageengine.com/products/active-directory-audit/how-to/audit-kerberos-authentication-events.html).
140
-
141
-
When you're ready to put the service account into production, grant access to it more securely.
142
-
143
-
### Schedule regular reviews of service accounts
144
-
145
-
Set up regular reviews of service accounts that are classified as medium and high risk. Reviews should include:
146
-
147
-
* Owner attestation to the continued need for the account, and a justification of permissions and scopes.
148
-
149
-
* Review by privacy and security teams, including an evaluation of upstream and downstream connections.
130
+
> [!NOTE]
131
+
> Create a service account after the risk assessment, and document the findings in a CMDB. Align account restrictions with risk assessment findings.
132
+
133
+
Consider the following restrictions, although some might not be relevant to your assessment.
134
+
135
+
* For user accounts used as service accounts, define a realistic end date
136
+
* Use the **Account Expires** flag to set the date
* Create accounts in an [organizational unit location](/windows-server/identity/ad-ds/plan/delegating-administration-of-account-ous-and-resource-ous) that ensures only some users will manage it
141
+
* Set up and collect auditing that detects [service account changes](/windows/security/threat-protection/auditing/audit-directory-service-changes), and [service account usage](https://www.manageengine.com/products/active-directory-audit/how-to/audit-kerberos-authentication-events.html)
142
+
* Grant account access more securely before it goes into production
143
+
144
+
### Service account reviews
145
+
146
+
Schedule regular service account reviews, especially those classified Medium and High Risk. Reviews can include:
150
147
151
-
* Data from audits, ensuring that it's being used only for its intended purposes.
148
+
* Owner attestation of the need for the account, with justification of permissions and scopes
149
+
* Privacy and security team reviews that include upstream and downstream dependencies
150
+
* Audit data review
151
+
* Ensure the account is used for its stated purpose
152
152
153
153
### Deprovision service accounts
154
154
155
-
In your deprovisioning process, first remove permissions and monitoring, and then remove the account, if appropriate.
156
-
157
-
You deprovision service accounts when:
158
-
159
-
* The script or application that the service account was created for is retired.
155
+
Deprovision service accounts at the following junctures:
160
156
161
-
* The function within the script or application, which the service account is used for (for example, access to a specific resource), is retired.
157
+
* Retirement of the script or application for which the service account was created
158
+
* Retirement of the script or application function, for which the service account was used
159
+
* Replacement of the service account for another
162
160
163
-
* The service account has been replaced with a different service account.
164
-
165
-
After you've removed all permissions, remove the account by doing the following:
166
-
167
-
1. When the associated application or script is deprovisioned, monitor the sign-ins and resource access for the associated service accounts to be sure that they're not being used in another process. If you're sure it's no longer needed, go to next step.
168
-
169
-
1. Disable the service account to prevent sign-in, and ensure that it's no longer needed. Create a business policy for the time during which accounts should remain disabled.
170
-
171
-
1. After the remain-disabled policy is fulfilled, delete the service account.
172
-
173
-
***For MSAs**: [Uninstall the account](/powershell/module/activedirectory/uninstall-adserviceaccount?view=winserver2012-ps&preserve-view=true) by using PowerShell, or delete it manually from the managed service account container.
161
+
To deprovision:
162
+
163
+
1. Remove permissions and monitoring.
164
+
2. Examine sign-ins and resource access of related service accounts to ensure no potential effect on them.
165
+
3. Prevent account sign-in.
166
+
4. Ensure the account is no longer needed (there's no complaint).
167
+
5. Create a business policy that determines the amount of time that accounts are disabled.
168
+
6. Delete the service account.
174
169
175
-
***For computer or user accounts**: Manually delete the account from within Active Directory.
170
+
* MSAs - see, [Uninstall the account](/powershell/module/activedirectory/uninstall-adserviceaccount?view=winserver2012-ps&preserve-view=true). Use PowerShell, or delete it manually from the managed service account container.
171
+
* Computer or user accounts - manually delete the account from Active Directory
176
172
177
173
## Next steps
178
174
179
175
To learn more about securing service accounts, see the following articles:
180
176
181
-
*[Introduction to on-premises service accounts](service-accounts-on-premises.md)
177
+
*[Securing on-premises service accounts](service-accounts-on-premises.md)
182
178
*[Secure group managed service accounts](service-accounts-group-managed.md)
183
179
*[Secure standalone managed service accounts](service-accounts-standalone-managed.md)
0 commit comments