Good practice, Part 4: Admin rights for IT staff

In Part 2, I said that no one should be logged in to their computer on a daily basis with an admin account. That goes for IT staff as well. They can also make mistakes and be exploited by malicious individuals or software. In this article I will cover how to delegate admin rights to IT staff throughout the business, so you enable them to do their job and at the same time mitigate the risk of having admin rights.

Personal vs. general accounts

First of all, strive to make accounts personal and identifiable, like “adm.jonas” instead of  the general “administrator”. This is especially important if the account has admin rights. Accountability becomes a possibility with such accounts. If staff uses an account named “administrator” to perform tasks, how would you know who actually did something during reviews? So, make it policy that accounts are personal when possible, and personal credentials are not to be shared between staff.

Just what you need, when you need it

You should evaluate what kind of rights the staff need in order to get their job done. Then have a look at what frequency they need access to those rights, and what harm the different rights could do if it got into the wrong hands. Remember that no matter how much you trust someone, their account can be compromised and exploited.

Let say someone need an powerful access right for a monthly recurring task. Consider giving out a separate account with delegated rights for that task, so they don’t run with that right on a regular basis – mitigating risk. You should also consider creating a more strict password policy for more powerful accounts, like changing the password after each use if the account is very powerful.

Make sure accounts only have just enough delegated rights, not more – not less, to perform the task they are intended to do.

Protected Users

In Part 1, I mentioned the pass the hash attack. To mitigate the risk of becoming a victim of that, you can protect Active Directory (AD) accounts by making them member of a built-in security group called “Protected Users”.

One feature of this group is that credentials isn’t cached on systems, which makes it much harder to deploy a pass the hash attack. Since you don’t have your account cached, you cannot log in to a system if you are offline, because log on attempts must be validated with an domain controller each time. This is important to bear in mind before deploying Protected Users.

There are other pitfalls to be aware of, so you should study all features of Protected Users before deployment. I will later discuss some suitable scenarios for Protected Users.

Now, lets look at some specific scenarios where IT staff need admin rights, and how to handle them in a good manner.

Local admin rights for helpdesk staff

Helpdesk staff need access to local admin on employees computers.

• Create descriptive personal AD accounts, like “adm.client.jonas”.
  
• Create a descriptive security group, like “Local client admins”, and add the newly created users to it.
• Add them to Protected Users.
• Using Group Policy, add the “Local client admins” group to the local administrator group on employee computers.

Doing this will give helpdesk staff admin rights on the client computers they work on, and a pass the hash attack will be very hard against these accounts. Manual software installations should only be done with these accounts, since such accounts will reduce possible harm done by malicious software, given the accounts don’t have rights on servers or AD itself.

Delegated rights for domain admin staff

Helpdesk staff need to manage employees user accounts in AD.

• Create descriptive personal AD accounts, like “adm.ad.jonas”.
• Create a descriptive security group, like “Helpdesk domain admins”, and add the newly created users to it.
• Add them to Protected Users
  
• Delegate specific rights in AD to the account to enable the staff to do their job, like the right to create and modify user accounts in the Users Organizational Unit.
  

Domain administrators will now be able to manage employees users accounts, without unnecessary (and powerful) permissions. This will reduce the potential damage by human error or malicious intent.

Fail-safe accounts

You should always have at least one account pr system that is not used on a daily basis, with all administrator rights enabled. Without it, you would loose total control. Use these accounts to delegate rights to other accounts, and to perform emergency actions. These are the master keys, protect them as such.

Built-in administrator accounts

To mitigate the risk of a brute force attack, do not call general admin accounts “administrator”, but rather “adm.<systemname>”. The built-in Administrator account in AD should be disabled, because it has the same SID in every AD. Attackers know and exploit this when trying to gain access to AD based systems.

The above is also true for Windows clients. The built-in administrator account should be disabled and replaced. This is best done with LAPS.

Local Administrator Password Solution (LAPS)

LAPS, developed by Microsoft, is available without extra cost. It will let you change the password on a local account to a random password, and stores it in a protected attribute on the related computer object in AD.

You should use Group Policy to create a local admin account on your client systems with a descriptive name, like “adm.client”. Then make LAPS randomize its password on a regular basis. Delegate read rights to the LAPS password attribute to the staff that need access to the local admin on clients. Now staff can access local admin on clients even if the clients are offline.

Since the password is unique and changed periodically on all clients, pass the hash is out of the question. Should you need to give out the password for the local admin account to the end user, the compromise will not affect the security of other clients.

When you have confirmed that all clients computers have a LAPS password stored in AD, consider to disable the built-in administrator account using Group Policy.