In this article, I have tried to collect all major organizational and technical rules of using privileged / administrative accounts in the organization to improve security in the Windows network. Following these recommendations, you will significantly increase the protection of computers and servers in Active Directory domain against the attacks similar to the summer incident with Petya ransomware, which penetrated the domain computers remotely using administrator credentials obtained from the LSASS memory (by Mimikatz-like tools) and the SMB v1.0 vulnerability. Some of the recommendations may be disputable or not applicable in the specific cases, but you’d better follow them.
So, in the previous article, we considered the basic techniquesof protection against extracting passwords from the memory using Mimikatz. However, all these technical means may be useless, if you don’t follow basic security rules to keep the administrative accounts in Windows domain.
The main rule you should use is the maximum restriction of the administrative privileges, both for users and for administrators. You should give users and support teams only the minimal permissions that are necessary for performing daily tasks.
Here is the basic list of rules:
- Domain/enterprise administrator accounts should be used only to manage the domain or domain controllers. Don’t use these accounts to access and manage your workstations. A similar requirement applies to server administrator accounts.
- It’s worth to use two-factor authentication (2FA) for the domain administrator accounts
- The administrators must log in on their workstations using regular (restricted) user accounts
- To protect privileged accounts (domain-, Exchange-, server- administrators), consider using the feature of Protected Users group
- Never use the depersonified shared administrative accounts. All administrator accounts must be personified
- Never run any services using administrator accounts (the same applies to the domain administrator account), it’s better to use dedicated accounts or Managed Service Accounts
- Do not allow users to work with local administrator privileges
Using the GPO you must enable the policies that provide sufficient password length and complexity both for users and administrators, as well as account lockout settings. These policies are located in the Computer Configuration -> Windows Settings -> Security Settings -> Account Policies section:
- Password Policy
- Account Lockout Policy
You can make more stringent requirements to the length and stored password history for administrators with the help of Fine-Grained Password Policies.
As for the built-in accounts on users’ computers, you should never use the same local administrator passwords on all PCs. It’s better to completely disable (or at least rename) the local administrator account. To provide a regular password change for this account to a unique one on each computer in your network, you can use LAPS.
With the help of GPO, prevent remote access to the computers under local accounts and the remote access using RDP (NT AUTHORITY\Local accounts and member of Administrators group). These settings are located in GPO: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment.
- Deny access to this computer from the network
- Deny log on through Remote Desktop Services
- Deny log on as a batch job
- Deny log on as a service
After the end of the administrative session (software installation, system configuration, etc.), it’s better to restart the user’s computer. Also you can forcefully terminate idle/disconnected sessions on RDS servers using the policies in the following section: Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Session Time Limits.
In Windows Server 2016 domain, you can use the new Temporary Group Membership feature to grant temporary administrative privileges.
In this article I have described the most important rules that will help you to enhance the protection of the administrative accounts on your Windows domain. In fact, this article does not provide complete guidelines on the security and privilege restriction of the administrator accounts, but it can be used as a starting point to build a secure infrastructure. To get more information, I recommend starting with Microsoft documentation Best Practices for Securing Active Directory.