Conditional Access für Anfänger
Da das Thema immer wichtiger (nicht nur) für mich wird schreibe ich heute ein wenig zu Conditional Access.
Was ist Conditional Access?
Ein Feature von Entra ID (Azure AD) mit dem der Zugriff auf Ressourcen kontrolliert werden kann.
Was brauche ich dafür?
-
Die Applikation muss per Modern Authentication an Entra ID (Azure AD) angebunden sein.
-
Die User müssen sich am Entra ID (Azure AD) authentisieren können.
-
Es werden AAD Premium Lizenzen benötigt
Was meint Modern Authentication nochmal?
Das meint, dass meine Applikation mit einer Claims basierten Authentisierung arbeiten kann. Das ist der Fall wenn eines oder mehrere dieser Protokolle unterstützt werden: SAML, OAuth, WS-Federation.
Ähnlich wie bei Kerberos erfolgt die Authentifizierung gegen einen Identity Provider und es werden Tickets ausgestellt anhand dessen die Applikation autorisieren kann.
Anhand welcher Kriterien kann ich einschränken?
anhand von:
-
User / Groups
-
erfolgter MFA Authentication
-
Device Status (siehe Intune)
-
Location (IP-Adressen)
-
Client App
-
Devicetyp
-
…
Diese Liste wächst momentan noch, um z.B. Custom Controls für die Anbindung von Drittanbietern.
Wie sehen Conditional Access Policies aus?
Eine CA Policy besteht immer aus 2 Teilen. Im ersten Teil wird definiert wann die Policy gilt und im zweiten Teil wird definiert was dann getan wird:
Im ersten Teil der Policy (Assignment/Conditions) wird definiert,
- für wen (who?) bei welchen Zugriffen (what?) und welchen Umständen (how?) die Policy wirkt.
Im zweiten Teil (Access Control) wird definiert, ob die Policy
-
einen Zugriff erlaubt (grant) oder sperrt (block)
-
ein grant muss immer noch durch ein oder mehrere Controls eingeschränkt werden
-
Bei den Controls kann entschieden werden, ob alle (AND) oder mind. eine (OR) zutreffen muss.
-
(zukünftig werden werden hier auch Einschränkungen innerhalb der Session konfigurierbar sein)
Wie wird mit diesen Policies ein Regelsatz gebaut?
Grundsätzlich gilt:
-
Greift keine Regel ist der Zugriff erlaubt
-
Ein block schlägt immer ein Grant
-
Für einen Zugriff müssen alle angewendeten Grant-Regeln erfüllt sein (AND)
-
Ein Grant muss immer durch weitere Controls eingeschränkt werden
Diese Voraussetzungen machen es etwas schwierig Regelsätze zu bauen, da es z.B. kein Best-Match oder First-Match gibt. Um etwas komplexere Regelsätze abbilden zu können muss oftmals an mehreren Regeln gepflegt werden, um sicherzustellen, dass die Regeln sich gegenseitig ausschließen.
Beispiel 1:
Um sicherzustellen, dass ein Zugriff auf einen Service nur von Clients im Status Compliant oder einer Terminalserver-Farm erfolgen kann braucht es zwei Policies die sich gegenseitig ausschließen, da niemals beide Bedingungen erfüllt sein können!
-
In der einen (Grant-)Regel werden die IP-Adressen der Terminalserver werden explizit ausgeschlossen und es wird der Status Compliant als Control ausgewählt
-
In der anderen (Grant-)Regel werden die die IP-Adressen der Terminalserver zur Bedingung gemacht und es wird MFA als Control ausgewählt
-
Damit der Zugriff von den Terminalservern ohne MFA funktioniert nehmen werden die IP-Adressen der Terminalserver zusätzlich noch in die “MFA Trusted IPs” aufgenommen.
Beispiel 2:
Um das Default-Verhalten “Grant All” zu ändern und den Zugriff nur für eine bestimmte Gruppe (hier: GROUP-A ) zuzulassen braucht es ebenfalls zwei Policies die sich gegenseitig ausschließen.
-
In der einen (Deny-)Regel werden die User aus GROUP-A explizit ausgeschlossen: “Include All users” und “Exclude GROUP-A”
-
In der anderen (Grant-)Regel wird die Mitgliedschaft in GROUP-A zur Bedingung gemacht
Beispiel 3:
Wir wollen nun beides miteinander verbinden: Der Zugriff auf den Service soll nur von einer bestimmten Gruppe (hier: GROUP-A) von Clients im Status Compliant oder einer Terminalserver-Farm erfolgen. Es braucht dafür folgende Regeln:
-
In einer (block-)Regel werden die User aus GROUP-A explizit ausgeschlossen: “Include All users” und “Exclude GROUP-A”
-
In einer (Grant-)Regel wird die Mitgliedschaft in GROUP-A zur Bedingung gemacht, der Status Compliant wird zur Bedingung gemacht und die IP-Adressen der Terminalserver werden explizit ausgeschlossen.
-
In einer weiteren (Grant-)Regel wird wird die Mitgliedschaft in GROUP-A zur Bedingung gemacht, die IP-Adressen der Terminalserver werden zur Bedingung gemacht und es wird MFA als Control ausgewählt
-
Damit der Zugriff von den Terminalservern ohne MFA funktioniert nehmen werden die IP-Adressen der Terminalserver zusätzlich noch in die “MFA Trusted IPs” aufgenommen.
Generell ist es sinnvoll einen Testtenant zu haben und die WhatIf-Funktion zu verwenden. Wenn MS die Powershell Unterstützung einbaut wäre es auch möglich die Policies von der Testumgebung in die Produktion zu portieren.
Welche Gruppen kann ich für Conditional Access verwenden?
Bisher konnte ich keine Einschränkungen feststellen. Es können alle Sorten von Sicherheitsgruppen (synced oder cloud-only) verwendet werden und auch eine Verschachtelung ist möglich.
Aber kann ich das nicht schon alles mit dem ADFS machen?
Prinzipiell ja aber vor allem im Bezug auf O365 nein. Am ADFS wird für alle Azure / O365 Services nur ein (1) Relaying Party Trust angelegt also ist die Eingrenzung des Ziels nicht granular möglich. Man kann hier nur versuchen anhand der Umstände des Zugriffs (z.B. via ActiveSync) einzugrenzen.
Kann ich von Conditional Access auch OnPrem profitieren?
Ja - aber meine Applikation muss Modern Auth beherrschen und als Relaying Party am Entra ID (Azure AD) hängen.
Bei Exchange und Skype kann ich diesen Zustand über einen Hybridaufbau erreichen. (Hybrid Modern Authentication)
Für Applikationen, die nicht Modern Authentication beherrschen kann der Entra ID (Azure AD) Application Proxy oder ein Netscaler helfen.
Ist es möglich Regelsätze am ADFS und Conditional Access miteinander zu kombinieren?
Ja, wenn ich Federated Identities habe. Dann kann ich an eine Authentisierung am ADFS Bedingungen knüpfen und erst danach greift Conditional Access.
Was haben Device Compliance und Conditional Access miteinander zu tun?
In den Policies kann als Control konfiguriert werden, dass das Device als Compliant markiert wurde. Ob ein Gerät Compliant ist entscheided Intune anhand einer dort zu konfigurierenden Policy.
Der Status eines Clients kann übrigens auch über Device-Writeback für Regelsätze des ADFS genutzt werden.
Wie kann ich Conditional Access sinnvoll debuggen?
Leider konnte ich bisher keine Möglichkeit für ein Tracing am Entra ID (Azure AD) finden. Somit bleiben neben der WhatIf-Funktion nur ein guter Testaufbau (Testtenant, Testclients, Testregeln) und Tools wie Fiddler.
Gibt es Powershell Unterstützung für Conditional Access?
Aktuell gibt es noch nichts aber auf der BUILD 2018 wurde angekündigt die GRAPH API unter anderem für Conditional Access zu erweitern. Besonders hilfreich wäre hier meiner Meinung nach eine Möglichkeit Regelsätze vom Testtenant zur Produktionsumgebung migrieren zu können.