How to Improve Service Account Security

Finding ways to maintain and control user objects during the COVID-19 crisis with reduced staff and budgets can be challenging. Some user objects may be overlooked as they are not regularly authenticated to or tied to a specific user. These types of accounts, called Service Accounts, are domain user objects that can be used to run applications, services, and tasks. In some organizations these accounts are enabled without password rotation for years and are not being recycled as new Service Accounts are being created, which elevates the risk to your infrastructure.

Ideally, organizations can eliminate the risk of Service Accounts with newer technologies like Managed Service Accounts (MSAs), also known as standalone Managed Service Account (sMSA), or Group Managed Service Accounts (gMSAs). MSAs were introduced with Windows Server 2008 R2, allowing you to create an account that is tied to a specific computer, and account password rotation is managed when the computer objects password is updated. Group Managed Service Accounts, introduced in Windows Server 2012, extend the features of MSAs to multiple servers including entire server farms. In some situations, Service Accounts cannot be MSAs or gMSAs and quickly become a management issue due to their increased risk of compromise.

This blog will detail security steps that can be applied to Service Accounts without additional infrastructure or costs, as well as best practices for minimizing risks. These measures can help your organization manage Service Accounts and comply with security requirements without deploying additional applications.

Change approval process

Placing standardized procedures in front of your account creation process is a necessity if you wish to maintain any consistency with service accounts. Having a Change Approval Process that includes a technical review of all requested service accounts is ideal. Some required information should include:

What environment will this account be used in? (example: development/testing/production)
What will this service account be used for? (examples: application/task/service/testing)
Description of what the account will be doing and when and why?
What permissions does this account require?
How long do you require this account?
How many systems will use this account, including system names?
What department will this account belong to and who is the responsible owner?
Will multiple users have access to credentials? If so, who?

These are just some of the recommended questions to place in the account approval process. Having a detailed technical review will allow for different account creation procedures that can be done from the start to provide added security and least privilege access.

12 built-in Active Directory security options

Once you have a strong service account process in place, you can utilize the below built-in security options in Active Directory to add procedures to strengthen security further.

Standardized Naming: Having a consistent naming standard for service accounts will allow for fast and easy identification.
Creation of Organizational Units (OUs): Housing service accounts in their own OU, OUs, and sub-OUs will allow for greater management.
Group Membership: Placing service accounts in groups can lead to simplicity of management. If Engineering needs 4 testing accounts on multiple servers, adding a SA_Engineering_Test group and adding all Engineering’s testing service accounts as members to it will allow you to simplify group membership, Group Policy Objects (GPOs) and Discretionary Access Control List (DACL) modifications when needed.
Manager (Owner): Adding a manager that owns the service account should be the primary user of the account. This can also help during a termination process where rotating passwords for service accounts is needed when users are terminated.
Attribute Tagging: You can have multiple classifications for service accounts. Examples include tagging the account by its risk level, i.e., if Engineering has a service account used in a production environment and the credentials are shared among multiple engineers, tagging it as EngProd3 (Eng=Engineering Dept, Prod=Production Service Account, 3=High Risk) could tell you immediately that if an engineer is terminated you will have a high-risk production service account that needs to be remediated immediately.
Logon Hours: If a testing account is only going to be used during business hours, setting logon hours is beneficial to reduce risk of the account being compromised.
Logon To: In smaller organizations or in testing and development areas utilizing the built-in Logon To can be modified to specific servers or workstations. This could be beneficial if this account is only going to be used for 30 days. There is a 64-computer object limit; for larger organizations you will want to utilize OU GPO links and/or Authentication Silos.
Expiration Dates: Testing and development accounts should expire as they should not be used indefinitely. Most organizations have a 90-day expiration on testing/development accounts unless they are renewed via a new Change Approval Request, which would include another technical review.
Group Policy Object (GPO): Utilizing GPOs that have the Allow Logon/Deny Logon for Remote Logon and Interactive Logons should be utilized and linked to the OUs that are housing the affected servers that the service accounts need to be used on. GPOs can also be used to maintain local administrator accounts when needed.
OU DACL modifications: Modify DACLs where you need to limit Enterprise/Domain Admin access requirements for the service accounts that are requested. In some instances, the requestor may not know exactly why this access is requested and additional application documentation or consultation with the application developer may be needed. This may take some trial and error to get exact settings, but if you can limit service accounts to the least privilege it will result in improved compliance.
Authentication Silo: Using Authentication Silos in large organizations where multiple service accounts need to access servers with Remote and Interactive Logons will help eliminate risk of both the accounts and servers. Authentication Silos can also be used when you have too many servers and service accounts and are managing them via group memberships. Starting from the Windows 2012 R2 functional level, there are multiple lockdown options you can utilize. Some organizations lock down Domain Administrator accounts to Domain Controllers in their own Silo and Silo Policies.
PowerShell (PS) Scripts: Most compliance audits want to see regular rotation of service accounts passwords. With PS scripts you can easily query service accounts that have not had passwords changed within your compliance standard or will be expiring soon to force password changes, disable accounts, etc. PS Scripts can be integral to helping you manage your service accounts. You can run scripts as tasks and upload and maintain a database that others may access and pull reports from – giving your compliance staff peace of mind.

Once you have your standardized procedures in place, PS scripts can be used to find non-compliant accounts, allowing you to take control and place them within your current processes.

Have a strong, consistent, and standardized process with set procedures for your entire Service Account lifecycle

Having maintenance procedures in place within your procedures will help ensure that changes are updated. It can be challenging due to a complex combination of changes, growing infrastructure, projects, workloads, user turn-over, etc. The best practice for managing and securing Service Accounts is to have a strong, consistent, and standardized process with set procedures for your entire service account lifecycle. Maintaining regular service account reviews, updating owners, regular password rotation and/or upon ownership/department change, and setting account expiration are key to security. Deleting expired/disabled accounts on a regular basis will help you maintain a clean and healthy Active Directory Infrastructure, streamline business practices with control over your service accounts, and improve compliance – all without additional applications or expenses.

Webinar Recording: Service Accounts – The Overlooked Gap in Your Security Strategy

Helpful Links:

If your organization needs assistance with Service Account security, our expert team can help! Contact us here.