Using regular user accounts as service accounts is a common practice that puts the responsibility of managing passwords on users. Unfortunately, this often results in passwords that remain the same for long periods of time, making them vulnerable to attacks and misuse. However, Group Managed Service Accounts (gMSAs) provide a more secure solution for running automated tasks, services, and applications. Introduced in Windows Server 2016, gMSAs can also be used on Windows Server 2012 and newer versions. With gMSAs, Windows handles all aspects of password management. The passwords are randomly generated and automatically changed on a regular basis. Additionally, no user needs to know the passwords since gMSAs are installed on the server and retrieve their password information from Active Directory at runtime. This makes gMSAs significantly less susceptible to misuse and compromise compared to using user accounts as service accounts.
Why Are Group Managed Service Accounts (gMSAs) Important?
The use of service accounts is important for providing security for background services on Windows devices. Without proper security measures, these services can be targeted by hackers. gMSAs offer several benefits for security management, which include;
- The ability to run services and tasks on multiple servers
- Automated password management
- Handling passwords through the operating system
- Delegation of management to other administrators
How to Find and Manage gMSAs
Your company might have already established gMSAs that can provide a starting point for managing your service accounts. Finding and managing your MSAs is a relatively straightforward process, which involves executing the following PowerShell commands:
- Get-ADServiceAccount
- Install-ADServiceAccount
- New-ADServiceAccount
- Remove-ADServiceAccount
- Set-ADServiceAccount
- Test-ADServiceAccount
- Uninstall-ADServiceAccount
How to Set Up Group Managed Service Accounts (gMSAs)
To administer gMSAs using Powershell, a 64-bit architecture is required. It is important to ensure that the forest schema is updated to Windows Server 2012, a master root key for Active Directory is deployed, and at least one Windows Server 2012 domain controller is present on the domain where the gMSA will be created.
To create a Group Managed Service Account, the New-ADServiceAccount cmdlet can be used. If AD PowerShell is not installed, the Active Directory module for Windows PowerShell can be added through the Server Manager. The parameters for creating a gMSA include;
- The name of the account
- The DNS hostname of the service
- The encryption type supported by the host servers
- The password change interval
- The accounts allowed to retrieve the managed password
- The NetBIOS name for the service
- The Service Principal Names (SPNs) for the service.
To add members to the security group managed by the gMSA, computer accounts can be added using the Active Directory GUI, the command-line, or Windows PowerShell Active Directory cmdlets. Once the gMSA is created, it can be checked in the Managed Service Accounts OU.
Best Practices for Managing Group Managed Service Accounts
In order to ensure that Group Managed Service Accounts are effectively safeguarding your organization, it is essential to ensure that you are managing them appropriately. Below are some helpful suggestions;
Arrange them correctly: Place all gMSAs in the Managed Service Account folder or organizational unit (OU). If you have multiple types of MSAs, create a sub-OU to keep all gMSAs separate for convenient access. Maintaining a uniform naming convention can also aid in organizing your gMSAs effectively.
Keep an inventory of your service accounts: It is important to keep track of your organization’s service accounts to maintain security and prevent authentication issues. Use tools like PowerShell cmdlets or a dedicated cybersecurity solution to manage and monitor these accounts effectively.
Maintain suitable security practices: To reduce the risk to service accounts, it is important to prevent administrators from using their personal accounts as service accounts and minimize interactive logins for services. Using gMSAs you can automate password management and keep authentications within the operating system, eliminating the need for human interaction.
Group Managed Service Account Security
Group Managed Service Accounts are a specific object type in Active Directory and have special attributes related to their password and rotation. To ensure security, it is important to limit access to these attributes only to the necessary Active Directory objects. The attributes of gMSAs include;
- The password itself (msDS-ManagedPassword)
- The key ID used for the current password (msDS-ManagedPasswordID)
- The key ID used for the previous password (msDS-ManagedPasswordPreviousID)
- A list of objects with permission to query the password (msDS-GroupMSAMembership)
- The password rotation interval (msDS-ManagedPasswordInterval)
Knowing who can access the password is crucial, as it is stored in the msDS-ManagedPassword attribute. Access to query the password is determined by the msDS-GroupMSAMembership attribute, but additional Active Directory permissions are also required. Users or objects with permissions to query the password must also have ‘Read’ permissions for the gMSA’s msDS-ManagedPassword attribute.
To secure gMSA passwords, two steps should be taken. First, ensure that only necessary objects have permission to query the password and that they are listed in the msDS-GroupMSAMembership attribute. Second, restrict access to read the attribute only to administrative users who need access and the computer accounts where gMSAs are installed. Mismanaged permissions or configurations can lead to the compromise of gMSAs, allowing attackers to escalate privileges or move laterally within the network.
gMSA Monitoring
Enabling the ‘Audit directory service access’ policy and configuring a SACL on gMSAs allows you to generate event logs that track queries made to password attributes. By monitoring these logs, you can identify who is accessing gMSA account passwords. Event ID 4662 is generated when this setting is turned on, and it logs details like the account that made the query and the specific attribute accessed. By using a dedicated change auditing solution, you can effectively track and monitor access to these attributes.
How Lepide Helps Secure gMSAs
The Lepide Data Security Platform provides visibility into how group managed service accounts are created, accessed and used. It can detect gMSA password access and high-risk permissions assignments right out of the box. With Lepide, you can create a custom script to execute when gMSA abuse is detected. The script can involve multiple steps, such as requiring the user to respond to an MFA request, disabling the account or creating a ServiceNow incident.
The platform enables users to track every change to gMSAs, providing before and after values along with details about who, what, where and when, critical changes are made. Additionally, it helps troubleshoot account lockouts and other relevant logon activities, such as failed logon attempts. Finally, you can also rollback any unwanted or unplanned changes to gMSAs and retrieve objects from a tombstone or recycled state.
If you’d like to see how the Lepide Data Security Platform can help to safeguard your gMSAs, schedule a demo with one of our engineers.