Tag Archives: Managed 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”


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"


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. 

Active Directory Managed Service Accounts (PowerShell Guide)

Services Accounts are recommended to use when install application or services in infrastructure. It is dedicated account with specific privileges which use to run services, batch jobs, management tasks. In most of the infrastructures, service accounts are typical user accounts with “Password never expire” option. Since these service accounts are not been use regularly, Administrators have to keep track of these accounts and their credentials. I have seen in many occasions where engineers face in to issues due to outdated or misplace service account credential details. Pain of it is, if you reset the password of service accounts, you will need to update services, databases, application settings to get application or services up and running again. Apart from it Engineers also have to manage service principle names (SPN) which helps to identify service instance uniquely. 

After considering all these challenges Microsoft has introduced Managed Service Accounts with windows server 2008 R2. These accounts got following features and limitations,

No more password management. It uses a complex, random, 240-character password and change that automatically when it reaches the domain or computer password expire date.

It cannot be lock out or use for interactive login. 

One managed service account only can use in one computer. it cannot be share between multiple computers

Simplified SPN Management – System will automatically change the SPN value if sAMaccount details of the computer change or DNS name property change. 

In order to create Managed service account, we can use following command, I am running this from the domain controller.

New-ADServiceAccount -Name "MyAcc1" -RestrictToSingleComputer

In above command I am creating service account called MyAcc1 and I am restricting it to one computer. 

Next step is associate the service account with the Host REBEL-SRV01 where I am going to use this service account. 

Add-ADComputerServiceAccount -Identity REBEL-SRV01 -ServiceAccount "MyAcc1"

Next step is to install service account in the REBEL-SRV01 server. We need active directory PowerShell module for this. We can install it using RSAT tools. Once its ready run the command,

Install-ADServiceAccount -Identity "MyAcc1"

Once it’s done, we can test it using,

Test-ADServiceAccount "MyAcc1"

It is return the value True which means the test is successful. 

From active directory server, we can verify the service account by running
Get-ADServiceAccount "MyAcc1"
Tip – When configure the Manager service account in service make sure to leave the password as empty. You do not need to define any password there as system auto generate the password. 
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.


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. 


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.


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


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


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


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


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