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
Standalone managed service accounts (sMSAs) are managed domain accounts that you use to help secure one or more services that run on a server. They can't be reused across multiple servers. sMSAs provide automatic password management, simplified service principal name (SPN) management, and the ability to delegate management to other administrators.
20
+
Standalone managed service accounts (sMSAs) are managed domain accounts that help secure services running on a server. They can't be reused across multiple servers. sMSAs have automatic password management, simplified service principal name (SPN) management, and delegated management to administrators.
21
21
22
-
In Active Directory, sMSAs are tied to a specific server that runs a service. You can find these accounts listed in the Active Directory Users and Computers snap-in of the Microsoft Management Console.
22
+
In Active Directory (AD), sMSAs are tied to a server that runs a service. You can find accounts in the Active Directory Users and Computers snap-in in Microsoft Management Console.
23
23
24
-
24
+
25
25
26
-
Managed service accounts were introduced with Windows Server 2008 R2 Active Directory Schema, and they require at least Windows Server 2008 R2.
26
+
Managed service accounts were introduced in Windows Server 2008 R2 Active Directory Schema, and they require Windows Server 2008 R2, or later version.
27
27
28
-
## Benefits of using sMSAs
28
+
## sMSA benefits
29
29
30
-
sMSAs offer greater security than user accounts that are used as service accounts. At the same time, to help reduce administrative overhead, they:
30
+
sMSAs have greater security than user accounts used as service accounts. They help reduce administrative overhead:
31
31
32
-
***Set strong passwords**: sMSAs use 240-byte, randomly generated complex passwords. The complexity and length of sMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
32
+
* Set strong passwords - sMSAs use 240-byte, randomly generated complex passwords
33
+
* The complexity minimizes the likelihood of compromise by brute force or dictionary attacks
34
+
* Cycle passwords regularly - Windows changes the sMSA password every 30 days.
35
+
* Service and domain administrators don’t need to schedule password changes or manage the associated downtime
36
+
* Simplify SPN management - SPNs are updated if the domain functional level is Windows Server 2008 R2. The SPN is updated when you:
37
+
* Rename the host computer account
38
+
* Change the host computer domain name server (DNS) name
39
+
* Use PowerShell to add or remove other sam-accountname or dns-hostname parameters
40
+
* See, [Set-ADServiceAccount](/powershell/module/activedirectory/set-adserviceaccount)
33
41
34
-
***Cycle passwords regularly**: Windows automatically changes the sMSA password every 30 days. Service and domain administrators don’t need to schedule password changes or manage the associated downtime.
42
+
## Using sMSAs
35
43
36
-
***Simplify SPN management**: Service principal names are automatically updated if the domain functional level is Windows Server 2008 R2. For instance, the service principal name is automatically updated when you:
37
-
* Rename the host computer account.
38
-
* Change the domain name server (DNS) name of the host computer.
39
-
* Add or remove other sam-accountname or dns-hostname parameters by using [PowerShell](/powershell/module/activedirectory/set-adserviceaccount).
40
-
41
-
## When to use sMSAs
42
-
43
-
sMSAs can simplify management and security tasks. Use sMSAs when you have one or more services deployed to a single server and you can't use a group managed service account (gMSA).
44
+
Use sMSAs to simplify management and security tasks. sMSAs are useful when services are deployed to a server and you can't use a group managed service account (gMSA).
44
45
45
46
> [!NOTE]
46
-
> Although you can use sMSAs for more than one service, we recommend that each service have its own identity for auditing purposes.
47
+
> You can use sMSAs for more than one service, but it's recommended that each service has an identity for auditing.
47
48
48
-
If the creator of the software can’t tell you whether it can use an MSA, you must test your application. To do so, create a test environment and ensure that it can access all required resources. For more information, see [Create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting).
49
+
If the software creator can’t tell you if the applicaiton uses an MSA, test the application. Create a test environment and ensure it accesses required resources.
49
50
50
-
### Assess the security posture of sMSAs
51
+
Learn more: [Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting).
51
52
52
-
sMSAs are inherently more secure than standard user accounts, which require ongoing password management. However, it's important to consider sMSAs’ scope of access as part of their overall security posture.
53
+
### Assess sMSA security posture
53
54
54
-
To see how to mitigate potential security issues posed by sMSAs, refer to the following table:
55
+
Consider the sMSA scope of access as part of the security posture. To mitigate potential security issues, see the following table:
55
56
56
57
| Security issue| Mitigation |
57
58
| - | - |
58
-
| sMSA is a member of privileged groups. | <li>Remove the sMSA from elevated privileged groups, such as Domain Admins.<li>Use the *least privileged* model, and grant the sMSA only the rights and permissions it requires to run its services.<li>If you're unsure of the required permissions, consult the service creator. |
59
-
| sMSA has read/write access to sensitive resources. | <li>Audit access to sensitive resources.<li>Archive audit logs to a Security Information and Event Management (SIEM) program, such as Azure Log Analytics or Microsoft Sentinel, for analysis.<li>Remediate resource permissions if an undesirable level of access is detected. |
60
-
| By default, the sMSA password rollover frequency is 30 days. | You can use group policy to tune the duration, depending on enterprise security requirements. To set the password expiration duration, use the following path:<br>*Computer Configuration\Policies\Windows Settings\Security Settings\Security Options*. For domain member, use **Maximum machine account password age**. |
61
-
|||
62
-
59
+
| sMSA is a member of privileged groups | <li>Remove the sMSA from elevated privileged groups, such as Domain Admins<li>Use the least-privileged model <li> Grant the sMSA rights and permissions to run its services<li>If you're unsure about permissions, consult the service creator|
60
+
| sMSA has read/write access to sensitive resources | <li>Audit access to sensitive resources<li>Archive audit logs to a security information and event management (SIEM) program, such as Azure Log Analytics or Microsoft Sentinel.<li>Remediate resource permissions if an undesirable access is detected |
61
+
| By default, the sMSA password rollover frequency is 30 days | Use group policy to tune the duration, depending on enterprise security requirements. To set the password expiration duration, go to:<br>Computer Configuration>Policies>Windows Settings>Security Settings>Security Options. For domain member, use **Maximum machine account password age**. |
63
62
64
-
65
-
### Challenges with sMSAs
66
-
67
-
The challenges associated with sMSAs are as follows:
63
+
### sMSA challenges
64
+
65
+
Use the following table to associate challenges with mitigations.
68
66
69
67
| Challenge| Mitigation |
70
68
| - | - |
71
-
| sMSAs can be used on a single server only. | Use a gMSA if you need to use the account across servers. |
72
-
| sMSAs can't be used across domains. | Use a gMSA if you need to use the account across domains. |
73
-
| Not all applications support sMSAs. | Use a gMSA if possible. Otherwise, use a standard user account or a computer account, as recommended by the application creator. |
74
-
|||
75
-
69
+
| sMSAs are on a single server | Use a gMSA to use the account across servers |
70
+
| sMSAs can't be used across domains | Use a gMSA to use the account across domains |
71
+
| Not all applications support sMSAs| Use a gMSA, if possible. Otherwise, use a standard user account or a computer account, as recommended by the creator.|
76
72
77
73
## Find sMSAs
78
74
79
-
On any domain controller, run DSA.msc, and then expand the managed service accounts container to view all sMSAs.
75
+
On a domain controller, run DSA.msc, and then expand the managed service accounts container to view all sMSAs.
80
76
81
77
To return all sMSAs and gMSAs in the Active Directory domain, run the following PowerShell command:
82
78
83
79
`Get-ADServiceAccount -Filter *`
84
80
85
-
To return only sMSAs in the Active Directory domain, run the following command:
81
+
To return sMSAs in the Active Directory domain, run the following command:
86
82
87
83
`Get-ADServiceAccount -Filter * | where { $_.objectClass -eq "msDS-ManagedServiceAccount" }`
88
84
89
85
## Manage sMSAs
90
86
91
-
To manage your sMSAs, you can use the following Active Directory PowerShell cmdlets:
87
+
To manage your sMSAs, you can use the following AD PowerShell cmdlets:
92
88
93
89
`Get-ADServiceAccount`
94
90
`Install-ADServiceAccount`
@@ -100,16 +96,17 @@ To manage your sMSAs, you can use the following Active Directory PowerShell cmdl
100
96
101
97
## Move to sMSAs
102
98
103
-
If an application service supports sMSAs but not gMSAs, and you're currently using a user account or computer account for the security context, [Create and install an sMSA](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting) on the server.
99
+
If an application service supports sMSAs, but not gMSAs, and you're using a user account or computer account for the security context, see</br>
100
+
[Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting](/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting).
104
101
105
-
Ideally, you would move resources to Azure and use Azure Managed Identities or service principals.
102
+
If possible, move resources to Azure and use Azure managed identities or service principals.
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, see
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)
0 commit comments