Bedingter Zugriff: Bedingungen

Ein Administrator kann in einer Richtlinie für bedingten Zugriff ein oder mehrere Signale verwenden, um Entscheidungen auf Grundlage der Richtlinie zu verbessern.

Es können mehrere Bedingungen kombiniert werden, um differenzierte und spezifische Richtlinien für bedingten Zugriff zu erstellen.

Wenn Benutzer auf eine vertrauliche Anwendung zugreifen, kann ein Administrator mehrere Bedingungen in ihre Zugriffsentscheidungen einbeziehen, z. B.:

• Informationen zum Anmelderisiko aus ID Protection
• Netzwerkadresse
• Geräteinformationen

Benutzerrisiko

Administratoren und Administratorinnen mit Zugriff auf ID Protection können das Benutzerrisiko im Rahmen einer Richtlinie für bedingten Zugriff auswerten. Ein Benutzerrisiko stellt die Wahrscheinlichkeit dar, dass eine bestimmte Identität oder ein bestimmtes Konto kompromittiert wurde. Weitere Informationen zu Benutzerrisiken finden Sie in den Artikeln Was bedeutet Risiko? und Anleitung: Konfigurieren und Aktivieren von Risikorichtlinien.

Anmelderisiko

Administratoren und Administratorinnen mit Zugriff auf ID Protection können das Anmelderisiko im Rahmen einer Richtlinie für bedingten Zugriff auswerten. Ein Anmelderisiko ist die Möglichkeit, dass eine bestimmte Authentifizierungsanforderung nicht vom Identitätsbesitzer autorisiert wurde. Weitere Informationen zu Anmelderisiken finden Sie in den Artikeln Was bedeutet Risiko? und Anleitung: Konfigurieren und Aktivieren von Risikorichtlinien.

Insider-Risiko (Vorschau)

Administratoren und Administratorinnen mit Zugriff auf den adaptiven Schutz von Microsoft Purview können Risikosignale von Microsoft Purview in Entscheidungen für Richtlinien für bedingten Zugriff einbeziehen. Beim Insider-Risiko werden Ihre Datengovernance, die Datensicherheit und Ihre Risiko- und Compliancekonfigurationen von Microsoft Purview berücksichtigt. Diese Signale basieren auf kontextbezogenen Faktoren wie:

• Benutzerverhalten
• Frühere Muster
• Anomalieerkennungen

Diese Bedingung ermöglicht Administratoren und Administratorinnen die Verwendung von Richtlinien für bedingten Zugriff, um Aktionen wie das Blockieren des Zugriffs auszuführen oder stärkere Authentifizierungsmethoden bzw. das Akzeptieren von Nutzungsbedingungen zu erzwingen.

Diese Funktionalität umfasst das Einbinden von Parametern, die speziell für potenzielle Risiken innerhalb einer Organisation gelten. Durch die Konfiguration der Einbeziehung des Insider-Risikos in Entscheidungen zum bedingten Zugriff können Administratoren und Administratorinnen Zugriffsberechtigungen basierend auf kontextbezogenen Faktoren wie Benutzerverhalten, früheren Mustern und Anomalieerkennungen anpassen.

Weitere Informationen finden Sie im Artikel Konfigurieren und Aktivieren einer auf dem Insider-Risiko basierenden Richtlinie.

Geräteplattformen

Der bedingte Zugriff identifiziert die Geräteplattform mithilfe der vom Gerät bereitgestellten Informationen, wie z. B. Benutzer-Agent-Zeichenfolgen. Da Benutzer-Agent-Zeichenfolgen geändert werden können, werden diese Informationen nicht überprüft. Die Geräteplattform sollte zusammen mit Microsoft Intune-Richtlinien zur Gerätekonformität oder als Teil einer Blockierungsanweisung verwendet werden. Standardmäßig werden Richtlinien auf alle Geräteplattformen angewendet.

Für den bedingten Zugriff werden folgende Geräteplattformen unterstützt:

• Android
• iOS
• Windows
• macOS
• Linux

Wenn Sie die ältere Authentifizierung mit der Bedingung „Andere Clients“ blockieren, können Sie auch die Geräteplattform als Bedingung festlegen.

Die Auswahl von macOS- oder Linux-Geräteplattformen wird nicht unterstützt, wenn Sie genehmigte Client-App anfordern oder App-Schutzrichtlinie anfordern als die einzigen Zuweisungssteuerelemente auswählen oder wenn Sie Alle ausgewählten Steuerelemente anfordern auswählen.

Wichtig

Microsoft empfiehlt, dass Sie eine Richtlinie für bedingten Zugriff für nicht unterstützte Geräteplattformen haben. Wenn Sie beispielsweise den Zugriff auf Ihre Unternehmensressourcen von Chrome OS oder anderen nicht unterstützten Clients aus blockieren möchten, sollten Sie eine Richtlinie mit einer Bedingung für Geräteplattformen konfigurieren, die alle Geräte einschließt und unterstützte Geräteplattformen sowie das Gewährungssteuerelement, das auf Blockieren des Zugriffs festlegt ist, ausschließt.

Standorte

Wenn Administrator den Standort als Bedingung konfigurieren, können sie auswählen, ob Standorte ein- oder ausgeschlossen werden sollen. Diese benannten Standorte können die Informationen zum öffentlichen IPv4- oder IPv6-Netzwerk, das Land oder die Region, unbekannte Bereiche, die bestimmten Ländern oder Regionen nicht zugeordnet sind, und das mit Global Secure Access kompatible Netzwerk umfassen.

Wenn Sie alle Standorte einschließen, umfasst diese Option alle IP-Adressen im Internet und nicht nur konfigurierte benannte Standorte. Wenn Administratoren Alle Standorte auswählen, können sie entscheiden, ob alle vertrauenswürdigen oder ausgewählte Standorte ausgeschlossen werden sollen.

Administratoren können Richtlinien erstellen, die auf bestimmte Standorte zusammen mit anderen Bedingungen ausgerichtet sind. Im Artikel Was sind Standortbedingungen beim bedingten Zugriff in Microsoft Entra? finden Sie weitere Informationen zu Standorten.

Client-Apps

Standardmäßig gelten alle neu erstellten Richtlinien für bedingten Zugriff für alle Client-App-Typen, auch wenn die Client-Apps-Bedingung nicht konfiguriert ist.

Hinweis

Das Verhalten der Client-Apps-Bedingung wurde im August 2020 aktualisiert. Vorhandene Richtlinien für bedingten Zugriff bleiben unverändert erhalten. Wenn Sie jedoch eine vorhandene Richtlinie auswählen, sehen Sie, dass die Umschaltfläche Konfigurieren nicht vorhanden ist und die Client-Apps ausgewählt sind, für die diese Richtlinie gilt.

Wichtig

Bei Anmeldungen von Clients mit Legacyauthentifizierung wird die Multi-Faktor-Authentifizierung (MFA) nicht unterstützt, und es werden keine Gerätestatusinformationen übergeben. Die Anmeldungen werden daher durch den bedingten Zugriff mit seinen Zuweisungssteuerelementen (z. B. MFA oder kompatible Geräte erforderlich ) blockiert. Wenn Sie Konten haben, für die die Legacyauthentifizierung verwendet werden muss, müssen Sie diese Konten entweder aus der Richtlinie ausschließen oder die Richtlinie so konfigurieren, dass sie nur für moderne Authentifizierungsclients gilt.

Wenn die Umschaltfläche Konfigurieren auf Ja festgelegt ist, gilt sie für markierte Elemente. Wenn sie auf Nein eingestellt ist, gilt sie für alle Client-Apps, einschließlich Clients mit moderner und Legacyauthentifizierung. Diese Umschaltfläche ist in Richtlinien, die vor August 2020 erstellt wurden, nicht enthalten.

• Clients mit moderner Authentifizierung
  • Browser
    • Hierzu gehören webbasierte Anwendungen, die Protokolle wie SAML, WS-Verbund, OpenID Connect oder Dienste verwenden, die als vertraulicher OAuth-Client registriert sind.
  • Mobile Apps und Desktop-Apps
    • Diese Option umfasst Anwendungen wie Office-Desktop- und Telefonanwendungen.
• Clients mit Legacyauthentifizierung
  • Exchange ActiveSync-Clients
    • Diese Auswahl umfasst die gesamte Verwendung des Exchange ActiveSync (EAS)-Protokolls.
    • Wenn die Verwendung von Exchange ActiveSync durch eine Richtlinie blockiert wird, erhält der betroffene Benutzer eine einzige Quarantäne-E-Mail. Diese E-Mail enthält Informationen zum Grund für die Blockierung und gegebenenfalls Korrekturanweisungen.
    • Administratoren können die Richtlinie über den bedingten Zugriff der Microsoft Graph-API nur auf unterstützte Plattformen (z. B. iOS, Android und Windows) anwenden.
  • Andere Clients
    • Diese Option umfasst Clients, die Standard-/Legacyauthentifizierungsprotokolle verwenden, von denen keine moderne Authentifizierung unterstützt wird.
      • SMTP – Wird von POP- und IMAP-Clients zum Senden von E-Mail-Nachrichten verwendet.
      • AutoErmittlung: wird von Outlook und EAS-Clients verwendet, um Postfächer in Exchange Online zu suchen und diese zu verbinden
      • Exchange Online PowerShell: wird zum Herstellen einer Verbindung mit Exchange Online über Remote-PowerShell verwendet Wenn Sie die Standardauthentifizierung für Exchange Online PowerShell blockieren, müssen Sie das Exchange Online PowerShell-Modul verwenden, um eine Verbindung herzustellen. Anweisungen finden Sie unter Herstellen einer Verbindung mit Exchange Online PowerShell mithilfe der mehrstufigen Authentifizierung.
      • Exchange Web Services (EWS): eine Programmierschnittstelle, die von Outlook, Outlook für Mac und Drittanbieter-Apps verwendet wird.
      • IMAP4: wird von IMAP-E-Mail-Clients verwendet
      • MAPI über HTTP (MAPI/HTTP): wird von Outlook 2010 und höher verwendet
      • Offlineadressbuch (OAB): eine Kopie der Adressenlistensammlungen, die von Outlook heruntergeladen und verwendet werden
      • Outlook Anywhere (RPC über HTTP): wird von Outlook 2016 und früher verwendet
      • Outlook-Dienst: wird von der Mail- und Kalender-App für Windows 10 verwendet
      • POP3: wird von POP-E-Mail-Clients verwendet
      • Berichtswebdienste: Werden zum Abrufen von Berichtsdaten in Exchange Online verwendet.

Diese Bedingungen werden häufig für Folgendes verwendet:

• Erfordern eines verwalteten Geräts
• Blockieren älterer Authentifizierungsmethoden
• Blockieren von Webanwendungen, aber Zulassen von mobile oder Desktop-Apps

Unterstützte Browser

Diese Einstellung funktioniert mit allen Browsern. Die folgenden Betriebssysteme und Browser werden jedoch unterstützt, um eine Geräterichtlinie (beispielsweise eine Gerätekonformitätsanforderung) zu erfüllen. Betriebssysteme und Browser, die nicht mehr vom grundlegenden Support abgedeckt werden, sind in dieser Liste nicht enthalten:

Betriebssysteme	Browsers
Windows 10 und höher	Microsoft Edge, Chrome, Firefox 91 und höher
Windows Server 2022	Microsoft Edge, Chrome
Windows Server 2019	Microsoft Edge, Chrome
iOS	Microsoft Edge, Safari (siehe die Hinweise)
Android	Microsoft Edge, Chrome
macOS	Microsoft Edge, Chrome, Safari
Linux Desktop	Microsoft Edge

Diese Browser unterstützen die Geräteauthentifizierung, sodass das Gerät identifiziert und anhand einer Richtlinie überprüft werden kann. Bei der Geräteüberprüfung tritt ein Fehler auf, wenn der Browser im privaten Modus ausgeführt wird oder Cookies deaktiviert sind.

Hinweis

Bei Microsoft Edge 85+ muss der Benutzer beim Browser angemeldet sein, um die Geräteidentität ordnungsgemäß zu übergeben. Andernfalls ist das Verhalten vergleichbar mit Chrome ohne Kontoerweiterung. Diese Anmeldung erfolgt in einem hybriden Geräteeinbindungsszenario möglicherweise nicht automatisch.

Safari wird auf einem verwalteten Gerät für den gerätebasierten bedingten Zugriff unterstützt, kann jedoch die Bedingungen Genehmigte Client-App erforderlich und App-Schutzrichtlinie erforderlich nicht erfüllen. Ein verwalteter Browser wie Microsoft Edge erfüllt diese Anforderungen („Genehmigte Client-App erforderlich“ und „App-Schutzrichtlinie erforderlich“). Unter iOS mit der einer MDM-Drittanbieterlösung unterstützt nur der Microsoft Edge Browser die Geräterichtlinie.

Firefox 91 und höher wird für den gerätebasierten bedingten Zugriff unterstützt, doch muss die Option „Einmaliges Anmelden von Windows für Microsoft-Konten sowie Geschäfts-, Schul- oder Unikonten zulassen“ muss aktiviert werden.

Chrome 111+ wird für gerätebasierten bedingten Zugriff unterstützt, doch muss „CloudApAuthEnabled“ aktiviert werden.

Warum wird im Browser eine Aufforderung zur Clientzertifikatauswahl angezeigt?

Unter Windows 7 werden iOS-, Android- und macOS-Geräte mithilfe eines Clientzertifikats identifiziert. Dieses Zertifikat wird bereitgestellt, wenn das Gerät registriert wird. Wenn sich ein Benutzer zum ersten Mal über den Browser anmeldet, wird er zum Auswählen des Zertifikats aufgefordert. Der Benutzer muss dieses Zertifikat vor dem Verwenden des Browsers auswählen.

Chrome-Unterstützung

Damit Chrome in Windows 10 Creators Update (Version 1703) oder höher unterstützt wird, installieren Sie die Erweiterung Windows-Konten, oder aktivieren Sie CloudAPAuthEnabled in Chrome. Diese Konfigurationen sind erforderlich, wenn eine Richtlinie für bedingten Zugriff gerätespezifische Details speziell für Windows-Plattformen erfordert.

Um die CloudAPAuthEnabled-Richtlinie in Chrome automatisch zu aktivieren, erstellen Sie den folgenden Registrierungsschlüssel:

• Pfad: HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
• Name: CloudAPAuthEnabled
• Wert: 0x00000001
• PropertyType: DWORD

Um die Windows-Konto-Erweiterung für Chrome-Browser automatisch bereitzustellen, erstellen Sie den folgenden Registrierungsschlüssel:

• Pfad: HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\ExtensionInstallForcelist
• Name: 1
• Typ: REG_SZ (String)
• Daten: ppnbnpeolgkicgegkbkbjmhlideopiji;https\://clients2.google.com/service/update2/crx

Erstellen Sie den folgenden Registrierungsschlüssel, damit Chrome unter Windows 8.1 und 7 unterstützt wird:

• Pfad: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\AutoSelectCertificateForUrls
• Name: 1
• Typ: REG_SZ (String)
• Daten: {"pattern":"https://device.login.microsoftonline.com","filter":{"ISSUER":{"CN":"MS-Organization-Access"}}}

Unterstützte mobile Anwendungen und Desktopclients

Administratoren können Mobile Apps und Desktopclients als Client-App auswählen.

Diese Einstellung wirken sich auf Zugriffsversuche von den folgenden mobilen Apps und Desktopclients aus:

Client-Apps	Zieldienst	Plattform
Dynamics CRM-App	Dynamics CRM	Windows 10, Windows 8.1, iOS und Android
E-Mail-/Kalender-/Kontakte-App, Outlook 2016, Outlook 2013 (mit moderner Authentifizierung)	Exchange Online	Windows 10
MFA- und Standort-Richtlinien für Apps Gerätebasierte Richtlinien werden nicht unterstützt.	Alle Meine Apps-App-Dienste	Android und iOS
Microsoft Teams-Dienste: Diese Client-App steuert alle Dienste, die Microsoft Teams und alle zugehörigen Client-Apps (Windows Desktop, iOS, Android, WP und Webclient) unterstützen	Microsoft Teams	Windows 10, Windows 8.1, Windows 7, iOS, Android und macOS
Office 2016-Apps, Office 2013 (mit moderner Authentifizierung), OneDrive-Synchronisierungsclient	SharePoint	Windows 8.1, Windows 7
Office 2016-Apps, universelle Office-Apps, Office 2013 (mit moderner Authentifizierung), OneDrive-Synchronisierungsclient	SharePoint Online	Windows 10
Office 2016 (nur Word, Excel, PowerPoint und OneNote).	SharePoint	macOS
Office 2019	SharePoint	Windows 10, macOS
Office Mobile-Apps	SharePoint	Android, iOS
Office Yammer-App	Yammer	Windows 10, iOS und Android
Outlook 2019	SharePoint	Windows 10, macOS
Outlook 2016 (Office für macOS)	Exchange Online	macOS
Outlook 2016, Outlook 2013 (mit moderner Authentifizierung), Skype for Business (mit moderner Authentifizierung)	Exchange Online	Windows 8.1, Windows 7
Outlook Mobile-App	Exchange Online	Android, iOS
Power BI-App	Power BI-Dienst	Windows 10, Windows 8.1, Windows 7, Android und iOS
Skype for Business	Exchange Online	Android, iOS
Azure DevOps Services-App (früher Visual Studio Team Services bzw. VSTS)	Azure DevOps Services (früher Visual Studio Team Services bzw. VSTS)	Windows 10, Windows 8.1, Windows 7, iOS, Android

Exchange ActiveSync-Clients

• Administratoren können Exchange ActiveSync-Clients nur auswählen, wenn sie Benutzern oder Gruppen Richtlinien zuweisen. Wenn Alle Benutzer, Alle Gast- und externen Benutzer oder Verzeichnisrollen ausgewählt wird, unterliegen alle Benutzer der Richtlinie.
• Wenn Administratoren eine Richtlinie erstellen, die Exchange ActiveSync-Clients zugewiesen ist, sollte Exchange Online der Richtlinie als einzige Cloudanwendung zugewiesen sein.
• Administratoren können den Umfang dieser Richtlinie auf bestimmte Plattformen beschränken, indem sie die Bedingung Geräteplattformen verwenden.

Wenn die der Richtlinie zugewiesene Zugriffssteuerung die Option Genehmigte Client-App erforderlich verwendet, wird der Benutzer angewiesen, den Outlook Mobile-Client zu installieren und zu verwenden. Wenn Multi-Faktor-Authentifizierung, Nutzungsbedingungen oder benutzerdefinierte Kontrollen erforderlich ist/sind, werden betroffene Benutzer*innen blockiert, weil die Standardauthentifizierung diese Kontrollmechanismen nicht unterstützt.

Weitere Informationen finden Sie in den folgenden Artikeln:

• Blockieren der Legacyauthentifizierung mit bedingtem Zugriff
• Vorschreiben der Verwendung von genehmigten Client-Apps für den Zugriff auf Cloud-Apps mithilfe des bedingten Zugriffs

Andere Clients

Wenn Sie Andere Clients auswählen, können Sie eine Bedingung für Apps mit Standardauthentifizierung über E-Mail-Protokolle wie IMAP, MAPI, POP oder SMTP sowie für ältere Office-Apps angeben, die keine moderne Authentifizierung verwenden.

Gerätestatus (veraltet)

Diese Bedingung war veraltet. Kunden sollten die Bedingung Nach Geräten filtern in der Richtlinie für bedingten Zugriff verwenden, um Szenarien zu ermöglichen, die zuvor mithilfe der Bedingung für den Gerätestatus umgesetzt wurden.

Wichtig

„Gerätestatus“ und „Filter für Geräte“ können in der Richtlinie für bedingten Zugriff nicht zusammen verwendet werden. „Filter für Geräte“ bietet eine präzisere Zielgruppenadressierung sowie Unterstützung für das Ansteuern von Gerätestatusinformationen über die Eigenschaften trustType und isCompliant.

Filtern nach Geräten

Wenn Administratoren „Filter für Geräte“ als Bedingung konfigurieren, können sie Geräte anhand eines Filters und mithilfe eines Regelausdrucks für Geräteeigenschaften ein- oder ausschließen. Der Regelausdruck für „Filter für Geräte“ kann mithilfe des Regel-Generators oder der Regelsyntax erstellt werden. Diese Funktion ähnelt der Funktion, die für die Regeln für die dynamische Mitgliedschaft in Gruppen verwendet wird. Weitere Informationen finden Sie im Artikel Bedingter Zugriff: Filter für Geräte.

Authentifizierungsflows (Vorschau)

Authentifizierungsflows steuern, wie Ihre Organisation bestimmte Authentifizierungs- und Autorisierungsprotokolle verwendet und gewährt. Diese Flows bieten möglicherweise eine nahtlose Benutzeroberfläche für Geräte, die möglicherweise keine lokalen Eingabegeräte wie gemeinsam genutzte Geräte oder digitale Beschilderung aufweisen. Verwenden Sie dieses Steuerelement, um Übertragungsmethoden wie Gerätecodeflow oder Authentifizierungsübertragung zu konfigurieren.

Nächste Schritte

• Bedingter Zugriff: Gewähren
• Allgemeine Richtlinien für bedingten Zugriff