MFG Microsoft Federation Gateway

Der neue Name für das Federation Gateway ist "Azure Authentication System "
Siehe auch https://technet.microsoft.com/en-us/library/dd335047(v=exchg.150).aspx und https://techcommunity.microsoft.com/t5/exchange-team-blog/the-hybrid-mesh/ba-p/605910

Diese Funktion ist mit Exchange 2013+ oder höher nicht mehr so wichtig, da OAUTH als Authentifizierung verwendet wird
Siehe auch Exchange OAuth oder Exchange Partner Application

Demystifying Hybrid Free/Busy: what are the moving parts?
https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/emystifying-Hybrid-Free-Busy-what-are-the-moving-parts/ba-p/607704
Sehr guter und wichtiger Artikel für Free/Busy zwischen Exchange 2007 und höher mit Autodiscover

Achtung:
Microsoft erzwingt TLS 1.2. Ein Exchange 2010 auf Windows 2008R2 kann dies erst mit den aktuellen Updates UND einer Freischaltung in der Registrierung. Siehe auch TLS 1.2 Enforcement

Das Federation Gateway ist eine Schlüsselkomponente für die Verbindung von Diensten zwischen Firmen. Eine der ersten Anwendungen ist natürlich mal wieder Exchange, welches für die Kalenderfederation das MFG zur Authentifizierung bemüht.

Warum?

Exchange ist der erste Nutzer dieser Funktion und anhand von Exchange ist der Mehrwert auch am schnellsten erklärt:

Wenn ein Benutzer der Firma-A einen Termin mit einem Benutzer der Firma-B abstimmen möchte, dann fragt der Client A den Exchange aus Firma-A der zum CAS-Server der Firma-B geht. Nur wie stellt der CAS von Firma-B sicher, dass die Anfrage wirklich von Firma-A kommt? Bei Exchange 2007 wurden dazu "Dienstkonten" hinterlegt. Aber es war natürlich nicht gut, dass das Dienstkonto für den Zugriff auf die Frei/Belegt-Zeiten von Firma-B nun bei allen anderen Firmen bekannt waren und es zudem ein aktives AD-Konto war. Das skaliert nicht und wenn das Kennwort geändert wird, mussten alle Partner ihre Konfiguration anpassen. Das war Version 1.0 mit Exchange 2007. Seit Exchange 2010 erfolgt die Authentifizierung über das von Microsoft bereit gestellte Federation Gateway.

Wie?

Mit der Einrichtung der Partnerschaft hinterlegt jeder Partner den Public Key eines Zertifikats beim MFG und belegt über einen TXT-Record im DNS die Authentizität dieses Schlüssels. Wenn dann ein Server zu einem anderen Server einen Zugriff starten will, dann geht der anfragende Server zuerst zum MFG um sich mit seinem Zertifikat auszuweisen und ein Ticket für das Ziel zu erhalten.

Das MFG stellt dann ein Ticket aus, welches mit den Schlüsseln des Zielserver und des MFG signiert ist. Mit diesem Ticket kann der Quellserver dann direkt den Request an das Zielsystem stellen. Das Zielsystem vertraut diesem Schlüssel vom MFG, welches auch die Domäne der Quelle enthält und damit die Abfrageberechtigungen verifiziert.

Einrichtung für Exchange

Die erste Konfiguration betrifft die Einbindung ihrer Exchange Organisation zum Microsoft Federation Gateway. Folgende Dinge sind dazu erforderlich:

Aktion Status

Firewall/Internet Erreichbarkeit einrichten

Der Exchange CAS Server muss per HTTPS mit dem Microsoft Federation Gateway sprechen können und auch die Abfrage der Free/Busy-Daten an andere Exchange Umgebungen erfolgt per HTTPS. Der Exchange Server muss also z.B.: per NAT die Server im Internet erreichen und per DNS auflösen können oder per Proxy ansprechen können. Folgende Ziele sind für MFG relevant:

207.46.150.128/25
207.46.164.0/24
*.microsoftonline-p.com
*.live.com
*.microsoftonline.com
*.microsoftonlinesupport.net

Bitte prüfen Sie diese Adressen auf Aktualität.

Zur Internet Erreichbarkeit gehört natürlich auch, dass alle Exchange Server ggfls. über den richtigen Proxy eine Verbindung versuchen und der ProxyServer das Computerkonto als "berechtigt" zulässt. Aktuelle Versionen von Exchange nutzen nicht mehr die Einstellungen des IE oder Betriebssystems, so dass Einstellungen per NETSH und PROXYCFG nicht greifen. Die PowerShell ist gefragt:

Set-Exchangeserver` 
   -InternetWebProxy "http://<proxyserver:port>"

Lokale Zertifikat erstellen

Dies kann ein "Selbstzertifikat" oder eines der öffentlichen CAs sein. Ich nutze in der Regel die Funktion mit einem eigenen privaten Zertifikat zu arbeiten. Dieses wird z.B. durch folgende Befehle lokal generiert und abgelegt.

$ski = [System.Guid]::NewGuid().ToString("N")
New-ExchangeCertificate `
   -FriendlyName "Exchange Federated Delegation" `
   -DomainName $env:UserDNSDOMAIN `
   -Services Federation `
   -KeySize 2048 `
   -PrivateKeyExportable $true `
   -SubjectKeyIdentifier $ski

FederationTrust anlegen

Mit dem nun erzeugten Zertifikat wird ein Federation Trust angelegt. Er ist damit aber noch nicht bestätigt:

New-FederationTrust `
   -Name "Microsoft Federation Gateway" `
   -Thumbprint thumbprint_des_zertifikats

# Oder mit
Get-ExchangeCertificate `
   | ?{$_.friendlyname -eq "Exchange Federated Delegation"} `
   | New-FederationTrust -Name "Microsoft Federation Gateway"

DNS-Eintrag anlegen

Dann ist es an der Zeit eben die Kennzahlen dieses Zertifikats im öffentlichen DNS für jede Domain zu hinterlegen, für die Sie die Kalender Federation zulassen wollen. Dazu generieren Sie sich einfach die erforderlichen Einträge mit folgendem Befehl, der ihnen zur Domäne den passenden Thumbprint ausgibt, aber auch gleich die komplette DNS-Zeile für das Zonenfile (zur Lesbarkeit gekürzt).

Get-FederatedDomainProof -DomainName msxfaq.de

RunspaceId : 6ae2da7b-ed01-4808-b1b4-075a5d979595
DomainName : msxfaq.de
Name       : OrgPrivCertificate
Thumbprint : 55DF3E4A0FA4CE3BF28
Proof      : 35ONcYuDBlFSjTgbJwKGrijNNFPvIqjyA34Ia==
DnsRecord  : msxfaq.de TXT IN 35ONcYuDBlFSjTgbJwKGrijNNFPvIqjyA34Ia==

Diese Information ist NICHT geheim. Über einen einfachen "NSLOOKUP -q=TXT <domain>" können Sie die Information auslesen und damit indirekt erkennen, welche Firma schon mit dem dem Microsoft Federation Gateway arbeitet. Der Thumbprint ist für alle Domains der Organisation gleich, und hängt am Federation-Zertifikat.

Aktivieren der Federation

Nachdem die DNS-Einträge vorhanden und hoffentlich repliziert sind, kann die Verbindung zum Federation Gateway aktiviert werden. Beim Einsatz der Exchange 2010 GUI aktualisiert diese zuerst die Metadaten bei Microsoft um dann den Identifier zu setzen. Das geht natürlich auch per PowerShell:

Set-FederationTrust `
   -RefreshMetaData `
   -Identity "Microsoft Federation Gateway"

Set-FederatedOrganizationIdentifier `
   -DelegationFederationTrust "Microsoft Federation Gateway" `
   -AccountNameSpace msxfaq.de `
   -Enabled $true

Weitere Domains aktivieren

Wenn Sie mehrere SMTP-Domains haben, dann können Sie diese nun über den bestehenden FederationTrust mit veröffentlichen. Natürlich ist müssen auch hierzu diese DNS-Domänen mit den passenden Keys im DNS veröffentlicht werden.

Add-FederatedDomain `
   -Domainname "zweitedomain.tld"

Diese Schritte können natürlich auch komplett mit der GUI ausgeführt werden.

 

Nachdem Sie dann die TXT-Records angelegt haben, gehen Sie in der MMC erneut auf die Verwaltung des Federation Trust, addieren die Domains und schließen den Assistenten ab.

Funktion überprüfen

Microsoft hat auch für den Federation Trust entsprechende Commandlets bereit gestellt. Einmal ist die "Test-FederationTrust", welches in sechs Schritten die wesentlichen Komponenten prüft.

[PS] C:\>Test-FederationTrust | ft id,type,message -AutoSize

Begin process.

STEP 1 of 6: Getting ADUser information for extest_1e2fec674...
RESULT: Success.

STEP 2 of 6: Getting FederationTrust object for extest_1e2fec674...
RESULT: Success.

STEP 3 of 6: Validating that the FederationTrust has the same STS certificates 
             as the actual certificates published by the STS in the federation metadata.
RESULT: Success.

STEP 4 of 6: Getting STS and Organization certificates from the federation trust object...
RESULT: Success.

Validating current configuration for FYDIBOHF25SPDLT.msxfaq.net...

Validation successful.

STEP 5 of 6: Requesting delegation token...
RESULT: Success. Token retrieved.

STEP 6 of 6: Validating delegation token...
RESULT: Success.

Closing Test-FederationTrust...

Id                           Type    Message
--                           ----    -------
FederationTrustConfiguration Success FederationTrust object in ActiveDirectory is valid.
FederationMetadata           Success The federation trust contains the same certificates published by the security token service in its federation metadata.
StsCertificate               Success Valid certificate referenced by property TokenIssuerCertificate in the FederationTrust object.
StsPreviousCertificate       Success Valid certificate referenced by property TokenIssuerPrevCertificate in the FederationTrust object.
OrganizationCertificate      Success Valid certificate referenced by property OrgPrivCertificate in the FederationTrust object.
TokenRequest                 Success Request for delegation token succeeded.
TokenValidation              Success Requested delegation token is valid.

Ob das Federation-Zertifikat richtig installiert ist, können Sie mit "Test-FederationCertificate" prüfen:

[PS] C:\>Test-FederationTrustCertificate


RunspaceId : 887ff00d-5b7f-4e0c-9fc6-724a1f48731b
Site       : msxfaq.net/Configuration/Sites/Paderborn
State      : Installed
Thumbprint : 45C0C9210FA4DD3DF60B29B641A7871BF9CF9014

Überwachen!

Zertifikats sind nicht ewig gültig. Sie laufen also irgendwann ab. wenn das MFG-Zertifikat abläuft, funktioniert aktuell dann keine Anzeige der "Free/Busy-Zeiten mehr. Aber die Funktion von MFG könnte zukünftig auch noch in anderen Diensten Verwendung finden. Leider sendet weder das Microsoft Federation Gateway noch der Exchange Server eine aktive Benachrichtigung an den Exchange Administrator. Erst wenn es schon abgelaufen ist, sehen sie im ECP eine Wartung:

Sie sollten daher eine aktive Überwachung der Zertifikate einplanen. Das kann einfach durch ein PowerShell-Script erfolgen:

[PS] C:\>(Get-FederationTrust).orgcertificate.notafter

Montag, 27. Januar 2019 10:57:21

So ein Check kann einmal am Tag einfach ausgeführt werden. Vergessen Sie danach aber nicht das alte abgelaufene Zertifikat zu löschen, ansonsten kommt die Warnung doch wieder samt Eintrag im Eventlog

Log Name:      Application
Source:        MSExchange Certificate Deployment
Date:          27.01.2017 12:59:37
Event ID:      2010
Task Category: General
Level:         Error
Keywords:      Classic User:          N/A
Computer:      EX16.msxfaq.com
Description:
The Federation or Auth certificate 03C46B33F33B00B5ABEFDE7059821E0463412B9C has expired. Renew the certificate to ensure proper functionality of Federation Trust or Auth services.

Zertifikat erneuern

Wenn ein Zertifikat abgelaufen ist oder bald abläuft, dann sollten Sie auch die Schritte dokumentieren, um das Zertifikat zu verlängern. Letztlich erstellen Sie einfach ein neues Zertifikat, welches dann durch Exchange auf alle Server repliziert wird.

Achtung
Ein neues Zertifikat hat einen neuen Hashwert. Insofern müssen Sie bei allen Domänen den TXT-Record aktualisieren.

Die Federation Services unterstützen aber schon ein "Zertifikat Rollover, d.h. sie addieren ein neues Zertifikat neben das vorhandenen noch gütige Zertifikat. Dann tragen Sie die DNS-Einträge ein und am Schluss schalten Sie einfach das Zertifikat um,

Aktion Status

Neues Federation Zertifikat rechnen

Zuerst erstellen wir auf eine beliebigen Exchange Server ein neues Zertifikat

# Generating new GUID
$SubjectKeyIdentifier = [System.Guid]::NewGuid().ToString("N")

# Create new selfsigned certificate
$cert= New-ExchangeCertificate `
   -FriendlyName "Exchange Federated Sharing" `
   -DomainName $env:<contoso.com> `
   -Services Federation `
   -KeySize 2048 `
   -PrivateKeyExportable $true `
   -SubjectKeyIdentifier $SubjectKeyIdentifier

Neues Zertifikat für Federation addieren

Nun sorgen wir dafür, dass das neue Zertifikat von Exchange für Federation eingebaut wird. Exchange repliziert das Zertifikat auf alle Server.

Set-FederationTrust "Microsoft Federation Gateway" `
   -Thumbprint $cert.thumbprint

DNS Updates

Jede Domäne, die das Zertifikat nutze, muss nun die neuen TXT--Records für das neue Zertifikat bekommen. Wie belegen quasi damit, dass das Zertifikat autoritativ ist. Das ist bei mehreren Domänen etwas aufwändiger.

forech ($domain in Get-AcceptedDomains) {
   Get-FederatedDomainProof -DomainName ($domain.domain)
}

Kontrolle der Replikation

Ehe wir weiter machen, müsse wir prüfen, dass das Zertifikat bei allen Servern angekommen ist:

Test-FederationTrustCertificate

Neues Zertifikat aktivieren

Set-FederationTrust "Microsoft Federation Gateway" -PublishFederationCertificate
Set-FederationTrust "Microsoft Federation Gateway" -RefreshMetadata

Funktionstest

Der einfachste Weg zu kontrollieren, dass die Federation auch mit dem neuen Zertifikat funktioniert, ist ein Test.

Test-FederationTrust `
   -UserIdentity msxfaq.de `
   -Verbose

Sie sollten sehen, dass das Commandlet erfolgreich ein Token erhalten konnte

Weitere Links