1. Challenge Description

Denying interactive logons for service account is a recognise industry best-practise which envisions to increase security within a Wintel environment.Security auditors trawling your environment for security flaws will most certainly identify the ability for service accounts to logon interactively to LAN machines as a security breach. There are several reasons why this is the case, the most obvious potentially being the fact that when service accounts are used to logon interactively, this generally means that the service account’s credentials have been or are likely to be made available to a number of different people, and having different people accessing devices and performing configurations and data manipulation with a shared login defeats the information-security benefits of traceability and accountability.

Because, unless you have a decent automated password management solution in place, resetting passwords for service accounts can be a huge task with the potential to cause service disruption, by denying interactive logons to service accounts, it is possible to configure them with passwords which do not expire, whilst ensuring an acceptable degree of security.

The goal of this exercise is, therefore, to ensure the ability to restrict interactive logons for service accounts.

In broad strokes, can be implemented through AD Group Policy where for computers in the OU , users in the OU which are members of the security group are denied interactive logon, as:

Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment

Deny log on locally: {service accounts’ security group}

Deny log on through Terminal Services: {service accounts’ security group}

3. Implementation

The implementation is very straight forward, and consists of the following steps:

1. Ensure that all service accounts are located in the same OU – this will simplify administration moving forward.

2. Create security group like “Service Accounts – Deny Interactive Logon” and add the objects in the service accounts’ OU as members.

3. Create test GPO like “Service Accounts – Deny Interactive Logon” with settings:

Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment

– Deny log on locally: {security group “Service Accounts – Deny Interactive Logon”}

– Deny log on through Terminal Services: {security group “Service Accounts – Deny Interactive Logon”}

 

1. Link GPO to any OUs containing machines which you want to stop service accounts from being able to logon to interactively.

2. The policy will apply as you reboot these machines.

3. For testing purposes, run “gpupdate /force” in one of the machines affected. Don’t lo off, just restart when prompted.

4. Attempt to log on to the machine you’ve just updated the group policy for using one of the service accounts in the security group “Service Accounts – Deny Interactive Logon” via RDP, to test Terminal Services login.

5. If all is well, you will not be able to log on using that account.

6. Then, attempt to log on to the test machine using the same account, using your KVM (or equivalent, if this is a physical server), or via the vSphere console (if virtual), to test the local login.

7. Again, if all is well, you will not be able to log on using that account.

4. Exceptions 

If a single service account requires access to one or several domain machines

1. Remove service account from security group “Service Accounts – Deny Interactive Logon”.

2. Run “gpupdate /force” on the relevant server and then reboot it.

3. Try to logon interactively as the relevant service account to confirm functionality.

 

If a single or multiple service accounts must access a single machine

1. Create an OU to host machines this policy doesn’t apply to and ensure that the GPO is not linked to or inherited by this OU.

2. Move the relevant service to this OU.

Or…

1. If the settings to deny interactive logon for service accounts are included in another more complex GPO (ie. a security baseline GPO), create an exception policy for that machine by making a copy of the baseline policy and altering only those settings which must not be applied to the machine the GPO copy will be used for.

2. Filter the policy’s security so that it applies only to the intended machines.