Kapitel 3 Identitäten und Active-Directory- Synchronisierung

Transkript

1 Kapitel 3 Identitäten und Active-Directory- Synchronisierung : Maximalanzahl der mit dem SQL Server 2008 R2 Express synchronisierbaren Active-Directory-Objekte Typischerweise wollen Sie Ihre Endanwender bei der Arbeit unterstützen und alltägliche Schritte vereinfachen. Dazu gehört beispielsweise die Bereitstellung von Single Sign-on. Bei Office 365 bedeutet dies, dass sich Ihre Anwender etwa an den Exchange- Online-Postfächern mit dem Benutzerkonto anmelden können, mit dem sie sich auch am lokalen Active Directory anmelden. Um das zu erreichen, müssen Sie einen Identitätsverbund konfigurieren. Mit diesem erstellen Sie eine Art Vertrauensverhältnis zwischen Ihrem eigenen Active Directory und Office 365, sodass Office 365 die erfolgreiche Authentifizierung an Ihrem Active Directory übernimmt. Eine solche Konfiguration ist zwar für Ihre Anwender sehr elegant, erfordert dafür jedoch die Einrichtung einer ADFS-Umgebung in Ihrem Netzwerk. Diese ist nicht selten mit zusätzlichem Ressourcenaufwand verbunden, sofern Sie noch nicht über eine ADFS-Installation verfügen. Diesen Aufwand wird nicht jedes Unternehmen akzeptieren. Voraussetzung für einen Identitätsverbund und nicht nur da ist die Aktivierung der Active-Directory-Synchronisierung. Sie installieren dazu auf einem lokalen Server eine Softwarekomponente, die in regelmäßigen Abständen lokal vorhandene Benutzerkonten, Gruppen und Kontakte automatisch im Verzeichnisdienst von Office 365, dem Windows Azure Active Directory (WAAD), anlegt und Änderungen an diesen Objekten übernimmt. Dadurch entfällt zunächst für Sie als Administrator der doppelte Pflegeaufwand beispielsweise beim Anlegen von Benutzerkonten für Mitarbeiter. Doch es gibt weitere Vorteile, die ich in diesem Kapitel noch besprechen werde. Verwenden Sie ein Small Business-Konto, können Sie dieses Kapitel überspringen dort sind weder der Identitätsverbund noch die Active-Directory-Synchronisierung möglich. 199

2 3 Identitäten und Active-Directory-Synchronisierung 3.1 Verschiedene Identitäten Office 365 verwendet intern mit dem Windows Azure Active Directory (WAAD) einen eigenen Verzeichnisdienst, so wie Sie selbst höchstwahrscheinlich ein Active Directory einsetzen. Für jeden Ihrer Office 365-Anwender muss im WAAD ein Benutzerkonto angelegt sein, das dann für die verschiedenen Dienste autorisiert wird (siehe Abbildung 3.1). Das ist auch der Fall, wenn Sie Single Sign-on einrichten. Eigenes Unternehmen Active Directory Identitätsprovider Authentifizierungs- Plattform Benutzerbereitstellung Verzeichnisdienst Identitätsprovider Lync Online SharePoint Online Exchange Online Office 365-Portal Powershell Abbildung 3.1 Office 365 verfügt über einen eigenen Verzeichnisdienst. Das WAAD wird übrigens nicht nur von Office 365, sondern auch von Dynamics CRM Online und Windows Intune eingesetzt. Mehr zu diesen beiden Produkten lesen Sie in Kapitel 8,»Weitere Dienste«. Die Frage ist nun, wie Sie in der Praxis mit diesem zusätzlichen Verzeichnisdienst umgehen, obwohl Sie ja schon selbst einen haben. Dabei gibt es mehrere verschiedene Varianten. Um die zu verstehen, müssen wir zunächst drei Begriffe klären: Microsoft-Online-Identität Für jeden Office 365-Anwender wird im Office 365-Verzeichnisdienst ein Benutzerkonto angelegt. Diesen Benutzerkonten weisen Sie dann eine Office 365-Lizenz zu. Außerdem bekommen die Konten separate Kennwörter. Ihre Anwender melden sich dann an Office 365 mit diesen Benutzerkonten und Kennwörtern an den 200

3 3.1 Verschiedene Identitäten Microsoft-Online-Identitäten. Diese haben mit den im lokalen Verzeichnisdienst vorhandenen Benutzerkonten zunächst nichts zu tun. Der Identitätsprovider wird von Office 365 gestellt. Daneben verwenden Sie mit Ihrem lokalen Active Directory einen weiteren Identitätsprovider. Verbundidentität Auch bei Verbundidentitäten (Federated Identity) werden im Office 365-Verzeichnisdienst Benutzerkonten angelegt und mit einer Lizenz versehen. Allerdings arbeiten Ihre Anwender in Umgebungen mit einem Identitätsverbund nicht direkt mit den Benutzerkonten aus Office 365, sondern mit den Benutzerkonten aus dem lokalen Active Directory. Zwischen Ihrem Active Directory und Office 365 wird dabei eine Art Vertrauensverhältnis konfiguriert, sodass sich Ihre Anwender letztlich mit den lokalen Benutzerdaten an Office 365 und den darin enthaltenen Diensten anmelden können. Der Identitätsprovider ist hier Ihr lokales Active Directory. Active-Directory-Synchronisierung Dabei handelt es sich um eine im lokalen Netzwerk zu installierende Komponente, die in einem regelmäßigen Intervall im Active Directory vorhandene Objekte im Office 365-Verzeichnisdienst nachpflegt. Dazu gehören die Benutzerkonten, Gruppen und Kontakte. Setzen Sie diese optionale Komponente ein, werden die Active- Directory-Benutzer in Office 365 automatisch angelegt, und Sie müssen sie nur noch mit einer Lizenz (und gegebenenfalls einem Kennwort) ausstatten. Die Active-Directory-Synchronisierung sehen wir uns in Abschnitt 3.4,»Active-Directory-Synchronisierung«, im Detail an. 3 Grundsätzlich gibt es in Office 365 drei unterschiedliche Szenarien, wie Sie mit Identitäten umgehen. Sehen wir uns diese genauer an: Szenario»Microsoft-Online-Identität«In diesem Szenario legen Sie im Office 365-Verzeichnisdienst manuell Benutzerkonten für Ihre Anwender an. Dies können Sie beispielsweise ganz klassisch über das Office 365-Portal durchführen, wie ich es in Abschnitt ,»Benutzer anlegen«, beschrieben habe. Eine Alternative zur Automatisierung wäre die Power- Shell, wie in Abschnitt ,»Benutzer anlegen«, beschrieben. Ihre Anwender melden sich an Office 365 über das Benutzerkonto aus dem Office 365-Verzeichnisdienst an. Die Authentifizierung erfolgt also nicht im lokalen Active Directory, sondern direkt in Office 365. Lassen Sie sich dieses Szenario durch den Kopf gehen, erkennen Sie verschiedene Nachteile, beispielsweise: Die Anwender müssen mit zwei Identitäten umgehen einmal mit der lokalen Identität und einmal mit der Identität aus Office 365. Sie müssen also auch mit zwei unterschiedlichen Kennwörtern und manchmal auch mit unterschiedlichen Benutzernamen umgehen können und erkennen, wann Sie 201

4 3 Identitäten und Active-Directory-Synchronisierung welches einzugeben haben. Identische Kennwörter sind dabei oft nicht möglich, da unterschiedliche Kennwortrichtlinien und Ablaufzeiten bestehen (siehe Abschnitt ,»Kennwortablaufrichtlinie«). Vergisst ein Anwender sein Kennwort, muss es potenziell an zwei unterschiedlichen Stellen zurückgesetzt werden. Dieses Szenario hat aber auch zwei große Vorteile: Es fällt der geringste Konfigurationsaufwand an, und es kann direkt nach dem Anlegen eines Office 365-Kontos angewandt werden. Abbildung 3.1 zeigt das Szenario in einem Schaubild. Szenario»Microsoft-Online-Identität mit Active-Directory-Synchronisierung«Im Unterschied zum ersten Szenario legen Sie hier die Benutzerkonten im Office 365-Verzeichnisdienst nicht selbst an, sondern lassen das über eine optionale Softwarekomponente erledigen. Kennwörter werden dabei nicht synchronisiert. Ansonsten gibt es aber keinen weiteren Unterschied. Die grundsätzlichen Probleme durch die unterschiedlichen Identitäten, mit denen der Anwender umgehen muss, bleiben bestehen (siehe Abbildung 3.2). Wie eben angemerkt, werden in diesem Szenario Kennwörter nicht synchronisiert. In Zukunft soll dies jedoch möglich sein. Eigenes Unternehmen Active Directory- Synchronisierung Active Directory Identitätsprovider Authentifizierungs- Plattform Benutzerbereitstellung Verzeichnisdienst Identitätsprovider Lync Online SharePoint Online Exchange Online Office 365-Portal Powershell Abbildung 3.2 Microsoft-Online-Identitäten mit Active-Directory-Synchronisierung 202

5 3.1 Verschiedene Identitäten Szenario»Verbundidentität mit Active-Directory-Synchronisierung«Die Active-Directory-Synchronisierung ist in diesem Szenario obligatorisch. Im Vergleich zu den beiden vorangegangenen Szenarien gibt es einen ganz wesentlichen Unterschied: Obwohl durch die Synchronisierung auch im Office 365-Verzeichnisdienst für jeden Anwender ein Benutzerkonto angelegt wird, verwenden die Anwender diese nicht direkt. Über ein Vertrauensverhältnis zwischen Office 365 und dem lokalen Active Directory erkennt Office 365 die lokale Anmeldung an, mit dem Ziel, ein Single-Sign-on-Verfahren zu erreichen. Die Lizenzierung erfolgt aber nach wie vor in Office 365, weshalb dort auch die Benutzerkonten über die Active-Directory-Synchronisierung angelegt werden müssen (siehe Abbildung 3.3). Dieses Szenario erfordert eine relativ aufwendige Konfiguration auf Basis der Active Directory Federation Services (ADFS oder auf Deutsch Active-Directory- Verbunddienste). Wie das geht, werde ich Ihnen in Abschnitt 3.4,»Active-Directory-Synchronisierung«, zeigen. 3 Eigenes Unternehmen Active Directory Federation Services Active Directory- Synchronisierung Active Directory Identitätsprovider Authentifizierungs- Plattform Benutzerbereitstellung Verzeichnisdienst Vertrauensverhältnis Identitätsprovider Lync Online SharePoint Online Exchange Online Office 365-Portal Powershell Abbildung 3.3 Verbundidentitäten mit Active-Directory-Synchronisierung Tabelle 3.1 zeigt einen Vergleich der drei Identitätsvarianten. 203

6 3 Identitäten und Active-Directory-Synchronisierung Kriterium Microsoft- Online-Identität Microsoft-Online- Identität + Synchronisierung Verbundidentität + Synchronisierung Zielgruppe kleine Unternehmen mittlere und große Unternehmen mit eigenem Active Directory große Unternehmen mit eigenem Active Directory Single Sign-on nein nein ja Identitäten pro Anwender Ort der Authentifizierung Ort der Benutzerverwaltung lokal + Office 365 lokal + Office 365 nur lokal lokal + Office 365 nur lokal nur lokal Zusätzliche lokale Installation erforderlich nein ja, für Synchronisierung ja, für Synchronisierung + ADFS In Small Business- Konten verfügbar In Midsize Business- Konten verfügbar In Enterprise-Konten verfügbar ja nein nein ja ja ja ja ja ja Tabelle 3.1 Vergleich der Identitätsalternativen In den folgenden Abschnitten werden wir uns um die Einrichtung dieser Szenarien kümmern. 3.2 Überprüfen der lokalen Umgebung Für die Einrichtung eines Identitätsverbunds für Single Sign-on und/oder für die Active-Directory-Synchronisierung muss Ihre lokale Umgebung einige Voraussetzungen erfüllen, beispielsweise müssen geeignete Benutzerprinzipalnamen (auf Englisch User Principal Name) der Benutzerkonten gesetzt sein. Die genauen Voraussetzungen zeige ich in den jeweiligen Abschnitten. Vorab aber bereits ein Tipp: 204

7 3.2 Überprüfen der lokalen Umgebung Microsoft stellt Ihnen mit dem Office 365 Deployment Readiness Tool ein brauchbares Werkzeug zur Verfügung, mit dem Sie ohne großen Aufwand Ihre lokale Umgebung schon vor der Konfigurationsänderung auf mögliche Problemstellen hin untersuchen können. So erhalten Sie rechtzeitig Hinweise, was Sie zunächst noch ändern sollten, bevor Sie tatsächlich mit der Einrichtung des Identitätsverbunds und der Synchronisierung beginnen. 3 Bei dem Tool handelt es sich um eine Webanwendung, die an Ihrer Umgebung keine Änderungen vornimmt, sondern nur einen Bericht liefert, der das Ergebnis der Überprüfung enthält. Ein Beispiel sehen Sie in Abbildung 3.4. Abbildung 3.4 Bericht des Deployment Readiness Tools Das Tool können Sie unter folgender Adresse herunterladen: Durchgeführte Tests Das Deployment Readiness Tool nimmt eine ganze Palette unterschiedlicher Tests vor und erzeugt verschiedene Statistiken. Darunter sind die folgenden Punkte: Erkennung vorhandener Domänen, Multi-Forest-Umgebungen und Vertrauensstellungen Anzahl von Active-Directory-Objekten Erkennung möglicher Synchronisierungsprobleme 205

8 3 Identitäten und Active-Directory-Synchronisierung Überprüfung, ob auf die Office 365-Dienste zugegriffen werden kann Definition möglicher Probleme beim Einsatz von Exchange Online, SharePoint Online, Lync Online Voraussetzungen für einen Identitätsverbund Definition erforderlicher Berechtigungen Voraussetzungen Zur Ausführung des Deployment Readiness Tools müssen folgende Voraussetzungen erfüllt sein: Betriebssystem: Windows XP, Vista 7 Windows Server 2003 (R2) Windows Server 2008 (R2) Es wird empfohlen, eine englischsprachige Windows-Version zu verwenden. Browser: Internet Explorer 7 oder neuer Firefox 4 Chrome 10 Safari 3.5 Ein Active Directory muss vorhanden sein. Der Computer, auf dem Sie das Tool ausführen, muss mit der Domäne verbunden sein. Zur Ausführung ist ein Domänenbenutzer ausreichend, dieser muss nicht über administrative Berechtigungen verfügen Ausführung Die Ausführung des Deployment Readiness Tools ist recht einfach. Auf einem Computer, der die Voraussetzungen erfüllt, starten Sie die Anwendung und warten dann geduldig ab (siehe Abbildung 3.5). Je nach Größe Ihres Active Directorys und der aktuellen Auslastung dauert es eine ganze Weile, bis alle Tests durchgeführt wurden. Ist das Tool fertig, wird der Ergebnisbericht automatisch angezeigt. Die während der Testausführung erzeugten Dateien finden Sie im Ordner C:\ office365reskit. 206

9 3.3 Identitätsverbund 3 Abbildung 3.5 Ausführung des Deployment Readiness Tools 3.3 Identitätsverbund In diesem Abschnitt besprechen wir die optionale Konfiguration eines Identitätsverbunds Vorteile Der Identitätsverbund mit dem Aufbau einer Vertrauensstellung zwischen Office 365 und Ihrem Active Directory ist mit einigem Aufwand und nicht selten zusätzlichen Servern verbunden. Dennoch hat der Identitätsverbund einige bedeutsame Vorteile: Single Sign-on Ihre Anwender müssen sich für die Anmeldung an den Office 365-Diensten keine separaten Zugangsdaten merken. 207

10 3 Identitäten und Active-Directory-Synchronisierung Kennwortrichtlinie Die Konfiguration der Kennwortrichtlinie verbleibt bei Ihrer lokalen Umgebung. Zugriffssteuerung Sie können bestimmen, von wo aus auf Office 365 zugegriffen werden darf, beispielsweise nur dann, wenn der Anwender sich im lokalen Netzwerk und nicht etwa irgendwo außerhalb im Hotel befindet. Zweistufige Authentifizierung Nur mit einem Identitätsverbund können Sie die Anmeldung an Office 365 zusätzlich über eine zweistufige Authentifizierung (Two-Factor Authentication, auch Strong Authentication genannt) realisieren. Dabei müssen die Anwender sich nicht nur durch die Angabe eines Benutzernamens samt Kennwort authentifizieren, sondern zusätzlich durch die TAN eines Sicherheitstoken, Smartcards oder Ähnlichem Anforderungen Damit der Identitätsverbund zwischen Ihrem Active Directory und Office 365 funktioniert, müssen einige Voraussetzungen erfüllt sein: Sie verwenden ein Midsize Business- oder Enterprise-Konto. Small Business-Konten unterstützen weder einen Identitätsverbund noch die Active-Directory-Synchronisierung. Die Domänencontroller müssen auf Basis von Windows Server 2003, 2008, 2008 R2 oder 2012 aufgesetzt sein. Das Active Directory kann im gemischten oder im einheitlichen Modus konfiguriert sein. Sie benötigen mindestens eine Installation von ADFS 2.0 auf einem Windows Server 2008 oder 2008 R2 bzw. ADFS 2.1 auf einem Windows Server Alternativ zu ADFS können Sie auch Shibboleth einsetzen. Sollte das für Sie in Betracht kommen, finden Sie unter folgender URL weitere Informationen: technet.microsoft.com/de-de/library/jj aspx Sind Anwender nicht direkt mit dem Unternehmensnetzwerk verbunden (z. B. Außendienstmitarbeiter ohne VPN), sollen sich aber trotzdem an Office 365 anmelden können, ist mindestens ein ADFS-Proxy oder alternativ ein Microsoft Forefront TMG (Threat Management Gateway) oder ein Microsoft Forefront UAG (Unified Access Gateway) erforderlich. Die Active-Directory-Synchronisierung muss eingerichtet sein bzw. werden. Dabei ist empfohlen, zunächst den Identitätsverbund zu konfigurieren und erst anschließend die Active-Directory-Synchronisierung zu aktivieren (siehe Ab- 208

11 3.3 Identitätsverbund schnitt 3.4). Wenn Sie zuerst die Active-Directory-Synchronisierung aktivieren und danach den Identitätsverbund einrichten, kann es bis zu 24 Stunden dauern, bis sich Ihre Anwender wieder an den Office 365-Diensten anmelden können. Für den Benutzerprinzipalnamen der Benutzerkonten gelten folgende Voraussetzungen: Der UPN muss vergeben sein. Die Domäne muss öffentlich und im Internet routbar sein (also kein.local,.intranet oder Ähnliches). Der UPN muss auf die Domäne gesetzt werden, für die der Identitätsverbund konfiguriert wird. Es sind zwei Zertifikate erforderlich: SSL-Zertifikat (Serverauthentifizierungszertifikat): Dieses Zertifikat ist für die Absicherung der Kommunikation zwischen ADFS-Server, Client und gegebenenfalls ADFS-Proxy erforderlich. Das Zertifikat muss auf den ADFS-Clients als vertrauenswürdig eingestuft werden, weshalb ein Zertifikat einer öffentlichen vertrauenswürdigen Zertifizierungsstelle eingesetzt werden sollte, beispielsweise von VeriSign oder Thawte. Verwenden Sie Outlook oder andere ActiveSync-Clients, muss das Zertifikat ebenfalls von einer öffentlichen Zertifizierungsstelle stammen. Für welche Domäne das Zertifikat ausgestellt sein muss, lesen Sie in Abschnitt 3.3.5,»Einrichtung«. Tokensignaturzertifikat: Hier ist ein selbst signiertes Zertifikat ausreichend. Es empfiehlt sich, das bei der ADFS-Konfiguration automatisch erzeugte Zertifikat zu verwenden. 3 Achtung: Zertifikate haben nur einen begrenzten Gültigkeitszeitraum. Das gilt sowohl für das SSL-Zertifikat als auch für das automatisch generierte Tokensignaturzertifikat. Letzteres hat eine standardmäßige Gültigkeit von einem Jahr. Notieren Sie sich diese Daten sorgfältig, und tauschen Sie die Zertifikate aus, bevor (!) sie abgelaufen sind. Ansonsten können sich Ihre Anwender nicht mehr an Office 365 anmelden. Nähere Informationen hierzu finden Sie auf folgender Seite: support.microsoft.com/kb/ /de SSL-Zertifikat Achten Sie bei der Auswahl eines SSL-Zertifikatsanbieters auf eine möglichst breite Unterstützung der ausgebenden Zertifizierungsstelle in Browsern und mobilen Endgeräten. Denken Sie insbesondere auch an ActiveSync-Clients wie Smartphones, die sich bei der Anmeldung an Exchange Online an einem nicht vertrauenswürdigem Zertifikat stoßen würden. Wird die Zertifizierungsstelle auf den Geräten nicht als vertrauenswürdig eingestuft, müssten Sie dort erst das Root-Zertifikat der Zertifizierungsstelle installieren. 209

12 3 Identitäten und Active-Directory-Synchronisierung Für erste Tests ist ein kostenlos erhältliches SSL-Zertifikat der Klasse 1, wie es etwa von StartCom ( ausgegeben wird, durchaus ausreichend. Für den produktiven Einsatz empfiehlt sich aber ein kostenpflichtiges Zertifikat aus der Klasse, die Ihren Sicherheitsansprüchen gerecht wird Topologien Single Sign-on bietet zwar sowohl für Administratoren als auch für Endanwender unbestreitbare Vorteile bei der Verwaltung und beim Komfort bei der Anmeldung an den Office 365-Diensten. Der Aufwand, um das zu erreichen, ist jedoch nicht zu unterschätzen. Verfügen Sie noch nicht über eine ADFS-Umgebung, heißt das unter Umständen, dass fünf zusätzliche Server installiert werden müssen. Diese können zwar gerne virtuell sein, müssen aber dennoch eingerichtet und verwaltet und lizenziert werden. Mit Einschränkungen können Sie die ADFS-Komponenten aber auch auf vorhandene Server zu bereits vorhandenen Anwendungen installieren. Darauf werden wir gleich zu sprechen kommen. Wie ich auf fünf Maschinen komme, sehen wir uns jetzt genauer an. ADFS-Einzelserver Um den Identitätsverbund zwischen dem lokalen Active Directory und Office 365 einzurichten, ist die lokale Installation von mindestens einem ADFS-Server erforderlich. Technisch möglich wäre es, ADFS auf einem Domänencontroller zu installieren. Dabei sollten Sie aber beachten, dass ADFS von den IIS (Internet Information Services) abhängt, also dem Webserver aus dem Hause Microsoft. Ob Sie die IIS auf Ihren Domänencontrollern einsetzen wollen, müssen Sie selbst entscheiden. Wenn das für Sie nicht infrage kommt, erfolgt die Installation auf einem Mitgliedsserver der Domäne. Bei der Auswahl des Servers müssen Sie außerdem beachten, dass ADFS zwingend die Standardwebsite in den IIS verwendet. Sollte diese also schon belegt sein, ist auf diesem Server eine ADFS-Installation nicht möglich. Abbildung 3.6 zeigt den möglichen Aufbau. Eine solche Einzelserver-Umgebung ist zwar mit dem geringsten Aufwand zu realisieren, hat aber auch einige Nachteile. Hier die wichtigsten: keine Ausfallsicherheit Sollte der Server oder ADFS aus irgendeinem Grund ausfallen, kann sich kein Anwender mehr an Office 365 anmelden. Aus diesem Grund sollte statt eines ein- 210

13 3.3 Identitätsverbund zelnen ADFS-Servers eine ADFS-Serverfarm mit zwei ADFS-Servern aufgesetzt werden. Dazu kommt noch ein Network Load Balancer (NLB), der die Anfragen auf die Server verteilt. Damit erreichen Sie für die Zukunft auch eine bessere Skalierbarkeit, wenn die Last auf den Servern zunimmt. Als NLB können Sie den Windows-eigenen Dienst Netzwerklastenausgleich einsetzen, sodass keine weitere Maschine erforderlich ist. eingeschränkter Zugriff von außerhalb des Unternehmensnetzwerks Die ADFS-Server sollten sicherheitsbedingt nicht über das Internet erreichbar sein und sollten auch nicht in der DMZ (Demilitarized Zone) des Unternehmensnetzwerks untergebracht werden. Damit sind sie aber nur für Clients erreichbar, die auch tatsächlich direkt mit dem Unternehmensnetzwerk verbunden sind. Dies trifft aber beispielsweise auf folgende Situationen nicht zu: Außendienstmitarbeiter ohne VPN-Verbindung Heimarbeiter ohne VPN-Verbindung Smartphones ohne VPN-Verbindung Damit diese Anwender sich auch an Office 365 anmelden können, ist die Einrichtung einer der beiden folgenden Optionen erforderlich: ADFS-Proxyserver in der DMZ: Diese fungieren als Kommunikationsschnittstelle zwischen den internen ADFS-Servern und den Clients. Die Kommunikation ins interne Netzwerk und vom Internet erfolgt dabei über HTTPS 443/ TCP. Da ein solcher Proxy auch ausfallen kann, sollten es wieder zwei samt NLB(-Dienst) sein. Alternativ zu den ADFS-Proxys kann auch ein Microsoft Forefront Threat Management Gateway (TMG) oder ein Microsoft Forefront Unified Access Gateway (UAG) zum Einsatz kommen. In diesem Buch verwenden wir die Proxyvariante. 3 Internes Netzwerk ADFS Server Active Directory Abbildung 3.6 ADFS in einer Einzelserver-Umgebung 211

14 3 Identitäten und Active-Directory-Synchronisierung keine Outlook- bzw. ActiveSync-Unterstützung Sollten Ihre Anwender Outlook oder andere ActiveSync-Clients wie Smartphones verwenden (also in den allermeisten Fällen), benötigen Sie ebenfalls zwingend ADFS-Proxys oder ein Microsoft Forefront TMG oder ein Forefront UAG. Der Grund dafür liegt am Anmeldevorgang dieser Clients. Mehr dazu lesen Sie in Abschnitt 3.3.4,»Anmeldevorgang«. ADFS-Serverfarm Mit einer ADFS-Serverfarm lösen Sie einen Teil der Probleme eines ADFS-Einzelservers. Da nicht nur ein einzelner, sondern mehrere ADFS-Server zum Einsatz kommen, ist die Ausfallwahrscheinlichkeit geringer. Allerdings benötigen Sie bei mehreren Servern auch einen NLB(-Dienst), der die Anfragen auf die Server verteilt. Abbildung 3.7 zeigt diese Topologie in einem Schaubild. Internes Netzwerk Load Balancer ADFS Server ADFS Server Active Directory Abbildung 3.7 ADFS in einer Serverfarm-Umgebung Alle Probleme werden jedoch nicht gelöst: Unternehmensexterne Geräte, Outlook und Activesync-Clients bleiben unberücksichtigt. Hier hilft die nächste Topologie. ADFS-Serverfarm und ADFS-Proxys Die letzte hier vorgestellte Topologie verwendet über NLBs angesprochene ADFS-Server in einer Farmkonfiguration und mehrere ADFS-Proxys für den externen Zugriff. Abbildung 3.8 zeigt die Topologie im Schaubild. Warum werden also oft fünf zusätzliche Server benötigt? Benötigt werden zwei ADFS-Server, zwei ADFS-Proxys und ein Server für die Active-Directory-Synchronisierung macht zusammen fünf. 212

15 3.3 Identitätsverbund Internes Netzwerk ADFS Server 3 Load Balancer ADFS Server Active Directory Interne Firewall DMZ ADFS Server Proxy ADFS Server Proxy Load Balancer Externe Firewall Internet Abbildung 3.8 ADFS in einer Serverfarm mit Proxys Empfohlene Topologiegrößen Microsoft empfiehlt abhängig von der Benutzerzahl den Einsatz bestimmter Topologien, wie Sie in Tabelle 3.2 aufgeführt sind. 213

16 3 Identitäten und Active-Directory-Synchronisierung Benutzeranzahl bis zu 1000 Topologie Installation der ADFS-Farm auf zwei bestehenden Domänencontrollern Installation der ADFS-Proxys auf zwei bestehenden Webservern in der DMZ 1000 bis Installation von zwei separaten ADFS-Farm-Servern Installation von zwei separaten ADFS-Proxys in der DMZ ab Installation von drei bis fünf separaten ADFS-Farm-Servern Installation von mindestens zwei separaten ADFS-Proxys in der DMZ Tabelle 3.2 Empfohlene Topologien Anmeldevorgang In einer Active Directory-Umgebung läuft die Authentifizierung grundsätzlich über Kerberos ab. Dabei werden Token ausgestellt, mit denen sich der Anwender ausweisen kann. Mit diesen Kerberos-Token kann jedoch eine Anmeldung an Office 365 nicht vorgenommen werden. Die Office 365-Authentifizierung wird im Fall eines Identitätsverbunds über Sicherheitstoken vorgenommen. Die Sicherheitstoken müssen dabei von einem von Office 365 als vertrauenswürdig eingestuften Sicherheitstokendienst (STS für Security Token Service) ausgestellt werden. Um dieses Prinzip zu erläutern, hier zunächst einige Hintergrundinformationen: Ein Sicherheitstoken enthält verschiedene Angaben zu einer Person (wie in unserem Fall) oder zu einer Anwendung. Das könnten beispielsweise Daten sein, wie der Anmeldename, Vor- und Nachname, die Abteilung, die Adresse, das Alter, Identifikationsnummer etc. Je nach Anwendungsfall können unterschiedlichen Daten erforderlich sein. Solch ein Sicherheitstoken wird von einem Sicherheitstokendienst ausgestellt. Derartige Dienste gibt es viele von unterschiedlichen Anbietern, beispielsweise von Facebook, Google, Yahoo, Twitter etc. In unserem Fall verwenden wir Microsofts Sicherheitstokendienst für das Active Directory, namens ADFS (Active Directory Federation Services). Damit die Sicherheitstoken unabhängig von Hersteller und Anwender verarbeitet werden können, sind Sie nach einem Standard namens SAML (Security Assertion Markup Language) aufgebaut. Und um sicherzustellen, dass die Token auch nicht gefälscht sind, werden sie vom ausstellenden Sicherheitstokendienst digital signiert. Darüber kann man auch auf den Dienst selbst zurückschließen. Ein vereinfachtes Beispiel eines Sicherheitstokens sehen Sie in Abbildung

17 3.3 Identitätsverbund Sicherheitstoken ID 3 Name Vorname Abteilung Claims Gruppen Alter... Signatur Abbildung 3.9 Sicherheitstoken Um nun einen Identitätsverbund bereitzustellen, müssen wir also lokal eine ADFS- Umgebung aufbauen, die für unsere Anwender Sicherheitstoken ausstellt. Die ADFS- Umgebung wird bei der Office 365-Authentifizierungsplattform (AP) als vertrauenswürdig konfiguriert, sodass Office 365 die Sicherheitstoken unserer ADFS-Umgebung akzeptiert. Die AP fungiert ebenfalls als Sicherheitstokendienst und kann damit selbst Sicherheitstoken ausstellen. Warum das wichtig ist, werden wir gleich bei den Anmeldeszenarien sehen. Der Anmeldevorgang an Office 365 unterscheidet sich dann je nach einem der folgenden Szenarien: Webanwendungen Clientanwendungen Outlook/ActiveSync Sehen wir uns die verschiedenen Szenarien an. Alle basieren auf Kerberos, und es wird immer vorausgesetzt, dass sich jeder Anwender mit dem Benutzerprinzipalnamen anmeldet (und nicht etwa mit dem alten Anmeldenamen in der Form Domäne\ Benutzer). Hier müssen also gegebenenfalls Ihre Anwender umlernen. Webanwendungen Der Anwender greift hier auf einen Office 365-Dienst über einen Browser zu, also beispielsweise auf OWA, um s zu verwalten. Der nun folgende Vorgang wird in Abbildung 3.10 dargestellt. 215

18 3 Identitäten und Active-Directory-Synchronisierung Eigenes Unternehmen ADFS Server Active Directory Exchange Online Authentifizierungs- Plattform Abbildung 3.10 Anmeldung an einer Webanwendung 1. Der Zugriff auf den Office 365-Dienst kann nicht erfolgen, da dazu ein Sicherheitstoken der Office 365-Authentifizierungsplattform (AP) erforderlich ist. Das Sicherheitstoken muss von der AP signiert werden. 2. Der Client verbindet sich mit der Office 365-AP und fragt ein Sicherheitstoken an. Die AP erkennt, dass der Benutzer von einer Verbunddomäne kommt. Entsprechend kann die AP den Benutzer nicht authentifizieren, sondern fragt nach einem Sicherheitstoken, das von ADFS ausgestellt und signiert wurde. 3. Der Client verbindet sich mit dem ADFS-Server und fragt ein Sicherheitstoken an. ADFS kontaktiert das Active Directory und erhält von dort ein NTLM- oder Kerberos-Token für den Benutzer. ADFS wandelt dieses in das erforderliche Sicherheitstoken um und signiert es. Das Sicherheitstoken enthält den UPN des Benutzers und eine User-Source-ID. Die User-Source-ID wird auch Immutable-ID genannt und stimmt mit der Objekt- GUID des AD-Objekts überein. Mehr zu dieser ID lesen Sie in Abschnitt 3.4.1,»Synchronisierungsvorgang«. 4. Der Client überträgt das Sicherheitstoken an die Office 365-AP. Die AP überprüft das Token etwa daraufhin, ob es von der vertrauten ADFS-Umgebung stammt. Die AP wandelt die User-Source-ID um in eine Net-ID, erstellt daraus ein neues Sicherheitstoken und signiert es. 216

19 3.3 Identitätsverbund Die Net-ID wird beim Anlegen des Benutzerkontos im Office 365-Verzeichnisdienst automatisch erzeugt. Im Falle des Identitätsverbunds passiert das im Rahmen der Active-Directory-Synchronisierung. 5. Der Client überträgt das neue Sicherheitstoken an den ursprünglich angefragten Office 365-Dienst. Dieser überprüft beispielsweise, ob es von der Office 365-AP stammt. Der Dienst liest die Net-ID aus und sucht im Office 365-Verzeichnisdienst nach der Net-ID. Ist diese gefunden, kann der Dienst den Benutzer entsprechend dessen Lizenz arbeiten lassen. 3 Clientanwendungen Der Anmeldevorgang sieht bei der Verwendung eines Clients wie den Office Anwendungen, der PowerShell-Erweiterung und dem Verzeichnissynchronisierungstool etwas anders aus. Hier kommt der Online Services-Anmelde-Assistent zum Einsatz. Die Office 2013-Anwendungen nutzen eine Komponente aus dem Assistenten, die automatisch mit Office 2013 mit installiert wird. Der Assistent selbst muss bei Office 2013 nicht installiert sein. Abbildung 3.11 stellt den Vorgang dar. Eigenes Unternehmen ADFS Server Active Directory Lync Online Authentifizierungs- Plattform Abbildung 3.11 Anmeldung mit einer Clientanwendung 217

20 3 Identitäten und Active-Directory-Synchronisierung 1. Der Anwender meldet sich mit seinem Computer am Unternehmensnetzwerk an. 2. Der Office 365-Anmelde-Assistent startet und ermittelt die Domäne des Benutzers über dessen UPN. 3. Der Anmeldeassistent verbindet sich mit der Office 365-AP, um zu ermitteln, ob die Domäne eine Verbunddomäne ist. Ist sie es nicht, ist der Vorgang zu Ende. 4. Im anderen Fall verbindet sich der Anmeldeassistent mit der lokalen ADFS- Umgebung und fragt ein Sicherheitstoken an. ADFS kontaktiert das Active Directory und erhält von dort ein NTLM- oder Kerberos-Token für den Benutzer. ADFS wandelt dieses in das erforderliche Sicherheitstoken um und signiert es. Das Sicherheitstoken enthält den UPN des Benutzers und eine User-Source-ID. 5. Der Anmelde-Assistent überträgt das Sicherheitstoken an die Office 365-AP. Die AP überprüft das Sicherheitstoken daraufhin, ob es etwa von der vertrauten ADFS- Umgebung stammt. Die AP wandelt die User-Source-ID um in eine Net-ID und erstellt ein neues Ticket Granting Ticket (TGT). Das TGT wird zum Anmeldeassistent übertragen. 6. Der Anmeldeassistent speichert das TGT in einem lokalen Cache, für den Fall, dass eine Clientanwendung es benötigt. Angenommen, der Anwender startet nun den Lync-Client, werden folgende Schritte durchgeführt: 1. Der Lync-Client versucht sich mit Lync Online zu verbinden. Lync Online fragt nach einem Sicherheitstoken, das von der Office 365-AP signiert sein muss. 2. Der Lync-Client fragt das TGT beim Anmeldeassistenten an. Dieser überträgt das TGT an das Federation Gateway und erhält nach Prüfung ein Sicherheitstoken. 3. Das Sicherheitstoken wird an Lync Online übertragen. Lync Online überprüft, ob es etwa von der Office 365-AP stammt. Dann wird die Net-ID ausgelesen und im Office 365-Verzeichnisdienst gesucht. Ist sie gefunden, kann Lync Online den Benutzer entsprechend seiner Lizenz arbeiten lassen. Outlook/ActiveSync Der dritte Anmeldevorgang kommt zum Einsatz, wenn der Anwender Outlook oder ein anderes Gerät mit ActiveSync nutzt, um eine Verbindung zu seinem Postfach aufzubauen. Abbildung 3.12 zeigt den Vorgang. 1. Der Anwender meldet sich mit seinem Computer am Unternehmensnetzwerk an und startet beispielsweise Outlook. 2. Outlook verbindet sich mit Exchange Online und wird nach Basisauthentifizierungsdaten gefragt. Bei den Basisauthentifizierungsdaten handelt es sich um Benutzername (UPN) und Kennwort. 218