Identitäten und Active-Directory-Synchronisierung
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Kapitel 3
Identitäten und Active-Directory- 3
Synchronisierung
50.000: 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äg-
liche 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 Vertrauensver-
hä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 Ein-
richtung einer ADFS-Umgebung in Ihrem Netzwerk. Diese ist nicht selten mit zusätz-
lichem Ressourcenaufwand verbunden, sofern Sie noch nicht über eine ADFS-Instal-
lation 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 Ser-
ver 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 Mitar-
beiter. 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.
1993 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 Direc-
tory einsetzen. Für jeden Ihrer Office 365-Anwender muss im WAAD ein Benutzer-
konto 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
Identitäts-
provider
Active Directory
Identitäts-
Verzeichnis- provider
dienst
Authentifizierungs- Benutzer-
Plattform bereitstellung
Lync SharePoint Exchange Office 365-Portal
Online Online Online 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 verschie-
dene 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 Benutzer-
konto 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
2003.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 Direc-
tory einen weiteren Identitätsprovider. 3
왘 Verbundidentität
Auch bei Verbundidentitäten (Federated Identity) werden im Office 365-Verzeich-
nisdienst 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, Grup-
pen 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-Direc-
tory-Synchronisierung«, im Detail an.
Grundsätzlich gibt es in Office 365 drei unterschiedliche Szenarien, wie Sie mit Iden-
titäten umgehen. Sehen wir uns diese genauer an:
왘 Szenario »Microsoft-Online-Identität«
In diesem Szenario legen Sie im Office 365-Verzeichnisdienst manuell Benutzer-
konten für Ihre Anwender an. Dies können Sie beispielsweise ganz klassisch über
das Office 365-Portal durchführen, wie ich es in Abschnitt 1.11.2, »Benutzer anle-
gen«, beschrieben habe. Eine Alternative zur Automatisierung wäre die Power-
Shell, wie in Abschnitt 2.14.3, »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
2013 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 1.11.5, »Kennwortablaufrichtlinie«). Vergisst ein Anwender sein Kenn-
wort, muss es potenziell an zwei unterschiedlichen Stellen zurückgesetzt werden.
Dieses Szenario hat aber auch zwei große Vorteile: Es fällt der geringste Konfigura-
tionsaufwand 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 Soft-
warekomponente erledigen. Kennwörter werden dabei nicht synchronisiert.
Ansonsten gibt es aber keinen weiteren Unterschied. Die grundsätzlichen Pro-
bleme 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 synchroni-
siert. In Zukunft soll dies jedoch möglich sein.
Eigenes Unternehmen
Identitäts-
provider
Active Directory-
Synchronisierung
Active Directory
Identitäts-
Verzeichnis- provider
dienst
Authentifizierungs- Benutzer-
Plattform bereitstellung
Lync SharePoint Exchange Office 365-Portal
Online Online Online Powershell
Abbildung 3.2 Microsoft-Online-Identitäten mit Active-Directory-Synchronisierung
2023.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 wesent-
lichen Unterschied: Obwohl durch die Synchronisierung auch im Office 365-Ver- 3
zeichnisdienst 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 Ac-
tive-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-Direc-
tory-Synchronisierung«, zeigen.
Eigenes Unternehmen
Identitäts-
provider
Active Directory Active Directory-
Federation Services Synchronisierung
Vertrauens-
Active Directory verhältnis
Identitäts-
Verzeichnis- provider
dienst
Authentifizierungs- Benutzer-
Plattform bereitstellung
Lync SharePoint Exchange Office 365-Portal
Online Online Online Powershell
Abbildung 3.3 Verbundidentitäten mit Active-Directory-Synchronisierung
Tabelle 3.1 zeigt einen Vergleich der drei Identitätsvarianten.
2033 Identitäten und Active-Directory-Synchronisierung
Kriterium Microsoft- Microsoft-Online- Verbundidentität
Online-Identität Identität + Syn- + Synchronisie-
chronisierung rung
Zielgruppe kleine Unterneh- mittlere und große Unterneh-
men große Unterneh- men mit eigenem
men mit eige- Active Directory
nem Active
Directory
Single Sign-on nein nein ja
Identitäten pro 2 2 1
Anwender
Ort der Authentifizie- lokal + Office 365 lokal + Office 365 nur lokal
rung
Ort der Benutzer- lokal + Office 365 nur lokal nur lokal
verwaltung
Zusätzliche lokale nein ja, für Synchroni- ja, für Synchroni-
Installation erforder- sierung sierung + ADFS
lich
In Small Business- ja nein nein
Konten verfügbar
In Midsize Business- ja ja ja
Konten verfügbar
In Enterprise-Konten ja ja ja
verfügbar
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 Vorausset-
zungen erfüllen, beispielsweise müssen geeignete Benutzerprinzipalnamen (auf
Englisch User Principal Name) der Benutzerkonten gesetzt sein. Die genauen Voraus-
setzungen zeige ich in den jeweiligen Abschnitten. Vorab aber bereits ein Tipp:
2043.2 Überprüfen der lokalen Umgebung
Microsoft stellt Ihnen mit dem Office 365 Deployment Readiness Tool ein brauchba-
res Werkzeug zur Verfügung, mit dem Sie ohne großen Aufwand Ihre lokale Umge-
bung schon vor der Konfigurationsänderung auf mögliche Problemstellen hin unter-
suchen können. So erhalten Sie rechtzeitig Hinweise, was Sie zunächst noch ändern 3
sollten, bevor Sie tatsächlich mit der Einrichtung des Identitätsverbunds und der
Synchronisierung beginnen.
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 Über-
prü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:
http://community.office365.com/en-us/f/183/t/2285.aspx
3.2.1 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 Vertrauens-
stellungen
왘 Anzahl von Active-Directory-Objekten
왘 Erkennung möglicher Synchronisierungsprobleme
2053 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
3.2.2 Voraussetzungen
Zur Ausführung des Deployment Readiness Tools müssen folgende Voraussetzun-
gen 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.
3.2.3 Ausführung
Die Ausführung des Deployment Readiness Tools ist recht einfach. Auf einem Com-
puter, 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 Ergebnis-
bericht automatisch angezeigt.
Die während der Testausführung erzeugten Dateien finden Sie im Ordner C:\
office365reskit.
2063.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ätsver-
bunds.
3.3.1 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.
2073 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, bei-
spielsweise 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ätz-
lich ü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 authentifizie-
ren, sondern zusätzlich durch die TAN eines Sicherheitstoken, Smartcards oder
Ähnlichem.
3.3.2 Anforderungen
Damit der Identitätsverbund zwischen Ihrem Active Directory und Office 365 funk-
tioniert, müssen einige Voraussetzungen erfüllt sein:
왘 Sie verwenden ein Midsize Business- oder Enterprise-Konto. Small Business-Kon-
ten unterstützen weder einen Identitätsverbund noch die Active-Directory-Syn-
chronisierung.
왘 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 konfigu-
riert sein.
왘 Sie benötigen mindestens eine Installation von ADFS 2.0 auf einem Windows Ser-
ver 2008 oder 2008 R2 bzw. ADFS 2.1 auf einem Windows Server 2012.
Alternativ zu ADFS können Sie auch Shibboleth einsetzen. Sollte das für Sie in
Betracht kommen, finden Sie unter folgender URL weitere Informationen: http://
technet.microsoft.com/de-de/library/jj205456.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-
2083.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 Vorausset- 3
zungen:
– 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 gege-
benenfalls ADFS-Proxy erforderlich. Das Zertifikat muss auf den ADFS-Clients
als vertrauenswürdig eingestuft werden, weshalb ein Zertifikat einer öffentli-
chen vertrauenswürdigen Zertifizierungsstelle eingesetzt werden sollte, bei-
spielsweise von VeriSign oder Thawte. Verwenden Sie Outlook oder andere
ActiveSync-Clients, muss das Zertifikat ebenfalls von einer öffentlichen Zertifi-
zierungsstelle 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.
Achtung: Zertifikate haben nur einen begrenzten Gültigkeitszeitraum. Das gilt so-
wohl für das SSL-Zertifikat als auch für das automatisch generierte Tokensignaturzer-
tifikat. 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 ab-
gelaufen sind. Ansonsten können sich Ihre Anwender nicht mehr an Office 365
anmelden. Nähere Informationen hierzu finden Sie auf folgender Seite: http://
support.microsoft.com/kb/2383983/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ürdi-
gem 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 Zer-
tifizierungsstelle installieren.
2093 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 (www.startssl.com) ausgegeben wird, durchaus ausreichend. Für den
produktiven Einsatz empfiehlt sich aber ein kostenpflichtiges Zertifikat aus der
Klasse, die Ihren Sicherheitsansprüchen gerecht wird.
3.3.3 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 lizen-
ziert 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 erforder-
lich.
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 Ser-
vices) 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 die-
sem 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 rea-
lisieren, 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-
2103.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 Skalier-
barkeit, wenn die Last auf den Servern zunimmt. Als NLB können Sie den Win- 3
dows-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 Unternehmensnetz-
werks 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 Einrich-
tung einer der beiden folgenden Optionen erforderlich:
– ADFS-Proxyserver in der DMZ: Diese fungieren als Kommunikationsschnitt-
stelle zwischen den internen ADFS-Servern und den Clients. Die Kommunika-
tion 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.
Internes Netzwerk
ADFS
Server
Active Directory
Abbildung 3.6 ADFS in einer Einzelserver-Umgebung
2113 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-Einzelser-
vers. Da nicht nur ein einzelner, sondern mehrere ADFS-Server zum Einsatz kom-
men, ist die Ausfallwahrscheinlichkeit geringer. Allerdings benötigen Sie bei mehre-
ren Servern auch einen NLB(-Dienst), der die Anfragen auf die Server verteilt.
Abbildung 3.7 zeigt diese Topologie in einem Schaubild.
Internes Netzwerk
ADFS
Server
Load
Balancer
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-Ser-
ver 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-Synchroni-
sierung – macht zusammen fünf.
2123.3 Identitätsverbund
Internes Netzwerk
3
ADFS
Server
Load
Balancer
ADFS
Server
Active Directory
Interne Firewall
DMZ
ADFS ADFS
Server Proxy 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 Topolo-
gien, wie Sie in Tabelle 3.2 aufgeführt sind.
2133 Identitäten und Active-Directory-Synchronisierung
Benutzeranzahl Topologie
bis zu 1000 왘 Installation der ADFS-Farm auf zwei bestehenden Domänen-
controllern
왘 Installation der ADFS-Proxys auf zwei bestehenden Webservern
in der DMZ
1000 bis 15000 왘 Installation von zwei separaten ADFS-Farm-Servern
왘 Installation von zwei separaten ADFS-Proxys in der DMZ
ab 15000 왘 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
3.3.4 Anmeldevorgang
In einer Active Directory-Umgebung läuft die Authentifizierung grundsätzlich über
Kerberos ab. Dabei werden Token ausgestellt, mit denen sich der Anwender auswei-
sen 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 Sicher-
heitstokendienst (STS für Security Token Service) ausgestellt werden. Um dieses Prin-
zip 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, Identifika-
tionsnummer etc. Je nach Anwendungsfall können unterschiedlichen Daten erfor-
derlich sein. Solch ein Sicherheitstoken wird von einem Sicherheitstokendienst
ausgestellt. Derartige Dienste gibt es viele von unterschiedlichen Anbietern, bei-
spielsweise 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 Herstel-
ler 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 Sicherheits-
tokendienst digital signiert. Darüber kann man auch auf den Dienst selbst zurück-
schließen.
Ein vereinfachtes Beispiel eines Sicherheitstokens sehen Sie in Abbildung 3.9.
2143.3 Identitätsverbund
Sicherheitstoken
3
ID
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 vertrauens-
wü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 fol-
genden 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 Benutzerprinzipalna-
men 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 bei-
spielsweise auf OWA, um E-Mails zu verwalten. Der nun folgende Vorgang wird in
Abbildung 3.10 dargestellt.
2153 Identitäten und Active-Directory-Synchronisierung
Eigenes Unternehmen
ADFS
Server
Active Directory
Exchange Authentifizierungs-
Online Plattform
Abbildung 3.10 Anmeldung an einer Webanwendung
1. Der Zugriff auf den Office 365-Dienst kann nicht erfolgen, da dazu ein Sicherheits-
token der Office 365-Authentifizierungsplattform (AP) erforderlich ist. Das Sicher-
heitstoken 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. Entspre-
chend 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 Ker-
beros-Token für den Benutzer. ADFS wandelt dieses in das erforderliche Sicher-
heitstoken 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, »Syn-
chronisierungsvorgang«.
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 Sicher-
heitstoken und signiert es.
2163.3 Identitätsverbund
Die Net-ID wird beim Anlegen des Benutzerkontos im Office 365-Verzeichnis-
dienst automatisch erzeugt. Im Falle des Identitätsverbunds passiert das im Rah-
men der Active-Directory-Synchronisierung.
5. Der Client überträgt das neue Sicherheitstoken an den ursprünglich angefragten 3
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.
Clientanwendungen
Der Anmeldevorgang sieht bei der Verwendung eines Clients wie den Office 2010-
Anwendungen, der PowerShell-Erweiterung und dem Verzeichnissynchronisie-
rungstool 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 Authentifizierungs-
Online Plattform
Abbildung 3.11 Anmeldung mit einer Clientanwendung
2173 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 Direc-
tory 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 Anmeldeassis-
tent ü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 auf-
zubauen. 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 Basisauthentifizie-
rungsdaten gefragt.
Bei den Basisauthentifizierungsdaten handelt es sich um Benutzername (UPN)
und Kennwort.
2183.3 Identitätsverbund
Eigenes Unternehmen
Outlook
3
ADFS
Server
Active Directory
Exchange Authentifizierungs-
Online Plattform
Abbildung 3.12 Anmeldung mit Outlook/ActiveSync
3. Outlook antwortet mit den Basisauthentifizierungsdaten des Benutzers.
4. Exchange Online verbindet sich mit der Office 365-AP. Dort wird überprüft, ob die
Benutzerdomäne eine Verbunddomäne ist. Wenn ja, antwortet die AP mit der
ADFS-URL.
5. Exchange Online überträgt die Basisauthentifizierungsdaten an den lokalen
ADFS-Server und fragt ein Sicherheitstoken an.
Dies ist der Grund, warum ein ADFS-Proxy oder ein TMG bzw. UAG erforderlich
ist: Exchange Online muss mit der lokalen ADFS-Umgebung kommunizieren
können.
6. Der lokale ADFS-Server authentifiziert den Benutzer mit den Basisauthentifizie-
rungsdaten am Active Directory. 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 Login-Token enthält
den UPN des Benutzers und eine User-Source-ID.
7. Das Login-Token wird zurück an Exchange Online übertragen.
2193 Identitäten und Active-Directory-Synchronisierung
8. Exchange Online überträgt das Sicherheitstoken an die Office 365-AP. Die AP
überprüft, ob das Login-Token etwa 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.
9. Das neue Sicherheitstoken wird zurück an Exchange Online übertragen.
10. Exchange Online überprüft es daraufhin, ob es etwa von der Office 365-AP
stammt. Exchange Online liest die Net-ID aus und sucht im Office 365-Verzeich-
nisdienst nach der Net-ID. Ist diese gefunden, kann der Benutzer entsprechend
seiner Lizenz arbeiten.
3.3.5 Einrichtung
Die Einrichtung eines Identitätsverbunds lässt sich in folgende Schritte aufteilen:
1. Domäne verifizieren
2. Bestimmung der ADFS-URL
3. DNS-Konfiguration (intern und extern)
4. SSL-Zertifikatsplanung
5. ADFS-Installation (Server und Proxy)
6. IIS-Konfiguration
7. ADFS-Serverfarm-Konfiguration
8. ADFS-Proxykonfiguration
9. Identitätsverbund für Domäne aktivieren
10. Active-Directory-Synchronisierung aktivieren
In diesem Abschnitt gehen wir die einzelnen Schritte durch und erstellen damit eine
Konfiguration wie in Abbildung 3.8, beschränken uns aber auf jeweils einen einzel-
nen ADFS-Server und einen einzelnen ADFS-Proxy.
Zu ADFS veröffentlicht Microsoft gelegentlich Update Rollups, die Sie grundsätzlich
installieren sollten. Dies betrifft insbesondere ADFS 2.0 vom Windows Server 2008
(R2). Aktuell gibt es dafür das Update Rollup 2 unter folgender URL: http://
support.microsoft.com/kb/2681584
Die Abbildungen in diesem Abschnitt wurden mit einem Windows Server 2012
gemacht. Auf den älteren Versionen sieht die Oberfläche leicht anders aus, und die
Bezeichner sind nicht exakt gleich. Das grundsätzliche Vorgehen ist aber identisch.
Schritt 1: Domäne verifizieren
Dieser Schritt dient der Vorbereitung und wurde von Ihnen wahrscheinlich bereits
durchgeführt. Falls nicht, fügen Sie die Domäne zu Ihrem Office 365-Konto hinzu
2203.3 Identitätsverbund
(einschließlich Verifizierung), die bei den UPNs verwendet wird. Wie das geht, lesen
Sie in Abschnitt 1.10, »Domänenverwaltung«.
Diese Domäne wird später zur Verbunddomäne (Federated Domain). Beachten Sie
3
insbesondere die Voraussetzungen für die UPNs.
Schritt 2: Bestimmung der ADFS-URL
Wir benötigen eine URL, über die der Zugriff auf ADFS erfolgt. Dazu nehmen Sie typi-
scherweise Ihre öffentliche Domäne, beispielsweise beispielag.de, und stellen ihr
einen frei wählbaren Hostnamen voran, beispielsweise logon, fs (für »Federation Ser-
vices«) oder sts (für »Security Token Service«).
So ergibt sich die ADFS-URL in der Form von logon.beispielag.de. Diese URL muss
nun DNS-seitig eingerichtet werden.
Schritt 3: DNS-Konfiguration (intern und extern)
Die DNS-Konfiguration müssen wir von der netzwerkinternen und -externen Seite
betrachten (Split DNS). Beginnen wir mit der internen:
Gehen wir von der ADFS-URL logon.beispielag.de aus. Verwenden Sie intern eine
andere Domäne, wie beispielag.local, müssen wir zunächst eine neue Forward-
Lookupzone für beispielag.de anlegen. Auf jeden Fall aber benötigen wir einen
Hosteintrag (A-Record) für logon, der dann auf die ADFS-Serverfarm zeigt. Gehen Sie
dazu wie folgt vor:
1. Öffnen Sie die DNS-Manager-Konsole (siehe Abbildung 3.13).
Abbildung 3.13 DNS-Manager
2. Ist unter Forward-Lookupzone die Domäne beispielag.de noch nicht vorhan-
den, klicken Sie mit der rechten Maustaste auf Forward-Lookupzone und wäh-
len im Kontextmenü den Befehl Neue Zone.
2213 Identitäten und Active-Directory-Synchronisierung
3. Legen Sie mit dem erscheinenden Assistenten eine neue Zone mit folgenden
Eigenschaften an:
– Zonentyp: Primäre Zone
– Active Directory-Zonenreplikationsbereich: Auf allen DNS-Servern,
die auf Domänencontrollern in dieser Domäne ausgeführt werden
– Zonenname: beispielag.de
– Dynamisches Update: Nur sichere dynamische Updates zulassen
Die weiteren Optionen belassen Sie in der Standardkonfiguration.
4. Innerhalb der Zone beispielag.de legen Sie nun wieder über das Kontextmenü
einen neuen Host mit folgenden Einstellungen an (siehe Abbildung 3.14):
– Name: logon.beispielag.de
– IP-Adresse: Hier geben Sie die IP-Adresse der zukünftigen ADFS-Serverfarm
an. Besteht diese aus mehr als einem Server, benötigen Sie einen NLB, über den
Sie auf die Serverfarm über eine virtuelle IP-Adresse zugreifen. Geben Sie dann
diese virtuelle IP-Adresse an.
Alle weiteren Optionen bleiben wieder in der Standardkonfiguration.
Abbildung 3.14 Neuer Hosteintrag
Jetzt müssen wir noch einen Umstand berücksichtigen, der in der Praxis gerne ver-
gessen wird: Wenn Sie in diesem Schritt eine Forward-Lookupzone für die externe
Domäne eingerichtet haben, beantwortet Ihr interner DNS-Server die Anfragen Ihrer
Clients an die eigentlich externe Domäne. Dies hat nun zur Folge, dass die Clients die
DNS-Einträge für Exchange (beispielsweise für die AutoErmittlung), Lync und Share-
Point nicht mehr erhalten – denn diese Einträge sind ja im externen DNS-System
hinterlegt. Es ist deshalb erforderlich, dass Sie in der neuen Forward-Lookupzone die
DNS-Einträge nachpflegen. Lesen Sie hierzu auch Abschnitt 1.10, »Domänenverwal-
tung«.
2223.3 Identitätsverbund
Damit ist die interne DNS-Konfiguration abgeschlossen. In der DNS-Konfiguration
unseres DNS-Anbieters für beispielag.de benötigen wir ebenfalls einen A-Record, bei
dem das Ziel auf die IP-Adresse unseres zukünftigen ADFS-Proxys in der DMZ gesetzt
ist bzw. auf die virtuelle IP-Adresse des NLB. Nehmen Sie die entsprechende Konfigu- 3
ration vor. Eine genaue Beschreibung kann ich Ihnen hier nicht liefern, da sich die
notwendigen Schritte von Anbieter zu Anbieter unterscheiden.
Schritt 4: SSL-Zertifikatsplanung
Wie in Abschnitt 3.3.2, »Anforderungen«, bereits erläutert, sollten wir ein kommerzi-
elles SSL-Zertifikat einer öffentlichen Zertifizierungsstelle verwenden. Dieses muss
dann für logon.beispielag.de ausgestellt sein.
Für Teststellungen ist das nicht unbedingt erforderlich, hier ist auch ein SSL-Zertifi-
kat einer eigenen Zertifizierungsstelle ausreichend. Dazu können Sie etwa die optio-
nale Rolle Active Directory-Zertifikatsdienste der Windows-Server-Betriebssysteme
über den Server Manager installieren (siehe Abbildung 3.15).
Abbildung 3.15 Installation der Active Directory-Zertifikatsdienste
Auf einem Windows Server 2012 würden die folgenden Optionen bei der Installation
der Rolle ausreichen:
왘 Rollendienste: Zertifizierungsstelle
왘 Installationstyp: Unternehmenszertifizierungsstelle
2233 Identitäten und Active-Directory-Synchronisierung
왘 Zertifizierungsstellentyp: Stammzertifizierungsstelle
왘 Privater Schlüssel: Neuen privaten Schlüssel erstellen
왘 Kryptografie für Zertifizierungsstelle: Standardoptionen
왘 Name der Zertifizierungsstelle konfigurieren: Standardoptionen
왘 Gültigkeitsdauer: Standardoptionen
왘 Zertifizierungsstellendatenbank: Standardoptionen
Diese Optionen passen Sie natürlich an Ihre Umgebung an.
Eine weitere Konfiguration ist zunächst nicht erforderlich. Das SSL-Zertifikat selbst
werden wir bei der IIS-Konfiguration erstellen lassen.
Schritt 5: ADFS-Installation (Server und Proxy)
Bei ADFS handelt es sich um eine optionale Rolle der Windows-Server-Betriebssys-
teme. Für Office 365 benötigen Sie mindestens Version 2.0 und wenigstens einen
Windows Server 2008. Für die Windows Server 2008 und 2008 R2 können Sie ADFS
2.0 unter folgender URL herunterladen:
www.microsoft.com/downloads/de-de/details.aspx?familyid=118c3588-9070-426a-
b655-6cec0a92c10b&displaylang=de
Beim Windows Server 2012 können Sie ADFS 2.1 als optionale Rolle unter dem Namen
Active Directory-Verbunddienste über den Server Manager nachinstallieren.
In Abschnitt 3.3.3, »Topologien«, finden Sie einige Aspekte, die Sie bei der Wahl der
passenden Maschinen berücksichtigen sollten.
Verwenden Sie Windows Server 2008 oder 2008 R2 laden Sie also das richtige Instal-
lationspaket für Ihre Maschinen herunter (32 oder 64 Bit bzw. Windows Server 2008
oder R2), und führen Sie die Installation des Pakets auf allen zukünftigen ADFS-Ser-
vern und -Proxys aus. Der Installationsassistent fragt, ob ein Verbundserver oder ein
Verbundserverproxy installiert werden soll (siehe Abbildung 3.16).
Wählen Sie hier auf den ADFS-Servern die Option Verbundserver und auf den
ADFS-Proxys die Option Verbundserverproxy. Nach der Installation werden Sie
noch gefragt, ob das ADFS 2.0-Verwaltungs-Snap-in zur ADFS-Konfiguration geöffnet
werden soll. Übergehen Sie diese Option, da wir zunächst noch die IIS konfigurieren,
die Konfiguration von ADFS selbst erfolgt dann im übernächsten Schritt.
Während der Installation werden alle Voraussetzungen überprüft und möglicher-
weise fehlende Komponenten nachinstalliert, wie beispielsweise die IIS.
Denken Sie an dieser Stelle daran, nach verfügbaren Update Rollups für ADFS zu
suchen und diese gegebenenfalls zu installieren.
2243.3 Identitätsverbund
3
Abbildung 3.16 ADFS-Installation auf Windows Server 2008 R2
Beim Windows Server 2012 werden Sie beim Installieren der Rolle über den Server
Manager nach den Rollendiensten gefragt (siehe Abbildung 3.17). Wählen Sie hier
Verbunddienst oder Verbunddienstproxy.
Abbildung 3.17 ADFS-Installation auf Windows Server 2012
Schritt 6: IIS-Konfiguration
In den IIS der ADFS-Server und Proxys müssen wir zwei Punkte konfigurieren:
왘 Hinzufügen des SSL-Zertifikats zu den Serverzertifikaten
왘 Hinzufügen des HTTPS-Bindings zur Standardwebsite
2253 Identitäten und Active-Directory-Synchronisierung
Beginnen wir mit dem SSL-Zertifikat:
1. Öffnen Sie den Internetinformationsdienste (IIS)-Manager (siehe Abbil-
dung 3.18).
Abbildung 3.18 IIS-Manager
2. Klicken Sie in der linken Spalte auf den lokalen Server.
Erscheint bei Ihnen die Frage nach der Verwendung der Microsoft-Webplattform,
können Sie diese abbrechen.
3. Doppelklicken Sie in der mittleren Auswahl im Abschnitt IIS den Punkt Server-
zertifikate (siehe Abbildung 3.19).
Abbildung 3.19 Server-Zertifikatsverwaltung
4. An dieser Stelle muss nun ein SSL-Zertifikat hinterlegt werden. Dabei können Sie
verschiedene Wege gehen. Der Kasten zeigt drei Wege auf.
2263.3 Identitätsverbund
SSL-Zertifikat
왘 Variante 1: bestehendes Zertifikat importieren
Haben Sie bereits ein kommerzielles SSL-Zertifikat eingekauft und in Dateiform 3
vorliegen, können Sie dieses nun in der Aktionsleiste am rechten Rand über
Importieren hinzufügen.
왘 Variante 2: neues Zertifikat mit eigener Zertifizierungsstelle erzeugen
Wollen Sie ein SSL-Zertifikat über die Windows-eigene Zertifizierungsstelle erzeu-
gen, wählen Sie stattdessen den Befehl Domänenzertifikat erstellen. Geben Sie
dann im Assistenten folgende Optionen an (siehe Abbildung 3.20):
– Gemeinsamer Name: die ADFS-URL, also beispielsweise logon.beispielag.de
– Organisation, Organisationseinheit, Ort, Bundesland/Kanton,
Land/Region: beliebig
– Online-Zertifizierungsstelle: Ihre Windows-Zertifizierungsstelle
– Anzeigename: wieder die ADFS-URL, also beispielsweise logon.beispielag.de
Das so erstellte SSL-Zertifikat können Sie dann über die Aktionsleiste exportieren,
um es bei den anderen ADFS-Servern zu importieren.
Abbildung 3.20 Erstellen eines Zertifikats
왘 Variante 3: neues Zertifikat von kommerzieller Zertifizierungsstelle beantragen
(empfohlen)
Verfügen Sie noch nicht über ein passendes SSL-Zertifikat für die ADFS-URL, kön-
nen Sie direkt im IIS-Manager eine Anforderung erstellen. Dabei handelt es sich
um eine Zeichenfolge, mit der Sie bei einer kommerziellen Zertifizierungsstelle
ein SSL-Zertifikat anfordern können. Die Zertifizierungsstelle antwortet wie-
derum mit einer Zeichenfolge, die Sie dann im IIS-Manager angeben. Gehen Sie
dazu wie folgt vor:
2273 Identitäten und Active-Directory-Synchronisierung
Wählen Sie den Befehl Zertifikatanforderung erstellen, und geben Sie im
erscheinenden Assistenten folgende Optionen an:
– Gemeinsamer Name: die ADFS-URL, also beispielsweise logon.beispielag.de
– Organisation, Organisationseinheit, Ort, Bundesland/Kanton,
Land/Region: beliebig
Im nächsten Assistentenschritt wählen Sie einen Kryptografiedienstanbieter
und eine Bitlänge aus. Was Sie hier angeben, hängt von Ihrem SSL-Zertifikatsan-
bieter ab. Im Zweifelsfall wählen Sie als Kryptografiedienstanbieter Microsoft
RSA Channel Cryptographic Provider und als Bitlänge 2048.
Im letzten Schritt geben Sie einen Dateinamen an, in dem die Anforderungszei-
chenfolge abgelegt wird.
Nachdem Sie von der Zertifizierungsstelle die Antwort bekommen haben, wählen
Sie den Befehl Zertifikatsanforderung abschließen; geben Sie die Datei und als
Anzeigename Ihre ADFS-URL an (siehe Abbildung 3.21).
Abbildung 3.21 Antwort der Zertifizierungsstelle angeben
Das so hinzugefügte SSL-Zertifikat können Sie dann über die Aktionsleiste expor-
tieren, um es bei den anderen ADFS-Servern zu importieren.
5. Markieren Sie in der linken Spalte die Default Web Site unter Server • Sites.
6. In der Aktionsleiste am rechten Rand wählen Sie den Befehl Bindungen.
7. Fügen Sie eine neue Bindung mit diesen Optionen hinzu (siehe Abbildung 3.22):
– Typ: https
– IP-Adresse: Keine zugewiesen
– Port: 443
– SSL-Zertifikat: das für ADFS bereitgestellte Zertifikat
2283.3 Identitätsverbund
3
Abbildung 3.22 Anlegen einer Bindung
Das Importieren des SSL-Zertifikats und das Erstellen der Bindung für die Standard-
website führen Sie dann auf allen anderen ADFS-Servern (und Proxys) aus. Achten Sie
darauf, überall dasselbe Zertifikat zu verwenden.
Damit haben wir jetzt die Voraussetzungen geschaffen, um die ADFS-Konfiguration
durchzuführen.
Schritt 7: ADFS-Serverfarm-Konfiguration
In Abschnitt 3.3.3, »Topologien«, haben wir uns mit den Unterschieden zwischen
einem ADFS-Einzelserver und einer ADFS-Serverfarm befasst. Bei der ADFS-Konfigu-
ration können wir zwischen diesen beiden Topologien wählen. Dabei ist grundsätz-
lich das Anlegen einer ADFS-Serverfarm die bessere Wahl, auch wenn die Farm nur
aus einem einzigen Server besteht (ein NLB wäre dann auch nicht erforderlich). Die
ADFS-Serverfarm ist im weiteren Betrieb flexibler, da wir bei Bedarf zur Farm einfach
einen weiteren ADFS-Server hinzufügen können.
Der Unterschied bei der Konfiguration zwischen Einzelserver und Farm liegt bei Letz-
terem in der Angabe eines Active-Directory-Benutzerkontos, das als Dienstkonto ver-
wendet wird. Dieses ist bei einem Einzelserver nicht erforderlich.
Mit den folgenden Schritten erstellen wir eine ADFS-Serverfarm mit nur einem ein-
zelnen Server:
1. Starten Sie die AD FS-Verwaltung über die Startseite (siehe Abbildung 3.23).
2. Klicken Sie im mittleren Teil des Fensters auf Konfigurations-Assistent für
den AD FS-Verbundserver.
3. Im Schritt Willkommen wählen Sie die Option Neuen Verbunddienst er-
stellen.
Hier könnten Sie auch einen Server zu einer bestehenden Serverfarm hinzufügen.
2293 Identitäten und Active-Directory-Synchronisierung
Abbildung 3.23 AD FS-Verwaltung
4. Im Schritt Bereitstellungstyp auswählen markieren Sie die Option Neue
Verbundserverfarm (siehe Abbildung 3.24).
Hier könnten Sie mit der Option Eigenständiger Verbundserver auch einen
ADFS-Einzelserver anlegen.
Abbildung 3.24 Bereitstellungstyp
5. Im Schritt Verbunddienstname sollte jetzt das zuvor in den IIS angegebene SSL-
Zertifikat zu sehen sein. Änderungen sind hier nicht erforderlich.
6. Im Schritt Dienstkonto angeben geben Sie ein zuvor angelegtes Active-Direc-
tory-Benutzerkonto samt Kennwort an, das für ADFS verwendet werden soll.
Achten Sie darauf, dass das Kennwort dieses Benutzerkontos nicht abläuft.
2303.3 Identitätsverbund
Die Installation selbst dauert dann einige Minuten. Der Assistent hält Sie während-
dessen auf dem Laufenden (siehe Abbildung 3.25).
3
Abbildung 3.25 Konfigurationsfortschritt
Nachdem die Installation und der Assistent abgeschlossen wurden, erhalten Sie eine
Informationsmeldung, die Konfiguration wäre unvollständig (siehe Abbildung 3.26).
Abbildung 3.26 Konfiguration unvollständig
2313 Identitäten und Active-Directory-Synchronisierung
Dies ist korrekt, da wir noch keine Vertrauensstellung zwischen ADFS und Office 365
hergestellt haben. Das holen wir aber in Kürze nach.
Falls Sie zu Ihrer ADFS-Serverfarm weitere Server hinzufügen, denken Sie daran, dass
dann ein NLB erforderlich ist. Sie könnten dazu das optionale Windows-Server-
Feature Netzwerklastausgleich verwenden.
Schritt 8: ADFS-Proxykonfiguration
Nach der Erstellung unserer ADFS-Serverfarm folgt das Konfigurieren des ADFS-Pro-
xys in der DMZ. Stellen Sie bitte vorab in der Firewallkonfiguration sicher, dass der
ADFS-Proxy die ADFS-Serverfarm über den Standard-HTTPS-Port 443 erreichen kann.
Ebenso sollte dieser Port samt Protokoll in Richtung Internet freigegeben werden.
Danach konfigurieren Sie den Proxy:
1. Starten Sie den AD FS-Verbundserverproxy-Konfigurations-Assistent aus
dem Startmenü (siehe Abbildung 3.27).
Abbildung 3.27 AD FS-Verbundserverproxy-Konfigurations-Assistent
2. Im Schritt Verbunddienstnamen angeben sollte der Name der ADFS-Server-
farm automatisch aufgeführt sein.
Mit einem Klick auf Verbindung testen können Sie sicherstellen, dass die ADFS-
Serverfarm erreicht werden kann. Sollte es hier Probleme geben, überprüfen Sie
die Firewallkonfiguration.
3. Geben Sie in das Anmeldefenster die Benutzerkontodaten des ADFS-Dienstkontos
an.
Die Installation selbst ist dann in wenigen Augenblicken abgeschlossen.
Auch hier können Sie wieder weitere ADFS-Proxyserver einrichten und diese über
einen vorangestellten NLB koppeln.
232Sie können auch lesen
