ADFS Signing Zertifikat aktualisieren

"Alle Jahre wieder" ist nicht nur ein Spruch zu Weihnachten. Auch dem ADFS-Service sollte einmal im Jahr etwas Aufmerksamkeit zuteil werden, ob er denn sein "Signing-Zertifikate" korrekt aktualisiert und dann die abhängigen Dienste dieses neue Zertifikat erhalten. Mit Office 365 wird das erste Zertifikat per Powershell noch in die Cloud hochgeladen. Siehe ADFS mit O365.

Zum Tausch der ADFS Service  Keys gibt es die eigne Seite ADFS Service Zertifikat aktualisieren

Zeitpunkt erkennen

Technisch handelt es sich zum Zertifikate, die natürlich überwacht werden können. Allerdings wird z.B. das Signing-Zertifikat nur zum Ausstellen der Tickets verwendet aber nicht als Webseite o.ä. erreichbar gemacht. Tools, die per TLS-Handshake ein Zertifikate überprüfen, können dies also so erst einmal nicht erkennen. Aber es gibt ja andere Wege:

  • Eventlog ADFS-Server
    Auf dem ADFS-Server wird ein bald ablaufendes Zertifikat natürlich im Eventlog gemeldet
  • Powershell ADFS-Server
    Über die lokale PowerShell kann ebenfalls der Status des ADFS-Servers überprüft werden.
  • ADFS-Service
    Natürlich kann auch der Dienste, der die ADFS-Tickets auswertet erkennen, dass ein Signing-Zertifikat bald abläuft. Schließlich versucht er auch das aktuelle Signing-Zertifikat selbständig zu holen.
  • Abruf der Federation Metadata
    Aber am einfachsten wird es sein, wenn man einfach die Federation Metadata per HTTPS abruft und die darin enthaltenen Zertifikate prüft. Siehe dazu ADFS Monitoring

Es gibt also eine ganz umfängliche Möglichkeiten hier zu überwachen. Für PRTG habe ich da ein Skript gebaut, welches die Federation Metadata abruft und das dort veröffentliche Zertifikat auswertet.

ADFS und Office 365

In Verbindung mit Office 365 überwacht Microsoft z.B. die Partnerschaft und zeigt die im Admin im Panel entsprechende Meldungen an.



Und wer hier nicht regelmäßig nachschaut, bekommt noch mal eine Mail:

Das ganze Spiel wiederholt sich immer wieder:

Die Warnung von Microsoft ist leider etwas früh, denn das Zertifikat wird von ADFS erst 20 tage vor Ablauf "automatisch" neu generiert. Wenn Sie vorher versuchen das Zertifikat zu ersetzen, bremst Sie ADFS erst mal aus:

Wenn Sie die Zertifikatserneuerung also nicht manuell machen wollen, dann müssen Sie diese Mails ein paar Tage ignorieren und erst dann aktiv werden. Das jährliche Update können Sie über einen "geplanten Task" durchführen, bei dem aber die Anmeldedaten hinterlegt werden müssen.

Microsoft Federation Metadata Update Automation Installation Tool
http://go.microsoft.com/fwlink/p/?linkid=248972
https://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
Tool von Microsoft um den geplanten Task zu erstellen

Sie können aber auch auf die Mail warten und dies manuell ausführen. Die Befehle sind recht einfach:

# Office 365 Modul laden
Import-Module MSOnline

#Office 365 Credentials einsammeln
$cred=Get-Credential

#Verbindung mit Office 365 herstellenb
Connect-MsolService -Credential $cred

# Optional den ADFS-Server angeben, wenn der Admin auf einem anderen PC angemeldet ist
Set-MSOLAdfscontext -Computer <interner ADFS-FQDN>

# ADFS-Properties in der Cloud aktualisieren
Update-MSOLFederatedDomain -DomainName <adfs-domain>

Aber das ist natürlich nur die eine Seite einer ADFS-Konfiguration. Auf der anderen Seite steht natürlich das System, welches den Tickets des ausstellenden ADFS-Servers vertraut. Dieses System benötigt das Signing-Zertifikat, um die Gültigkeit der Tickets zu prüfen.

Once the relying party trust is established, it must also be maintained. It is possible that one or more of the URL's that identify the relying party may change, or the set of claims that the relying party will accept might change, but more likely, the X.509 Certificate used für encryption will have to be replaced, either because it has expired or because it has become compromised. Managing the updating of encryption certificates across an organization that might contain hundreds, or thousands, of relying parties presents a daunting challenge.
Quelle: http://blogs.msdn.com/b/card/archive/2010/06/25/using-federation-metadata-to-establish-a-relying-party-trust-in-ad-fs-2-0.aspx

ADFS Auto Enrollment

Wenn ADFS so wichtig für die Funktion ist, und das Signing-Zertifkat per Default jedes Jahr abläuft, dann ist das für jeden Office 365 -Tenant eine latente Gefahr und wenn es tausende oder Millionen von Tenant gibt und davon nur ein Prozent einen Fehler hat, sind dies sehr viele Anwender, die nach einem Jahr weder an ihr Exchange Postfach, ihr OneDrive, ihre SharePoint-Seiten kommen und mittlerweile vielleicht gar nicht mehr telefonieren können.

Es es gibt eine Lösung in Form eines "Auto Enrollment", der aus drei Bestandteilen besteht:

  • ADFS-Server muss Signing-Zertifikat alleine aktualisieren
    Der Windows ADFS-Server kann das Zertifikat alleine kurz vor dem Ablauf erneuern. Dies können Sie wie folgt prüfen.
PS C:\> Add-Pssnapin Microsoft.Adfs.Powershell

# ab Windows 2013 ist die ADFS-Verwaltung ein Modul
PS C:\> Import-Module ADFS

PS C:\> Get-AdfsProperties | fl *certificate*

AutoCertificateRollover : True
CertificateCriticalThreshold : 2
CertificateDuration : 365
CertificateGenerationThreshold : 20
CertificatePromotionThreshold : 5
CertificateRolloverInterval : 720
CertificateSharingContainer : CN=<GUID>,CN=ADFS,CN=Microsoft,CN=ProgramData,DC=msxfaq,DC=net
CertificateThresholdMultiplier : 1440
  • Bereitstellung des Zertifikats
    Dann muss der ADFS-Server natürlich das neue Zertifikat bereitstellen, damit die davon abhängigen Dienste dieses in ihre Konfiguration übernehmen können. Das macht der Windows ADFS-Server ebenfalls. Unter der folgenden URL kann jeder auch Anonym diese Information beziehen. Voraussetzung ist natürlich, dass diese URL auch veröffentlicht und vom anderen Dienst erreichbar ist.
https://(your_FS_name)/federationmetadata/2007-06/federationmetadata.xml
  • Import des Zertifikats
    Nun bleibt noch die Applikation auf der anderen Seite, der Sie die URL zur federationmetadata.xml hinterlegen müssen. Dann muss dieser Dienst einfach nur "oft genug" diese URL wieder abfragen.

Auf dem ADFS-Server können Sie den Prozess des RollOvers im Eventlog einfach erkennen. Folgende Events sollten Sie chronologisch im "AD FS/Admin"-Eventlog finden:

EventID Beschreibung

335

MSIS10005: Certificate rollover service has added certificate with thumbprint '46AD9FE08F79339E42E20E499C215F15F950BC3F' to 'Encryption' certificate collection.

335

MSIS10005: Certificate rollover service has added certificate with thumbprint '2A47C8D6F6C06577DFC2C1FEB6F739378009C456' to 'Signing' certificate collection.

336

The certificate management cycle was initiated.

358

Restarting Issuance ServiceHost. This restart is necessary because a change was detected in the certificates that this service host uses. Requests that are served by endpoints of this service host may fail during restart.

335

MSIS10004: Certificate rollover service has set certificate with thumbprint '46AD9FE08F79339E42E20E499C215F15F950BC3F' as primäry 'Encryption' certificate.

358

Restarting Issuance ServiceHost. This restart is necessary because a change was detected in the certificates that this service host uses. Requests that are served by endpoints of this service host may fail during restart.

335

MSIS10004: Certificate rollover service has set certificate with thumbprint '2A47C8D6F6C06577DFC2C1FEB6F739378009C456' as primäry 'Signing' certificate.

337

The certificate management cycle was completed.

335

MSIS10006: Certificate rollover service has removed certificate with thumbprint '9A3C9DE3FAE34EF822ADDEF7CA66F3486A0F2C0E' from 'Signing' certificate collection.

335

MSIS10006: Certificate rollover service has removed certificate with thumbprint '4F697BAB96E1521ADDCDB09733889379B9F4307A' from 'Encryption' certificate collection.

Leider stellt der ADFS 20 und höher keine Logdateien analog zu einem IISLog bereit, so dass Sie hier gar nicht einfach ermitteln können. ob und wie oft die Gegenseite auch die Federationmetadata.xml abruft. Das geht allerdings, wenn Sie z.B.: einen Loadbalancer oder Reverse Proxy davor geschaltet haben, welcher dann diese HTTP-Request protokollieren kann.

Damit ist schon einmal sichergestellt, dass der ADFS-Server nicht mehr mit eine alten abgelaufenen Zertifikat signiert. Aber die Gegenseite muss natürlich den Zertifikatswechsel mitbekommen. AzureAD macht das automatisch, wenn die FederationMetadataURL hinterlegt wurde.

Azure AD updates certificates via an autorollover process in which it attempts to retrieve a new certificate from the federation service metadata, 30 days before expiry of the current certificate. If a new certificate isn't available, Azure AD monitors the metadata daily and will update the federation settings for the domain when a new certificate is available.
Quelle: Update samlOrWsFedExternalDomainFederation https://docs.microsoft.com/en-us/graph/api/samlorwsfedexternaldomainfederation-update

Das ist natürlich auch für alle anderen verbundenen Applikationen zu beachten, die den Federation-Service nutzen. Auch in der umgekehrten Richtung kann das Thema relevant werden, d.h. AzureAD kann auch einen anderen Federation-Service nutzen. Hier sollten Sie dann natürlich prüfen, ob dieser die Metadaten ebenfalls bereit stellt.

Aktuelle Konfiguration abfragen

Wenn ADFS nicht funktioniert, dann ist ein schneller Blick auf die aktuellen Einstellungen sinnvoll:

# Office 365 Modul laden
Import-Module MSOnline

#Office 365 Credentials einsammeln
$cred=Get-Credential

#Verbindung mit Office 365 herstellenb
Connect-MsolService -Credential $cred

# Aktuelle Einstellung anschauen
Get-MsolDomainFederationSettings -domain netatwork.de

ActiveLogOnUri                         : https://sts.netatwork.de/adfs/services/trust/2005/Usernamemixed
DefaultInteractiveAuthenticationMethod :
FederationBrandName                    : Net at Work GmbH
IssuerUri                              : http://sts.netatwork.de/adfs/services/trust
LogOffUri                              : https://sts.netatwork.de/adfs/ls/
MetadataExchangeUri                    : https://sts.netatwork.de/adfs/services/trust/mex
NextSigningCertificate                 : MIIC3jCCAcagAwIBAgIQUjCcCNT+6rJInd6UloEsaTANBgkqhkiG9w0BAQsFADArMSkwJwYDVQQDEyBBREZTIFNpZ2
                                         5pbmcgLSBhZGZzLm5ldGF0d29yay5kZTAeFw0xNTEyMjUxOTM1MTJaFw0xNjEyMjQxOTM1MTJaMCsxKTAnBgNVBAMT
                                         IEFERlMgU2lnbmluZyAtIGFkZnMubmV0YXR3b3JrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvQ
                                         tHBV5baVMz63x45KfcQVfN4jXqEq2HL32T/gplxl1ELqzp8t1eQfo3J5lip22ZLQXTK2fmCPfy3MbJ/0nPOwqr2ak7
                                         Q1rZY63RUTr7+s2qXlsyE4gvrjmzwyaNOuIY6lqal2/Y+A7z6Nt9oiKe4ypbd5JwXtjIZrjlmrhKMsIFoaLoUtiA03
                                         xSeCiTP5RT4DAFquxdoyi31PCI10BsrKFyK/EF5Dxnj4uFaBKVZBoRzHxsrunalerCSaVJgjhEXcta75YvXHcCUoqs
                                         64e6120x2TsU2X1eH1QuIvNkVxWna1o18xfRG0u2UN6TS9wRlvP2tiagz8xxeaxVoEIo+QIDAQABMA0GCSqGSIb3DQ
                                         EBCwUAA4IBAQCh7DBtU2LNJ0AJXExkZKLCpV0O/EIVkcenIDHZsDdCeopRJqPgRlz/eh35Mby/rTza8UFr3MJ0CFTX
                                         I+oBNQquGu2B0OMDjdL6tFu0JLkx6Bvtb3kgL0baX8ber8rnyHvlP7yPS+GA7NOuFyChTFUVYH/dtBGgnLV1TTr8Hp
                                         hG7kgcViKXyqQxTd599UQgkUazzs2Ulrda5vIKEjVlmCqfPkpB6U5ULzun59DM3JoNcoGVXzLhShMPr7GUCbSBDZlb
                                         XD4JOlWyXv6NRBM5f11wxaO9kut+gS9hsegmUqYG+CLNN5lwA1KW8bhKURv0QQZCU1ZMxJNFd5zr1Kix9OSw
OpenIdConnectDiscoveryEndpoint         :
PassiveLogOnUri                        : https://sts.netatwork.de/adfs/ls/
SigningCertificate                     : MIIC3jCCAcagAwIBAgIQbhqjNUEuy5BLLNpzrZr2DjANBgkqhkiG9w0BAQsFADArMSkwJwYDVQQDEyBBREZTIFNpZ2
                                         5pbmcgLSBhZGZzLm5ldGF0d29yay5kZTAeFw0xNTAxMTQxMjM4NTdaFw0xNjAxMTQxMjM4NTdaMCsxKTAnBgNVBAMT
                                         IEFERlMgU2lnbmluZyAtIGFkZnMubmV0YXR3b3JrLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA9Z
                                         FNJ3dOjtBJgfbW4UmFtwwwhVpopSFtevnWtI5HL2BgHTpYPHB3jh9vO919M1VHZNXngG6v7HCWs8dbSVVeP1lfiPS8
                                         1yORYq4Rro54dy0BXXWBEqBBfJ6gYfLzbQ8UsVE7+4WTiy/rz8mGwi2JXq1BL3Mda+gw6vmLOaHelxNJf7X2G+gtRr
                                         p+WXCpsYGW7W3Z4ppRfI3VA3hH6UYpJD3XhT4MmY3Syj+GGOjwstaRWj5NhUhfZ5ScNLmu/8CPeyc43pzRVzk2p4dZ
                                         hjKIz++MhiN2S9PZBRSk0kSeev+HUCPHtRCvVHoYXqPA+b1n2QmzRM24sf6hdBO/NZfSvQIDAQABMA0GCSqGSIb3DQ
                                         EBCwUAA4IBAQCRHrqG0Lm1ENmWyYM3NxsRQCpwcxFQHmAGGVfuxRxiCGZCLXDvZaePrlHRqTANWT0c7Y73aWmzPSdN
                                         qoIVXam91h265z7USGga0S9g91eIAWlvMH0wXbLQGmdZsIqciZVe7Uc+7rDRhrIr47Q7b0JVL+7jfwp5C+1F4A1s8u
                                         HXh4LejRuaKR+9OXwnm+VrjkSWapETY8rbxakD07X+jkhwGpVhXrugVSgMllIFuDnKZ/+X9AZRYw7HdqwHrJs88UG7
                                         0zIDd/GTEYyJWb7rugYG/Ila9sl+yzOI4PyVmhT23vl+Yhzhw+RwKlCbrgNzwmkwkREWx1SqOAdtbh/BFHnZ
SupportsMfa                            : False

Sie sehen hier auf einen Blick die URLs zu den ADFS-Servern aber auch die hinterlegten Zertifikate.

Yammer und Co

Nicht alle Dienste unterstützen aber die "AutoCertificateRollover". Dazu gehört 2015 auch immer noch Yammer. Es wurde zwar schon oft gemunkelt, dass Yammer irgendwann auch einfach Azure-AD und damit den ADFS-Service von Office 365 nutzen könnte, aber bislang müssen Sie immer noch einen eigenen Federation Trust aufbauen. Auch der DirSync für Yammer ist immer noch ein einer Service und läuft parallel zu DirSync, ADSync, AADConnect.

Und da Yammer anscheinend immer noch nicht den automatischen Download des Signierungszertifikats unterstützt, dürfen/müssen sie heute noch die Daten manuell abrufen und über ein Ticket in Yammer einspielen lassen.

After you enable SSO, it’s your responsibility to track certificate expiration dates. These generally occur once a year. If a certificate expires, Users will not be able to log in to Yammer. Plan to renew certificates two to three weeks before they expire by opening a support case consult with the documentation für your identity provider to understand how they manage certificate rollovers.
To add new certificates to your SSO connection, open a support case with Microsoft, and include the new certificates. Make sure that all certificate files (.cer files) are attached in a compressed file that uses a .zip file name extension. To avoid any interruption to service, you can add the new certificates as secondary certificates that operate in parallel with the old certificates. Old certificates will be removed later.
Quelle: Set up single sign-on in a Yammer network
https://technet.microsoft.com/en-us/library/dn800661.aspx

The moral of the story:  ADFS uses a lot of certificates.  O365 will autorenew (gracefully in our case, your mileage may vary), but Yammer requires intervention and planning if you're using SSO.
Yammer SSO gotcha - ADFS certificate autorenewal
Quelle: http://blaughwtech.blogspot.de/2014/12/yammer-sso-gotcha-adfs-certificate.html

Mittlerweile können Sie aber auch in Yammer eine Authentifizierung an Office 365 erzwingen.

Damit verliert der ADFS Zertifikats Rollover auch bei Yammer seinen Schrecken. Allerdings muss dazu natürlich die Anmeldung als Admin an Yammer möglich sein. Wer also den Wechsel des ADFS-Zertifikats verpasst hat, muss erst noch einmal das neue Signing-Zertifikat einspielen lassen um sich dann als Admin anzumelden und die Einstellung auf Office 365 zu ändern.

SharePoint u.a.

Auch SharePoint 2013 kann einen Wechsel des Signing-Zertifikats nicht alleine umsetzen. Meine Kollegen von Net at Work haben daher ein kleines Powershell-Skript gebaut, welches im SharePoint die Konfiguration aktualisiert:

param (
   $adfsserver = "adfs.msxfaq.de"
)

Write-host "Lade Code Signing Zertifikat"
$result = Invoke-WebRequest -Uri "https://$($adfsserver)/federationmetadata/2007-06/federationmetadata.xml"

# Write-host "Konvertiere Zertifikat"
$content = [xml]$result.Content
$s1 = $content.EntityDescriptor
$RawCert = $s1.RoleDescriptor[0].KeyDescriptor.KeyInfo.X509Data.X509Certificate
$Header = "-----BEGIN CERTIFICATE-----"
$Footer = "-----END CERTIFICATE-----"
$NewCert = $Header
$NewCert += $RawCert
$NewCert += $Footer

Write-Host "Schreibe CER-Datei"
$NewCert | Out-File -FilePath D:\Install\newCert_Temp.cer -Force

Write-Host "Lade CER-Datei in Objekt" 
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("D:\Install\newCert_Temp.cer" )

Write-Host "Aktualisiere SharePoint" 
Get-SPTrustedRootAuthority | ?{$_.name -match "ADFS"} | Set-SPTrustedRootAuthority  -Certificate $cert
Get-SPTrustedIdentityTokenIssuer | Set-SPTrustedIdentityTokenIssuer -ImportTrustCertificate $cert

Write-host "Done"

Den ersten Teil können Sie natürlich auch für ihre anderen Produkte verwenden um das aktuelle Signing-Zertifikat in eine Datei zu exportieren. Das Update in der Konfiguration ist dann aber wieder individuell. Wenn ihre Software nicht zwei Zertifikaten vertrauen kann, dann müssen Sie den Wechsel entsprechend abstimmen.

  • PRTG Check ADFS
    PowerShell Script um die Gültigkeit des Zertifikats zu prüfen

Zertifikatstore und Datenbank

Wer mit der MMC für Zertifikate auf dem Windows Server nun nach dem Token Signing und Token Encryption-Zertifikat sucht, wird erst mal verblüfft sein. Weder im privaten Speicher des Computers noch des Dienstkontos finden sich die entsprechenden Zertifikate. Im Computer-Store befindet sich nur das Zertifikat für den IIS an der gewohnten Stellen.

ADFS speichert die Konfiguration nicht in irgendwelchen Dateien ab, sondern nutzt die Windows Internal Database (WID). Unter C:\Windows\WID\Data liegen neben den üblichen Datendateien auch eine "AdfsArtifactstore" und AdfsConfiguration"

Zertifikatspeicher und AD/LDAP

Oft unbemerkt gibt es aber noch einen zweiten Speicher, in den ADFS sein Schlüsselmaterial ablegt. Sie bekommen darauf einen Hinweis, wenn der Key-Rollover nicht funktioniert.


Auszug Eventlog EventID 332

In der Domäne gibt es ebenfalls einen Speicherort, in denen ADFS Informationen ablegt.

OU=ADFS,OU=Microsoft,OU=Program Data,DC=msxfaq,DC=net

Wenn ich mit das "Creationdate" der Container mit der GUID anschaue, dann passen diese Werte recht gut auf den Zeitpunkt, zudem das Signing Zertifikat aktualisiert wurde. Bei den Eigenschaften fallen zwei Felder auf:

  • givenName = 2.16.840.1.101.3.4.1.2
    Laut https://oidref.com/2.16.840.1.101.3.4.1.2 steht dieser Wert für "aes128-CBC"
  • thumbnailPhoto
    Ich wüsste nicht, warum ein Contact hier ein Bild braucht und die Daten scheinen auch kein Bild zu sein, weil der Anfang weder auf JPEB (0xFF 0xC0) noch auf GIF (0x47 0x49 0x46) anhand des Headers hinweist. Hier scheint ADFS selbst ein Binär-Feld zweckentfremdet zu verwenden.

Wenn das ADFS-Dienstkonto keine Berechtigungen auf diesen LDAP-Bereich hat, dann sehen Sie einen Fehler 332 im Eventlog. Eventuell können Sie dies dann wieder wie folgt korrigieren:

Set-AdfsCertificateSharingContainer -ServiceAccount DOMAIN\ADFSSERVICEACCOUNT

An der gleichen Stelle hinterlässt übrigens auch Lync/Skype for Business einige Einträge:

 

Backup / Restore

Wer eine ADFS-Farm aus mehreren Servern betreibt, kann  mit dem Thema Backup/Restore entspannter umgehen, da die Konfiguration als auch die Zertifikate zwischen den Servern synchronisiert werden. Fällt ein Server aus, wird er einfach neu installiert. Selbst wenn der primäre Server ausfällt, können die Anwender weiter authentifiziert werden. Wird eine Konfigurationsänderung erforderlich, dann muss ein sekundärer Server zum primären Server hochgestuft werden.

Betreiben Sie aber nur genau einen ADFS-Server, dann sollten Sie auch den "Verlust" des Servers betrachten. Sicher kann ein neuer ADFS-Server schnell wieder aufgesetzt werden. Aber das neue Token Signing und Token Encryption Zertifikat muss bei allen Partnerschaften wieder neu eingetragen werden. Diese Änderung kann dann je Partner durchaus einige Stunden dauern, bis diese wieder aktuell ist.

Insofern sollten sie zumindest die Zertifikate und die Konfiguration sichern

If you have your SQL DB backuped up, you need SSL, Token Signing and Token Decryption certificates with private keys also to be backed up. This set of backuped data lets you install new ADFS role on any W2K12R2 server and join to the ADFS farm. Quelle: How to backup and restore Windows 2012R2 ADFS

If you want to have ONLY a backup of RP or/and CP you can run export-federationconfiguration.ps1 I mentioned with "-RelyingPartyTrustName" switch.

Quelle: How to backup and restore Windows 2012R2 ADFS
https://social.technet.microsoft.com/Forums/windows/en-US/507a1002-939f-4120-a69c-0e227ca21081/how-to-backup-and-restore-windows-2012r2-adfs?forum=winserverDS

Andrzej Kazmierczak (MVP) hat in 2014 im gleichen Thread sogar eine sehr umfangreiche Auflistung erstellt, die ich hier mit archiviere.

  • 0. Always backup your SSL, Token-Signing and Token-Decryption certificates with private keys.
  • 1. You should always backup SQL ADFS DBs. It stores all necessary ADFS configuration (except private keys of certificates and custom developed files). After SQL restore you simply reinstall ADFS role on any given server and configure ADFS to use current SQL DB to pull ADFS configuration (during joining ADFS server to the farm wizard).
  • 2. If you don't have SQL backup, you need to recreate ADFS configuration manually, and you should backup:
    • a) Certificates properties (Get-ADFSCertificate | Out-File ".\certificates.txt" and netsh http show sslcert | Out-File ".\showsslcert.txt")
    • b) ADFS properties (Get-ADFSProperties | Out-File ".\properties.txt")
    • c) ADFS service account name and password
    • d) Application configuration file C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config
    • e) If you have cusotmized endpoints, claimtypes or attributes store (Get-ADFSEndpoint | Out-File ".\endpoints.txt" or Get-ADFSClaimDescription | Out-File ".\claimtypes.txt" or Get-ADFSAttributeStore | Out-File ".\attributestore.txt")
    • f) You can export configuration settings for you Relying Party and/or Claims Provider. To export run the PowerShell script from the media/server_en-us/support/adfs path of the W2K12R2 installation media or from C:\Windows\ADFS\ path: export-federationconfiguration.ps1.

Da ein einzelner ADFS-Server aber kein "besonders großer" Server ist, können Sie auch überlegen den kompletten Server zu sichern oder mit Hilfsmitteln der Virtualisierung zu arbeiten.

Weitere Links