It’s not news that the extra privileges on admin accounts make them a target for attackers, and one reason why insider threats are so dangerous. You want the people who run your IT infrastructure to have the power they need to run your infrastructure — but you don’t want them to have more access or more control than they need.
Just because an admin needs access to one system setting, database or network doesn’t mean they need access to all of them; applying role-based security permissions to your IT team makes as much sense as not giving receptionists access to the build tree for your internal applications.
SEE: Checklist: Securing Windows 10 systems (TechRepublic Premium)
While having privileged admin access is convenient, if there’s a data leak, a database admin would much rather be able to say that the contents of the database are encrypted so they can’t have seen anything than to try and prove they didn’t copy data they didn’t need to have access to in the first place.
Limiting which accounts have privileged access can also help with productivity. As an admin, I might think that 2pm on a Friday afternoon is the perfect time to restart your virtual desktop to migrate you onto a new terminal server, but that’s not so useful if you’re in the middle of a sales meeting. Removing end-user access rights also often reduces helpdesk calls — usually because it stops people changing settings that later cause problems or stops them installing unauthorised utilities that make those changes in misguided attempts to ‘tune’ the PC.
We’ve also known for a while that the level of access required by security and monitoring tools can also lead to issues, because the convenience of deployment often trumps the slower process of deploying with limited permissions. This leaves critical systems like domain controllers and database servers with weak passwords on service accounts with all the rights an attacker would need to take over an entire network.
But the impact of the SolarWinds attack means that organizations can’t afford to postpone auditing which accounts have admin and access privileges, applying the principles of least privilege and shifting to just-in-time audited admin access rather than permanent unmonitored privileges on high-value systems.
Attackers target admins
Any system that has accounts with admin rights is potentially vulnerable to attackers. Many attacks look for common misconfigurations in Active Directory or systems that still use legacy authentication like NTLMv1 (where passwords are easily brute-forced). The Solorigate attacks used privileged accounts on Domain Controllers, Group Managed Service Accounts and stolen or forged Kerberos tickets, as well as running legitimate AD tools to look at accounts on remote systems and federated domains.
Spend some time reviewing all the highly privileged service accounts you have with domain admin rights, system access, global administration rights and the equivalent, and find out which of them really need that much access and which could have read-only permissions. You also need to look at intermediary devices — VPNs, remote desktops and access gateways, VDI, application publishing that uses access proxies and other areas where privileged identity and access management is particularly important.
You can find AD admins with the PowerShell command Get-ADGroupMember ‘Administrators’ -Recursive check, but to run a more thorough check on the status of admin, service and other privileged accounts and groups in your Active Directory and on domain controllers, use these PowerShell scripts or a tool like ADRecon. That way you can spot issues like sensitive accounts with the ‘password never expires’ flag set. Microsoft has published an Azure Monitor workbook for collecting similar information for Azure AD.
Look for applications and service accounts in the Domain Administrators Group; applications that need domain admin privileges are probably using legacy authentication. Also look for applications that have the same privileged account on multiple systems on the network; they probably use the same credentials, so an attacker who compromises one account can use it to move laterally across the network. Check if applications with local admin accounts really need admin privileges to run, and look at your long-term plans for upgrading or replace them with applications that use modern authentication methods.
SEE: Windows 10 Start menu hacks (TechRepublic Premium)
Use the Local Administrator Password Solution (LAPS) tool to manage local admin account passwords for domain-joined computers. These often end up with the same admin password on every device because that’s easier for troubleshooting and support. LAPS sets a different, rotated random password (that’s stored in Active Directory and protected by ACLs to limit who can read and reset it) for the common local administrator account on every computer in the domain.
If you use Azure AD, create recurring Azure AD access reviews (this requires a P2 subscription) to check who has admin access, how many of those are Global Administrators or have Azure resource roles like User Access Administrator, and if any external guests or partners who were given temporary admin access still have it months later. The review can be delegated to the managers who should be making business decisions, but the IT team will want to explain why it matters.
Make sure you have no on-premises accounts with administrative privileges in Office 365 or Microsoft 365, and isolate the Microsoft 365 admin accounts. If you have a commercial Microsoft 365 subscription, there are tools in the Microsoft 365 Admin Center (or you can use Exchange Management PowerShell) to help with privileges account management for Office 365.
Enforcing MFA (ideally with security keys or biometrics) for admin accounts and admin roles is especially important: if you have any Microsoft commercial subscription at all, it includes Azure AD MFA at no additional cost. Use conditional access policies to make sure admin accounts can’t authenticate in high-risk scenarios where they could be compromised.
Microsoft Defender for Identity (formerly Azure Advanced Threat Protection) monitors on-premises identities and the AD infrastructure, detecting lateral movement and other signs that attackers have compromised credentials. It already protects domain controllers on premises and in hybrid environments, and can now cover Active Directory Federation Services (ADFS). That lets you see failed logins from ADFS logs as well as Active Directory details like whether logins by the same user used MFA, making it easier to spot brute-force attacks — if there are dozens of failed logins to multiple accounts and no MFA when the account finally logs in, that’s more likely to be a successful attacker than several very forgetful employees.
Just enough privileges
The most important pieces of your infrastructure need extra protections because the admin privileges you can’t get rid of will be targeted. Identify sensitive and privileged accounts with the highest level of access and implement more protections around them like setting up Azure AD Privileged Identity Management.
Just Enough Administration (JEA) — originally called Just In Time Just Enough Admin or JITJEA — is a PowerShell feature for delegating administration of anything managed through PowerShell so it can be done through temporary virtual or team accounts. This limits the commands those accounts can run to those needed for specific tasks, which are available only for a preset time once the admin request has been approved.
For particularly sensitive admin accounts and privileges you may want to implement secure workstations where the OS has been hardened. Deploying a Privileged Access Workstation is a fairly lengthy process that’s simplest with a Microsoft 365 E5 licence, but lower SKUs include many of the tools.