3 Ways to Secure Service Accounts in Active Directory

If you’re looking for security weak spots in your organization, auditing service accounts isn’t a bad place to start. Active Directory audit should include establishing the rights assigned to each account, the password strength, the last time it was reset, and whether it is a domain account, local account, Managed Service Account (MSA), or Group Managed Service Account (gMSA).

Services can be configured to run using the Local Service, Network Service, or Local System accounts, but these are shared with other processes and applications, and they can’t be managed centrally. Although Local System has wide-ranging access to Windows, Local Service and Network Service are standard users with the Logon as a service NT right. Network Service is additionally able to connect to other devices on the network using the device’s computer account.

When domain user accounts are used as service accounts, they provide a greater level of isolation and management, but passwords need to be managed manually or using a custom solution—or, as is often the case, passwords are rarely, if ever, reset.

Step#1. Group Managed Service Accounts

There are two special types of accounts that can be used for services: MSAs and gMSAs. If you remember back to Windows Server 2008 R2, Microsoft introduced MSAs, but they came with so many caveats that the potential use cases were limited. The basic premise of MSAs was to provide the management and isolation of a domain user account but with automated password management. MSAs also provide simplified service principal name (SPN) management.

Microsoft improved MSAs in Windows 2012 with gMSAs. Unlike MSAs, gMSAs can be used on more than one device, run scheduled tasks, and work with applications such as IIS and Exchange. The Key Distribution Service (KDS) on Windows Server 2012 domain controllers manages the 120-character password assigned to each gMSA. Before you can use gMSAs, you must have at least one Windows Server 2012 (or a higher domain) controller in your domain, as well as domain-joined devices running Windows Server 2012 or Windows 8 (and later). PowerShell is used to configure gMSAs.

Step#2. Long Passwords

Not all applications are compatible with gMSAs, so sometimes a domain user account is the best option. Microsoft recommends passwords of at least 25 characters for service accounts, and a process for changing service account passwords should also be implemented. Additionally, place service accounts in a dedicated organizational unit (OU) in AD so that they can be managed separately from other accounts, and make sure that a strong password policy is applied to them.

Step#3. Principle of Least Privilege

In the event that a service account is compromised, the fewer rights assigned to the account, the better. Although it’s easy to assign administrator privileges for maximum compatibility, such far-reaching access is rarely required. Find out what rights the service account needs, and assign only those rights to limit the amount of damage that can be done.