Moderne Authentifizierung im Azure AD
Zugang neu geregelt
Veröffentlicht in Ausgabe 05/2021 - PRAXIS
Die ursprünglich für 2020 angedachte Abkündigung der Standardauthentifizierung und unsicheren Appzugriffe seitens Microsoft und Google wurde zwar aufgrund der Corona-Pandemie auf die zweite Jahreshälfte 2021 (Microsoft) beziehungsweise unbestimmt (Google) verschoben, ist aber immer noch vollumfänglich in Planung. Daher sollten sich Nutzer von Microsoft 365 oder Google Workspace baldmöglichst mit der "modernen Authentifizierung" auseinandersetzen.
Moderne Authentifizierung
Bevor es an die Implementierung geht, stellt sich die Frage, um was es sich bei moderner Authentifizierung oder "modern authentication" überhaupt handelt. Eine einheitliche Definition dieses Begriffs gibt es nicht. Was unterscheidet dann aber die moderne von der bisherigen Authentifizierung? Letztlich geht es dabei um einen Paradigmenwechsel auf Protokollebene, um so die Verfahren den Anforderungen der heutigen Zeit anzupassen.
Ein Grundproblem mit der sogenannten Standardauthentifizierung (Nutzername und Passwort) ist, dass diese Zugangsdaten uneingeschränkt weitergegeben werden können, da keine zusätzliche Prüfung stattfindet. Außerdem benötigen Nutzer für jeden Dienst einen neuen Login, was zu den bekannten Problemen in der Passwortsicherheit führt und für User natürlich nicht komfortabel ist. Single Sign-on (SSO) schafft hier Abhilfe. Dennoch ist SSO nicht mit moderner Authentifizierung zu verwechseln, denn die einmalige Authentisierung mit anschließender automatischer Autorisierung ist auch unter traditionellen Protokollen wie Kerberos möglich.
Die ursprünglich für 2020 angedachte Abkündigung der Standardauthentifizierung und unsicheren Appzugriffe seitens Microsoft und Google wurde zwar aufgrund der Corona-Pandemie auf die zweite Jahreshälfte 2021 (Microsoft) beziehungsweise unbestimmt (Google) verschoben, ist aber immer noch vollumfänglich in Planung. Daher sollten sich Nutzer von Microsoft 365 oder Google Workspace baldmöglichst mit der "modernen Authentifizierung" auseinandersetzen.
Moderne Authentifizierung
Bevor es an die Implementierung geht, stellt sich die Frage, um was es sich bei moderner Authentifizierung oder "modern authentication" überhaupt handelt. Eine einheitliche Definition dieses Begriffs gibt es nicht. Was unterscheidet dann aber die moderne von der bisherigen Authentifizierung? Letztlich geht es dabei um einen Paradigmenwechsel auf Protokollebene, um so die Verfahren den Anforderungen der heutigen Zeit anzupassen.
Ein Grundproblem mit der sogenannten Standardauthentifizierung (Nutzername und Passwort) ist, dass diese Zugangsdaten uneingeschränkt weitergegeben werden können, da keine zusätzliche Prüfung stattfindet. Außerdem benötigen Nutzer für jeden Dienst einen neuen Login, was zu den bekannten Problemen in der Passwortsicherheit führt und für User natürlich nicht komfortabel ist. Single Sign-on (SSO) schafft hier Abhilfe. Dennoch ist SSO nicht mit moderner Authentifizierung zu verwechseln, denn die einmalige Authentisierung mit anschließender automatischer Autorisierung ist auch unter traditionellen Protokollen wie Kerberos möglich.
Als die Grundlagen der Authentifikation gelegt wurden, konnte sich noch niemand den Umfang der vernetzten Welt von heute vorstellen. Die Geschichte des besagten Protokolls Kerberos reicht beispielsweise bis in die 1970er-Jahre zurück, dennoch kommt es in seiner aktuellsten Version auch heute noch zum Einsatz. Für abgeschlossene Unternehmensnetzwerke kann es immer noch gute Dienste leisten, doch stehen wir heute vor ganz anderen Herausforderungen. Statt geschlossener Systeme haben wir es inzwischen mit verteilten Infrastrukturen zu tun. VPN-Verbindungen zwischen Home Office und Büro stellen zwar einen Workaround dar, um die traditionellen Verfahren zu erweitern, sind aber keine optimale Lösung.
Kerberos als Standardprotokoll in Active-Directory-Umgebungen ist mit seiner Funktionsweise noch tief in den traditionellen Unternehmensnetzwerken verwurzelt, wo es nur wenige Anknüpfungen in das öffentliche Netz gab. Zu einer Welt, in der remote gearbeitet wird, Daten in der Cloud lagern und Software als Service ins Haus kommt, passt das Protokoll aber nicht mehr. Dafür braucht es neue Ansätze, die einige Voraussetzungen erfüllen: Zunächst müssen sie die Trennung von Identity Provider (wie etwa Microsoft) und Service Provider (zum Beispiel MailStore) ermöglichen. Zwischen diesen beiden Entitäten sollte es keine direkte Kommunikation geben, die etwa das Öffnen von Firewalls erfordern würde. Das bedeutet aber im Umkehrschluss, dass Vertrauen in den Identity Provider für das Verfahren essentiell ist.
OpenID Connect als Schnittstelle
Aufbauend auf diesen Forderungen und der Einführung des Identity Providers als vertrauenswürdige dritte Instanz gibt es verschiedene Protokolle für die sichere Kommunikation zwischen Identity Provider und Service Provider. Diese lassen sich dann zusammenfassend als moderne Authentifizierung beschreiben. Das wichtigste darunter ist heute OpenID Connect. OAuth, das ebenfalls eine große Bedeutung für die modernen Verfahren innehat, ist kein Authentifizierungsprotokoll, sondern ein Autorisierungsprotokoll; verwandt sind die beiden dennoch.
OpenID Connect stellt eine Erweiterung von OAuth dar, das zunächst nur für die Dienst-zu-Dienst-Interaktion entwickelt wurde. Mit OpenID Connect ist dagegen auch die Authentifikation von Personen oder Benutzern möglich. Über OAuth werden Autorisierungstoken zwischen Identity- und Service Provider übermittelt.
In dieser automatisierten Interaktion der Dienste untereinander über Token liegt für Administratoren ein großer Vorteil. Sie können alle Richtlinien an einer zentralen Stelle konfigurieren, wenn erst einmal alle relevanten Anwendungen beim Identity Provider registriert sind. Dies kann etwa das Festlegen sein, wann und wie oft Multifaktorauthentifizierung zum Einsatz kommt.
Damit sich die Vorteile moderner Authentifizierung für Administratoren voll auszahlen, müssen alle im Unternehmen eingesetzten Anwendungen sie unterstützen. Diese Anforderung gilt für cloudnative Anwendungen ebenso wie für solche, die on-premises im Unternehmen laufen. Wie die Registrierung einer aktuellen Anwendung in Microsoft 365 über Azure AD funktionieren kann, zeigen wir im Folgenden.
Anwendungen als App in Azure AD registrieren
Durch die Registrierung als App erhält eine Anwendung oder ein Dienst eine Identität innerhalb von Azure AD. Diese ermöglicht die Authentifizierung gegenüber den Mandantendiensten und die Nutzung ihrer Ressourcen. Melden Sie sich als globaler Administrator für Ihren Microsoft-365-Mandanten im Azure-Portal an. Wählen Sie im Navigationsmenü die Option "Azure Active Directory" und in der folgenden Ansicht im Navigationsmenü links in der Sektion "Verwalten" die Option "App-Registrierungen". Klicken Sie auf "Neue Registrierung", sehen Sie die Ansicht "Anwendung registrieren". Geben Sie in das Feld "Name" den gewünschten Anzeigenamen ein. Dieser wird den Benutzern später zum Beispiel beim Login angezeigt.
Alle weiteren Einstellungen auf der Seite können Sie im Allgemeinen in ihren Voreinstellungen belassen. Klicken Sie nun auf "Registrieren". Wenn die Registrierung erfolgreich war, gelangen Sie auf die Übersichtsseite der neu registrierten App. Die auf der Übersichtsseite angezeigte Anwendungs-ID (Client) identifiziert die Anwendung innerhalb Ihres Azure-AD-Mandanten und muss zusammen mit dessen Verzeichnis-ID (Mandant) als Nächstes in die Anwendung eingetragen werden. Lassen Sie dazu die Übersichtsseite der App im Browser geöffnet.
Erstellen und Bekanntmachen der Anmeldeinformationen
Anmeldeinformationen für Microsoft 365 bestehen aus den eben erstellten IDs und einem Geheimnis, mit dem eine Anwendung ihre Identität gegenüber Azure AD nachweist. Microsoft empfiehlt die Verwendung von Zertifikaten als Geheimnis zur Identifizierung einer App in Azure AD. Ein solches Zertifikat wird in der Regel beim Erstellen von Anmeldeinformationen in der Anwendung erzeugt. Die genauen Schritte finden Sie in der Dokumentation der jeweiligen Anwendung. Für Applikationen, die keine Zertifikate unterstützen, bietet sich alternativ auch eine Zeichenfolge als sogenannter geheimer Clientschlüssel an, was aber weniger sicher ist. Im Folgenden gehen wir davon aus, dass ein Zertifikat als Anmeldeinformation generiert wurde.
Damit Azure AD die Identität einer Anwendung überprüfen kann, muss das erstellte Zertifikat in Azure AD bekannt gemacht werden. Wechseln Sie in das noch geöffnete Browser-Fenster mit der Übersichtsseite der App in Azure AD. Wählen Sie im Navigationsmenü links in der Sektion Verwalten die Option "Zertifikate & Geheimnisse" und dann im Bereich "Zertifikate" die Schaltfläche "Zertifikat hochladen". Selektieren Sie die zuvor gespeicherte Zertifikatsdatei und laden Sie diese durch Klicken auf "Hinzufügen" in Azure AD hoch. Anschließend sehen Sie den Fingerabdruck des hochgeladenen Zertifikats und sein Start- und Ablaufdatum in der Zertifikatsliste.
Konfigurieren der App-Authentifizierung
Damit Azure AD das Ergebnis einer Benutzerauthentifizierungsanfrage einer anderen Anwendung mitteilen kann, muss Azure AD der Endpunkt mitgeteilt werden, auf dem diese App die Authentifizierungsantworten erwartet – der sogenannte Umleitungs-URI. Wählen Sie im geöffneten Browser-Fenster im Navigationsmenü links in der Sektion "Verwalten" die Option "Authentifizierung". Selektieren Sie dann im Bereich "Plattformkonfiguration" die Schaltfläche "Plattform hinzufügen". Die auszuwählende Plattform, der dort zu konfigurierende Wert des Umleitungs-URIs und die vom Autorisierungsendpunkt auszugebenden Token unterscheiden sich je nach Anwendung, folgen Sie auch hier der Dokumentation der Anwendung.
Vier Schritte zum Zugriff
- Authentisierung: Der erste Schritt zur Prüfung der Identität, indem eine Entität aktiv eine bestimmte Identität behauptet. Beispiel: Eingabe von Benutzername und Passwort durch einen Benutzer.- Authentifikation: Die Überprüfung der Echtheit der behaupteten Identität anhand der vorgelegten Nachweise. Beispiel: Die Überprüfung von eingegebenen Benutzernamen und Passwort gegen die im Backend gespeicherten Daten.- Authentifizierung: Die Bestätigung der behaupteten Identität, wenn die Authentifikation erfolgreich war. Da es im englischen Sprachraum keine Unterscheidung zwischen der Authentifikation (Vorgang) und der Authentifizierung (Ergebnis) gibt, werden beide Schritte auch im Deutschen häufig unter dem Begriff "Authentifizieren" (also authenticate) zusammengefasst.- Autorisierung: Das Überprüfen und gegebenenfalls Einräumen bestimmter Rechte der authentifizierten Identität. Beispiel: Ein Benutzer hat nach erfolgreicher Authentifizierung nur Zugriff auf jene Dateien, für die er berechtigt ist.
Umleitungs-URI und API konfigurieren
Damit die Anwendung den Umleitungs-URI anfragenden Clients diesen mitteilen kann, muss jener auch dort konfiguriert werden. Kopieren Sie hierzu einfach den zuvor konfigurierten Wert aus dem Azure AD im Browser in das entsprechende Feld der Anwendung. Sollen sich Benutzer von außerhalb des Firmennetzwerks ohne VPN an der Anwendung anmelden, muss der Umleitungs-URI auch im Internet per DNS auflösbar sein und gegebenenfalls Port-Weiterleitungsregeln auf der Firewall oder dem Router eingerichtet werden.
Sinn der Registrierung und Konfiguration der Anwendung zur Kommunikation mit Azure AD ist letztendlich, dieser den Zugriff auf bestimmte Ressourcen zu ermöglichen. Dazu ist es notwendig, die Anwendung für solche Aufrufe zu autorisieren. Eine solche Berechtigung kann je nach angefragter Ressource durch einen Benutzer oder einen Administrator erfolgen. Dabei unterscheidet die Azure AD zugrundeliegende Microsoft Identity Platform zwischen delegierten Berechtigungen und Anwendungsberechtigungen.
Delegierte Berechtigungen erlauben es der Anwendung, als ein angemeldeter Benutzer auf bestimmte Ressourcen in Azure zuzugreifen. Der angemeldete Benutzer willigt hierbei ein, dass die Anwendung bei bestimmten Aufrufen in Azure so tut, als sei sie der Benutzer – der Benutzer delegiert also bestimmte Berechtigungen an die Anwendung. Der Vorteil dieses Mechanismus etwa gegenüber einer Impersonation ist, dass die Anwendung nicht mit allen Rechten ausgestattet wird, die ein angemeldeter Benutzer hat, sondern eben nur mit den an die Anwendung delegierten.
Zudem hängen diese effektiven Berechtigungen auch davon ab, welcher Benutzer angemeldet ist. Beispielsweise wird der Anwendung durch die hier im Artikel beschriebene Registrierung standardmäßig die delegierte Berechtigung "User.Read" in der Microsoft Graph API erteilt, damit sich Benutzer mit ihren Azure-AD-Credentials anmelden können und die Anwendung Benutzerprofilinformationen auslesen darf. Die Berechtigung ist dabei auf das Lesen des Benutzerprofils beschränkt, das sich bei Azure AD anmeldet. Bei bestimmten erhöhten Berechtigungen ist jedoch eine Administratoreinwilligung erforderlich.
Anwendungsberechtigungen erlauben es der Anwendung, im eigenen Namen auf Ressourcen zuzugreifen, also auch wenn kein Benutzer angemeldet ist. Dies ist etwa bei Windows-Diensten oder Unix-Daemons der Fall. Die Anwendung erhält also explizite, ihr zugehörige Berechtigungen, die unabhängig vom gerade angemeldeten Benutzer sind; häufig sind solche Berechtigungen weiter gefasst als delegierte Berechtigungen. Beispielsweise könnte eine Anwendung mittels der Anwendungsberechtigung "Directory.Read. All" Daten aller Benutzer, Gruppen oder Anwendungen im Verzeichnis der Organisation auslesen, ohne dass hierfür etwa jeder dieser Benutzer seine Zustimmung erteilen müsste. Anwendungsberechtigungen erfordern die Einwilligung eines Administrators.
Welche Berechtigungen von einer bestimmten Anwendung benötigt werden, ist natürlich von Fall zu Fall verschieden. Um die Vergabe von Berechtigungen etwas anschaulicher zu machen, zeigen wir im Folgenden, wie Sie einer Anwendung die Berechtigung erteilen können, um die Liste aller Benutzer eines Mandanten in Azure AD auslesen zu dürfen. Wechseln Sie wieder zu Azure AD im noch geöffneten Browser-Fenster. Wählen Sie dort im Navigationsmenü links in der Sektion "Verwalten" die Option "API-Berechtigungen". Selektieren Sie im Bereich "Konfigurierte Berechtigungen" die Schaltfläche "Berechtigung hinzufügen". Nun wählen Sie auf der Menüseite "API-Berechtigungen anfordern" im Bereich "Häufig verwendete Microsoft-APIs" die API "Microsoft Graph".
Hier nehmen Sie die Option "Anwendungsberechtigungen" und aktivieren im Bereich "Berechtigungen auswählen" die Berechtigung "Directory / Directory.Read.All". Klicken Sie auf "Berechtigungen hinzufügen", woraufhin sich die Anzeige aktualisiert. Die Berechtigung "Directory. Read.All" erscheint in der Liste der API-Berechtigungen unter "Microsoft Graph". Wählen Sie im Bereich "Konfigurierte Berechtigungen" erneut die Schaltfläche "Berechtigung hinzufügen". Klicken Sie dann unter "Konfigurierte Berechtigungen" auf die Schaltfläche "Administratorzustimmung für <Ihr Mandantenname> erteilen". Bestätigen Sie den nachfolgenden Hinweis mit "Ja". Der Status der erteilten Berechtigungen wird auf "Gewährt für <Ihr Mandantenname>" aktualisiert.
Fazit
Auch wenn Google und Microsoft die Fristen für das Ende der Standardauthentifizierung nach hinten verschoben haben, lohnt sich ein Umstieg auf die moderne Authentifizierung. Die moderne Authentifizierung ist nicht nur wesentlich sicherer, sondern auch benutzerfreundlicher. Dazu kommen noch die Vorteile für Administratoren in der Verwaltung.
(dr)
Björn-Arne Meyn ist Product Manager bei der MailStore Software GmbH.