How to Secure Active Directory Service Accounts

Service accounts used for managing the applications in the active directory environment like MSSQL, IIS, EXCHANGE, SAP, etc. They are also responsible for generating and validating the service tickets in the Kerberos protocol. For the applications to run without any error, related service accounts are either granted higher privileges than they require or added into privileged groups (Domain Admins, Enterprise Admins, Administrators).  These types of unnecessary rights bring higher risks and impacts.

Service Principal Names are used for representing these services uniquely in the Active Directory. These SPN records are uniquely structured within the same domain. The SPN record of each service is associated with the account that managing the service and used during the Kerberos protocol. These SPN values are kept in the ServicePrincipalName attribute of the assigned accounts. These values can be seen with tools such as Active Directory Users and Computers and ADExplorer. SPN values can be in different formats. Some of the possible syntaxes are given below.

SPN values and related accounts can be seen with the commands below.

TTP Card of Kerberoasting

In Kerberos protocol, to access a service, the user first receives a Ticket Granting Ticket (TGT) from the Key Distribution Center (KDC) and then a Service Ticket (ST) for the service they want to access using the TGT. Then, the client accesses the service with the ST. There are two significant points in this process in terms of security.

Kerberos Protocol

Attackers can use these two key points to perform an attack called Kerberoasting. To perform this attack, the ST of the target service must be obtained by using the domain user privileges. Since the obtained ticket is encrypted with the NTHash of the service account, the clear-text password can be obtained with the offline brute force attack. If the password is not complex enough, the hash can be cracked easily. Attackers can use this cracked password for compromising the entire domain.

The complexity of the service accounts’ passwords is one of the most crucial points for Kerberoasting, brute force, and password spraying attacks. If the passwords of the service accounts are not specified as long/complex and are not changed periodically, they will most likely be compromised by attackers.

Service accounts are often equipped with more than necessary privileges to avoid any problems while running applications. They are usually added as a member of the administrator groups (Administrators, Domain Admins, etc.) or the local administrator group (Local Administrators). If the service users are added as a member of these groups, as a result of the above-mentioned attacks, the attacker can easily increase his/her privileges and take over the entire domain environment.

In the image below, the mssql.admin user who manages the MSSQL service has been added to both the Domain Admins and the Local Administrators group on the WS01 computer. In this scenario, when the attackers compromise the WS01 computer, they will easily take over the Domain Admin privileges.

Domain Admins and Local Administrators Group Memberships of mssql.admin

Access Control Entry is a security mechanism designed in detail to control the access rights on objects in the Active Directory environment. Due to its detailed design, managing the access control entries are very hard, and this complexity enables the attackers to target this mechanism. Even if service accounts are not a member of privileged groups, they may have admin privileges because wrong ACE definitions. Also, non-privileged users can affect these service accounts because of misconfigured ACE implementations. Either using or creating misconfigured ACEs, the adversaries can compromise the AD environment and create backdoors for persistency.

For example, in the image below, with a little change on the mssql.admin user, all users in the Domain Users group can reset the password of this account.

Reset Password ACE change on mssql.admin

Similarly in the image below, the mssql.admin user has been given the right to change the ownership (Modify Owner) of furkan.ozer, which is a privileged user. With this modification right, desired changes can be made by changing the owner of the object.

Modify Owner ACE change on furkan.ozer user

Finally, the attack path caused by these misconfigured Access Control Entries can be seen below.

Attack path from Domain Users group to furkan.ozer user with misconfigured ACE’s

Managed Service Account (comes with Windows Server 2008 R2) and Group Managed Service Account (comes with Windows Server 2012 R2) are objects that automate the management of service accounts and periodic password change process. Unlike MSA, GMSA can also be used in cluster structures with more than one server. This article will explain how to configure the GMSA account as it is more up-to-date.

• The password of the GMSA account is set by the KDC as 120 characters long and is automatically updated every 30 days. There is no need for any manual interaction on the server side during this process.
• Because GMSA passwords are set automatically, they are not affected by Password Policies and Fine-Grained Password Policies.
• Also, GMSA accounts neither have interactive logon rights like standard service accounts nor have high privileges unless granted especially. However, these accounts contain different risks, and we will discuss these risks in another article.
• GMSA’s can also be used for scheduled tasks other than services. However, to use it in scheduled tasks, Logon as batch job privilege must be given to the GMSA.

Powershell and ActiveDirectory module are mostly used to create a GMSA. In addition to this method, these operations can also be performed with the Managed Service Accounts GUI application of CJWDEV.

To create a GMSA, it is necessary to create a KDS Root Key first. It is sufficient to create this key once in a domain environment.

Querying the KDS Root Key object in the domain

Creating the KDS Root Key object in the domain

To manage the servers where the GMSA accounts will be used, servers can be added into a security group. In this way, services can be managed by adding and removing from the group without making any changes on the GMSA object. Although this process is recommended, it is not mandatory for the use of GMSA.

The group created for servers where the GMSA will be used

After performing these operations, a GMSA can be created using the following commands.

Creating GMSA using Powershell ActiveDirectory module

After the GMSA is created, it can be viewed with Active Directory Users and Computers application.

After the GMSA is created, login to the server where the service is running and run the following commands.

Installing the GMSA on the server

There is no need to enter a password while using the GMSA in the service.

1. Service accounts with SPN should be determined and documented. This can be done by using the FindServiceAccounts.ps1 script under the references.
2. In addition, domain accounts that are manually used on servers should be detected and documented using the FindLocalServiceAccounts.ps1 script under the references.
3. All service accounts should be prioritized according to the importance of the service, and GMSA’s should be created for these services in this order.
4. After the GMSA’s are assigned to the related services, membership of the old service accounts should be removed from the privileged groups, then they should be disabled or deleted.
5. If GMSA cannot be used instead of service accounts.
   a. Service accounts’ parent groups should be analyzed and the account should be removed from the administrator groups. The account must be given the least privileges required by the service.
   b. Special policies and long/complex passwords should be specified for such service accounts using the Fine-Grained Password Policy.
   c. Access Control Entries on the service accounts should be examined and suspicious objects that may affect this account should be prevented.
   d. Access Control Entries from the service account to other objects should be examined, and unnecessary entries should be deleted.

• https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
• https://azurecloudai.blog/2020/04/15/create-a-group-managed-service-account-gmsa/
• https://gitlab.com/forestallio/manage-serviceaccount/-/blob/master/Find-ServiceAccounts.ps1
• https://gitlab.com/forestallio/manage-serviceaccount/-/blob/master/Find-LocalServiceAccounts.ps1