9 Tips for Preventing Active Directory Service Accounts Misuse

From a security point of view, it is always recommended to use special service accounts to run application services instead of system accounts. The reason being, if a service account is compromised, the losses will be limited compared to a system account. However, any data breach (big or small) is a threat to IT security and when they can be so easily avoided what’s the point of relaxing security? The security of Service Accounts in Active Directory is important and there are some simple things you can do to ensure it. Here are nine tips to prevent the misuse of service accounts and keep them secure:

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”.

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”:

1. Right-click “Documents” folder and click “Properties”.
2. In folder properties, switch to “Security” tab.
3. Here, click “Advanced” button to access the Advanced Security Settings.
4. In “Permissions” tab of “Advanced Security Settings”, click “Add” button. “Permission Entry” window appears on the screen.
5. Click “Select a Principal” link to access the “Select Users….” dialog box.
6. Type the name of Service Account and click “Check Names”. After verifying the name, it formats it as a URL.
7. Click “OK” to come back to “Permission Entry” window.
8. Here, select “Deny” in “Type” drop-down menu.
9. Click “Full Control” to deny all permissions.
10. Click “OK” to finalize your selection. It takes you back to “Advanced Security Settings”.
11. 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):

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”.

Here, select and modify “Deny access to this computer from the network” policy. The steps are shown in the following image:

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.

Click “Logon To” button to access the following window.

Select 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.

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.

Conclusion

Native auditing of Active Directory suffers from numerous drawbacks; including noise in event logs and the absence of predefined reports. Therefore, we recommend (obviously) that you use Lepide Active Directory Auditor which is a part of Lepide Data Security Platform to audit your Active Directory and keep track of all activities and changes made in Service Accounts.