Conditional Access

Unter Conditional Access versteht man die Kontrolle, welche Clients auf Daten des Unternehmens wie zugreifen können. Speziell das Arbeiten auf fremden oder unsicheren Clients kann so über weitere Faktoren bei der Anmeldung abgesichert werden. Solange ihr Daten im LAN liegen, können Sie über ihre Firewall den Zugriff von extern steuern. Mit VPNs können sie interne Dienste für "bekannte" Clients erreichbar machen. Webseiten lassen sich per Reverse Proxy und Portalen auch per Multi Faktor Authentifizierung absichern. Aber nun landen alle Daten in der Cloud und da bestimmen Sie nicht mehr über die Firewall oder den Reverse Proxy davor. Diese Seite beschäftigt sich mit den Möglichkeiten hier weiterhin zu filtern.

Beachte dazu auch Device Registration Android und Azure Conditional Access

Die MFA-Funktion ist Microsoft sogar so wichtig, dass seit Anfang 2024 in jedem Tenant mit AzureAD P1-Lizenz sogar zwei Default Policies anlegt, die erst 90 Tage im "Report Mode" laufen und dann aktiviert werden. Damit wird die Lücke geschlossen, damit Firmen mit Azure AD P1 aber mangels Zeit für eine Konfiguration letztlich unsicherer sind als Firmen ohne Lizenz und aktivierten Security Defaults.

Warum Schutz erforderlich ist!

Lange Zeit war der Benutzername und das Kennwort ausreichend um den Zugriff auf Informationen zu steuern. Berechtigungen wurden über Gruppen vergeben und erreichbar waren die Systeme sowieso erst mal nur intern, Mitglied einer Domäne und per Gruppenrichtlinien und Anmeldeskripte unter ihrer Kontrolle. Nun ändern sich aber sie Regeln. Hier ein paar Beispiele:

  • Smartphones
    Selbst durch die Firma gestellte Smartphones sind von Hause aus erst einmal "unmanaged", d.h. der Anwender könnte z.B. neben der ActiveSync-Partnerschaft zur Firma auch andere Mailkonten einrichten.
  • Bring your Own Device oder Browser
    Die Steigerung besteht darin, dass Anwender auf beliebigen Geräten Zugriff auf Daten begehren. Vielleicht nicht auf alle Daten aber mal schnell in einem Browser die Mails checken gehört schon zum guten Ton, wenn ein Arbeitgeber nicht altmodisch wirken will.
  • Skype for Business Telefone und Mobile Clients
    Dann gibt es natürlich Apps, die sich nicht über ActiveSync verbinden, sondern z.B. EWS direkt zum Abruf der nächsten Besprechungen ansprechen.

Und das ist nur ein kleiner Anfang. Die Liste kann fast endlos verlängert werden und ich habe sehr viele unterschiedliche Anforderungen und Wünsche gesehen.

Ehe Sie nun vorschnell "Ich fordere Multi Faktor Auth" schreien, sollten wir zuerst einmal die verschiedenen Szenarien aufstellen, die zu berücksichtigen sind. Das sind leider nur nur ein paar wenige Kombinationen sondern die Liste kann durchaus mehrdimensional werden.

Kriterium: Standort

Ein Kriterium bei der Entscheidung zur Clientabsicherung ist natürlich der Standort. Ich unterscheide da in der Regel vier Lokationen, die durch einen Authentifizierungsdienst und Firewalls unterschiedlich gehandhabt werden können:

  • Firmennetzwerk
    In der Regel haben diese Client dann auch private IP-Adressen und können die Server intern direkt erreichen. Sogar "SingleSignOn" ist ziemlich einfach möglich, da NTLM und Kerberos zur Wahl stehen. Selbst wenn die Daten in der Cloud liegen, kann ein lokaler Authentifizierungsservice, z.B. ADFS, intern oft direkt angesprochen werden. Wenn Sie dann noch ihr Netzwerk dank 802.1x im Griff haben, sollte kein "unbekannter Client" diesen Status "Firmennetzwerk" haben.
  • Bekannter Remotestandort
    Wenn die eigentlichen Server aber im Internet stehen oder es keine WAN-Verbindung zu den Servern gibt, dann sehen die Datenserver und vielleicht auch der Authentifizierungsserver eine öffentliche IP-Adresse des NAT-Routers oder des Proxy-Server. Wenn diese Quelle nur von vertrauenswürdigen internen Systemen genutzt werden kann, könnten Sie über IP-Allowlists die Authentifizierung dieser Clients vereinfachen. Die Source-IP ist quasi ein Faktor, wenngleich er für staatliche Angreifer natürlich nicht 100% sicher ist. Einmal schnell das Subnetz per BGP umgeroutet und einen Angriff fahren ist denkbar.
  • VPN
    Bestimmte Clients sind zwar im Internet aber haben eine VPN-Verbindung. Die durch den VPN-Tunnel angesprochenen Server sehen dann wieder eine interne Adresse. Wenn Sie über das VPN daher sicherstellen, dass die Clients für ihre Belange "Compliant" sind, dann ist auch dies ein mögliches Kriterium.
  • Internet/Dynamische IP
    Die letzte Art der Clients stellen unbekannte PCs, Smartphones etc. im Internet dar, über die eigentlich gar nichts bekannt sind. Zugriffe von hier wird man restriktiver behandeln, auch um DoS-Attacken und Brute Force Angriffe zu verhindern.

Kriterium: Protokoll und Client

Eine zweite Komponenten bei der Entscheidung zu "Conditional Access" ist das Zugriffsprotokoll und der verwendete Client. Nicht alle Clients unterstützen zusätzliche Abfragen für Conditional Access. Auch einige Server können dies nicht immer anfordern. Manchmal ist ein Reverse Proxy oder Loadbalancer mit Preauthenitcation dazwischen, der einen "alten Service" mit neuen Techniken schützen kann. Das hängt natürlich alles vom Protokoll ab. Hier ein paar Beispiele:

  • Browser und http
    Diese Kombination ist meist am einfachsten umzusetzen, das ein Browser der klassische "interaktive" Client ist und der Server das Verhalten in weiten Bereichen steuern kann. Es kann insbesondere Formularfelder für weitere Anmeldedaten, z.B. Einmaltoken etc. einblenden.
  • Outlook (MAPI/http) + EWS
    Bei Outlook wird es schon etwas kniffliger, da z.B. bei einem Einmaltoken ein Dialogfenster angezeigt werden muss, das kann Outlook 2010 noch nicht und 2013 nach entsprechender Konfiguration. Erst Outlook 2016 sind "Modern Auth" tauglich. Der Client sollte sich dann aber nicht nur anmelden sondern auch ein Token für eine spätere Reauthentifizierung holen. Wenn Anwender allzu oft wieder nach einer Anmeldung gefragt werden, leidet die Akzeptanz. Allerdings muss auch das Backend diese Verfahren unterstützen. Darauf gehe ich später noch ein.
  • Skype for Business Windows/Mobile (EWS)
    Dieser Client nutzt SIP und nach einer initialen Anmeldung sendet der Server ein Client Zertifikat für die spätere Nutzung. MFA ist hier möglich aber im Hintergrund spricht der Client auch mit Exchange per EWS um die Termine zu erhalten. Knifflig wird es hier, wenn Skype for Business Online auf Exchange On-Premises trifft,
  • ActiveSync (Native oder Outlook for IOS/Android
    Schon seit Exchange 2010 können Sie mit der ActiveSync Quarantäne die erlaubten Geräte filtern und dank ActiveSync Richtlinien schon seit Exchange 2003 gewisse Einstellungen auf dem Client steuern. Oft reicht das aus, um die meisten Anforderungen zu einem zweiten Faktor (das Telefon) zu erfüllen. Ansonsten gibt es entsprechende 3rd Party Add-ons. ActiveSync wird auf von den Outlook-Apps für IOS und Android und der Windows 10 Mail und Kalender App genutzt.

Sicher kennen Sie noch weitere Clients, die von extern auf Dienste in der Cloud und On-Premises zugreifen wollen und allein ein gültiger Benutzername und Kennwort als nicht sicher genug angesehen wird. Ich denke da auch an Add-ons für Outlook wie z.B. Salesforce, CRM etc.

Kriterium: Der zweite Faktor

Wenn Benutzername und Kennwort nicht sicher genug sind oder sie den Zugriff auf Informationen auf bestimmte "Endgeräte" beschränken wollen, dann kommt immer der "zusätzliche Faktor" zum Tragen. Ein paar Faktoren habe ich schon genannt aber wichtig ist natürlich zu verstehen, wie der Server diese Information auswerten kann.

  • Verbindung, Subnetze, Client-IP/VPN
    Der einfachste Faktor ist der Netzwerkstandort und der Weg zum Service. Bei lokalen Diensten können Sie über Firewalls im LAN oder auf dem Host den Zugriff der Clients einfach anhand der IP-Adresse filtern. Das geht natürlich "in der Cloud" ebenso wenig wie bei Clients im Internet, die auf ihre lokalen Dienste zugreifen. Dennoch sind IP-Adressen ein wichtiger und nützlicher Indikator zur Steuerung der Authentifizierung. Gerade wenn Sie z.B.: mit ADFS arbeiten und Mitarbeiter in Niederlassungen mit der gleichen IP-Adresse von extern auf ihre Daten zugreifen, können Sie so diese an sich vertrauenswürdigen Netzwerke aus der Multi Faktor Authentifizierung ausnehmen und den Anwender das Leben vereinfachen.
  • Geräte-ID und ActiveSync Quarantäne
    Gerade für mobile Geräte und die Nutzung mit ActiveSync ist das "Endgerät" natürlich ein gutes Hardware-Token. Exchange kann in gewissen Grenzen entsprechende Richtlinien mit verteilen (Kennwort, Sperren etc.) und sei Exchange 2010 kann ein Administrator eine White/Blocklist von Geräteklassen und individuellen Partnerschaften pflegen. Dies funktioniert sogar für andere ActiveSync-kompatible Apps wie "Outlook for IOS" oder "Outlook for Android" und die Windows Mail und Kalender-App
  • UserAgent oder Zertifikat
    Ein wichtiger Faktor ist natürlich die möglichst eindeutige Identifizierung des Endgeräts. Bestimmte Daten dürfen nur auf ausgewählten Geräten vorgehalten werden, die den Firmenvorgaben entsprechen (Bildschirmschoner, Kennwortschutz, Bitlocker Verschlüsselung etc.) Dazu muss das Geräte natürlich erkannt werden. Ein Weg ist die Kombination aus Computerzertifikat, welches zentral nur für Domänenmitglieder bereitgestellt wird, die per Gruppenrichtlinien auch die entsprechenden Vorgaben erfüllen müssen.
    Ein anderer Weg ist eine Management Komponente wie Intune, NPS/NAP, die generisch den "Compliance"-Status prüft und dann ein Zertifikat verteilt oder z.B. den User-Agenten für http-Anfragen erweitert. So arbeiten gerne diverse MDM-Systeme, damit ein Reverse Proxy die verwalteten Geräte von nicht verwalteten Geräten unterscheiden kann. Ein UserAgent ist zwar nicht 100% sicher, da er natürlich gefälscht werden könnte.
  • Gruppenmitgliedschaft
    Ein eher schwacher Faktor aber durchaus als Filter brauchbar sind Mitgliedschaften in Gruppen. Per Radius, ACLs, ADFS-Claim-Rules kann anhand dieser Eigenschaft gesteuert werden, welche erweiterten Anmeldesicherungen angewendet werden und wer dann auf welche Daten zugreifen kann.
  • Sonderfall: App-Kennwort
    Es gibt Dienste, oder Clients, die unterstützen ;MFA nicht richtig. Meist sind es WebServices, ActiveSync, REST-APIs etc., die dem Anwender keine GUI anzeigen können. Hier kann der Anwender ein eigenes "Appkennwort" anfordern und eingeben. Idealerweise nutzt der Anwender für jeden Dienst dann ein eigenes Kennwort, welches er auch getrennt wieder deaktivieren kann. So ein App-Kennwort kann aber nicht mit Diensten genutzt werden, die MFA unterstützen. So bleibt das eigentliche primäre Kennwort besser geschützt. Der zweite Faktor ist der Anwender, der hoffentlich sorgfältig und korrekt die Möglichkeiten der App-Kennworte nutzt.

Was mit Azure möglich ist, hat Microsoft auf der TechEd 2014 schon sehr früh vorgestellt. Mittlerweile sind viele Dinge natürlich schon dazu gekommen.


Quelle: Multi-Factor Authentication Deep Dive: Securing Access On-Premises and in the Cloud  https://www.youtube.com/watch?v=zohHQL36k8c

Kriterium: Endgerät

Auf den Ersten Blick fallen ihnen natürlich "Windows"-Computer und Smartphones bzw. Tablets ein. So einfach ist es aber nicht. Es gibt schon noch mehr Geräteklassifizierungen:

  • Firmencomputer in der Domäne
    Der klassische per Gruppenrichtlinien verwaltete PC. Meist steht er intern oder hat eine Verbindung per VPN
  • Firmen-Smartsphone
    Das mobile Pendant und als Firmeneigentum zumindest organisatorisch bestimmten Regelungen unterworfen. Wohl dem, der die Geräte auch per Mobile Device Management im Griff hat
  • "Partner"-Computer und "Partner"-Smartphone
    Diese Systeme sind gar nicht mal so selten ein einer "Connected World". Dazu zähle ich auch meinen Notebook, der z.B. auf Daten von Kunden in deren Netzwerk oder Office 365 Tenant zugreift. SharePoint mit Gastzugriff, OneDrive-Sharing oder auch Teams und Yammer sind durchaus relevante Datenspeicher, auf die der Zugriff geregelt sein muss.
  • Fremdsysteme
    Darunter fallen dann die ganzen "unmanaged" Privat-PCs mit fraglicher Anmeldesicherheit. Da wollen die meisten Firmen zumindest keine Daten exportierbar bereitstellen. Meist wird der Zugang auf einen Browser mit WebMail, WordApp etc. beschränkt oder die Applikation per Terminal Dienste als eigene Arbeitsumgebung bereit gestellt.

Conditional Access oder Claims-Based Rules

Die Steuerung des Zugriffs auf Applikationen und Dienste kann über zwei Wege erfolgen:

  • Claims Based (ADFS)
    Der Zugriff auf Daten in Office 365 ist nur für authentifizierte Benutzer möglich. Wenn die Firma ADFS einsetzt, dann wird der Client zum ADFS-Service weiter verwiesen, der dann z.B. einen zweiten Faktor erfordern kann, ehe er ein Authentifizierungsticket ausstellt. Gefiltert kann z.B. nach IP-Adressen, Aplikationsname etc. und per MFA sind Zertifikate oder 3rd Party MFA-Provider möglich, Die Einschränkungen dieser Lösung sind die Pflicht für ADFS, was in kleinen Firmen ein Nachteil sein kann. Zudem ist das Setup relativ komplex. Zugriff per "Guest Access" mit anderen Tenants unterliegen vielleicht anderen Sicherheitsvorgaben, so dass die Absicherung nicht zwingend durchgängig ist.
  • AzureAD Conditional Access
    Wenn ein Tenant nicht auf ADFS setzt, sondern z.B. Cloud Kennworte, Office 365 Password Sync oder Pass-Through Authentifizierung (PTA) nutzt, dann sind die Regeln bei ADFS nicht nutzbar. Daher hat Microsoft auch eine Filterfunktion auf der jeweiligen Applikation vorgesehen. Diese Funktion ist auch mit ADFS kombinierbar. Dieser Schutz ist neuer und kann für jeden Dienst konfiguriert werden. Das ist durchaus ein Vorteil. Allerdings benötigt jeder Anwender zusätzlich eine AzureAD Premium (P1 oder P2) als Lizenz und die Clients müssen "ModernAuthentification" unterstützen. Outlook 2010 und ActiveSync und älter sind außen vor. Bei Outlook ist da weniger ein Problem. Bei ActiveSync empfiehlt Microsoft den Wechsel auf "Outlook for IOS" oder "Outlook for Android", bis die Hersteller ihre nativen Clients entsprechend aktualisiert haben.

Microsoft pflegt selbst noch Seite mit den Pro und Cons:


Quelle: http://www.enowsoftware.com/solutions-engine/explaining-conditional-access-and-azure-pass-through-authentication

Wenn immer die Wahl zwischen zwei oder mehr Lösungen besteht, ist eine Entscheidung zu fällen. Aus heutiger Sicht (Mai 2018) ist die Funktion Conditional Access vorzuziehen, auch wenn die Lizenzkosten für AzureAD Premium P1 (ca. 5€/User/Monat) dazugerechnet werden müssen.

Of November 2016, there are two types of Azure AD Premium licenses – P1 and P2. Both work for conditional access. If your Users are licensed for Enterprise Mobility + Security (EM+S) E3 or E5, they already have licenses for Azure AD Premium.
Quelle: https://www.microsoft.com/en-cy/cloud-platform/enterprise-mobility-security-pricing

... MFA with Office 365 and/or Azure AD the MFA rules were generally enabled on the ADFS relying party trust itself.  The main limitation ... is the inability to define different MFA behaviours for the various services behind that relying party trust.  That is, within Office 365 (Exchange Online, Sharepoint Online, Skype for Business Online etc.) or through different Azure AD Apps that may have been added via the app gallery (e.g. ServiceNow, SalesForce etc.)
Quelle: https://blog.kloud.com.au/2017/07/01/using-adfs-On-Premises-mfa-with-azure-ad-conditional-access/ 

 Der Weg über ADFS ist eh nur für Umgebungen gangbar, die ADFS einsetzen werden und die Pflege der Claim Rules alles andere als trivial. Allerdings gibt es einen Generator

Azure AD RPT Claim Rules Generator
https://adfshelp.microsoft.com/AadTrustClaims/ClaimsGenerator

There are two types of conditional access. The first (and older) way is to use claims rules — it requires a claims-based authentication solution, such as AD FS On-Premises, Azure AD Premium or a third-party claims-based solution like Okta or Ping Identity. For example, using AD FS, the administrator can create a claims rule generating a valid SAML token only when the client is accessing the resource from the internal corporate network. The type of client application, such as Outlook, OWA or ActiveSync device, can be specified in the rule. Claims rules are used to develop complex requirements for access control.
Quelle: http://www.enowsoftware.com/solutions-engine/explaining-conditional-access-and-azure-pass-through-authentication

Conditional Access in Enterprise Mobility + Security
https://www.youtube.com/watch?v=A7IrxAH87wc

Multi-Factor Authentication Deep Dive: Securing Access On-Premises and in the Cloud
https://www.youtube.com/watch?v=zohHQL36k8c

ADAL und Modern Auth

Für den Einsatz von Conditional Access über AzureADPremium P1/P2 ist die Nutzung von "Modern Auth" erforderlich.

Modern authentication brings Active Directory Authentication Library (ADAL)-based sign-in to Office client apps across platforms. This enables sign-in features such as Multi-Factor Authentication (MFA), SAML-based third-party Identity Providers with Office client applications, smart card and certificate-based authentication, and it removes the need for Outlook to use the basic authentication protocol.
Quelle: Using Office 365 modern authentication with Office clients  https://support.office.com/en-us/article/Using-Office-365-modern-authentication-with-Office-clients-776c0036-66fd-41cb-8928-5495c0f9168a

Dies ist bei allen neu angelegten Tenants schon der Fall. Ältere Tenants könnten noch die alte Einstellung haben: Sie muss dann aktiviert werden

# Exchange
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

# Skype for Business
Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

# SharePoints
Set-SPOTenant -LegacyAuthProtocolsEnabled $false

BRK3249 Modern authentication for Exchange Server On-Premises
https://www.youtube.com/watch?v=e3n3ETHAbRs

Exchange ActiveSync Quarantäne

Wenn ihr Fokus erst einmal auf "Mobilgeräten" und Mail liegt, dann ist die Exchange Quarantäne auch in Exchange Online ein schnelles Hilfsmittel um die Anzahl und Qualität der Endgeräte zu kontrollieren. "Normalerweise" darf jeder Anwender bis zu 10 Endgeräte einfach mit seinem Postfach verbinden.

Der Exchange Administrator kann aber eine "Quarantäne" in Exchange aktivieren, damit Geräte erst explizit freigeschaltet werden müssen. Das ist zwar im Hinblick auf ein Mobile Device Management nur ein kleiner schritt aber speziell für kleinere Firmen ein durchaus interessanter Weg. Sie können damit natürlich kein Outlook und keine Windows 10 Desktops steuern und auch der Zugriff per OWA ist nicht reguliert. Sie können aber zumindest bestimmen, welche ActiveSync Clients sich mit ihrem Exchange Server verbinden und Postfächer replizieren dürfen. Dazu zählen neben dem im Mobilgerät meist vorhandenen ActiveSync Client (IOS, Android) auch die Windows 10 Mail App.

Sie können die Konfiguration einfach per Browser im Exchange Portal von Office 365 aktivieren.

Achtung:
Die Aktivierung der Quarantäne blockt auch alle bestehenden Partnerschaften. Sie müssen diese auch wieder freigeben oder eine Regel dazu erstellen.

SharePoint Online

Auch für SharePoint gibt es die ein oder andere eigene Funktion, die den Zugriff für bestimmte Geräte blockiert oder erlaubt. Nun bin ich nicht der SharePoint-Consultant, der die genaue Auswirkung beschreiben kann. Ich verweise daher auf andere Artikel im Internet.

Use Case

Nun nehmen Sie all die Client-Kriterien zusammen und am besten bauen Sie sich eine Tabelle um alle Varianten gegenüber zu stellen. Zuerst würde ich festlegen, welche Fälle überhaupt betrachtet werden müssen und welche quantitative Berücksichtigung anzustellen ist. Es wird immer Dinge geben, die (noch) nicht möglich sind, oder der Einsatz durchaus mit einem Mehraufwand bei Verwaltung, Betrieb und Kosten verbunden ist. Am besten beginnen Sie mit einer Tabelle der Clients wie in folgendem Beispiel:

Gerät

 Standort

Regelung

Firmen-PC

Intern

Keine Sonderbehandlung, Outlook, OWA erlaubt

Firmen-PC

DA/VPN-Verbindung

Keine Sonderbehandlung, Outlook, OWA erlaubt

Firmen-PC

Extern

z.B. ADFS mit Zertifikat oder PHS mit MFA

„Partner“ Windows-PC

Intern / DA / VPN

Nicht möglich. Fremde Clients sind nie intern oder per DA oder VPN verbunden

„Partner“ Windows-PC

Extern

Postfachzugriff per OWA mit MFA erlaubt. Kein Outlook

Anonyme PCs

Intern/ DA / VPN

Nicht möglich. Fremde Clients sind nie intern oder per DA oder VPN verbunden

Anonyme PCs

Extern

Postfachzugriff per OWA mit MFA erlaubt. Kein Outlook

Firmen Smartphone

Extern

Outlook Mobile mit MFA

Privates Smartphone

Extern

Outlook Mobile mit MFA

Services EWS (Archiv, Migration, EWS)

Internet

Service Principal oder User mit MFA

Die Liste ist natürlich auf ihre Gegebenheiten anzupassen und beschreibt erst einmal "Exchange Online". Die Frage ist immer

  • Welches Endgerät (Managed, Unmanaged, Typ)
  • Welche Client Software
  • Welcher Standort
  • Welcher Dienst

Bedenken Sie dabei auch immer, wie viele Geräte es pro Fall zu berücksichtigen gibt und ob es sich wirklich lohnt so viele Fälle zu unterscheiden.

Weitere Links