Teilen über

Bedingter Zugriff: Zielressourcen

  • Artikel

Zielressourcen (früher Cloud-Apps, -Aktionen und -Authentifizierungskontext) sind wichtige Signale in einer Richtlinie für bedingten Zugriff. Richtlinien für bedingten Zugriff ermöglichen Administrator*innen das Zuweisen von Steuerelementen zu bestimmten Anwendungen, Diensten, Aktionen oder Authentifizierungskontext.

  • Administratoren stehen eine Reihe von Anwendungen oder Diensten zur Auswahl. Dazu zählen integrierte Microsoft-Anwendungen und alle in Microsoft Entra integrierten Anwendungen (Katalog- und Nicht-Kataloganwendungen) sowie über den Anwendungsproxy veröffentlichte Anwendungen.
  • Administratoren können sich entscheiden, die Richtlinie nicht basierend auf einer Cloudanwendung zu definieren, sondern basierend auf einer Benutzeraktion wie etwa Sicherheitsinformationen registrieren oder Geräte registrieren oder beitreten, sodass der bedingte Zugriff Kontrollmaßnahmen bezüglich dieser Aktionen durchsetzen kann.
  • Administratoren können Datenverkehrsweiterleitungsprofile von Global Secure Access als Ziel für erweiterte Funktionen verwenden.
  • Administratoren können den Authentifizierungskontext verwenden, um eine zusätzliche Sicherheitsebene in Anwendungen zu schaffen.

Screenshot, der eine Richtlinie für bedingten Zugriff und den Bereich für Zielressourcen anzeigt.

Microsoft Cloud-Anwendungen

Viele der vorhandenen Microsoft-Cloudanwendungen sind in der Liste der Anwendungen enthalten, die zur Auswahl stehen.

Administratoren können diesen Microsoft-Cloudanwendungen eine Richtlinie für den bedingten Zugriff zuweisen. Zu einigen Apps wie Office 365 und Microsoft Azure-Dienstverwaltungs-API gehören mehrere untergeordnete Apps oder Dienste.

Wichtig

Anwendungen, die für bedingten Zugriff verfügbar sind, durchlaufen einen Onboarding- und Validierungsprozess. Diese Anwendungen enthalten nicht alle Microsoft-Apps. Viele Anwendungen sind Back-End-Dienste, die keine Richtlinie direkt darauf anwenden sollen. Wenn Sie eine fehlende Anwendung suchen, können Sie sich an das jeweilige Anwendungsteam wenden oder eine Anforderung an UserVoice senden.

Office 365

Microsoft 365 stellt cloudbasierte Dienste für Produktivität und Zusammenarbeit wie Exchange, SharePoint und Microsoft Teams bereit. Microsoft 365-Clouddienste sind umfassend integriert, um nahtlose Funktionen für die Zusammenarbeit zu gewährleisten. Diese Integration kann beim Erstellen von Richtlinien zu Verwirrung führen, da einige Apps wie Microsoft Teams Abhängigkeiten von anderen Apps wie SharePoint oder Exchange aufweisen.

Mit der Office 365-Suite können Sie gleichzeitig auf all diese Dienste abzielen. Wir empfehlen die Verwendung der neuen Office 365-Suite, statt auf einzelne Cloud-Apps abzuzielen, um Probleme mit Dienstabhängigkeiten zu vermeiden.

Eine Ausrichtung auf diese Gruppe von Anwendungen trägt dazu bei, Probleme zu vermeiden, die aufgrund inkonsistenter Richtlinien und Abhängigkeiten auftreten können. Beispiel: Die Exchange Online-App ist an herkömmliche Exchange Online-Daten wie E-Mail-, Kalender- und Kontaktinformationen gebunden. Zugehörige Metadaten können über verschiedene Ressourcen wie die Suche verfügbar gemacht werden. Administratoren sollten der Office 365-Suite Richtlinien zuweisen, um sicherzustellen, dass alle Metadaten wie beabsichtigt durch geschützt werden.

Administratoren können die gesamte Office 365-Suite oder bestimmte Office 365-Cloud-Apps aus der Richtlinie für bedingten Zugriff ausschließen.

Eine vollständige Liste aller enthaltenen Dienste finden Sie im Artikel Apps, die in der Office 365-App-Suite für bedingten Zugriff enthalten sind.

Windows Azure Dienstverwaltungs-API

Wenn Sie auf die Windows Azure Dienstverwaltungs-API-Anwendung abzielen, wird die Richtlinie für Token erzwungen, die an eine Gruppe von Diensten ausgestellt wurden, die eng an das Portal gebunden sind. Diese Gruppierung umfasst die Anwendungs-IDs von:

  • Azure Resource Manager
  • Azure-Portal, das auch das Microsoft Entra Admin Center abdeckt.
  • Azure Data Lake
  • Application Insights API
  • Log Analytics-API

Da die Richtlinie auf das Azure-Verwaltungsportal und die API angewendet wird, können Dienste oder Clients mit einer Azure-API-Dienstabhängigkeit indirekt betroffen sein. Zum Beispiel:

  • Azure CLI
  • Azure Data Factory-Portal
  • Azure DevOps
  • Azure Event Hubs
  • Azure PowerShell
  • Azure Service Bus
  • Azure SQL-Datenbank
  • Azure Synapse
  • APIs für das klassische Bereitstellungsmodell
  • Microsoft 365 Admin Center
  • Microsoft IoT Central
  • SQL Managed Instance
  • Administratorportal für Visual Studio-Abonnements

Hinweis

Die Windows Azure Dienstverwaltungs-API-Anwendung gilt für Azure PowerShell, die Azure Resource Manager-API aufruft. Sie gilt nicht für Microsoft Graph PowerShell-, die die Microsoft Graph-APIaufruft.

Weitere Informationen darüber, wie Sie eine Beispielrichtlinie für die Windows Azure Dienstverwaltungs-API einrichten, finden Sie unter Bedingter Zugriff: Anfordern von MFA für die Azure-Verwaltung.

Tipp

Für Azure Government sollten Sie die Anwendung „Azure Government Cloud Management API“ auswählen.

Microsoft-Verwaltungsportale

Wenn eine Richtlinie für bedingten Zugriff auf die Microsoft Admin Portals-Cloud-App ausgerichtet ist, wird die Richtlinie für Token erzwungen, die an Anwendungs-IDs der folgenden Microsoft-Verwaltungsportale ausgegeben werden:

  • Azure-Portal
  • Exchange Admin Center
  • Microsoft 365 Admin Center
  • Microsoft 365 Defender-Portal
  • Microsoft Entra Admin Center
  • Microsoft Intune Admin Center
  • Grundlegendes zum Microsoft Purview-Complianceportal
  • Microsoft Teams Admin Center

Wir fügen der Liste kontinuierlich weitere Verwaltungsportale hinzu.

Hinweis

Die Microsoft Admin Portals-App gilt nur für interaktive Anmeldungen bei den aufgeführten Verwaltungsportalen. Anmeldungen an den zugrunde liegenden Ressourcen oder Diensten wie Microsoft Graph oder Azure Resource Manager-APIs werden von dieser Anwendung nicht abgedeckt. Diese Ressourcen werden durch die Windows Azure Dienstverwaltungs-API-App geschützt. Diese Gruppierung ermöglicht Es Kunden, die MFA-Einführungsreise für Administratoren zu durchlaufen, ohne sich auf die Automatisierung zu auswirken, die auf APIs und PowerShell basiert. Wenn Sie bereit sind, empfiehlt Microsoft die Verwendung einer Richtlinie, die erfordert, dass Administratoren immer MFA durchführen, um umfassenden Schutz zu gewährleisten.

Andere Anwendungen

Administratoren können jede für Microsoft Entra registrierte Anwendung zu Richtlinien für bedingten Zugriff hinzufügen. Dazu können folgende Anwendungen zählen:

Hinweis

Da die Richtlinie für bedingten Zugriff die Anforderungen für den Zugriff auf einen Dienst festlegt, können Sie sie nicht auf eine Clientanwendung (öffentlich/native) anwenden. Anders ausgedrückt: Die Richtlinie wird nicht direkt auf einer Clientanwendung (öffentlich/systemeigene Anwendung) festgelegt, sondern angewendet, wenn ein Client einen Dienst aufruft. Eine Richtlinie, die für den SharePoint-Dienst festgelegt wurde, gilt beispielsweise für alle Clients, die SharePoint aufrufen. Eine Richtlinie, die für Exchange festgelegt wurde, gilt für den Zugriffsversuch auf E-Mail mithilfe des Outlook-Clients. Aus diesem Grund sind Clientanwendungen (öffentlich/systemeigene) nicht für die Auswahl in der App-Auswahl verfügbar, und die Option für bedingten Zugriff ist in den Anwendungseinstellungen für die in Ihrem Mandanten registrierte Clientanwendung (öffentlich/systemeigene Anwendung) nicht verfügbar.

Einige Anwendungen werden in der Auswahl überhaupt nicht angezeigt. Die einzige Möglichkeit, diese Anwendungen in eine Richtlinie für bedingten Zugriff aufzunehmen, besteht darin, Alle Ressourcen (zuvor „Alle Cloud-Apps“) einzuschließen.

Grundlegendes zum bedingten Zugriff für verschiedene Clienttypen

Bedingter Zugriff gilt für Ressourcen, die keine Clients sind, außer wenn der Client ein vertraulicher Client ist, der ein ID-Token anfordert.

  • Öffentlicher Client
    • Öffentliche Clients sind solche, die lokal auf Geräten wie Microsoft Outlook auf dem Desktop oder mobilen Apps wie Microsoft Teams ausgeführt werden.
    • Richtlinien für bedingten Zugriff gelten nicht für den öffentlichen Client selbst, gelten jedoch basierend auf den ressourcen, die von den öffentlichen Clients angefordert werden.
  • Vertraulicher Client
    • Der bedingte Zugriff gilt für die vom Client angeforderten Ressourcen und den vertraulichen Client selbst, wenn er ein ID-Token anfordert.
    • Beispiel: Wenn Outlook Web ein Token für Bereiche Mail.Read und Files.Readanfordert, wendet der bedingte Zugriff Richtlinien für Exchange und SharePoint an. Wenn Outlook Web ein ID-Token anfordert, wendet der bedingte Zugriff auch die Richtlinien für Outlook Web an.

So zeigen Sie Anmeldeprotokolle für diese Clienttypen im Microsoft Entra Admin Center an

  1. Melden Sie sich beim Microsoft Entra Admin Center mindestens mit der Rolle Berichtleseberechtigter an.
  2. Navigieren Sie zu Identität>Überwachung und Integrität>Anmeldeprotokolle.
  3. Fügen Sie einen Filter für den Client-Anmeldedatentyphinzu.
  4. Passen Sie den Filter an, um einen bestimmten Satz von Protokollen basierend auf den Clientanmeldeinformationen anzuzeigen, die in der Anmeldung verwendet werden.

Weitere Informationen finden Sie im Artikel Nr. Öffentliche und vertrauliche Client-Anwendungen.

Alle Ressourcen

Das Anwenden einer Richtlinie für bedingten Zugriff auf Alle Ressourcen (vormals "Alle Cloud-Apps") ohne App-Ausschlüsse führt dazu, dass die Richtlinie für alle Tokenanforderungen von Websites und Diensten erzwungen wird, einschließlich Global Secure Access-Datenverkehrsweiterleitungsprofile. Diese Option umfasst Anwendungen, die in der Richtlinie für bedingten Zugriff nicht einzeln als Ziel bestimmt werden können, z. B. Windows Azure Active Directory (0000002-00000-0000-c000000000000).

Wichtig

Microsoft empfiehlt, eine grundlegende Multifaktor-Authentifizierungsrichtlinie zu erstellen, die auf alle Benutzer und alle Ressourcen abzielt (ohne App-Ausschlüsse), wie es in "Multifaktor-Authentifizierung für alle Benutzer erforderlich"beschrieben ist.

Verhalten des bedingten Zugriffs, wenn eine Richtlinie für alle Ressourcen einen App-Ausschluss aufweist

Wenn eine App aus der Richtlinie ausgeschlossen ist, um den Benutzerzugriff nicht versehentlich zu blockieren, werden bestimmte Bereiche mit niedriger Berechtigung von der Richtlinienerzwingung ausgeschlossen. Diese Bereiche ermöglichen Aufrufen der zugrunde liegenden Graph-APIs wie Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) und Microsoft Graph (00000003-0000-0000-c0000-00000000000), um im Rahmen der Authentifizierung häufig von Anwendungen verwendeten Benutzerprofil- und Gruppenmitgliedschaftsinformationen zuzugreifen. Beispiel: Wenn Outlook ein Token für Exchange anfordert, wird auch der User.Read Bereich aufgefordert, die grundlegenden Kontoinformationen des aktuellen Benutzers anzuzeigen.

Die meisten Apps weisen eine ähnliche Abhängigkeit auf. Aus diesem Grund werden diese niedrigen Berechtigungsbereiche automatisch ausgeschlossen, wenn in einer Alle Ressourcen Richtlinie ein App-Ausschluss vorhanden ist. Diese Ausschlussbereiche mit geringen Rechten erlauben keinen Datenzugriff über grundlegende Benutzerprofil- und Gruppeninformationen hinaus. Die ausgeschlossenen Bereiche werden wie folgt aufgeführt, die Zustimmung ist weiterhin erforderlich, damit Apps diese Berechtigungen verwenden können.

  • Native-Clients und Einzelseitenanwendungen (Single Page Applications, SPAs) haben Zugriff auf die folgenden Berechtigungsstufen mit niedriger Privilegierung:
    • Azure AD Graph: email, offline_access, openid, profile, User.Read
    • Microsoft Graph: email, offline_access, openid, profile, User.Read, People.Read
  • Vertrauliche Clients haben Zugriff auf die folgenden Bereiche mit niedrigen Berechtigungen, wenn sie von der Richtlinie Alle Ressourcen ausgeschlossen sind:
    • Azure AD Graph: email, offline_access, openid, profile, User.Read, User.Read.All,User.ReadBasic.All
    • Microsoft Graph: email, offline_access, openid, profile, User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden

Weitere Informationen zu den genannten Bereichen finden Sie in der Referenz zu Microsoft Graph-Berechtigungen und unter Bereiche und Berechtigungen in Microsoft Identity Platform.

Schützen von Verzeichnisinformationen

Wenn die empfohlene Baseline-MFA-Richtlinie ohne App-Ausschlüsse aufgrund von geschäftlichen Gründen nicht konfiguriert werden kann und die Sicherheitsrichtlinie Ihrer Organisation verzeichnisbezogene niedrige Berechtigungsstufen enthalten muss (User.Read, User.Read.All, User.ReadBasic.All, People.Read, People.Read.All, GroupMember.Read.All, Member.Read.Hidden), besteht die Alternative darin, eine separate Richtlinie für Bedingter Zugriff für Windows Azure Active Directory (00000002-0000-0000-c000-000000000000) zu erstellen. Windows Azure Active Directory (auch Azure AD Graph genannt) ist eine Ressource, die daten darstellt, die im Verzeichnis gespeichert sind, z. B. Benutzer, Gruppen und Anwendungen. Die Windows Azure Active Directory-Ressource ist in Alle Ressourcen enthalten, können jedoch mithilfe der folgenden Schritte einzeln in Richtlinien für bedingten Zugriff gezielt werden:

  1. Melden Sie sich beim Microsoft Entra Admin Center als Attributdefinitionsadministrator und Attributzuweisungsadministratoran.
  2. Navigieren Sie zu Schutz>Benutzerdefinierte Sicherheitsattribute.
  3. Erstellen Sie eine neue Attributsatz- und Attributdefinition. Weitere Informationen finden Sie unter Hinzufügen oder Deaktivieren von Definitionen benutzerdefinierter Sicherheitsattribute in Microsoft Entra ID.
  4. Navigieren Sie zu Identität>Anwendungen>Unternehmensanwendungen.
  5. Entfernen Sie den Anwendungstyp-Filter und suchen Sie nach der Anwendungs-ID, die mit 00000002-0000-0000-c000-000000000000 beginnt.
  6. Wählen Sie Windows Azure Active Directory>Benutzerdefinierte Sicherheitsattribute>Zuweisung hinzufügen aus.
  7. Wählen Sie den Attributsatz und den Attributwert aus, den Sie in der Richtlinie verwenden möchten.
  8. Navigieren Sie zu Schutz>Bedingter Zugriff>Richtlinien.
  9. Erstellen oder Ändern einer vorhandenen Richtlinie.
  10. Wählen Sie unter Zielressourcen>Ressourcen (früher Cloud-Apps)>Einschließen die Optionen Ressourcen auswählen>Filter bearbeiten aus.
  11. Passen Sie den Filter an, um den Attributsatz und die Definition aus früheren Versionen einzuschließen.
  12. Speichern der Richtlinie

Alle Internetressourcen mit globalen sicheren Zugriff

Mit der Option Alle Internetressourcen mit globalem sicherem Zugriff können Administratoren das Internetzugriffs-Datenverkehrsweiterleitungsprofil von Microsoft Entra Internet Access anzielen.

Mithilfe dieser Profile in Global Secure Access können Administratoren definieren und steuern, wie Datenverkehr über Microsoft Entra Internet Access und Microsoft Entra Private Access weitergeleitet wird. Datenverkehrsweiterleitungsprofile können Geräten und Remotenetzwerken zugewiesen werden. Ein Beispiel für das Anwenden einer Richtlinie für bedingten Zugriff auf diese Datenverkehrsprofile finden Sie im Artikel Anwenden von Richtlinien für bedingten Zugriff auf das Microsoft 365-Datenverkehrsprofil.

Weitere Informationen zu diesen Profilen finden Sie im Artikel Datenverkehrsweiterleitungsprofile von Global Secure Access.

Benutzeraktionen

Benutzeraktionen sind Aufgaben, die von einem Benutzer ausgeführt werden. Der bedingte Zugriff unterstützt derzeit zwei Benutzeraktionen:

  • Sicherheitsinformationen registrieren: Mit dieser Benutzeraktion kann eine Richtlinie für bedingten Zugriff erzwungen werden, wenn Benutzer, für die die kombinierte Registrierung aktiviert ist, versuchen, ihre Sicherheitsinformationen zu registrieren. Weitere Informationen finden Sie im Artikel Kombinierte Registrierung von Sicherheitsinformationen.

Hinweis

Wenn Administratoren eine Richtlinie für Benutzeraktionen für die Registrierung von Sicherheitsinformationen anwenden, wenn das Benutzerkonto ein Gast von Microsoft Personal Account (MSA)ist, erfordert die Verwendung des Steuerelements "Mehrstufige Authentifizierung erfordern", dass der MSA-Benutzer Sicherheitsinformationen bei der Organisation registriert. Wenn der Gastbenutzer von einem anderen Anbieter wie Googlestammt, wird der Zugriff blockiert.

  • Geräte registrieren oder verknüpfen: Mit dieser Benutzeraktion können Administratoren eine Richtlinie für bedingten Zugriff erzwingen, wenn Benutzer Geräte in Azure AD registrieren oder mit Microsoft Entra ID verknüpfen. Sie bietet Granularität beim Konfigurieren der Multi-Faktor-Authentifizierung für das Registrieren oder Einbinden von Geräten anstelle einer derzeit vorhandenen mandantenweiten Richtlinie. Bei dieser Benutzeraktion sind drei wichtige Punkte zu beachten:
    • Require multifactor authentication ist die einzige Zugriffssteuerung, die bei dieser Benutzeraktion verfügbar ist. Alle anderen Zugriffssteuerungen sind deaktiviert. Durch diese Einschränkung werden Konflikte mit Zugriffssteuerungen verhindert, die entweder von der Microsoft Entra-Geräteregistrierung abhängig sind oder nicht für die Microsoft Entra-Geräteregistrierung gelten.
    • Die Bedingungen Client apps, Filters for devices und Device state sind bei dieser Benutzeraktion nicht verfügbar, da sie zum Erzwingen von Richtlinien für den bedingten Zugriff von der Microsoft Entra-Geräteregistrierung abhängig sind.

Warnung

Wenn eine Richtlinie für bedingten Zugriff mit der Benutzeraktion Geräte registrieren oder zusammenfügen konfiguriert ist, müssen Sie Identität>Geräte>Übersicht>Geräteeinstellungen - Require Multifactor Authentication to register or join devices with Microsoft Entra auf Nein setzen. Anderenfalls werden die Richtlinien für bedingten Zugriff bei dieser Benutzeraktion nicht ordnungsgemäß erzwungen. Weitere Informationen zu dieser Geräteeinstellung finden Sie unter Konfigurieren von Geräteeinstellungen.

Authentifizierungskontext

Der Authentifizierungskontext kann verwendet werden, um Daten und Aktionen in Anwendungen besser zu schützen. Bei diesen Anwendungen kann es sich um Ihre eigenen benutzerdefinierten Anwendungen, benutzerdefinierte Geschäftsbereichsanwendungen (LOB), Anwendungen wie SharePoint oder Anwendungen handeln, die durch Microsoft Defender für Cloud Apps geschützt sind.

Eine Organisation kann z. B. Dateien auf SharePoint-Websites speichern, etwa eine Speisekarte oder die geheime Rezeptur ihrer BBQ-Soße. Möglicherweise haben alle Zugriff auf die Speisekartenwebsite, aber Benutzer mit Zugriff auf die geheime BBQ-Soßenrezepturwebsite müssen möglicherweise von einem verwalteten Gerät aus darauf zugreifen und bestimmten Nutzungsbedingungen zustimmen.

Der Authentifizierungskontext funktioniert mit Benutzern oder Workloadidentitäten, jedoch nicht in derselben Richtlinie für bedingten Zugriff.

Authentifizierungskontexte konfigurieren

Authentifizierungskontexte werden unter Schutz>Bedingter Zugriff>Authentifizierungskontextverwaltet.

Screenshot, der die Verwaltung von Authentifizierungskontexten zeigt.

Erstellen Sie neue Authentifizierungskontextdefinitionen, indem Sie Neuer Authentifizierungskontext auswählen. Organisationen sind auf insgesamt 99 Authentifizierungskontextdefinitionen c1-c99 beschränkt. Konfigurieren Sie folgende Attribute:

  • Anzeigename ist der Name, der verwendet wird, um den Authentifizierungskontext in Microsoft Entra ID und anwendungsübergreifend in Authentifizierungskontext nutzenden Anwendungen zu identifizieren. Es werden Namen empfohlen, die ressourcenübergreifend verwendet werden können, z. B. vertrauenswürdige Geräte, um die Anzahl der erforderlichen Authentifizierungskontexte zu reduzieren. Durch einen reduzierten Satz an Namen wird die Anzahl der Umleitungen eingeschränkt, und die Endbenutzererfahrung wird verbessert.
  • Die Beschreibung enthält weitere Informationen zu den Richtlinien, die von Administratoren und Administratorinnen verwendet werden, und solchen, die Authentifizierungskontexte auf Ressourcen anwenden.
  • Wenn das Kontrollkästchen In Apps veröffentlichen aktiviert ist, wird der Authentifizierungskontext für Apps ankündigen und zur Zuweisung zur Verfügung gestellt. Wenn er nicht aktiviert ist, ist der Authentifizierungskontext für Downstream-Ressourcen nicht verfügbar.
  • Die ID ist schreibgeschützt und wird in Token und Apps für anforderungsspezifische Authentifizierungskontextdefinitionen verwendet. Er ist hier zu Zwecken der Problembehandlung und für Anwendungsfälle in der Entwicklung aufgeführt.

Hinzufügen zur Richtlinie für bedingten Zugriff

Administratoren können veröffentlichte Authentifizierungskontexte in ihren Richtlinien für bedingten Zugriff unter Zuweisungen>Cloud-Apps oder -AktionenAuthentifizierungskontext im Menü Auswählen, wofür diese Richtlinie gilt auswählen.

Screenshot, der zeigt, wie Sie einen Authentifizierungskontext für bedingten Zugriff zu einer Richtlinie hinzufügen.

Löschen eines Authentifizierungskontexts

Wenn Sie einen Authentifizierungskontext löschen, stellen Sie sicher, dass er nicht mehr von Anwendungen verwendet wird. Andernfalls wird der Zugriff auf App-Daten nicht mehr geschützt. Sie können diese Voraussetzung bestätigen, indem Sie Anmeldeprotokolle für Fälle überprüfen, in denen die Richtlinien für bedingten Zugriff im Authentifizierungskontext angewendet werden.

Um einen Authentifizierungskontext zu löschen, dürfen ihm keine Richtlinien für bedingten Zugriff zugewiesen sein, und er darf nicht in Apps veröffentlicht werden. Diese Anforderung hilft, das versehentliche Löschen eines Authentifizierungskontexts zu verhindern, der noch verwendet wird.

Ressourcen mit Authentifizierungskontexten markieren

Weitere Informationen zur Verwendung des Authentifizierungskontexts in Anwendungen finden Sie in den folgenden Artikeln.

Nächste Schritte