- Azure PowerShell vs. Azure CLI - Wed, Mar 15 2023
- Use Azure Storage for backup - Thu, Feb 23 2023
- Azure Data Studio vs. SQL Server Management (SSMS) - Wed, Feb 8 2023
Here’s the situation: You are called into consult for a client, and in examining their IT infrastructure you observe no organization as to how service accounts are deployed. For instance, some line-of-business (LOB) applications are using the domain Administrator as their service account identity, while others use the Local Service or Network Service identity.
Recently, the client began associating application services with dedicated domain user service accounts. However, because domain password policy forces password changes every 60 days, the manual reassignment of service account passwords created organizational headaches for the IT support staff.
How can you resolve this mess of a real-world situation?
Introducing Managed Service Accounts
In Windows Server 2008 R2, we finally have a solution to the problem of reconciling service accounts with Active Directory password policy: the Managed Service Account, or MSA.
When you define an MSA, you leave the account’s password to Windows. Thus, MSAs interoperate just fine with your organizational password policies. When it comes time to change the MSA password, Windows takes care of that for you, automatically generating a password that meets any complexity requirements you may have mandated.
As wonderful and convenient as MSAs are (and they are, trust me), we need to always keep in mind the IT security principle of least privilege. In other words, we must be careful not to assign permissions, either explicitly or implicitly, to the MSA account that are beyond the required access scope of that account.
Creating Managed Service Accounts
We use Windows PowerShell 2.0 to create and manage MSAs. From an elevated command prompt, type powershell to enter the Windows PowerShell environment.
Next, type import-module activedirectory to load the Active Directory PowerShell cmdlet library.
We use the new-adserviceaccount cmdlet to define a new MSA. For instance, the following statement creates an MSA named testmsa and enables the account for use:
PS>new-adserviceaccount –Name testmsa –Enabled $true
To verify that the MSA has been created and is "ready for action," so to speak, run the get-adserviceaccount cmdlet. Sample output from this cmdlet is shown in Figure 1:
The get-adserviceaccount cmdlet
NOTE: Windows appends a dollar sign ($) to the MSA account name. Therefore, an MSA named testmsa appears in the computer’s SAM or Active Directory as testmsa$.
We can also fetch MSA properties from Active Directory Users and Computers. Open the tool, click View > Advanced Features to display advanced features, and expand the Managed Service Accounts container. This is shown in Figure 2:
Viewing MSAs in Active Direcotry Users and Computers
Using Managed Service Accounts
Once they are defined, we can associate MSAs with applications and services by using any of the traditional methods with which you are familiar.
For instance, you can open the Service Control Manager, double-click a service, and navigate to the Log On tab to browse Active Directory for an MSA. This procedure is shown in Figure 3:
Assigning an MSA to a service
NOTE: Be sure to leave the Password and Confirm password fields empty. Remember, we are delegating account password management to Windows.
Once you apply the change, you will see a Services message box informing you that the designated MSA has been granted the Log On as a Service user right. This message box is shown in Figure 4:
Services message box
Taking the next step
From Windows PowerShell, you can issue the statement get-command –noun *adserv* to retrieve a list of all MSA-related cmdlets.
MSA-related Windows PowerShell cmdlets
You can then run help <cmdname> to obtain online help concerning syntax and usage concerning that specific cmdlet.
Conclusion
If you are like me, then you find that the Managed Service Account capability of Windows Server 2008 R2 is an administrative godsend. Windows PowerShell is increasingly becoming a "must have" skill set for Windows administrators; please see my 4sysops blog posts on the subject if you’d like a general introduction to Windows PowerShell.
How do MSA’s differ from computer accounts? I’ve always used computer$ accounts (local service if on local host) to run scheduled tasks, etc. Are MSA’s essentially the same thing?
Very good question Dave. I also would like to know the answer. Looking at the limitations(can’t be assigned to multiple computers) of MSA, it is unclear why we need them.
Hi Dave,
This is from Microsoft (ref: http://technet.microsoft.com/en-us/library/dd367859%28WS.10%29.aspx):
“On a local computer, an administrator can configure the application to run as Local Service, Network Service, or Local System. These service accounts are simple to configure and use, but they are typically shared among multiple applications and services and cannot be managed on a domain level.”
By contrast, if we configure an application to use a domain MSA, we can isolate the privileges for the app, and benefit from the OS managing the account password.
Does this make sense?
Thanks,
Tim
there are some limitations i know of, like not be able to use MSA on clusters.
i think its good practice to always explain the limitations of new technoly, so this article seems to explain more limitations of MSA;
http://blogs.technet.com/b/askds/archive/2009/09/10/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting.aspx
Thanks! That all helps and makes sense actually.
Under “Taking the next step,” it looks like you accidentally repeated the graphic used for Figure 1. Not a big deal, but worth fixing if it was a simple upload mistake.
Thanks for the write-up! It’s good to see MSA’s being used and the actual steps involved.
Jeff, that was my fault. I added the correct screenshot. Thanks for the hint!
A couple of things this article doesn’t mention that need to be done before you can actually use an MSA: You must associate the MSA with a specific computer account in AD (by using the Add-ADComputerServiceAccount cmdlet) and you must install the MSA on the computer that you want to use it on (by using the Install-ADServiceAccount cmdlet). If you don’t want to use Powershell, I’m going to be releasing a free GUI tool for creating, installing, and configuring MSAs in the next couple of days. I’ll be submitting an article on it to 4sysops shortly 🙂
MS enhanced Managed service accounts in windows 2012 and created a new principal called gMSA(Group Managed Service Accounts). Now services running on multiple hosts can run under the same gMSA account.