What is a Service Account?
A service account is a dedicated user account intended for running specific services or applications on the Windows operating system. Unlike regular user accounts, service accounts are not tied to individuals and can operate without human intervention. They are often granted with specific permissions to carry out predefined functions, such as accessing databases, running scripts or commands, connecting to APIs, or managing cloud services.
Service accounts enable organizations to manage and control access permissions more effectively, as they can easily be granted or revoked based on the specific requirements of the task or project. By using service accounts, organizations can restrict access to critical systems and applications while closely monitoring activities performed by these accounts. Service accounts allow for automated processes to be executed seamlessly without human intervention, thus increasing operational efficiency. These accounts can operate around the clock, ensuring continuous service availability. They also help to minimize the need for individuals to share their personal login credentials.
Types of Service Accounts
There are different types of service accounts that can be used to run services, with each type serving a different operational purpose.
- Built-in local user accounts, such as the System account, Local Service account, and Network Service account, have specific roles for local system administration and accessing network resources with or without credentials.
- Domain user accounts, managed centrally by Active Directory, are designed for service usage and can be created for a single or multiple services. However, privileges are limited to what is required for the service, and passwords need to be regularly reset.
- Active Directory managed service accounts are similar to domain user accounts, but they have the added benefit of regular and automatic password resets. Each computer can only have one assigned account, which can be used with multiple services or separate accounts can be created for each service.
The advantages of a managed service account include enhanced security measures and simplified maintenance. Furthermore, these accounts can run services on a computer while connecting to network services with specific user credentials. Nevertheless, it is crucial to regularly audit these accounts and follow best practices to ensure adequate security.
Best Practices for Service Accounts
Below are the tips for service accounts security and management:
1. Eliminate unnecessary access privileges
When creating a service account, always keep in mind that it should only have the minimum privilege required to complete the task at hand. For example, a few additional privileges that you can shed are remote access functionality, terminal service logons, internet and email access and remote control rights.
All these settings can be configured easily. The following image shows denying access to network access permissions that is available on “Dial-in” tab.
You have to open “Active Directory Users and Computers”, access “Users” container, and right-click a user account and access its properties. Switch to “Dial-in tab”.
Figure 1: Denying unnecessary privileges
2. Create service accounts from scratch
In some of the past cases of service account misuse, it was found that the accounts had extra privileges because they were created by copying old accounts with high privileges. When you create a new service account by copying, you run the risk to inadvertently assigning excessive privileges, because the old account’s role may differ from the new one. Copying lightens the administrative burden, but it comes with a risk!
3. Avoid putting service accounts in built-in privileged groups
Assigning service accounts in built-in privileged groups, such as the local Administrators or Domain Admins group, can be risky. Everybody in the group will know the service account’s credentials and those credentials can be misused. Additionally, tracking the offender will be difficult as several administrators in that group will know the credentials.
If, for some reason, you have to assign a service account to a privileged group, then create a custom group and add the service account to that instead. Then, explicitly deny access to other accounts for that group. Such measures will eliminate the possibilities of service account misuse.
4. Deny access permissions to service accounts through ACL (DACL)
To secure important objects, like files, folders, shared folders and registry objects, from service account misuse, you can use the ACL (Access Control List)/ DACL (Discretionary Access Control List).
You can use the deny checkbox in the object’s properties sheet to disallow permissions to the service account. For example, perform the following steps to deny access to a folder named “Documents”:
- Right-click “Documents” folder and click “Properties”.
- In folder properties, switch to “Security” tab.
- Here, click “Advanced” button to access the Advanced Security Settings.
- In “Permissions” tab of “Advanced Security Settings”, click “Add” button. “Permission Entry” window appears on the screen.
- Click “Select a Principal” link to access the “Select Users….” dialog box.
- Type the name of Service Account and click “Check Names”. After verifying the name, it formats it as a URL.
- Click “OK” to come back to “Permission Entry” window.
- Here, select “Deny” in “Type” drop-down menu.
- Click “Full Control” to deny all permissions.
- Click “OK” to finalize your selection. It takes you back to “Advanced Security Settings”.
- Click “Apply” and “OK”
After performing the above steps, permissions inherited from the parent are overridden. This way, even if the service account is compromised, vital resources will not be accessible to hackers.
In the following image, the “Documents” folder’s ACL has been shown (available under the “Security” tab of the folder properties):
Figure 3: ACL of “Documents” folder
5. Take away redundant user rights
Review and eliminate unnecessary user rights. Some of the common user rights that can be explicitly denied are “Deny access to this computer from the network” and “Deny logon as a batch job”.
To implement this, create a custom Group Policy Object (GPO) at domain level that denies a service account the right to log on through the network or as a batch job. Go to “Control Panel” “Group Policy Management Console”. Select a policy and edit it in “Group Policy Management Editor”. In the GPO Editor, you have to go to “Computer Configuration” “Policies” “Windows Settings” “Security Settings” “Local Policies” “User Rights Assignment”.
Figure 4: Path of “Deny access to this computer…” policyHere, select and modify “Deny access to this computer from the network” policy. The steps are shown in the following image:
Figure 5: Configure “Deny access to this computer…” policy
6. Use the “Log On To” option
You can limit the number of computers to which a service account can log on by using the “Log On To” option. This way, service accounts will not be able to access file servers with sensitive data.
To do this, open “Active Directory Users and Computers”, go to the container (or organizational unit) where the service account is located, right-click the service account and click “Properties”. Switch to “Account” tab.
Figure 6: Account Tab of User PropertiesClick “Logon To” button to access the following window.
Figure 7: Add WorkstationsSelect the option “The Following Computers”. Then type the computer name and click “Add”. Here you can add the name of those computers, on which any user with the selected Service Account can login. This service account will not work on other computers that are not listed here.
7. Service accounts should be restricted to log on at prescribed times
Service accounts should be configured to log on only during a specified time of the day. You can implement this plan by using the “Log on Hours” option that imposes time and day restrictions. To apply that setting, click “Logon Hours” in “Account” tab of User Properties, as shown earlier.
Figure 8: Configure Logon Hours
8. Secure service accounts by doing password configurations
You can use two password options to secure a service account, “User cannot change password” and “Account is sensitive and cannot be delegated”. The first option ensures that nobody but only administrators control password, the second option ensures that nobody delegates the account for misusing its privileges to connect to local or remote machines. Both options are again listed in the same “Account” tab of use properties, as depicted earlier.
9. Audit service accounts
You must enable auditing for all service accounts and other related objects. These audit settings can be configured locally at the system level or through GPO at the network level. After you have enabled the auditing, you must continuously check the logs to protect the service accounts.
10. Clean up accounts that are no longer needed
Many organizations have numerous service accounts that are active in their Active Directory environment. However, some of these accounts may have been created by mistake or are no longer used due to system decommissioning or other reasons. The problem is that these unused accounts can serve as easy targets for attackers since they are typically not monitored, meaning malicious activity or unauthorized access could go unnoticed.
To address this issue, it is important to establish a robust service account request and decommission process. However, even with this in place, a cleanup of unused service accounts is still necessary to achieve a clean state. The process of gathering knowledge about service accounts from Active Directory involves looking for all user accounts in specific service account organizational units, usernames starting with a specific prefix (e.g. svc), or specific formatting in descriptions or other fields. Additionally, a helpful query called “Service Accounts not logged in for 30 days” can be used as a starting point to identify old accounts that are not being used. It is recommended that you adopt a real-time auditing solution that can automatically detect and manage inactive service accounts.
How Lepide Helps Enhance Active Directory Security
The Lepide Data Security Platform enhances Active Directory security by actively monitoring and alerting administrators about important changes. In the context of securing service accounts, the Lepide solution can help with the following aspects:
- Removing unnecessary privileges: By continuously monitoring AD for important changes, our solution can identify and flag unnecessary access privileges granted to service accounts. This ensures that only the required permissions are assigned, reducing the risk of unauthorized access.
- Knowing when accounts are placed in built-in privileged groups: Our solution can provide alerts whenever a service account is added to a built-in privileged group, such as the Domain Admins or Enterprise Admins group.
- Monitoring service account logon times: Our solution can monitor changes to service account logon hours. If any unauthorized changes are detected, it will alert administrators, ensuring that service accounts are restricted to log on only at prescribed times, as defined by the organization’s security policies.
- Managing inactive user accounts: Our solution can automatically identify and notify administrators about inactive or unused accounts. This helps streamline user management processes and ensures that only active and necessary accounts are retained.
- Auditing service accounts: Our solution can provide detailed logs and reports on service account activities, including logons, privilege changes, and group membership modifications. This allows organizations to conduct audits, meet compliance requirements, and identify any misused or compromised service accounts.
If you’d like to see how the Lepide Data Security Platform can help to secure your Active Directory service accounts, schedule a demo with one of our engineers.