MFG Microsoft Federation Gateway

Der neue Name für das Federation Gateway ist nun "Azure AD Authentication System "
Siehe auch https://technet.microsoft.com/en-us/library/dd335047(v=exchg.150).aspx 

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 Publickey 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 `
   -internetproxy "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.


[PS] C:\>

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

Weitere Links