What are GMSAs?:
Group managed service accounts (gMSAs) are managed domain accounts that you use to help secure services. gMSAs can run on a single server or on a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. After you configure your services to use a gMSA principal, password management for that account is handled by the Windows operating system.
gMSAs offer a single identity solution with greater security. At the same time, to help reduce administrative overhead, they:
-
Set strong passwords: gMSAs use 240-byte, randomly generated complex passwords. The complexity and length of gMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.
-
Cycle passwords regularly: gMSAs shift password management to the Windows operating system, which changes the password every 30 days. Service and domain administrators no longer need to schedule password changes or manage service outages to help keep service accounts secure.
-
Support deployment to server farms: The ability to deploy gMSAs to multiple servers allows for the support of load balanced solutions where multiple hosts run the same service.
-
Support simplified service principal name (SPN) management: You can set up an SPN by using PowerShell when you create an account. In addition, services that support automatic SPN registrations might do so against the gMSA, provided that the gMSA permissions are correctly set.
More info at the following link: GMSA by Microsoft
How Discovery Benefits from GMSA?:
Not only Discovery benefits from the security posture brought by GMSA concept but also administrators that usually needs to control and manage service accounts regularly.
What we will see in the following article is that:
- You can choose the cycle of the password rotation of the GMSA for better security
- You won't need to store password into ServiceNow instance
- The GMSA user doesn't need to be member of a domain admin group
- The computers which will be able to use the GMSA doesn't need to be in a domain admin group
- The GMSA user that will be used as the mid server service account, doesn't need to be on the local admin group of the mid server
GMSA Implementation:
What will be presented here is the following:
- Creating a KDS Root key on a Domain Controller
- Creating a security group
- Creating a GMSA account as described here: https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-star...
- Allowing the security group to retrieve the password of the GMSA
- Adding all computers to the security group
- Adding the GMSA account to the local admin group of each computer (no need on the mid server)
- Install the GMSA on all computers
- Starting the mid server with the GMSA account: https://docs.servicenow.com/bundle/rome-servicenow-platform/page/product/mid-server/concept/mid-serv...
- Create a windows credentials with the option “use mid server service account”
- Launch a discovery on the server hosting mid server and another computer (see schema above)
Key Distribution Services KDS Root Key
Domain Controllers require a root key to generate the password for gMSA accounts.
The root key only needs to be created once, thus if there are already gMSA accounts in the domain, then there is no need to create the root key.
To determine if the root key exists, run Get-KdsRootKey in the forest root domain and child domain using Windows PowerShell (open the powershell window as an administrator):
In this example the root key already exists. To create a new on execute the following command:
Add-KdsRootKey -EffectiveImmediately
With the above command the root key will be operational in 10 hours. To bypass this you can execute the following command for test:
Add-KdsRootKey –EffectiveTime ((Get-Date).AddHours(-10))
The KDS Root Key can also be viewed using the Active Directory Sites and Services Console. In the console, select View then select Show Services Node:
Create a domain user group:
In the Active Directory Users and Computers, create a new group:
Add all computers to the group that should use the GMSA as a service account:
Create a Group Managed Service Account (gMSA)
The root key is available in the root domain and operational. let's now create a GMSA in the root domain.
When creating the gMSA you need to specify the computer accounts that will be allowed to make use of the gMSA. The gMSA will not work on any computers that are not specified in the PrincipalsAllowedToRetrieveManagedPassword attribute. You can specify the computer accounts using a comma separated list, or you can specify a security group (what has been done earlier), and then add the computer accounts to the security group instead.
New-ADServiceAccount -Name "gmsa-03" `
-DNSHostName "gmsa-03.XXX.XXX.XXX" `
-PrincipalsAllowedToRetrieveManagedPassword "GMSAGroup" `
-Description "gMSA for SN Discovery" `
-ManagedPasswordIntervalInDays 30 `
-Enabled $True
The gMSA account was created and can be seen in the Managed Service Accounts container:
Let’s view some of the properties for the gMSA account using Windows PowerShell. The command I use is as follows:
Get-ADServiceAccount gmsa-03 -Properties * | FL DNSHostName,KerberosEncryptionType,ManagedPasswordIntervalInDays,Name,PrincipalsAllowedToRetrieveManagedPassword,SamAccountName
Now we will install the GMSA account on the servers that need to use it (the ones that have been added to the security group).
the following command does this:
Install-ADServiceAccount gMSA-03
If you have an Access Denied error message it is normal. You need to restart the computer in order to take in account its belonging to the security group. When you relaunch the command it should work:
To test the installation of the GMSA, the following command can be executed:
Test-AdServiceAccount -Identity gmsa-03
Configure Discovery to use the GMSA service account
In order for Discovery to use the GMSA, it needs to be part of the local administrators group of each computer
The mid server needs to be installed by specifying the GMSA as the Mid server Service account. If the mid server has already been installed, you can change the "log on" property by specifying the new GMSA in the "services.msc" window. Or you can launch the following command (as an administrator) to change the user in the service:
sc config snc_mid_liferaymid obj=CORP\gmsa-03$
"snc_mid_liferaymid" is the service name of the mid server
the "$" at the end of the GMSA is to identify a GMSA user and that the password is managed by the system. So you need to leave the password field empty
Restart the mid server.
Verify if the mid server is up and running in the instance:
Now let's create a windows credentials for the discovery to run.
When selecting the "Windows credentials" type, name it and check the box "Use mid server service account" like below:
Verify that this is the only active windows credentials in the list:
Configure a schedule discovery with the mid server installed previously and the list of servers's ip addresses
Launch the discovery and it should discover your servers.
You can open back the windows credentials window and see the "Discovery IP affinity":
