Last week I was in UK teaching the full bundle of the courses for the MCSA Windows Server 2012 and we discussed a lot with the students about the new type of Managed Service Accounts, now called Group Managed Service Accounts. It seems that the students were satisified, so they brought in class a small guitar (which I don’t remember the exact name now), and here it is:

So I think it’s a good idea to talk a bit about this new type of service accounts. These are particularly useful of you want to use them on the services that you install. What we’ve been doing all these years was to create the account for the service and specify that the password should never expire, but you already know that this is a security risk.

The problem with the first version of Managed Service Accounts on Windows Server 2008 R2 was that you had to create the accounts in AD, but then you had to import them on every server, so they couldn’t be used on server farms. Now this is possible, but there are a few things to consider first.

• 
  There is a new security principal called gMSA
  
• 
  Services now can run on multiple servers and use the same gMSA
  
• 
  … But you need Windows Server 2012 DCs
  
• 
  Passwords are created by Group Key Distribution Service (GKDS), available on every Windows Server 2012 DC
  
• 
  Member servers get the password from the GKDS
  
• 
  Passwords change every 30 days by default (but you can change this during the account creation)
  

The steps for creating a new gMSA are:

1. Create the KDS Root Key (only once per domain). This is used by the KDS service on DCs (along with other information) to generate passwords.

From a Windows Server 2012 DC you use Powershell and you type:

Add-KDSRootKey –EffectiveImmediately

EffectiveImmediately might take a long time though, as you have to be sure that the information is replicated to every domain controller. There is a trick to force the process to go faster, but use it only in lab environments. You should run:

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

2. Create and configure the gMSA

It’s a good idea to create a security group in AD and add all the computer accounts that you want to use the gMSA into that group. Next you shoud create the gMSA:

New-ADServiceAccount -name <ServiceAccountName> -DNSHostName <fqdn> -PrincipalsAllowedToRetrieveManagedPassword <group> -ServicePrincipalNames <SPN1,SPN2,…>

and I will specify that I want only my DCs to use the account:

If you get an error here you probably forgot to create the KDSRootKey or you should wait a bit more, go up to step 1 please. If everything went as expected, you should be able to see the new gMSA using AD Admin Center:

3. Install and test the gMSA on a host

Try to type these two commands on the host that you plan to use the gMSA:

Install-AdServiceAccount <gMSA>

Test-AdServiceAccount <gMSA>

Next, if you are going to use the gMSA for a service, an IIS Application Pool, or SQL 2012, you would simply plug it in the Logon/Credentials UI of the service. Don’t to append a $ after the account name, and leave the password blank:

Usually the account will get the “Log On As a Service” right, and once the service is started, the password will be automatically retrieved from a Windows Server 2012 DC.

Question: Can I use a gMSA for a scheduled task?

Answer: Yes you can, but is a little bit tricky…

Unfortunately you can’t use the Task Scheduler UI, so PowerShell only…

Practically we need to define an Action (what), a Trigger (when) and a Principal (under which identity):

$action = New-ScheduledTaskAction “c:tasksmytask.cmd”

$trigger = New-ScheduledTaskTrigger -At 10:00 -Daily

$principal = New-ScheduledTaskPrincipal -UserID contosomysrvaccount$ -LogonType Password

Important: After the –LogonType switch you type the word Password, and not an actual password. This tells the scheduled task to retrieve the actual password for the gMSA from a domain controller.

Then you need to run the Register-ScheduledTask cmdlet, so to create the task, using the variables that we already created before:

Register-ScheduledTask myAdminTask –Action $action –Trigger $trigger –Principal $principal

and you should see that the task was created:

Important: If you use the gMSA to run scheduled batch jobs, the account must have the “Log on as a batch job” on the machine, but you may also need to make this account a member of the Local Admins group, so to be able to perform the task.

And don’t forget: if you use Windows 8 or Windows 8.1, you can have access to all these articles by downloading my free blog reader app from the Windows Store! If you do, please give me a rating!

Next week I’ll be in Belgrade, presenting at Microsoft Sinergija 2013 a session about Windows Server 2012 R2 Work Folders, a smart way to access your files from anywhere.

See you next week!

Source