In this article you will learn the basics of managed service accounts in Windows Server 2008 R2.

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:

Managed Service Accounts - The get-adserviceaccount cmdlet

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:

Managed Service Accounts - Viewing MSAs in Active Direcotry Users and Computers

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:

Managed Service Accounts - Assigning an MSA to a service

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:

Managed Service Accounts - Services message box

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.

Managed Serviced Accounts - MSA-related Windows PowerShell 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.

0
9 Comments
  1. Dave 10 years ago

    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?

    0

  2. techibee.com 10 years ago

    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.

    0

  3. Tim Warner 10 years ago

    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

    0

  4. Dennis 10 years ago

    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

    0

  5. Dave 10 years ago

    Thanks! That all helps and makes sense actually.

    0

  6. Jeff McJunkin 10 years ago

    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.

    0

  7. Jeff, that was my fault. I added the correct screenshot. Thanks for the hint!

    0

  8. 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 🙂

    +1

  9. techibee.com 9 years ago

    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.

    0

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account