Remote Server Administration Tools (RSAT) put Active Directory, Group Policy, DNS, DHCP and certificate management consoles on ordinary Windows clients, which is convenient for administrators and just as convenient for attackers. RSAT grants no rights of its own, but it decides where privileged credentials get typed and gives an intruder with a domain account ready-made tools for reconnaissance and change. This guide covers what RSAT is in current Windows releases, where it should and should not be installed, how to control it, what to log on clients and domain controllers, and how to respond when it turns up somewhere unexpected. It is for Windows and Active Directory administrators, endpoint teams and detection engineers. For the wider privileged access model, see the Tiered Administration and Enterprise Access Model Guide.
Key takeaways
- RSAT is an OS feature now. Since Windows 10 version 1809 it ships as Features on Demand, added through Optional features, PowerShell or DISM, only on Pro and Enterprise editions.
- The risk is the workstation, not the tool. An administrator running Active Directory consoles on a device that also reads email and browses the web exposes control plane credentials to that device.
- Install it only on privileged access workstations or admin hosts. Remove it everywhere else, inventory it continuously and treat a new installation on a user device as a security event.
- Attackers use the same tools. ATT&CK notes that dsquery can be installed on clients through RSAT, and groups such as Scattered Spider have used the Active Directory PowerShell cmdlet Get-ADUser for discovery.
- Delegate tasks, not consoles. Just Enough Administration (JEA) and scoped delegation let help desk and DNS staff do their job without Domain Admins membership or full RSAT.
What RSAT is in current Windows
Microsoft describes RSAT as tools that let administrators manage Windows Server roles and features from a Windows client. From Windows 10 version 1809 it is part of the operating system and is added through Settings > Apps > Optional features (System > Optional features on Windows 10 22H2 and later), not through Turn Windows features on or off. It installs only on Professional and Enterprise editions. On Windows 11 version 25H2 on Arm64, RSAT Features on Demand are not supported and some tools are available through Turn Windows features on or off instead. On Windows Server 2012 R2 and later the tools are added through Add Roles and Features.
| Capability name | Tools | Security sensitivity |
|---|---|---|
| Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 | Active Directory Users and Computers, AD PowerShell module, dsquery and related tools, ADSI Edit | Control plane: read and change any object the user has rights to |
| Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0 | Group Policy Management Console | Control plane: a GPO linked to the domain runs on every computer |
| Rsat.CertificateServices.Tools~~~~0.0.1.0 | Certification authority and template management | Control plane: template misconfiguration enables domain escalation |
| Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0 | BitLocker recovery password viewer | Recovery keys unlock disks |
| Rsat.Dns.Tools~~~~0.0.1.0 and Rsat.DHCP.Tools~~~~0.0.1.0 | DNS and DHCP management | Traffic redirection, name resolution changes |
| Rsat.ServerManager.Tools~~~~0.0.1.0 | Server Manager | Remote server management; prerequisite for several others |
| Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0 | Remote access (VPN, DirectAccess) management | Edge access configuration |
| Rsat.WSUS.Tools~~~~0.0.1.0 | Update Services console | Approving updates to the whole estate |
Microsoft's Features on Demand list includes 22 RSAT capabilities and notes dependencies, for example the Active Directory tools depend on Server Manager tools, and BitLocker recovery tools depend on the Active Directory tools. It also advises that OEMs should not preinstall them.
Why RSAT placement matters
RSAT tools run with the rights of the signed-in user. What matters is which account is used and on which device. Microsoft's enterprise access model says control of higher planes must not be possible from lower planes; Active Directory administration is control plane work. If a Domain Admin opens Active Directory Users and Computers on a workstation that also handles email, a phishing payload on that workstation can capture or reuse those credentials and sessions.
| Where RSAT runs | Typical use | Risk | Verdict |
|---|---|---|---|
| Privileged access workstation (PAW) | Control plane administration with a dedicated admin account | Low: no email or browsing, application control, hardened device | Preferred |
| Admin jump host or management server in the same tier | Shared admin tooling reached from a PAW | Medium: shared host, but contained and logged | Acceptable with access controls |
| Help desk device with scoped tools | Password resets, group membership in delegated OUs | Medium: accounts must have only delegated rights | Prefer JEA or a web front end |
| Standard user or developer laptop | Convenience | High: credential exposure, ready recon tools for intruders | Remove |
Microsoft's privileged access device guidance defines three profiles (enterprise, specialised and privileged). The privileged profile blocks email and general web browsing, restricts local administration, enforces application control and installs applications only through the management service. See the Privileged Access Workstations Guide.
Controlling where RSAT is installed
- Remove local admin rights: adding Features on Demand requires administrative rights, so standard users without local admin cannot add RSAT themselves. This is the most effective control.
- Deploy centrally: install RSAT capabilities on PAWs through Intune, Configuration Manager or a build script, and remove them from other device groups with the same tooling.
- Control the installation source: Microsoft notes that WSUS-managed devices block Feature on Demand packages by default, so many organisations already prevent ad hoc installs. Provide RSAT from a controlled source only to PAW device groups.
- Application control: on non-admin devices, block the RSAT snap-ins and command-line tools (for example dsquery.exe) with WDAC or AppLocker. This also catches copies dropped by an attacker rather than installed (NIST SP 800-53 CM-7(5), allow-by-exception).
- Inventory: report installed capabilities across the estate (for example with
Get-WindowsCapability -Onlinethrough your endpoint management tool) and alert on any Rsat.* capability outside the PAW group. - Servers: management tools are often installed on member servers by default during role setup. Remove them where no one administers from that server.
Delegating instead of handing out consoles
Many RSAT installs exist because a team needs one task. Microsoft's JEA example is DNS administrators who would otherwise need Domain Admins membership: JEA gives them an endpoint that allows only DNS commands, run through a virtual account or group managed service account, with transcripts of what they ran.
- Help desk: delegate password reset and unlock on specific OUs only, and give them a JEA endpoint or an identity management portal rather than full Active Directory tools.
- DNS and DHCP operators: JEA role capabilities limited to the cmdlets they need.
- Group Policy editors: delegate edit rights on specific GPOs, not linking rights at domain level. See the Group Policy Security Guide.
- Remoting: JEA depends on PowerShell remoting over WinRM. See the Windows Remote Management and WinRM/PowerShell Remoting Security Guide.
Where identity fits
RSAT sessions are where privileged identities are most exposed. Use separate admin accounts for control plane work, never the daily account, and keep them out of email. Watch for service accounts used interactively in RSAT consoles: a service account with directory rights signed in on a workstation is a sign of credential sharing. Scripts that use the Active Directory PowerShell module under a service account should run from a managed server with a group managed service account, not from someone's laptop. Local administrator passwords on admin hosts should be managed by Windows LAPS. See the Local Administrator Password Solution (LAPS) Guide and the Group Managed Service Accounts (gMSA) Guide.
How attackers use RSAT and the AD module
ATT&CK v20 describes dsquery (S0105) as typically installed only on Windows Server but installable on clients through RSAT, and records its use by APT41, FIN8 and others for account, group, trust and host discovery. The Domain Account technique notes that PowerShell cmdlets such as Get-ADUser and Get-ADGroupMember can enumerate accounts and group members, and Scattered Spider (G1015) has used Get-ADUser and ADExplorer to enumerate security groups.
| Activity | ATT&CK v20 | What to look for |
|---|---|---|
| User and admin group enumeration | T1087.002 Domain Account, T1069.002 Domain Groups | dsquery or Get-ADUser and Get-ADGroupMember from a non-admin device or account |
| Trust and host discovery | T1482 Domain Trust Discovery, T1018 Remote System Discovery | Queries for trustedDomain objects or computer and subnet lists |
| Group Policy changes | T1484.001 Group Policy Modification | GPO edits or new links outside change windows |
| Use of stolen admin accounts | T1078.002 Domain Accounts | Admin account sign-in from a device that is not a PAW |
| Remote administration | T1059.001 PowerShell, T1021.006 Windows Remote Management | Remoting sessions from unexpected sources |
Defensive context on these techniques is in the Living off the Land Guide and the BloodHound and Active Directory Attack Path Guide.
Detection and logging
| Source | Signal | Notes |
|---|---|---|
| Endpoint inventory | Rsat.* capability installed outside PAW group | Highest-fidelity signal; check daily |
| EDR or Sysmon Event ID 1 (process creation) | mmc.exe opening dsa.msc, gpmc.msc, adsiedit.msc, dnsmgmt.msc; dsquery.exe or dsget.exe | Alert when the device or account is not in the admin set |
| PowerShell Event ID 4104 (script block logging) | Import of the ActiveDirectory module, Get-ADUser, Get-ADGroupMember, Get-ADTrust | Enable through the "Turn on PowerShell Script Block Logging" policy; consider protected event logging |
| Domain controller Security log 5136, 5137, 5139, 5141 | Directory objects modified, created, moved or deleted | Needs Audit Directory Service Changes and SACLs on the objects that matter; Microsoft suggests tracking high-value objects such as AdminSDHolder and Domain Admins |
| Domain controller sign-in events | Admin accounts authenticating from non-PAW hosts | Use authentication policies or logon restrictions to block, not just detect |
Run new rules in monitoring mode for two weeks to learn which devices and accounts legitimately use RSAT, then turn the exceptions into an allow list. See the Active Directory Security Monitoring and Event IDs Guide.
Implementation plan
- Inventory: report every device with any Rsat.* capability and every server with management tools, and list who uses them.
- Classify: sort users into control plane admins, delegated operators and occasional users. Most occasional users need delegation, not RSAT.
- Provide the right path: PAWs for control plane admins, JEA endpoints or portals for delegated tasks.
- Pilot removal: remove RSAT from one department's standard devices, keeping a removal list so it can be reinstalled for anyone with a genuine need within a day.
- Enforce: remove local admin rights, block RSAT tools with application control on non-admin devices and alert on new installations.
- Detect: enable script block logging and directory service change auditing, and deploy the detections above.
- Review quarterly: reconcile the RSAT allow list with the admin group membership and PAW inventory.
Small organisations without PAWs should at least use a separate admin account, a dedicated admin device or a hardened virtual machine that never opens email, and remove RSAT from daily laptops. Large organisations should enforce the enterprise access model with authentication policies so control plane accounts can sign in only from PAWs.
Measuring success
- RSAT outside PAWs: number of non-admin devices with any Rsat.* capability, target zero.
- Admin sign-ins from non-PAW devices: count per month, target zero for control plane accounts.
- Delegation coverage: percentage of operator tasks served by JEA or scoped delegation instead of broad group membership.
- Logging coverage: percentage of endpoints with script block logging and of domain controllers with directory service change auditing.
- Time to respond: median time from an unexpected RSAT install alert to triage.
Framework mapping
| Control | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Admin tools only for privileged roles | AC-6(5) Privileged Accounts, AC-6(3) Network Access to Privileged Commands | PR.AA-05 |
| Remove unneeded tools, allow by exception | CM-7 Least Functionality, CM-7(5), CM-11 User-installed Software | PR.PS-02 |
| Remote administration control | AC-17 Remote Access | PR.AA-05 |
| Directory change logging | AU-6 Audit Record Review | DE.CM-03 |
Common failure patterns
- RSAT in the standard image: tools are added to every laptop for convenience, so any compromised user device has directory tooling ready.
- Daily account with admin rights: the same account reads email and runs Active Directory consoles, so a phishing compromise is a domain compromise.
- Help desk with Domain Admins: operators are given full rights because delegation was never designed.
- Logging the clients only: domain controllers lack directory service change auditing, so GPO and group changes made through RSAT leave little trace.
- Blocking installs but not copies: RSAT installs are controlled but nothing stops an attacker running dsquery or the AD module from a dropped copy.
Practitioner checklist
- Inventory every Rsat.* capability and server management tool in the estate.
- Install RSAT only on PAWs and approved admin hosts through central deployment.
- Remove local admin rights so users cannot add Features on Demand.
- Block RSAT snap-ins and command-line tools with application control on non-admin devices.
- Replace broad console access with JEA endpoints and scoped OU delegation.
- Use separate admin accounts and restrict their sign-in to PAWs.
- Enable PowerShell script block logging and directory service change auditing with SACLs on high-value objects.
- Alert on new RSAT installs, AD module use and admin sign-ins outside the allow list.
- Review the RSAT allow list against admin group membership every quarter.
Standards and references
- Microsoft Learn: Remote Server Administration Tools
- Microsoft Learn: Available Features on Demand
- Microsoft Learn: Securing devices as part of the privileged access story
- Microsoft Learn: Enterprise access model
- Microsoft Learn: Just Enough Administration overview
- Microsoft Learn: Audit Directory Service Changes
- Microsoft Learn: about_Logging_Windows
- MITRE ATT&CK: dsquery
Related NHI Mgmt Group resources: Privileged Access Workstations Guide · Tiered Administration and Enterprise Access Model Guide · Windows Remote Management and WinRM/PowerShell Remoting Security Guide · Active Directory and Entra ID Hardening Guide