ADFS Basics

ACHTUNG
Die ADFS-Rolle in Windows 2008/2008R2 ist nur ADFS Version 1.0. für den Einsatz mit der Cloud müssen Sie Version 2.0 verwenden.

Step-by-Step Guide für Active Directory Federation Services
http://www.microsoft.com/download/en/details.aspx?id=15992

Office 365: Configuring DirSync and Single Sign On with ADFS
http://blogs.technet.com/b/ptsblog/archive/2013/05/07/office-365-configuring-DirSync-and-single-sign-on-with-adfs.aspx 

Bei der Installation auf Win2012 Servern müssen die Domains mit dem "Windows Azure Active Directory (WAAD) Module für Windows PowerShell" konvertiert werden.
http://www.msexchange.org/blogs/walther/news/office-365-federation-using-windows-server-2012-based-adfs-servers.html

Active Directory Federation Services,Part 1: How Do They Really Work
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM402
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM403

ADFS Calculator
http://download.microsoft.com/download/3/1/3/31312F45-4AB3-4B54-8E23-6326BAF4F5BC/adfs-capacity-planning-sizing-spreadsheet-DLC.xlsx

Basierend auf einem 4 Core können 10.000 user auf 5 Dienste mit 60% Anmeldungen innerhalb der "Busy Hour" mit 0,08 Servern bedient werden. Rechnen Sie einfach selbst.

Gehen wir mal davon aus, dass alle Leser aktuell noch ihren eigenen Exchange Server, eventuell schon Lync und Sharepoint betreiben. Auf jeden Fall dürften alle Firmen mit mehr als nur einer Hand voll PCs eine Domäne (also Active Directory) haben, indem heute schon Benutzer und Computer gepflegt werden und vielleicht auch die ein oder anderen Stammdaten (z.B. Telefonnummer etc.) enthält. Im Gegensatz zur den Überlegungen, die ich auf Cityhosting angestellt habe, vertraut die Cloud ihnen nicht, d.h. es gibt keinen Trust.

Im Hintergrund basiert auch Office365 natürlich auf Windows Servern, Exchange, Lync etc. in angepasster Form und natürlich müssen dort auch die Anwender, Postfächer etc. gepflegt werden. Diese Aufgabe können Sie bei geringen Benutzeranzahlen natürlich über die bereitgestellte Verwaltungsoberfläche machen. Aber sehr schnell werden Sie sich einen automatischen Abgleich wünschen. Diese Funktion liefert der Office 365 DirSync, den ich auf eigenen Seiten beschreibe.

Für ADFS ist dieser dahingehend wichtig, dass die Benutzer in Office 365 einige "besondere" Eigenschaften benötigen, damit die Office 365 Dienste nicht ein Kennwort in Office 365 zur Verwaltung anfordern, sondern vom Client ein ADFS-Ticket verlangen.

Innerhalb von Office 365 gibt es beim Benutzer keinen unterschied, ob dieser sich per ADFS anmeldet oder mit einem Kennwort kommt. für die Nutzung von ADFS ist ausschließlich die Aktivierung der Domäne und die korrekte Pflege der UPNs (z.B.: per Office 365 DirSync) erforderlich.

Funktionsweise

Dienste, die "ADFS-tauglich" sein, lehnen eines Zugriff eines Anwenders auf eine Ressource natürlich auch erst einmal mit einer "Nicht autorisiert"- Meldung ab. Diese Meldung enthält wieder die Information über mögliche Anmeldeverfahren. Hier ist dann aber nicht mehr nur BASIC, NTLM, KERBEROS eine Option, sondern eben auch Informationen, dass der Client ein Ticket vorweisen kann, welches es sich an einer angegebenen URL besorgen kann. Technische Details dazu finden Sie auf Office 365 ADFS Intern.

Ein entsprechend konfigurierter Client geht dann zu der URL um sich ein Ticket zu besorgen. Das ist der ADFS-Server, welcher auch "nur" eine Webseite ist. Den ADFS-Server betreiben Sie in ihrem LAN und interne Client können sich quasi direkt per "integrierter Authentifizierung" anmelden und erhalten ein Ticket, welches sie dann an den gewünschten Dienst weiter leiten.

Externe Anwender müssen von "draußen" auch auf den ADFS-Server zugreifen. Daher muss dann die URL auch im Internet erreichbar sein und der Zugriff per HTTPS abgesichert werden. Ein Zertifikat ist also erforderlich. Das Zertifikat für die Absicherung der ADFS-Webseite muss eigentlich kein offizielles Zertifikat sein. Zumindest dann nicht, wenn die Clients alle ihnen bekannt sind und z.B.: durch die Mitgliedschaft in der Domäne auch ihrer internen privaten Stammzertifizierungsstelle vertrauen. Sollten aber Mitarbeiter auch auf anderen Clients (z.B. privaten Computer) OWA und andere Cloud-Dienste nutzen, dann ist ein offizielles Zertifikat ratsam. Wenn alle Clients ihrer Office 365 Cloud immer nur intern sind, oder per VPN oder Direct Access sich wie intern verhalten, dann müssen Sie ADFS nicht veröffentlichen, solange Sie nur "Webdienste", also "SharePoint Online" oder "Outlook WebApp" in der Cloud nutzen.

Achtung:
Aktuell benötigen Sie ein offizielles Zertifikat, wenn Sie Outlook mit der Cloud einsetzen, da Outlook sich hier nicht das ADFS-Zertifikat holt, sondern Outlook die Anmeldedaten zu Office 365 sendet (Basic Auth mit SSL) und der Exchange CAS aus der Cloud sich dann mit ihren Daten von ihrem ADFS-Server ein Token holt. Gleiches gilt  auch

Für die Veröffentlichung ist ein Reverse Proxy ratsam. ADFS selbst kann auch als ADFS-Proxy auf einem zweiten System installiert werden, um z.B. von extern eine Anmeldung per "Formular" zu erlauben während intern der direkte Zugriff eine integrierte Anmeldung ermöglicht. Dies kann aber auch z.B.: mit TMG oder anderen Lösungen erreicht werden.

Hat der Client dann das ADFS-Token erhalten, sendet er es zum Service, welcher prüft, ob dieses Token von einer "vertrauenswürdigen" Stelle kommt. Das Token ist nämlich ebenfalls durch das Zertifikat des ADFS-Servers "digital signiert". Auch hierbei können Sie ein privates Zertifikat verwenden. Dieses müssen Sie aber in die Office 365-Cloud "hochladen", damit die Cloud das Token prüfen und als gültig erkennen kann.

Hinweis:
Auch dieses Zertifikat ist nicht endlos gültig. Stellen Sie also sicher, dass es ausreichend lang gültig ist und Sie rechtzeitig diese erneuern.

Active Directory Federation Services,Part 1: How Do They Really Work
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM402
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM403

Exchange Virtual Conference: Office 365 Identities and Federation
http://exchangevirtualconference.com/evc-2013-session-5/

Whiteboard video: How ADFS and the Microsoft Federation Gateway work together up in the Office 365 Cloud.
http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-federation-gateway-work-together-up-in-the-office-365-cloud.aspx

Hinweis zum Betrieb

ADFS vereinfacht die Anmeldung durch Anwender und verhindert, dass Kennworte in der Cloud abgelegt und verwaltet werden müssen. Erforderlich ist natürlich eine lokale Domäne. Die Anwender nutzen also ihre lokale Zugangsdaten, um sich quasi "Single SignOn" an der Cloud anzumelden. Damit sind sind natürlich einige Randbedingungen zu beachten:

  • Eigene Domäne
    Zuerst benötigen Sie natürlich eine eigene Active Directory Domäne. Ansonsten ist der Einsatz von ADFS nicht sinnvoll. ADFS 2 kann mit auf einem DC installiert werden. Allerdings sollten Sie die Anforderungen an die Sicherheit besonders beim externen Zugriff und die Abhängigkeiten bei Updates  berücksichtigen. Je mehr Benutzer sie haben, desto eher setzen Sie einen eigenen Server (gerne auch virtuell) auf.
  • Verzeichnisabgleich
    Bei der Pflege der Benutzer in der Cloud sollten Sie auch auf den Verzeichnisabgleich von Office 365 überlassen. Sie ersparen sich die manuelle Pflege. Allerdings "kostet" sie das einen weiteren (virtuellen) Server
  • Risiko des Ausfalls
    Wenn die Clients keine "Tickets" vom ADFS-Server bekommen, dann kann niemand mehr die Dienste in der Cloud nutzen !!. Dies betrifft "Neuanmeldung". Sie sollten sich daher genau überlegen, welche Dienste in der Cloud welche Verfügbarkeit erfordern und entsprechend ihre ADFS-Dienste planen. Sie können problemlos mehrere ADFS-Server installieren oder z.B. mit Virtualisierung arbeiten.
  • ADFS ist nicht auf Office 365 beschränkt
    ADFS ist eine Infrastrukturmaßnahme, die für die meisten Firmen mit Office 365 das erste Mal sichtbar wird. Die von ADFS ausgestellten Tickets sind natürlich nicht nur für Office 365 nutzbar. Es wird sicher auch bald andere Dienstleister geben, die mittels ADFS ein Single-SignOn anbieten.
  • ADFS-URL Erreichbarkeit und "Lokales Intranet"
    Ein Windows Client unterscheidet, ob ein Server im "Internet", "Lokales Intranet" oder "Trusted Site" ist. Damit intern eine Ausstellung ohne Kennworteingabe erfolgen kann, muss die ADFS-URL, die intern und extern gleich sind, natürlich von intern direkt auf den ADFS-Server mit integrierter Anmeldung gehen und der Clients diese Adresse auch als "trusted" können.
  • Externe Erreichbarkeit
    Sichert ein Dienst wie Office 365 den Zugriff per ADFS-Ticket ab, muss jeder Client natürlich auch überall ein Ticket bekommen können. Bedenken Sie dies bei der Planung von URLs, Zertifikaten, Veröffentlichungen etc. Und natürlich muss der Client auch "ADFS-tauglich" sein. Clients die die "not authorized"-Meldung mit einer URL zum ADFS-Server nicht verstehen, werden den Dienst nicht nutzen können.
  • DNS-Einträge
    Damit ADFS funktioniert, benötigen nicht nur die Clients entsprechende DNS-Einträge um den ADFS-Zugang zu finden, sondern auch die ADFS-Server müssen natürlich "nach hinten" zu den Domain Controllern und ggfls. zum SQL-Server oder Cluster sprechen. Auch wenn mehrere DNS-Server eine hohe Verfügbarkeit des Dienstes sicherstellen, so ist es doch genau ein DNS-Eintrag im AD, der bei einem Falscheintrag oder irrtümlichen Löschen das komplette Gebilde blockierne kann. So hat Win2008 bei einer IP-AdressÄnderung den eigenen Namen erst beim zweiten Neustart erfolgreich eintragen können. Eine Überwachung der kritische Einträge ist daher sinnvoll.
  • Kennwortrichtlinien
    Mit ADFS werden auch die Kennwortrichtlinien von Office 365 durch ihre eigenen Richtlinien ersetzt.

Weitere technische Details und Hintergründen finden sie auf der Seite Office 365 ADFS Intern und Office 365 ADFS-Setup.

Anwendersicht Intern

Für den Anwender hängt es davon ab, wie er auf die Dienste zugreift, was er dann von ADFS sieht. Der einfache und direkte Weg ist natürlich erst einmal die Anmeldung per Browser an Office 365. Der Anwender wird aufgefordert, seinen Anmeldenamen einzugeben.

Wenn der Anwender dann das Feld "verlässt" prüft Office 365 direkt den Anmeldenamen gegen die interne eigene Konfiguration. Ist dieses Konto für "Single SingOn" freigeschaltet, dann wird das Kennwortfeld ausgeblendet. Statt dessen sehen Sie unten den Hinweis, dass Sie sich an ihrer Domäne anmelden müssen. Das passiert intern dann sogar automatisch und von extern müssen Sie eben den blauen Link anwählen. Ihr Browser surft dann den ADFS-Server ihrer Firma an um ein Ticket zu erhalten. Mit dem Ticket kehrt der Browser dann wieder zu Office 365 zurück und ist angemeldet.

Voraussetzung ist natürlich, dass der interne Benutzer auch ein Ticket bekommen kann (Korrektes Kennwort, Benutzer nicht gesperrt, Kennwort nicht abgelaufen etc.) und der DirSync die Stammdaten in Office 365 richtig verwaltet. Sollte etwas nicht passen, dann sieht der Anwender eine leider wenig aussagekräftige Fehlermeldung.

In dem Fall war das Token Signing Zertifikat unterschiedlich, d.h. das Token wurde auf dem ADFS-Server von einem Zertifikat signiert, welches nicht mit dem Zertifikat in Office 365 übereinstimmt.

Applikationen wie Outlook und Lync können mit ADFS umgehen, so dass hier die Anmeldung integriert ist. Allerdings ist es auch dazu erforderlich auf dem Client den "Microsoft Online Services Sign-In Assistant" (Siehe Office 365 Client) auszuführen, damit die entsprechenden Einträge durchgeführt worden sind.

Externe Clients und ADFS-Proxy

Siehe dazu die Seite ADFS Proxy

ADFS mit Office 365

Siehe Office 365 ADFS Setup

ADFS Zertifikate

ADFS ist fast wie ein Kerberos Ticket Server zu sehen. Der Client fragt an, muss sich anmelden und bekommt eine Art kryptografisch gesichertes Ticket, dem dann das Zielsystem vertraut. Und natürlich kommen auch hier wieder Zertifikate zum Einsatz, genau genommen drei Zertifikate, die in der der Verwaltungskonsole einfache zu identifizieren sind:

Damit stellt sich die Frage, wer ihnen die Zertifikate ausstellen. Sie können einfach die vom ADFS Setup installierten "Self Signed"-Zertifikate nutzen, aber auf dauer werden Sie damit nicht weit kommen. Wenn da ADFS-Service Zertifikat nicht von einer öffentlichen PLKI kommt, dann werden Clients in den meisten Fällen eine Zertifikatswarnung bei der Anmeldung am ADFS-Server anzeigen. Schauen wir uns die Zertifikate mal an

Zertifikat Verwendungszeck Ausstelle

Service Communication

Dieses Zertifikat nutze der ADFS-HTTPS-Service um die Verbindung mit den Clients zu verschlüsseln.

Hierzu verwenden Sie am besten ein "öffentliches" Zertifikat, dem möglichst alle Clients vertrauen.

Token-Decrypting

Dieses Zertifikat können Sie anderen Token-Systmen geben, wenn die Tokans an den ADFS-Server verschlüsselt senden wollen

 

Token-Signing

Mit dem PrivateKey dieses Zertifikats werden die Zertifikate digital signiert. Den PublicKey müssen Sie also an alle Partner geben.

Sie können hier ein eigenes Zertifikat nutzen. Sie sollten hier CRLs nutzen, d.h. die ausstellende PKI sollte eine CRL bereitstellen. Insofern ist hier doch ein öffentliches Zertifikat für die meisten Firmen einfacher.

Unterm Strich sollten sie eigentlich immer mit "richtigen" Zertifikaten arbeiten, auch wenn diese Geld kosten. Sie ersparen sich aber dass addieren ihrer StammCA und die Veröffentlichung von CRLs und umgehen viele Problemen einfach.

Ach ja: Wenn Sie einen ADFS-Proxy und vielleicht noch Loadbalancer davor betreiben, die SSL-Offloading nutzen, dann sind für dieses Systeme ebenfalls Zertifikate erforderlich. Da der Name des Servers aber Intern und Extern identisch sind, können Sie meiste das "Service Communication"-Zertifikat auch dort einsetzen.

ADFS und andere Dienste

Wenn Sie nun natürlich schon mal einen ADFS-Server in ihrem unternehmen installiert haben und diesen optional auch von extern für Clients zugänglich gemacht haben, dann ist es nur noch ein kleiner Schritt, auch andere Partner und Dienste über den Weg ihren Mitarbeitern zugänglich zu machen. Der Anbieter muss einfach ADFS unterstützen und ihren Tokens vertrauen. Das geht natürlich erst mal nicht so einfach wie in Office 365, denn das Token-Zertifikat muss natürlich von ihnen auch an den Anbieter übertragen werden und der Anbieter muss irgendwie ja "Identitäten" und damit verbundene Berechtigungen verwalten. Aber der Aufwand kann sich lohnen.

Anders herum ist es, wenn Sie selbst einen Dienst hosten, der von anderen Firmen genutzt werden soll. Dann muss die andere Seite eine ADFS-Struktur aufbauen, deren Tokens Sie dann als "Vertrauenswürdig" ansehen.

Videos

Windows Azure Active Directory Cartoon
http://blogs.msdn.com/b/plankytronixx/archive/2013/01/12/windows-azure-active-directory-cartoon.aspx

Whiteboard video: How ADFS and the Microsoft Federation Gateway work together up in the Office 365 Cloud.
http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-
federation-gateway-work-together-up-in-the-office-365-cloud.aspx

Video Screencast: Complete setup details für federated identity access from OnPremise AD to Office 365. 
http://blogs.msdn.com/b/plankytronixx/archive/2011/01/24/video-screencast-complete-setup-details-for-federated-identity-access-from-OnPremise-ad-to-office-365.aspx

Weitere Links