AD Rights Management Service (Part 1): Architecture, Deprecation, and Reconnaissance

What it is

Part 1 of a Huntress series on attacking on-premises AD RMS. Beyond the SharpRMS tool and trust model the summary names, the page delivers the concrete reconnaissance procedure — the queries, file signatures, registry paths, SOAP endpoints and tool commands — that an operator or defender can run against a real deployment, plus the key facts that make the eventual key extraction unrecoverable.

How it works (the recon surface)

Discovery needs no credentials or special tooling:

• SCP in AD: LDAP filter keywords=MSRMRootCluster in the Configuration partition returns the cluster URL. This is AD RMS's entire directory footprint — no schema extension, no domain groups, no other objects (unlike Exchange or AD CS). Microsoft: "the Active Directory Schema Extension is not required."
• Workstation registry: HKLM\SOFTWARE\Microsoft\MSIPC\ServiceLocation — the EnterpriseCertification and EnterprisePublishing values name the cluster URLs outright.
• SOAP endpoints, all discoverable/probeable: /_wmcs/certification/, /_wmcs/licensing/, /_wmcs/admin/, /_wmcs/decommission/. Hitting /_wmcs/certification/server.asmx returns the (public) SLC cert chain to any authenticated user, confirming a live cluster.
• File detection by magic bytes: a normal .docx/.xlsx/.pptx is a ZIP (50 4B 03 04, "PK"); an RMS-protected one is an OLE compound file (D0 CF 11 E0 A1 B1 1A E1). Sweep a share for the D0 CF header to find protected files. Native formats .pfile, .ptxt, .ppdf, .rpmsg are also RMS. IRM mail carries Content-Type: application/x-microsoft-rms-protection.
• License leakage: the OLE container's Primary stream is signed, not encrypted. Parsing it yields the sealing server and licensing URL, owner + SID, content ID, applied policy/template name, and timestamp — with no key, no rights, no server contact.
• Templates as free recon: AcquireTemplateInformation on /licensing/TemplateDistribution.asmx returns template names, descriptions, grants and the Author field (the RMS admin account name) to any plain domain user (HTTP 200). The admin route GetAll on /admin/TemplateMgr.asmx returns the same but requires Service Group membership (401 otherwise).

SharpRMS commands

.\SharpRMS.exe enum

Automates SCP discovery, cert-chain retrieval, endpoint probe and GAC enumeration; runs as an unprivileged domain user.

Service Group–gated admin operations:

• admin /operation:templates — full template catalog
• admin /operation:clusterinfo — returns CryptoMode, IsDecommissioned, IsADFederationSvcInstalled
• admin /operation:keyprotection — GetServicePrivateKeyProtectionInformation returns IsServicePrivateKeySoftwareBased (true = extractable) and the config-DB DatabaseConnectionString

Why it matters

• The SLC certificate is valid 255 years (2002–2258) and has no rotation mechanism. Extract the private key once and it decrypts all content sealed under it indefinitely — even after domain remediation, even past the cert window. A new key protects only new documents.
• Rights (WellKnownRights bitfield: 0x1 View, 0x601 View+Edit+Save, 0x1000 full control) are client-honored policy, not cryptography. Offline decrypt ignores rights, expiration and revocation; view-only and full-control templates seal to the same SLC.
• The gating boundary is AD RMS Service Group membership (a local group in the server SAM), not Domain Admin. Anyone with admin on the RMS member server or the service account reaches it without ever becoming DA.

flowchart TD
    A[Any domain user] --> B[SCP / registry discovery]
    A --> C[Read templates via licensing]
    A --> D[Cert chain public]
    A -.401.-> E[Admin surface]
    F[AD RMS Service Group member] --> E
    E --> G[keyprotection: software-based key + DB location]
    G --> H[Part 2: extract SLC key from config DB on SQL]

What to do (defenders)

• Add the AD RMS Service Group to privileged-group monitoring — standard tooling watches Domain/Enterprise Admin but not this role-specific local group, so it is commonly left unwatched.
• Treat the configuration database and its backups (which hold the SLC key, templates and user keys) as crown jewels equal to the RMS server itself. In the recommended split deployment the key lives on the SQL server, one step from the RMS service.
• Prefer HSM-based key protection — software-based keys are extractable; the page notes software is the common default.
• For IR, the DRMS_Logging_* DB (ServiceRequestView) shows who requests licenses, from which hosts and how often — useful for spotting anomalous accounts/hosts/volume spikes.

Caveats

• Scope is on-premises AD RMS only. Azure Information Protection / Purview (cloud-held tenant key) are out of reach — except deployments that deliberately keep the key on-prem.
• The SLC key yields no AD credentials and no privileges outside the RMS trust domain — it is not a DCSync equivalent; it is total compromise of protected content, not the domain.
• The extraction and offline decrypt themselves are deferred to Part 2; Part 1 stops at confirming the key is grabbable and locating it.