Azure Conditional Access

Auf der Seite Conditional Access habe ich einige Beschreibungen zur generellen Funktion eines "Bedingten Zugriffs" beschrieben. Auf dieser Seite beschreibe ich einige Aspekte aus einer realen Umsetzung.

MFA und Conditional Access

Sehr oft werden die Begriffe MFA, Conditional Access als auch "zertifikatbasierte Authentifizierung" miteinander vermischt. Hier ist erst einmal Klarheit erforderlich

  • MFA
    MFA steht für "Multi Faktor Authentifizierung" und hat den Hintergrund, dass allein das Wissen eines Benutzernamens und Kennworts für einige Anwendungsfälle zu schwach ist. Hier geht es darum einen dritten Faktor, z.B. Gerätezertifikat, Einmaltoken, Smartcard o.ä. mit ins Bild zu rücken. Natürlich hat MFA auch etwas mit Conditional Access zu tun, denn die Verwendung eines weiteren Faktors kann ein Kriterium sein, damit ein Zugriff überhaupt erlaubt wird
  • Zertifikatbasierte Anmeldung
    Dies ist eine Möglichkeit eine MFA bereit zu stellen, aber bei weitem nicht das einzige Kriterium. Auch andere Identitätsmerkmale, z.B. IP-Adressen etc. sind legitime Kriterien für eine Entscheidung über die Anmeldung
  • Conditional Access
    Damit ist letztlich das Regelwerk beschrieben, welches anhand verschiedener vorgaben (Client, Service, Anmeldeverfahren, Standort, Compliance-Status etc. entscheidet, ob der Zugriff des Anwenders erlaubt ist.

Conditional Access ist die Klammer um all diese Steuerungsmöglichkeiten. Sie können dabei das "große Conditional Access" von Office 365 nutzen, um solche Regeln aufzubauen. Sie können aber auch ohne Office 365 eine "Conditional Access"-Lösung umsetzen, z.B. indem Sie auf einem Reverse Proxy ihrer Firewall-Lösung eine weitere Authentifizierung aktivieren oder ADFS selbst nutzen, um dort MFA zu aktivieren und über Claim-Rules dann weitere Regeln erstellen.

MFA und Device Authentication wird gerne zusammen gefasst, indem sich ein Benutzer nur auf einem zugelassenen gerät anmelden kann. Das Gerät ist quasi der zweite Faktor. Bei MFA geht es aber primär darum, dass die Anmeldung des Benutzers mit einem weiteren Kriterium gesichert wird, damit ein ausgespähtes Kennwort nicht alleine genutzt werden kann, egal ob dies nu auf einem fremden oder prinzipiell zugelassenen Gerät passiert.

Leistungsfähiger ist hinsichtlich Office 365 natürlich das Conditional Access-Modul von AzureAD, welches für Cloud-Dienste aber mit einem passenden Application Proxy in Azure auch für lokale Dienste genutzt werden kann.

Lizenz

Vor der Konfiguration steht aber erst einmal die Lizenz. Conditional Access in Office 365 ist nicht Bestandteil von Azure AD Basic oder Free, sondern erfordert eine AzureAD Premium Lizenz, die Sie additiv alleine oder z-B. auch über die EMS-Suite lizenzieren können. Ob Sie eine Lizenz für ihren Tenant haben, sehen Sie direkt im Azure Portal, wenn Sie Conditional Access konfigurieren wollen:

Für einen Testzeitraum können Sie natürlich eine Trial-Version aktivieren. Prüfen Sie aber dennoch vorab, welche Funktion in AzureAD Premium P1/P2 enthalten sind und welchen Mehrwert dies für ihr Unternehmen bedeutet.

Test-Konfiguration

Ehe Sie mit Conditional Access planen, sollten Sie sich mit der Bedienung einmal vertraut machen.

Forderung nach einem Test-Tenant
Ich rufe alle Administratoren und Firmen mit Office 365-Bezug auf, neben dem produktiven Tenant immer auch mindestens einen zweiten Tenant zum Testen zu betreiben. Ich kenne Firmen, die betreiben sogar analog zu einem SAP System sogar drei Tenants: Test, QM, PROD.
Der Betrieb eines zweiten Tenant ist nicht sonderlich teuer. Oft reichen wenigen E1-Lizenzen, da Sie in dem Tenant meist kein Office lizenzieren. Aber sie können hier Einstellungen und deren Auswirklungen besser testen und erarbeiten. Zudem können Sie diesen Tenant für "frühe Funktionen" freischalten und damit schon vorab Änderungen ausprobieren und dann im produktiven Tenant passen einstellen.

Ich habe in meinem Test-Tenant dazu einfach eine Regel addiert, die folgende Einstellungen hat:

Assignment: Users and Groups: Include selected: User@uclabor.de
CloudApps: Include selected: Office 365 SharePoint
Conditions: Location: Any Location + Exclude "FirmenIP"
AccessControl: Grant: Block access
Enable Policy: ON

Wenn ich nun in der Firma auf SharePoint zugreife, dann kommt ich auch hin aber von unterwegs werde ich geblockt.

Sie können gerne noch mit anderen Regeln experimentieren und weitere Erfahrungen sammeln.

Default Policy "allow" oder doch nicht?

Ich wollte in meinem Testfeld den Zugriff auf SharePoint auf Geräte beschränken, die zumindest in meinem lokalen AD vorhanden sind. Damit sperre ich "beliebige" Windows 10 Clients aus, die z.B. keine Gruppenrichtlinie haben. Azure kann natürlich bei der Konfiguration nicht wissen, ob die Geräte letztlich compliant sind.

Die Ausgangssituation ist so, dass ich Zugriff auf SharePoint habe, Ich habe dann folgende Regel angelegt:

Im Bild ist nicht sichtbar, das der Scope auf mich als Benutzer und SharePoint als App definiert sind. Aber ich habe bei "Access controls: Grant" die Einschränkung gesetzt, dass der Client "Require Hybrid Azure AD joined device" ist. Allein diese Regel blockt aber schon meinen Browser aus

Ich muss also gar nicht noch eine "Deny"-Regel am Ende setzen, wenn ich bei der Conditional Access Rule den "Grant" nutze. Allerdings blockiert die Regel nicht jeden Zugriff aller Benutzer. Die Filterung durch "Assignments" greift schon vorher.

All assignments are logically ANDed. If you have more than one assignment configured, all assignments must be satisfied to trigger a policy.
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-best-practices

For every sign-in, Azure Active Directory evaluates all policies and ensures that all requirements are met before granted access to the User.
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-best-practices

Es gibt also keine Reihenfolge aber es müssen alle Bedingungen erfüllt sein, damit der Zugriff gewährt wird. Eine Blockade überstimmt und sie sollten damit sehr vorsichtig sein, damit sie sich nicht selbst (insbesondere den Administrator) aussperren. In dem Fall hilft nur noch ein Support Ticket.

Device compliance

Bei der Ablehnung sehen Sie nun aber auch, das der "Gerätestatus: unregistered" ist. Das ist aber ein sehr starkes Kriterium, das man z.B. von extern nur "Compliant Devices" zulässt. So können Firmengeräte aber auch ausgewählte private Geräte im Rahmen einer BYOD-Strategie zulassen. Ich habe also die Regel angepasst und anstatt der Location nun den Device State eingebaut.

Ich kann hier also einmal einfach ein "Azure Ad Joined" aber auch ein "compliant" auswählen. Damit die funktioniert, muss das Gerät natürlich als solches in AzureAD bekannt sein.

Devices in Azure AD

Damit stellt sich aber die Frage, wie AzureAD die Geräte verwaltet. Ein Blick in die Devices von AzureAD listet schon einige Daten:

Bei Join-Type sehen sie hier drei unterschiedliche Werte: 

Damit stellt sich natürlich die Frage, ob und wie Anwender ein Gerät in da AzureAD "joinen" können. Auch das ist per AzureAD konfigurierbar. Der Default steht hier aus "ALL", d.h. jeder Mitarbeiter kann Geräte in das AzureAD per Join hinzufügen.

Das ist fast wie bei lokalen AD-Domänen.

Device Authentication und Registration mit ADFS

Wenn Sie einen lokalen ADFS-Server für Office 365 betreiben, dann erfolgt die erste Authentifizierung hinsichtlich des Anwenders natürlich gegen diesen Server. Domain-Computer haben zudem ein Computerkonto im lokalen Active Directory. In dem Fall kann der der lokale ADFS-Service für die Authentication der Geräte aktiviert werden,

Das ist nur eine kleine Checkbox und schnell gesetzt.
 Aber machen Sie das erst am Ende des kompletten Einrichtungsprozesses!

Die Einstellung ist auch per PowerShell möglich

Set-AdfsGlobalAuthenticationPolicy `
   -DeviceAuthenticationEnabled $true

Die Auswirkungen sind aber immens und sie erfordern entsprechende Vorarbeiten. Mit der Aktivierung erzwingt der ADFS die Authentifizierung und die Geräte, die noch nicht "registered" sind müssen einen Weg finden, um sich zu registrieren. Genau diese Funktion übernimmt ebenfalls der ADFS-Server. Auf die Einrichtung gehe hier hier aber nicht weiter ein und verweise auf  andere Quelle:

AADConnect und Device Writeback

Sie können natürlich auch den Service in Azure nutzen und AzureADConnect erlauben, die Informationen in das lokale Active Directory zurück zu schreiben. Allerdings kostet das einen kleinen Aufpreis

A subscription to Azure AD Premium is required for device writeback
Quelle: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-feature-device-writeback

Prüfen Sie aber, was in AzureAD Premium noch enthalten ist. Es gibt durchaus Gründe für diese Erweiterung, z.B. MFA, RMS, und gruppenbasierte Lizenzvergabe. Und natürlich benötigt "jemand" auch die Rechte die Geräte im lokalen AD anzulegen

Die erforderlichen Einstellungen hat Microsoft recht ausführlich dokumentiert

Chrome und Conditional Access

Dass die normalen Windows Apps wie Outlook, Explorer, Edge und Office mittels "Modern Auth" auch mit MFA und Conditional Access klarkommen, wäre zu erwarten. Was passiert aber, wenn ich z.B. per Chrome auf mein Postfach zugreifen will?. Hier der Fehler:

So komme ich erst einmal nicht hinein. Ich muss auf Chrome ein Add-on installieren. Das ist auf Computern einfach, die zur Firme gehören und zentral verwaltet werden.

Weitere Links