Tag Archives: service accounts

Step-by-Step Guide to work with Group Managed Service Accounts (gMSA) (PowerShell Guide)

In one of my previous blog posts I talked about managed service accounts. Before start on this I really recommend you to read it to have better understanding. It can find on http://www.rebeladmin.com/2018/01/active-directory-managed-service-accounts-powershell-guide/ . As I explained in there one managed service account only can use with one computer. But there are operation requirements which required to share same service account in multiple hosts. Microsoft network load balancer, IIS server farms are good example for these. All the hosts in these server groups required to use same service principal for authentications. Group Managed service accounts provides the same functionalities as managed service accounts but its extend its capabilities to host group levels. This is first introduced with windows server 2012. 

Group managed service accounts got following capabilities,

No Password Management 

Supports to share across multiple hosts

Can use to run schedule tasks (Managed service accounts do not support to run schedule tasks)

It is uses Microsoft Key Distribution Service (KDC) to create and manage the passwords for the gMSA. 

Key Distribution Service was introduced with the windows server 2012. KDS shares a secret (root Key ID) among all the KDS instance in the domain. This value will change periodically. When gMSA required a password, windows server 2012 domain controller will be generated password based on common algorithm which includes root key ID. Then all the hosts which shares the gMSA will query from domain controllers to retrieve the latest password. 

Requirements for gMSA

Windows server 2012 or higher forest level

Widows server 2012 or higher domain member servers (Windows 8 or upper domain joined computers also supported)

64-bit architecture to run PowerShell command to manage gMSA

Tip – gMSA not supported for the Failover Clustering setup. But it is supported for services which is run upon Failover clusters. 

In order to start the configuration process, we need to create KDS root key. This need to run from domain controller with domain admin or enterprise admin privileges. 

Add-KdsRootKey –EffectiveImmediately

Once this is executed, it has default 10 hours’ time limit to replicate it to all the domain controllers and start response to gMSA requests. In testing environment with one domain controller, it can force to remove this waiting time and start to response gMSA immediately. This is NOT recommended for production environment. 

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

After that we can create the first gMSA account. First I have created an AD group “IISFARM” and add all my IIS servers to it. This farm will be using the new gMSA account. 

New-ADServiceAccount "Mygmsa1" -DNSHostName "web.rebeladmin.com" –PrincipalsAllowedToRetrieveManagedPassword "IISFARM"

In above Mygmsa1 is the service account and web.rebeladmin.com is the FQDN of the service. Once its processed we can verify the new account using,

Get-ADServiceAccount “Mygmsa1”

gmsa1

Next step is to install it on server in IIS Farm. It needs active directory PowerShell module to run it. It can be install using RSAT. 

Install-ADServiceAccount -Identity "Mygmsa1"

Tip – If you created the server group recently and add the host, you need to restart the host computer to reflect the group membership. Otherwise above command will fail. 

Once its executed we can test the service account by running,

Test-ADServiceAccount " Mygmsa1"

gmsa2

Similar to managed service account, when you configure the gMSA with any service, leave the password as blank. 

Uninstall Service Account

There can be requirements to remove the managed service accounts. This can be done by executing, 

Remove-ADServiceAccount –identity “Mygmsa1”

Above command will remove the service account Mygmsa1. This is applying to both type of managed service accounts. 

This marks the end of this blog post. Hope this was useful. If you have any questions feel free to contact me on rebeladm@live.com also follow me on twitter @rebeladm to get updates about new blog posts. 

Service Accounts

In an organization there can be lot of applications, services running to serve its user base. Some time when you setup an application services it asking you to use a service account with certain permissions.

In a computer normally we can run application as Local Service, Network Service or Local System. Also if required you can use a user account setup on the domain or local computer.

service1

Traditional Service Account

Well in past (before server 2008 R2) a service account is nothing but a user account. As you know by default a typical user account password expires (in domain it’s depend on group policies), if it’s happens to a service account, the service or application will stop running as it can’t authenticate. So what usually do is create a user account and set password “not to expire”. So it’s more vulnerable. 

service2

Managed Service Accounts

Microsoft introduce Managed Server Accounts (MSAs) with windows server 2008 R2 to address the issues with traditional service accounts.

In traditional service account its night mare to handle the password changes. But with MSA it will automatically will change the password. In AD DS it will store the MSA object as msDS-ManagedServiceAccount. However MSAs are cannot be use between multiple computers or in cluster environment. MSA uses a complex, random, 240-character password and change that automatically when it reach the domain or computer password expire date. By default its 30 days’ time.  It also can’t be locked out and can’t use for interactive logins. Mainly the benefits of MSAs are automatic password change and simplified SPN (Service Principal Name) management.

In AD DS, MSA’s will stored under CN=Managed Service Accounts, DC=<domain>, DC=<com>, Container.

service3

In order to run MSAs you need to have following in your environment,
• Windows server 2008 R2 or later domain controller
• AD module for powershell
• .NET framework 3.5

Let’s see how we can create the MSA

1) Load the powershell cmd with domain administrator privileges

service4

2) To create service account,
New-ADServiceAccount –Name <MSA_Name> –DNSHostname <DNS name of Domain_Controller>

So in my demo-
New-ADServiceAccount –Name testmsa1 –DNSHostname DCM1.canitpro.local

service5

3) Then we need to associate it with the computer object

Add-ADComputerServiceAccount –identity <Host_Computer_Name> -ServiceAccount <MSA_Name>

In my demo I associate it with computer DCM1

Add-ADComputerServiceAccount –identity DCM1 -ServiceAccount testmsa1

service6

4) Then we need to install the MSA in hostcomputer.

Install-ADServiceAccount –Identity <MSA_Name>

In my demo its

Install-ADServiceAccount –Identity testmsa1

Now we can use it to assign for service. If you go to AD now we can see the new account under MSA OU

service7

If you have any question feel free to contact me on rebeladm@live.com