Self-Service Password Reset and the Domain-Takeover Risk

Lab Metadata

Core technologies

Scenario and Description

Northgate wants staff to reset their own passwords without ringing the service desk. Self-service password reset (SSPR) does that, and because registration is now combined with MFA, the methods a user proves themselves with for a reset are the same strong methods you deployed in Labs 02 to 04. Configured well, SSPR reduces cost and improves security at once. Configured carelessly, it becomes a self-service account-takeover portal.

The subtle risk, and the one the brief singles out, is not the SSPR settings screen. It is the trust anchors underneath identity recovery: the domains your tenant has verified, the DNS that proves you own them, the email addresses recovery codes are sent to, and any federation that lets an external identity provider issue tokens for your users. If a verified domain's registration lapses and an attacker re-registers it, if a recovery email points at a domain you no longer control, or if a federated domain trusts a signing key held elsewhere, then password reset and sign-in can be subverted without touching a single Northgate system.

You will baseline SSPR registration and enumerate the tenant's domains, configure SSPR with a strong, appropriate method mix, address hybrid password writeback, then run a domain-takeover risk assessment: flagging unverified, federated, stale and externally exposed domains, and applying the registrar and DNS hygiene that removes the exposure.

Prerequisites

Prior labs

Labs 01 to 04 recommended. SSPR shares the combined registration and strong methods you configured earlier, so a user who registered Authenticator or a key in those labs is already SSPR-capable. Domain assessment needs only the tenant from Lab 01.

Graph scopes introduced

Real-World Problem Statement

Identity recovery is a deliberate, controlled weakening of authentication: you let someone back in when they have lost their credential. If the proof required to do that rests on infrastructure outside your control, recovery becomes the attacker's easiest route. The problem spans two layers, the SSPR method mix, and the domain and DNS trust anchors beneath it.

Concrete scenario: Northgate acquired a smaller firm two years ago and inherited three custom domains. Nobody is sure which are still registered, which are federated to a decommissioned identity provider, or whether any recovery emails still point at them. Your job is to turn SSPR on safely and to prove that every domain the tenant trusts is one Northgate genuinely controls.

Skills Mapped to Production Solutions

Architecture Overview

An SSPR event depends on a chain of trust: the user proves themselves with registered methods, and the tenant trusts those methods, the domains the account lives in, and the DNS that verified those domains. A break anywhere in that chain, an expired domain, a lapsed DNS record, a stale federation, undermines the whole flow.

Step-by-Step Implementation

Phase A - Baseline SSPR readiness and domains

Connect-MgGraph -Scopes 'Domain.Read.All','Directory.Read.All',
  'User.Read.All','AuditLog.Read.All' -NoWelcome

# SSPR readiness from the registration report (reused from Lab 01).
$reg = Get-MgReportAuthenticationMethodUserRegistrationDetail -All
$ssprCapable    = $reg | Where-Object { $_.IsSsprCapable }
$ssprRegistered = $reg | Where-Object { $_.IsSsprRegistered }
"SSPR-capable   : $($ssprCapable.Count)"
"SSPR-registered: $($ssprRegistered.Count)"

# Every domain the tenant knows about.
Get-MgDomain -All |
  Select-Object Id, IsVerified, IsDefault, IsAdminManaged, AuthenticationType |
  Sort-Object AuthenticationType | Format-Table -AutoSize

Phase B - Configure SSPR correctly

# Microsoft Entra admin center (entra.microsoft.com)
# Protection > Password reset > Properties
#   Self service password reset enabled = Selected
#   Select a pilot group first (for example 'SSPR-Pilot'), widen to All after validation.
#   Rationale: staged rollout mirrors the report-only discipline from Lab 03.

# Password reset > Authentication methods
#   Number of methods required to reset = 2
#   Methods available to users (tick):
#     - Microsoft Authenticator (push/passwordless)  [strong]
#     - Mobile app code                              [strong]
#     - Email                                        [use with care, see Phase D]
#   Leave UNTICKED:
#     - Security questions   (knowledge-based, weak, phishable/guessable)
#   Rationale: two strong methods raise the bar for takeover via reset.

# Password reset > Registration
#   Require users to register when signing in = Yes
#   Number of days before users are asked to re-confirm = 180
#   Rationale: enforced registration means recovery is ready before it is needed.

# Password reset > Notifications
#   Notify users on password resets = Yes
#   Notify all admins when other admins reset their password = Yes
#   Rationale: a reset notification is an early tamper signal to the account owner.

# In Microsoft Entra Connect (on the sync server):
#   Entra Connect > Customize synchronization options >
#   Optional features > tick 'Password writeback' > complete the wizard.
#
# Then in the Entra admin center:
#   Protection > Password reset > On-premises integration
#     Write back passwords to your on-premises directory = Yes
#     Allow users to unlock accounts without resetting their password = Yes
#
# Cloud-only trial tenants have no on-prem directory, so this phase is
# conceptual here and becomes hands-on in Lab 09 (Hybrid identity).

Phase C - Domain-takeover risk assessment

$domains = Get-MgDomain -All

# Count how many users actually use each domain as their UPN suffix.
$users   = Get-MgUser -All -Property userPrincipalName
$suffixUse = $users | Group-Object { ($_.UserPrincipalName -split '@')[1] } |
             ForEach-Object { @{ $_.Name = $_.Count } }
$useMap = @{}; $suffixUse | ForEach-Object { $useMap += $_ }

$domainRisk = foreach ($d in $domains) {
  $fed = $null
  if ($d.AuthenticationType -eq 'Federated') {
    $fed = Get-MgDomainFederationConfiguration -DomainId $d.Id -ErrorAction SilentlyContinue
  }
  $userCount = if ($useMap.ContainsKey($d.Id)) { $useMap[$d.Id] } else { 0 }
  $flags = @()
  if (-not $d.IsVerified)                    { $flags += 'UNVERIFIED' }
  if ($d.AuthenticationType -eq 'Federated') { $flags += 'FEDERATED-review-trust' }
  if ($d.IsVerified -and $userCount -eq 0 -and -not $d.IsDefault) { $flags += 'STALE-no-users' }

  [pscustomobject]@{
    Domain    = $d.Id
    Verified  = $d.IsVerified
    Default   = $d.IsDefault
    AuthType  = $d.AuthenticationType
    Users     = $userCount
    IssuerUri = $fed.IssuerUri
    Risk      = ($flags -join '; ')
  }
}

$domainRisk | Sort-Object Risk -Descending | Format-Table -AutoSize
$domainRisk | Export-Csv "domain-risk-$(Get-Date -f yyyyMMdd).csv" -NoTypeInformation

# Removing a stale, unused, verified domain (needs Domain.ReadWrite.All).
# A domain can only be removed once no objects reference it.
Connect-MgGraph -Scopes 'Domain.ReadWrite.All','Directory.ReadWrite.All' -NoWelcome

$stale = 'legacy-acquired-domain.example'   # from your STALE-no-users flags
# Confirm no users, groups or apps use it, then:
Remove-MgDomain -DomainId $stale

# For a federated domain you no longer trust, plan a conversion to managed
# (cloud) authentication. This is an impactful change: it moves those users'
# authentication from the external IdP to Entra, so schedule and communicate it.
#   Review with: Get-MgDomainFederationConfiguration -DomainId <domain>
#   Convert with the supported federation-to-managed process (Update-MgDomain
#   authenticationType, plus the documented cutover steps).

# These are actions at your DNS registrar and DNS host, not in Entra.
# They close the 'expired or externally controlled domain' risk directly.
#
# 1. Enable auto-renew on every domain used by the tenant. An expired domain
#    can be re-registered by anyone, then re-verified into another tenant.
# 2. Enable registrar lock (clientTransferProhibited) to block unauthorised transfers.
# 3. Restrict and MFA-protect registrar and DNS host admin accounts (tier-zero).
# 4. Monitor domain expiry dates and alert well ahead of renewal.
# 5. Consider DNSSEC to protect the integrity of your DNS records.
# 6. Keep the Entra domain-verification TXT record only as long as needed,
#    and audit who at the registrar can change DNS.
# 7. For SSPR/recovery email, avoid alternate email addresses on domains you
#    do not control, an attacker who owns that domain can receive reset codes.

Testing and Validation

1. SSPR end to end: as asmith, go to https://aka.ms/sspr, complete a reset using two registered strong methods, and confirm you receive the reset notification.
2. Method mix: confirm security questions are not offered as a reset method.
3. Domain report: re-run the Phase C script and confirm any stale domain you removed no longer appears, and no in-use domain was affected.
4. Registration: re-run the Lab 01 baseline, the SSPR-registered count should rise as enforced registration takes effect.

Security Analysis

The domain-takeover attack chain, made concrete

Understanding the threat clarifies every control above. A takeover typically runs as follows: an organisation verifies a custom domain in its tenant, then over time lets the domain registration lapse or loses control of its DNS. An attacker registers the now-available domain, gains DNS control, and can then receive email sent to addresses at that domain, including any recovery or SSPR alternate-email codes. If the domain was federated and the trust was never removed, the exposure is worse, control of the domain can enable issuing or forging tokens for users in it. The fix is to never let a trusted domain fall out of your control, and to remove trust you no longer need.

What makes this configuration sound

• Strong reset proof: two strong methods and no security questions make reset-based takeover hard.
• Minimised trust surface: stale and unnecessary domains and federations are removed, so there is less to take over.
• DNS treated as tier zero: registrar lock, auto-renew and monitored expiry close the expired-domain path.

Intentionally simplified for the lab

• Writeback is conceptual in a cloud-only tenant, it becomes hands-on in the hybrid lab.
• Federation-to-managed conversion is described rather than performed, as it is disruptive and environment-specific.

Production hardening

• Alert on any new domain added to the tenant and on any change to a domain's federation configuration.
• Maintain a register of every tenant domain with owner, registrar, expiry and DNS host, and review it quarterly.
• Prefer app and key based recovery over email, and never permit recovery email on domains outside your control.

Cleanup Instructions

# To revert the pilot, set Protection > Password reset > Properties >
# 'Self service password reset enabled' back to None in the portal.
# Remove any test domains you created for this lab (Remove-MgDomain).
Disconnect-MgGraph

Recommended Learning Links

• Enable self-service password reset
• How SSPR works, including method options
• Enable password writeback
• Manage custom domain names
• Graph API: domain resource
• Federation management and considerations

Key Takeaways and Next Lab

• SSPR is safe only when it uses strong methods and rests on domains you fully control.
• Security questions are a weak recovery factor, prefer app, key and carefully governed email.
• Expired, externally controlled and stale federated domains are real account-takeover paths, assess and remove them.
• Registrar and DNS control are tier-zero identity infrastructure, protect them accordingly.