Immer mehr Unternehmen haben einen Sync ihres Active Directory zu Azure. Also eine AD Hybrid Stellung. Das Synchronisieren von Identitäten hat immer auch mit Vertrauen zu tun. Deswegen vergleichen wir hier unterschiedliche AD Hybrid Methoden und zeigen deren Vor- & Nachteile auf.
Der Pakt mit der Cloud
Solange man die on-premise Welt und die Cloud Welt in Azure mit der gleichen Identität betreiben will, ist ein Pakt mit der Cloud notwendig. Andere sprechen von Hybrid Stellung. Microsoft stellt 4 verschiedene Authentisierungsmethoden zur Verfügung:
-
- Password Hash Synchronisation (PHS)
- Pass-Through Authentication (PTA)
- Federation with ADFS (ADFS)
- PingFederate (3rd Party)
Möchte man ein Azure Dienst nutzen, wird die Authentisierung für dessen Dienst bei den ersten beiden Methoden direkt in Azure durchgeführt. Das bedeutet, dass zumindest kurzzeitig die Credentials der Benutzer Azure bekannt sind. Bei PHS werden, wie der Name schon sagt, die 16 Bytes NTLM-Hashes der Benutzerpasswörter zur Azure gesyncht. Mehr dazu später.
Zwei Welten verbinden
An dieser Stelle ist wichtig zu erwähnen, dass die Hybrid Stellung nur dafür da ist, dass der Weg der zukünftigen Azure Kunden möglichst einfach sein soll. Mit einer Hybrid Stellung treffen zwei komplett unterschiedliche Welten aufeinander. Beispielsweise wird bei einer on-premise Ressource auf Kerberos Authentication gesetzt, in Azure kommt hingegen OpenID Connect / OAuth2 zum Zuge. Wenn eine on-premise Identität zu Azure synchronisiert wird, braucht es zwischen diesen beiden Identitäten einen Anker der die beiden Identitäten «miteinander verbindet».
Azure AD muss schliesslich «wissen», welche on-premise Identität zur welcher Azure Identität gehört. Als Anker wählt man ein AD Attribut aus, welches on-premise nur einmalig pro AD Objekt vorkommt. Dieses schreibt man bei der Synchronisierung zu Azure Active Directory (AAD) ins AAD Objekt. Dieses AD Attribut darf zudem nie geändert werden. Als Anker könnte man auf den ersten Blick den User Prinzipal Name (UPN) oder die Emailadresse des Benutzers nehmen. Aber wenn eine Firmenübernahme stattfindet, besteht die Gefahr, dass auch diese beiden AD Attribute geändert werden. Daher ist als Anker das mS-DS-ConsistencyGuid Attribut zu empfehlen.
AAD Connect
Da PingFederate nicht so häufig vorkommt, vergleichen wir die ersten drei Methoden. Bei all diesen Methoden wird die Installation des Azure AD (AAD) Connect vorausgesetzt. AAD Connect wird on-premise auf einem Member Server Installiert. AAD Connect kann aus redundanzgründen mehrfach installiert werden, aber es gibt immer nur einen Primary AAD Connect Server. AAD Connect synchronisiert das Active Directory, oder Teile davon, mit dem Azure AD. Die AAD Connect Server sollten wie ein Tier 0 Server geschützt werden, denn mit Hilfe dieses Konto kann man für jeden AD User ein Kerberos Ticket generieren.
Password Hash Synchronisation (PHS)
Diese Authentisierungsmethode für Hybrid Stellungen ist die einfachste ihrer Art.
Der AAD Connect Agent synchronisiert die Identitäten von AD ins AAD inklusiv des Password Hashes (unicodepwd). Somit kann Azure die Benutzerauthentisierung direkt in der Cloud durchführen. Während des Authentisierungsprozesses vergleicht Azure das eingegebene Password mit einer Liste von geleakten Passwörtern. Bei einem Treffer wird es im Leaked Credential Report aufgeführt und eine Benachrichtigung findet statt. PHS bietet zusätzlich das Feature Seamless SSO an. Das bietet den Vorteil, dass der Benutzer sich nur einmal anmelden muss. Hat der Benutzer sich on-premise angemeldet, muss er oder sie sich für den Zugriff auf eine Azure Ressource nicht nochmals erneut anmelden. Seamles SSO funktioniert auch, wenn der Benutzer sich zuerst in Azure authentisiert hat und dann auf eine on-premise Ressource per Kerberos zugreifen will. Hier ist wichtig, dass der Azure AD Connect stets funktioniert.
Pass-Through Authentication (PTA)
Microsoft empfiehlt aus Redundanzgründen, dass on-premise auf drei Domain Member Servern jeweils ein Authentication Agent installiert wird.
Wenn sich ein Benutzer in Azure anmelden möchte, wird er auf die Webseite von Azure Security Token Service (Azure STS) weitergeleitet. Nach der Eingabe von Benutzername und Passwort verschlüsselt Azure STS die Credientals mit den jeweiligen Public Keys von den Authentication Agents und sendet es zum entsprechenden Authentication Agent. Dieser entschlüsselt es mit dem Private Key und sendet die Anmeldedaten über die Win32 LogonUser-API zum Domänen Controller. Die Antwort des DC’s sendet der Authentication Agent an Azure STS weiter. Nach der positiven Validierung der Antwort wird der Benutzer zur Azure MFA Authentisierung weitergeleitet, wenn dies aktiv ist. Im anderen Falle ohne MFA wird der Benutzer zu seinem Azure Dienst weitgergeleitet.
PTA kann wiePHS mit Seamless SSO erweitert werden. Als Backup Authentisierungsmethode kann PHS eingerichtet werden. Dann würde Azure die Authentisierung übernehmen, wenn kein Authentication Agent on-premise erreichbar ist. Da das Passwort während des Authentisierungsprozesses «durch Azure fliesst», vergleicht Azure wie bei PHS das verwendete Passwort mit der Liste von geleakten Passwörtern ab. Wie die AAD Connect Server sind auch die PTA Server im Tier 0 anzusiedeln. Denn durch einen kompromittierten PTA können die 16 Byte NTLM Hashes der AD Benutzer entwendet werden.
Federation with ADFS (ADFS)
Dies ist die einzige dieser drei Methoden, bei dem der Anmeldeprozess (Authentisierung) on-premise durchgeführt wird. Anders ausgedrückt, die Passwörter bleiben in der on-premise Welt.
On-Premise wird eine Active Directory Federation Services (ADFS)-Farm von mindestens zwei ADFS Servern installiert. Die ADFS Server bieten den Benutzern die Möglichkeit, dass Sie webbasiert sich authentisieren können. ADFS Server müssen in die Domäne eingebunden werden und sind somit in der internen Zone angesiedelt. Da es sich hier auch um Identity Server handelt, sollten sie als Tier 0 Server klassifiziert werden. Damit die ADFS Dienste von extern erreichbar sind, werden in der DMZ Web Application Proxy (WAP) installiert. Oben im Bild sind diese als Federation Proxy beschrieben.
Wenn der Benutzer von extern sich bei Azure anmelden will, wird er zum Azure STS weitergeleitet, wo der Benutzer seine Emailadresse eingeben kann. Anhand der Email Domain kann Azure das Tenant Mapping machen und der Benutzer wird zum Federation Proxy weitergeleitet. Bei dieser Weiterleitung erhält der Browser des Benutzers ein sogenanten WS-FED Request (Windows Federation Request). Dieser WS-FED sendet der Browser dem Federation Proxy und der Benutzer kann sich on-premise authentisieren. Nach erfolgreicher Anmeldung erhält der Browser des Benutzers den WS-FED Response. Darin bezeugt der ADFS Server, dass der Benutzer sich erfolgreich angemeldet hat und Mitglied von ausgewählten AD Gruppen ist. Dieser WS-FED Response wird aus Sicherheitsgründen signiert. Zusätzlich erhält der Browser des Benutzers den Befehl, dass er die Azure STS Webseite aufrufen und das WS-FED vorzeigen soll. Azure STS validiert den WS-FED Response und leitet den Benutzer zur Azure MFA Authentisierung weiter, falls MFA aktiviert ist. Ansonsten wird der Benutzer zu seinem Azure Dienst weitergeleitet. Sollte hingegen der Benutzer von seinem AD bereits ein Kerberos TGT bekommen haben, kann die Authentisierung beim ADFS smooth per Sing-Sign-On (SSO) durchgeführt werden. Und schon wieder hat man der Belegschaft die Usability erhöht. «Gärngsche.»
Microsoft hat in den letzten Jahren vielen Funktionen des ADFS Servers bei PHS & PTA eingebaut. Beim Conditional Access hat sogar Azure AD die Nase vorn, da dies beim ADFS nicht so ausgereift implementiert wurde. Auch Smart Card Authentication ist bei Azure über Windows Hello for Business (WHfB) verfügbar. Daher kommt die ADFS Authentisierungsmethode grundsätzlich nur noch dort zum Einsatz, wo eine Cloud Authentication nicht in Frage kommt. Die ADFS Authentisierungsmethode ist vor allem in der Schweiz und in Deutschland im Gesundheitswesen, Versicherungen und Behörden anzutreffen.
Entscheidungsmethode
Alle drei Authentisierungsmethoden haben ihre Abhängigkeiten und sollten hoch verfügbar ausgelegt werden. Daher sollte die Entscheidung der Authentisierungsmethode mit folgendem Decision tree von Microsoft gefällt werden:
Persönliches Fazit
Microsoft bietet mit den unterschiedlichen Authentisierungsmethoden ein sehr grosses Spektrum für Authentisierung und Authorisierung für Cloud Dienste ab. Schliesslich will Microsoft den zukünftigen Kunden den Einstieg in Azure möglichst einfach gestalten. Anhand der Funktionen, die neu implementiert wurden, kann man erkennen, dass Microsoft PTA & PHS deutlich vor ADFS bevorzugt. Trotzdem bin ich immer noch Fan von der ADFS Authentisierungsmethode, da die Credentials on-premise bleiben. Soll heissen der Authentisierungsprozess findet on-premise statt. Zusätzlich kann mit der bestehenden ADFS-Farm für Azure auch SSO für andere Webdienste ermöglicht werden. Egal ob es sich da um Webdienste von anderen Cloudanbietern oder on-premise Webdienste handelt. Solange die on-premise Welt noch besteht, würde ich ADFS aus den oben genannten Security- und Usability-Gründen bevorzugen. Hat man kein on-premise mehr, braucht es auch keine Hybrid Stellung mehr. 😉
Point
Point ist Security Engineer bei AVANTEC und hat sich spezialisiert im Access-, Identitäts- und im Clientbereich. Die MS-Welt ist ihm auch nicht fremd. Er setzt sich für das Gute ein, weil die gute Seite am Schluss immer gewinnt :-)