Federated domains: a quiet backdoor in Entra ID
After a compromise, passwords are reset, sessions revoked and suspicious applications deleted. But if the attacker has federated a domain to an identity provider they control, they can keep issuing their own tokens. Domain settings belong at the top of the checklist.
How federation works
A custom domain in Entra ID can be managed, in which case Entra ID validates passwords itself, or federated. In the latter case, authentication for users in that domain is delegated to an external identity provider, historically AD FS. Entra ID then accepts any token properly signed with the certificate declared in the federation configuration.
That is exactly what makes it a target: whoever controls the federation configuration, or the signing key, can produce tokens that Entra ID will treat as genuine, without knowing a single password.
Persistence techniques
| Technique | How it works |
|---|---|
| Adding a federated domain | The attacker adds a domain they own, verifies it with a DNS record, then federates it to their own identity provider. They can then forge tokens for users tied to that domain. |
| Converting an existing domain | A managed domain is converted to a federated domain pointing at infrastructure the attacker controls. |
| Extra signing certificate | On an already federated domain, a second signing certificate is added. The legitimate infrastructure keeps working while the attacker signs their own tokens with their key. |
| AD FS key theft | Without changing Entra ID at all, the attacker extracts the signing key from the AD FS server and forges valid SAML tokens. |
Depending on configuration, a forged token can also claim that MFA was already performed at the identity provider. The setting that decides whether Entra ID accepts that claim (federatedIdpMfaBehavior) therefore deserves a check.
Roles involved. You do not need to be a Global Administrator to act on domains and federation. The Domain Name Administrator and Hybrid Identity Administrator roles hold significant rights in this area and should be treated as privileged roles.
Detection
Domain operations are recorded in the Entra ID audit logs. Operations worth watching include:
Add unverified domainandVerify domain: a new domain being added;Set domain authentication: a domain switching from managed to federated, or back;Set federation settings on domain: federation settings being changed, certificates included.
These events are rare in the normal life of a tenant. Each one should trigger an alert and a check with the team responsible for identity.
Auditing the configuration
Beyond the logs, whose retention is limited, the current state must be checked directly. With Microsoft Graph PowerShell, Get-MgDomain lists domains and their authentication type, and Get-MgDomainFederationConfiguration -DomainId shows, for each federated domain, the issuer, endpoints and signing certificates. Checkpoints:
- Is every domain in the tenant known and legitimate?
- Does every federated domain point to the organisation's official infrastructure?
- Do the signing certificates, current and next, match those of that infrastructure?
- Is federation still needed? Moving to cloud authentication removes much of this risk.
What an audit checks
- The list of custom domains and their authentication mode.
- The federation configuration of every federated domain, certificates included.
- How MFA claimed by the identity provider is handled.
- Who holds the roles that can manage domains and federation.
- Alerts on domain and federation operations.