Azure Hybrid – wie wird sicher authentisiert?

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.

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.

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.

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:

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.