1. Why Operations Matter

ADFS is the front door to your corporate identity. When it’s down, users can’t access email, cloud apps, or partner portals. When it’s misconfigured, you risk token‑signing key leaks or unauthorized access. A solid monitoring, hardening, and disaster recovery plan turns ADFS from a single point of failure into a resilient, trustworthy service.

In this post we’ll set up real‑time monitoring, lock down security with best‑practice configurations, and build a rapid recovery strategy – all on your lab farm. You’ll leave with a checklist you can take directly to production.

2. Monitoring ADFS Health & Activity

ADFS exposes rich telemetry through event logs, performance counters, and dedicated audit logs. We’ll cover the most important ones and how to centralize them.

2.1 Critical Event Logs

Open Event Viewer → Applications and Services Logs → AD FS → Admin. This log captures configuration errors, token issuance failures, and proxy trust issues. Key event IDs to watch:

• 100 / 101 – Service started / stopped
• 364 – Certificate expiration warning
• 501 – Token request failed (check sub‑codes)
• 1021 – Relying party trust not found
• 1200‑1203 – Freshness / clock skew issues

2.2 Performance Counters

Add the ADFS performance counters to PerfMon or your monitoring tool (like SCOM, Azure Monitor). Critical counters:

# List all ADFS counters
Get-Counter -ListSet "AD FS" | Select-Object -ExpandProperty Counter

• Token Requests / sec – Measures load
• Artifact Database Latency – WID/SQL health
• WS‑Fed Passive Requests / sec – OWA/SaaS traffic

2.3 ADFS Audit Logging

Enable verbose auditing to see every token issuance, the claims sent, and the client IP. This is essential for security forensics.

Set-AdfsProperties -AuditLevel Verbose

The audit logs are stored in the Security event log (look for event ID 1200 – “A token was issued”). You can forward them to a SIEM using Windows Event Forwarding or Azure Sentinel.

3. Security Hardening Checklist

A default ADFS install is reasonably secure, but these additional steps bring it to enterprise standard.

3.1 Disable Legacy Protocols

If you only use WS‑Fed and SAML 2.0 for modern apps, turn off older Windows Integrated Authentication endpoints and HTTP endpoints that could leak tokens.

Set-AdfsProperties -WIASupportedUserAgents @()   # Block legacy WIA by default
Disable-AdfsEndpoint -TargetAddressPath "/adfs/services/trust/13/UsernameMixed"   # Example

Review all endpoints with Get-AdfsEndpoint and disable any you don’t actively use.

3.2 Enforce Strong Certificate Policies

• Use an HSM or store token‑signing certificates in the Microsoft Platform Crypto Provider (prevents export).
• Auto‑rollover token‑signing certificates every 30 days (default is 365) with a 10‑day overlap:

Set-AdfsProperties -CertificateGenerationThreshold 30 -CertificatePromotionThreshold 10

3.3 Harden the ADFS Service Account

We already use a gMSA (Part 3), which eliminates password management. Additionally, ensure the account has no interactive logon rights and minimal AD delegation.

# Verify gMSA
Test-ADServiceAccount ADFSSvc

3.4 Restrict Network Access

• Block internet access to the ADFS server directly – only the WAP (Part 5) should be reachable from outside.
• Use firewall rules to allow only HTTPS (443) to the ADFS server from internal subnets and the WAP.

3.5 Enable Extended Protection for Authentication

This helps prevent man‑in‑the‑middle relay attacks on Integrated Windows Authentication.

Set-AdfsProperties -ExtendedProtectionTokenCheck "Require"

4. High Availability & Disaster Recovery

In production, a single ADFS server is a ticking time bomb. Here’s how to build resilience.

4.1 Multi‑Node Farm

Add a second ADFS server to the farm (using the same service account, certificate, and WID farm). Then place a load balancer (hardware, or NLB in the lab) in front of them. The federation service name sts.corp.lab resolves to the VIP.

# On secondary server:
Install-AdfsFarm `
    -CertificateThumbprint "same_ssl_thumbprint" `
    -FederationServiceName "sts.corp.lab" `
    -GroupServiceAccountIdentifier "CORP\ADFSSvc$" `
    -PrimaryComputerName "ADFS01"   # Name of primary server

4.2 Farm Backup and Restore

Regularly back up the ADFS configuration and the token‑signing/decryption certificates. The built‑in Rapid Restore Tool can rebuild a farm from scratch in minutes.

# Backup ADFS configuration
Backup-AdfsFarm -BackupDirectory "C:\ADFS-Backup" -StorageType FileSystem

# Restore on a new server (disaster scenario)
Restore-AdfsFarm -BackupDirectory "C:\ADFS-Backup" -StorageType FileSystem

Store the backup securely off‑server. The backup includes all relying party trusts, claims rules, and certificate thumbprints – everything needed to rebuild.

4.3 Artifact Database Redundancy

If using WID, only the primary server can write to the database; secondary servers use pull replication. In an outage, you must promote a secondary to primary. For true HA with immediate failover, use SQL Server with a clustered instance or Always‑On Availability Groups.

# Promote a secondary WID server to primary in an emergency
Set-AdfsSyncProperties -Role PrimaryComputer

4.4 Geo‑Redundancy

For multi‑site deployments, you can deploy separate ADFS farms in each region, each with its own token‑signing certificate, and use federation metadata trust anchors in Microsoft 365 or relying parties. However, the simplest approach is a stretched VLAN with a single farm across sites (low latency required).

5. Disaster Recovery Drill (Lab Exercise)

Let’s simulate a complete ADFS server loss and recovery using the backup we just created.

1. Delete (or shut down) your ADFS01 VM – the farm is gone.
2. Spin up a fresh Windows Server 2022 VM with the same IP and domain membership.
3. Install the ADFS role, but do not configure it yet.
4. Import the SSL certificate and the backup’s token‑signing/decryption certificates (with private keys).
5. Run the restore command:

Restore-AdfsFarm -BackupDirectory "\\backupserver\adfs" -StorageType FileSystem -GroupServiceAccountIdentifier "CORP\ADFSSvc$" -FederationServiceName "sts.corp.lab" -CertificateThumbprint "ssl_thumbprint"

The new server will become the primary, pull the configuration from the backup, and resume servicing requests within minutes. Test by accessing an IdP‑initiated sign‑on page.

6. Troubleshooting Common Issues

• Performance drop? – Check the artifact database size and run the ADFS Farm Behavior Level check. Increase WID memory allocation or migrate to SQL.
• Token signing certificate expiring? – Use Get-AdfsCertificate to check dates. If auto‑rollover is enabled, it will automatically generate a new certificate. Ensure relying parties update their metadata automatically or you notify them.
• Event ID 364: Certificate validation failed? – A certificate in the chain (SSL, token‑signing, or CA) may have expired or be revoked. Replace immediately.
• Restore fails with “account not found”? – The gMSA must exist in the domain. In a true DR, you’d have restored AD first. You can also use a local service account temporarily.

7. Next Steps 🚀

You’ve reached the pinnacle of on‑premises ADFS mastery. The final chapter is looking forward – to a world where ADFS itself becomes optional.

👉 Part 10 – Modern Migration Path: ADFS to Entra ID (Cloud Auth)
We’ll design and execute a seamless shift from federation to cloud‑only authentication, leveraging Entra Connect cloud sync, pass‑through authentication, and staged rollout. Your users won’t even notice the change.