Authentifizierung im Azure AD

Tja, was soll man dazu sagen? Das Thema Authentifizierung ist generell im IT-Bereich sicher nicht das beliebteste, aber durchaus das wichtigste und aus technischer Sicht dann doch wieder einigermaßen interessant. Schließlich gehört das Thema in den Bereich "Identity Management" und somit zu den absoluten Basis-Voraussetzungen jeder guten IT. Da dieses Thema so wichtig ist, möchte ich ganz am Anfang gerne auf die Begriffsdefinition eingehen - was bedeutet Authentifizierung eigentlich? Und wie fügt sich das Thema in Office 365 / Azure ein?

 

Grundlage und Begriffserklärungen

Um hier eine Abgrenzung vornehmen zu können sollte man sich Begriffe ansehen, die ähnlich klingen und ähnliches meinen. Die Seite datenschutzbeauftragter-info.de hat sich die Mühe gemacht und einen sehr guten Artikel verfasst, der die Begriffe Authentisierung, Authentifizierung und Autorisierung gegeneinander abgrenzt. Ich möchte daher aus diesem Artikel die Kernaussage zitieren:

  1. Authentisierung: Eingabe von Login-Daten in einem EDV-System (Behauptung einer Identität)
  2. Authentifizierung: Überprüfung der Behauptung durch das EDV-Systems inkl. Ergebnis der Prüfung (Verifizierung der Behauptung aus 1.)
  3. Autorisierung: Prüfung der Rechte und Konsequenz (Einräumung oder Verweigerung von Rechten)

Quelle: https://www.datenschutzbeauftragter-info.de/authentisierung-authentifizierung-und-autorisierung/ (Abruf 11.09.2018)

Um bei den Basics zu bleiben: das Azure AD ist nichts anderes als die Grundlage für Benutzerkonten, denen gewisse Rechte und Lizenzen zugewiesen sind. Ohne ein Benutzerkonto im Azure AD kann sich der korrespondierende Benutzer nicht anmelden - in der Folge können keine Rechte- und Lizenzzuweisungen abgerufen werden und somit kann der Benutzer nicht arbeiten. 

Gibt es den korrespondierenden Benutzer jedoch im Azure AD und er meldet sich dort an (Authentisierung), dann wird in verschiedenen Szenarien auf verschiedene Weise geprüft (Authentifizierung), um dem Benutzer die Anmeldung schließlich freizugeben (Autorisierung) und ihm Rechte und Lizenzen bereitzustellen. Je nach Art und Umfang kann der Benutzer dann Microsoft Online-Dienste nutzen, wie beispielsweise Exchange Online oder Skype for Business Online.

Um die Verwirrung komplett zu machen: die Basis für die Identitäten muss nicht primär das Azure AD sein. Viele Unternehmen nutzen ein Active Directory oder ein anderes LDAP-Verzeichnis. Manche Unternehmen sind mit einem Notes Directory unterwegs. Wieder andere befinden sich mit der IT-Infrastruktur gerade im Aufbau und haben noch gar keine Grundlage. Aus diesem Grund bietet Microsoft viele unterschiedliche Mittel und Wege, das eigentliche Ziel (Benutzer kann sich anmelden und arbeiten) zu erreichen. Auf diese unterschiedlichen Szenarien möchte ich hier eingehen.

 

Mögliche Szenarien

 

Keine Anmeldeinfrastruktur vorhanden

Das wahrscheinlich einfachste, aber leider nicht häufigste Szenario. Es gibt keine bereits existierende Anmeldeinfrastruktur, kein AD, kein anderes LDAP-Verzeichnis, einfach nichts. Das Unternehmen befindet sich gerade im Aufbau (Gründung) oder existiert bereits, arbeitet jedoch mit bspw. lokalen Benutzer am PC. In diesem Fall ist es relativ simpel, das Azure AD zu befüllen: einfach im Azure Portal einloggen und im Azure AD Benutzer anlegen. Sofern in der Zukunft keine Notwendigkeit für eine lokale Netzwerkumgebung besteht ist dies der schnellste und effektivste Weg zum Ziel. Damit ist man auch zukünftig zu 100% auf Cloud-Nutzung ausgerichtet.

 

Active Directory oder LDAP-Dienst vorhanden - Anmeldung soll im Azure AD stattfinden

Dies ist das wahrscheinlich häufigste Szenario im deutschen Mittelstand. Es gibt eine lokale Netzwerkumgebung mit Dateifreigaben, geteilten Druckern usw. und Benutzer melden sich an den PC's mit einem Account an, der nicht lokal auf dem PC gespeichert ist, sondern in einer sogenannten Domäne (AD/LDAP). Dann haben die Benutzer bereits einen Benutzernamen und ein Passwort, welche gemerkt werden müssen - daher wäre es äußerst unkomfortabel, wenn ein zweiter Benutzername mit zweitem Passwort für das Azure AD dazukäme. 

Microsoft hat hierfür ein Tool entwickelt: den Azure AD Connect (AADC). Dieser wird in der lokalen Umgebung (LAN) auf einem vollwertigen Server (Small Business und Essentials sind ausgeschlossen) installiert und nach Wunsch konfiguriert. Die Firewall muss i.d.R. nicht angepasst werden, da der AADC über Port 443 mit dem Azure AD kommuniziert und gemäß der Konfiguration Benutzerkonten wahlweise mit/ohne Passwort-Hash-Synchronisation ins Azure AD synchronisiert. Wenn sich im AD etwas ändert, wird die Änderung im Standard nach spätestens 30 Minuten auch im Azure AD automatisch umgesetzt sein. Für die Benutzer ist es somit sehr einfach: immer, wenn sie nach Anmeldeinformationen gefragt werden, können sie die Daten eingeben, die sie bereits von der morgendlichen PC-Anmeldung kennen. Die Authentifizierung (wir erinnern uns: Prüfung der Behauptung, Person X zu sein) findet hierbei online (im Azure AD) statt.

 

Active Directory oder LDAP-Dienst vorhanden - Anmeldung soll lokal (nicht im Azure AD) stattfinden

Wer etwas mehr Luxus möchte und bereit ist, die lokale Infrastruktur entsprechend zu erweitern und zu konfigurieren, der hat die Möglichkeit, die Authentisierung und Authentifizierung weiterhin "im Haus" zu behalten und nur die Autorisierung durch das Azure AD durchführen zu lassen. Dafür kommt ein Microsoft-Dienst namens "Active Directory Federation Services" (ADFS) zum Einsatz. Dazu installieren man im Netzwerk der lokalen AD-Domäne den ADFS-Server (besser mind. zwei Server wegen Ausfallsicherheit). Der ADFS arbeitet fortan als sogenannter "Identity Provider" (IdP) - der Begriff wird sicher in so einigen Fachartikeln zu diesem Thema zu lesen sein. Nachdem die Anmeldung getestet wurde befiehlt man den Microsoft Online-Diensten bei Eingabe der Anmeldeadresse (Benutzername@TopLevelDomain) die TopLevelDomain zu erkennen und daraufhin den Anmeldeprozess nicht im Azure AD, sondern auf der Webseite des ADFS stattfinden zu lassen. Sobald also in der Anmeldemaske der Online-Dienste der Benutzername eingegeben wurde, erfolgt sofort die Umleitung auf die Anmeldeseite des ADFS-Servers. Ab diesem Zeitpunkt gibt der Benutzer sein Passwort nicht mehr in der Cloud ein, sondern in der lokalen Infrastruktur. Der ADFS authentifiziert dann die von ihm eingegebenen Daten gegen den Verzeichnisdienst (AD/LDAP) und überträgt lediglich einen sog. "Token" ins Azure AD. In diesem Token stehen keine Zugangsdaten oder Passwörter, sondern nur die Information, dass der Benutzer authentifiziert wurde und das Azure AD nun die Autorisierung vornehmen darf.

Ein weiterer Vorteil für die Benutzer: sofern sich ein Benutzer am Morgen am PC bereits mit den AD/LDAP-Zugangsdaten angemeldet hat und er sich im späteren Verlauf an einem Microsoft Online-Dienst anmelden möchte, so erkennt der ADFS den bereits auf dem PC gespeicherten Token und nutzt diesen - anstatt sich per Eingabe eines Passworts einen neue Token ausstellen zu lassen. Die Benutzer werden in diesem Fall also nie dazu aufgefordert, ein Passwort für die Anmeldung an Microsoft Online-Diensten einzugeben. Wir sprechen hier von "Single Sign-On" (SSO).

Der oben beschriebene ADFS-Aufbau funktioniert jedoch nur, wenn sich die Benutzer im internen Netz befinden. Sofern sie sich außerhalb befinden (WLAN Zuhause, öffentl. HotSpot, etc.), wird die Anmeldung nicht funktionieren, weil der ADFS-Server von außen nicht erreichbar ist. Man hat aber die Möglichkeit in eine öffentlich erreichbare Zone (DMZ) einen sogenannten "Web Application Proxy" (WAP, früher auch "ADFS Proxy" genannt) zu installieren. Besser sind natürlich auch hier wieder zwei Server, wegen der Ausfallsicherheit. Nach Freischaltungen in der Firewall (Port 443) und der Konfiguration mit den internen ADFS-Servern ist der Anmeldedienst dann auch extern erreichbar. Da außerhalb der Domäne keine Anmelde-Token ausgestellt werden können müssen Benutzer bei einer externen Anmeldung jedoch auf SSO verzichten und weiterhin klassisch das Passwort eingeben.

 

Besonderheit: Active Directory oder LDAP-Dienst vorhanden - Anmeldung soll lokal erfolgen, aber ohne ADFS

Dieses spezielle Szenario gibt es bereits seit einiger Zeit. Microsoft scheint erkannt zu haben, dass die "große" Installation von ADFS und WAP einige Kunden abschreckt - gleichzeitig die Synchronisation von Passwort-Hashes ins Azure AD aber keine Alternative darstellt. Die von Microsoft angebotene Lösung heißt "PassThrough Authentication" und ist kein richtiges "Single Sign-On", sondern vielmehr ein "Seamless Single Sign-On" (SSSO). Man kann sich hierbei die Installation von einem oder mehreren ADFS- und WAP-Servern sparen. Alles was man benötigt ist weiterhin ein Server für die Installation des Azure AD Connects sowie evtl. mehrere Server, die neben bestehenden Aufgaben den sog. "Authentification Agent" aufnehmen können. Einer dieser Agenten wird bereits auf dem Server installiert, auf dem auch der Azure AD Connect landet. Aus Gründen der Ausfallsicherheit sollte mind. ein weiterer Bestandsserver damit ausgestattet sein.

Das Besondere am PassThrough-Verfahren ist nun, dass hierbei keine Anforderung aus dem Azure AD auf einen lokalen IdP zurückverlagert wird. Stattdessen führt der "Authentification Agent" die Anmeldung proaktiv aus. Da ins Internet ausgehende Ports und Protokolle in der Firewall oftmals nicht gesperrt sind, werden hier auch häufig keine Freischaltungen notwendig sein. Wenn das Unternehmen also ein komfortables Anmeldeerlebnis für die Benutzer möchte, aber komplexe Infrastruktur scheut, dann ist man mit dem PassThrough-Verfahren gut aufgehoben.

 

Für eine weitergehende Architektur- und Implementierungs-Planung stehen die Experten der PRO DV AG gerne zur Verfügung! Kontakt und weitere Infos gibt es unter prodv.de.

 

 

Quellen und Links (Abruf alle 11.09.2018):


Print