In diesem Artikel wird die Authentifikation über AzureAD SAML Single Sign On beschrieben und wie man die Zugriffsberechtigungen hierzu auf Gruppen einschränkt. Zusätzlich wird die Möglichkeit zur Authentifizierung per Conditional Access auf IP-Ebene eingeschränkt.
Microsoft weist inzwischen darauf hin, dass man für neue Projekte die Microsoft Identity Platform verwenden soll. Das ist dan OpenID oder OAuth.
Wir benötigen einen AzureAD Admin mit entsprechenden Zugriffsrechten auf die folgenden Portale:
- portal.azure.com
- admin.microsoft.com
Das Portal admin.microsoft.com erreicht man auch über portal.office.com und dann links über das Symbol Admin.
Als erstes eine kleine Empfehlung: belasst das Portal portal.azur.com und admin.office.com auf Englisch. Die Übersetzung ist maximal schlecht. Meine Meinung.
SAML Dienst erstellen
Portal: aad.portal.azure.com
Unter Enterprise Applications eine neue Applikation erstellen.
In der rechten Seitenleiste einen sinnvollen Namen vergeben und Non-gallery Application erstellen:
Die neue Applikation findet man nun in der Liste aller Applikationen oder man sucht alternativ nach dem eben vergebenen Namen. Mit einem Klick auf den Namen gelangt man in das Konfigurationsmenu für unsere neue Applikation.
Hier wählen wir nun den Punkt Single Sign On->SAML
Etwas Theorie: SAML funktioniert über REST-Endpunkte. Der Dienst, für den man die SAML Authentifikation aufetzt, liefert normalerweise ein sogenanntes Metadata File in XML-Format. In der Datei sind die Endpunkte und das Zertifikat der gegenseite hinterlegt. Man kann diese Datei nun einfach in unsere AzureAD Applikation importieren. Dazu klicken wir oben auf „Upload metadata file“.
Wählt man die Datei aus erscheint rechts ein neuer Dialog, in dem man die Daten nochmal überprüfen kann. Im Normalfall kann man hier einfach oben auf „Save“ klicken.
Attribute und Claims
Der Dienst kann aus dem AzureAD bestimmte Attribute abfragen, bzw. diese werden beim einer Authentifizierung einfach mitgeliefert. Wenn also die Authentifizierung eines Benutzers über SAML erfolgreich ist, werden die hier definierten Attribute an den Dienst geliefert. Der Dienst sagt normalerweise über Hilfeseiten oder den Support an, welche Attribute benötigt werden. Das wichtigste Attribut ist hier der Unique User Identifier. Man verwendet normalerweise entweder den Userprincipalname (UPN) oder die E-Mail Adresse. Der UPN ist vorausgewählt. Wir ändern beispielhaft auf die E-Mail-Adresse.
Wir ändern den Wert user.principalname, indem wir auf das Feld klicken und aus der vorgegebenen Liste user.mail auswählen. Dann oben auf „Save“ klicken:
Metadata File
https://learn.microsoft.com/de-de/azure/active-directory/azuread-dev/azure-ad-federation-metadata
Die Gegenseite benötigt nun unser Metadata File. Die Datei kann man einfach unter Download Metadata File runterladen. Sie liegt im XML-Format vor.
Man kann dem Dienst auch noch das Base64-Zertifikat, die LoginURL, den AzureAD Identifier und die LogoutURL mitgeben. Damit könnte der Dienst seine Seite auch ohne Metadata File von uns konfigurieren (z.B. falls er die nicht importieren kann).
Zugriff auf bestimmte Benutzer beschränken
1. Benutzerquelle aus onPremise AD per AzureAD Connect
AzureAD Connect->Synchronisierungsoptionen anpassen->Kontodaten eingeben->Verzeichnis auswählen
Es werden nun die Active Directory OU’s angezeigt. Hier die OU’s auswählen, deren Benutzer/Gruppen mit dem AzureAD synchronisiert werden sollen.
ACHTUNG: AzureAD unterstützt keine verschachtelten Gruppen. Stand 2022.
2. Benutzerquelle direkt über AzureAD
Portal: admin.microsoft.com
3. Zugriff auf AzureAD Applikation einschränken
Die benötigten Daten sind nun durch die obige Konfiguration im AzureAD verfügbar. Wir wählen die AzureAD Applikation aus und wählen dort:
Users and Groups->Add user/group
Rechts geht die Liste der verfügbaren Benutzer und Gruppen auf. Hier einfach die entsprechende Auswahl treffen.
Conditional Access Location einrichten
Portal: azure.mocrosoft.com
Pfad: Azure Active Directory > Security > Conditional Access > Named Locations
https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/location-condition
Azure Active Directory > Security > AzureAD Conditional Access > Named locations
Auf „+IP ranges location“ klicken. Es geht rechts eine neue Eingabemaske auf.
Wenn wir ein vertrauenswürdiges Netz einrichten wollen, den Haken für „Mark as trusted location“ setzen. Dann einen Namen für das Netz vergeben, z.B. „Trusted Location Branch Office 1“. Unten auf das + klicken und die entsprechenden Netzbereiche eingeben. Wenn es nur eine IP ist, wird trotzdem eine Netzmaske verlangt. Wir geben dann IP/32 ein und speichern alles.
Damit haben wir die Conditional Access Location konfiguriert. Im nächsten Schritt verknüpfen wir die Location mit dem Dienst.
MFA Trusted IP’s
Portal: portal.azure.com
Pfad: Azure Active Directory > Security > Conditional Access > Named Locations
Eine Conditional Access Policy setzt normalerweise mindestens einen weiteren Sicherheitsfaktor voraus, meist Multi Factor Authentication. Um das zu umgehend Setzen die IP’s auch als MFA Trusted IP’s.
Conditional Access Policy für SAML Dienst einrichten
Portal: portal.azure.com
Wir wählen in der linken Spalte „Enterprise Applications“. Es werden alle Applikationen aufgelistet, die wir im Tenant konfiguriert haben. Wir wählen nun die App aus, für die wir den Conditional Access einrichten wollen. Dann wählen wir im Bereich Security „Conditional Access“ und klicken auf „+New policy“.
Folgende Informationen werden für eine Contitional Access Policy benötigt:
- Ein Name für die Policy
- Welchen Benutzern die Policy zugewiesen wird
- Die Anwendung, der die Policy zugewiesen wird
- Die Konditionen (Conditions, z.B. IP’s)
- Access Control über Grant oder Session Block
Folgendes sollte man außerdem beachten:
- Nie alle Benutzer in eine Policy einschließen. Es sollte sogenannte Break Glass Benutzer geben, die Zugreifen können, falls man sich über eine Fehlkonfiguration ausgeschlossen hat.
- Die Richtlinie nie direkt aktivieren, sondern erst über Report-only prüfen was passiert.
Wir bauen uns nun eine Deny-Regel. Wir blockieren also alle Locations, bis auf die oben spezifizierten Locations. Diese Regel wenden wir auf alle Benutzer an, bis auf die Break Glass Benutzer und evtl. spezielle Admins.
Users or workload identities
Include: All users
Exclude: Break Glass und Admins
Cloud apps or actions
Die SAML App auswählen
Conditions
Locations -> Include: Any location
Locations -> Exclude: Selected Locations (hier die Locations auswählen, die wir erlauben wollen)
Access Control
Block access