Block Privileged Accounts from Local Workstations

There are risks here. Make sure you understand group policy and specifically how you’re administering your servers and domain controllers. 

Don’t put this policy in an OU or container where your servers / domain controllers are present or you wont be able to login to them, even with your domain administrator account!

There are multiple ways to resolve this risk, including filtering the policy to only apply to certain operating systems. Is impossible for us to provide guidance because it will depend on how you (or whoever came before you) setup your active directory structure. When in doubt, start with small test OUs until you are confident.

---

Once a local workstation is compromised (no matter how) one of the first things many pentesters and hackers attempt to do is harvest cached credentials that may be stored in some fashion on the machine. Unless you’ve made specific changes to your network you should assume any privileged account (like yours as the system administrator if you’ve given yourself domain admin rights because it was convenient) that has logged onto the machine and not subsequently changed its password is vulnerable to being stolen this way.

As a result it’s considered a best practice to prevent privileged accounts (such as any domain administrator account, server accounts, etc) from ever logging on to those machines in the first place. By doing so you reduce the possibility that those sensitive and powerful credentials could be stolen by someone who compromises a workstation or other windows PC.
First we group All Those accounts that can do amazing things into one super group.

1. Open Active Directory Users and Computers
2. Create a domain security group to place all your privileged accounts in.  Maybe call it “Privileged Server Accounts”. You COULD just add all the relevant groups and users in when you build the group policy later, but this way is cleaner.
3. Add all the relevant users and user groups into this security group. Domain Admins is definitely one group you should include, but you may have others if you’e created separate admin accounts for server administration. None of these has a legitimate reason to need to login to endpoint workstations.

Then we create a group policy that prevents that security group from logging in to end-user workstations to begin with

1. Open Group Policy Management
2. Create a New Group Policy Object
3. Browse to the following folder – Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignment
4. Edit “Deny log on locally” and select “Define these policy settings”.
5. Click on Add User or Group
6. Click on Browse (it’s important you find the name specifically this way. The window will let you type anything in it, and will accept it without error. Browsing helps ensure you find the right group in  your domain). Find the group name you created in the step above.
7. Click OK and OK to work your way back out to the main screen
8. Repeat the process for the “Deny log on through Remote Desktop Services”, “Deny log on as a service” and “Deny log on as a batch job”
9. Save the group policy and link it in to your test OU
10. Once you are satisfied with how it works, link the group policy object into your workstation OU (whatever is appropriate for your environment – again, see warning at top of this document)

It MIGHT be (we hope not) that you’ve already got batch jobs or services using  domain administrator credentials on end user machines. You can always ease into this policy by leaving those policies blank until you resolve those issues. Just know that until you do hackers likely still have the ability to steal those credentials if they should happen to gain access to the PC.
The last thing we need to do is either a) change all the passwords for any of the privileged account we added to our group that might be on those end user machines or b) go to each machine and delete those accounts out in the System Properties \ Advanced \ User Profiles section. Changing the password is obviously the easier thing to do, unless of course you’re still using it for all these other places around the network that you’re not sure about. As  before though until that cached copy is deleted or the password is changed the credentials are still vulnerable to theft.
So, that’s it, and this goes a long way toward closing a door your enemies could and would be using. If you know what you’re doing it could be implemented in less than 30 minutes. As always when dealing with permissions and group policy, be REALLY careful you DO know what you’re doing. Its not rocket science, but no one wants to lock themselves out of their server.