Festlegen von Multi-Faktor-Authentifizierung (MFA) für Ihren Partnermandanten

Geeignete Rollen: Administrator-Agent | Vertriebsmitarbeiter | Helpdesk-Agent | Abrechnungsadministrator | Sicherheitsadministrator

Bessere Sicherheit und fortlaufende Sicherheit und Datenschutzbestimmungen gehören zu unseren wichtigsten Prioritäten, und wir helfen Partnern weiterhin dabei, ihre Kunden und Mandanten zu schützen.

Um Partnern dabei zu helfen, ihre Unternehmen und Kunden vor Identitätsdiebstahl und unbefugtem Zugriff zu schützen, haben wir mehr Sicherheitsvorkehrungen für Partnermandanten aktiviert. Diese Garantien gewährleisten das Mandat und die Überprüfung der MFA. Die Mandatierung von MFA hilft Partnern, ihren Zugriff auf Kundenressourcen gegen Kompromittierung von Anmeldeinformationen zu sichern.

In diesem Artikel finden Sie ausführliche Beispiele und Anleitungen für die Mandatierung der mehrstufigen Authentifizierung (MFA) im Partner Center.

Partner, die am CSP-Programm (Cloud Solution Provider), Systemsteuerung Vendors (CPVs) teilnehmen, und Berater müssen die Partnersicherheitsanforderungen implementieren, um die Compliance einzuhalten.

Partner sind verpflichtet, MFA für alle Benutzerkonten in ihrem Partnermandanten durchzusetzen. Dazu gehören auch Gastbenutzer. Benutzer müssen die MFA-Überprüfung für die folgenden Bereiche abschließen:

• Partner Center
• Partner Center-API
• Vom Partner delegierte Verwaltung

Partner Center

Einige Seiten im Partner Center sind MFA-geschützt, darunter:

• Alle Seiten unter der Registerkarte "Kunden " (d. a. alle Seiten mit einer URL, die mit https://partner.microsoft.com/commerce/*)
• Alle Seiten unter der Registerkarte "Support-Kundenanfragen>" (z. B. alle Seiten, auf die mit einer URL zugegriffen wird, die mit )https://partner.microsoft.com/dashboard/v2/support/customers/*
• Alle Seiten auf der Registerkarte "Abrechnung "

Andere Seiten im Partner Center, z. B. die Seite "Übersicht" und die Seite "Dienststatusüberprüfung", erfordern keine MFA.

Die folgende Tabelle zeigt, welche Benutzertypen für den Zugriff auf diese MFA-geschützten Seiten autorisiert sind (und von diesem Feature betroffen sind).

Um auf diese Seiten zuzugreifen, müssen Sie zuerst die MFA-Überprüfung abschließen.

Unterstützte MFA-Optionen

• Partner, die Microsoft verwenden, haben die mehrstufige Microsoft Entra-Authentifizierung unterstützt. Weitere Informationen finden Sie unter "Mehrere Möglichkeiten zum Aktivieren der mehrstufigen Microsoft Entra-Authentifizierung (MFA unterstützt)
• Partner, die integrierte MFA-Verbundauthentifizierung implementiert haben. Diese Partnerbenutzer dürfen auf Partner Center zugreifen und die Kunden mit GDAP verwalten. Sehen Sie sich die integrierten MFA-Anbieter mit MFA-Angeboten an, die mit AD FS verfügbar sind: Konfigurieren von Methoden für AD FS.

Partner Center und APIs

Für die folgenden Partner Center-APIs sind App+Benutzerzugriff und Microsoft Entra ID Support MFA erforderlich:

• Ermittlung (Preis/Katalog/Promotion)
• Transaktion und Verwaltung
• Abrechnung und Abstimmung
• Verwalten von Kunden mit delegiertem Zugriff/AOBO
• Benutzer- und Lizenzzuweisung (nur mit DAP)
• Benutzer- und Lizenzzuweisung (mit GDAP)
• Anforderung granularer Administratorbeziehungen und Zugriffszuweisung

Die folgenden Optionen sind für Partner verfügbar:

• Verwenden Sie integrierte Microsoft-Authentifizierungsmethoden, um die MFA-Anforderungen zu erfüllen.
• Wenn Sie einen Verbundidentitätsanbieter verwenden, stellen Sie sicher, dass der Partnerverbund so konfiguriert ist, dass er die Verbund-MFA akzeptiert.
• Wenn Sie ADFS verwenden möchten, um den externen zweiten Faktor zu konfigurieren, lesen Sie die Drittanbieter mit MFA-Angeboten, die mit AD FS verfügbar sind: Konfigurieren von Authentifizierungsmethoden für AD FS
• Implementieren Sie MFA: Aktivieren Sie MFA sofort über Sicherheitsstandardeinstellungen oder bedingten Zugriff, indem Sie den Sicherheitsstandardrichtlinien folgen.

Überprüfungsbeispiele

Betrachten Sie die folgenden Beispiele, um zu veranschaulichen, wie die Überprüfung im Partner Center funktioniert.

Beispiel 1: Partner hat die mehrstufige Microsoft Entra-Authentifizierung implementiert.

1. Alejandra arbeitet für einen CSP namens Contoso. Contoso hat MFA für alle benutzer unter Contoso-Partnermandanten mithilfe der mehrstufigen Microsoft Entra-Authentifizierung implementiert.

2. Alejandra startet eine neue Browsersitzung und wechselt zur Partner Center-Übersichtsseite (die nicht MFA-geschützt ist). Partner Center leitet Alejandra zu Microsoft Entra ID um, um sich anzumelden.

3. Aufgrund des vorhandenen mehrstufigen Authentifizierungssetups von Microsoft Entra von Contoso ist Alejandra erforderlich, um die MFA-Überprüfung abzuschließen. Nach erfolgreicher Anmeldung und MFA-Überprüfung wird Alejandra zurück zur Partner Center-Übersichtsseite umgeleitet.

4. Alejandra versucht, auf eine der MFA-geschützten Seiten im Partner Center zuzugreifen. Da Alejandra die MFA-Überprüfung während der Anmeldung früher abgeschlossen hat, kann Alejandra auf die MFA-geschützte Seite zugreifen, ohne dass die MFA-Überprüfung erneut durchlaufen werden muss.

Beispiel 2: Partner hat nicht-Microsoft MFA mithilfe des Identitätsverbunds implementiert

1. Prashob arbeitet für einen CSP mit dem Namen Wingtip. Wingtip hat MFA für alle benutzer unter Wingtip-Partnermandanten unter Verwendung von Nicht-Microsoft MFA implementiert, die mit Microsoft Entra ID über den Identitätsverbund integriert ist.

2. Prashob startet eine neue Browsersitzung und wechselt zur Partner Center-Übersichtsseite (die nicht MFA-geschützt ist). Partner Center leitet Prashob zu Microsoft Entra ID um, um sich anzumelden.

3. Da Wingtip einen Identitätsverbund eingerichtet hat, leitet Die Microsoft Entra-ID Prashob an den Verbundidentitätsanbieter um, um die Anmelde- und MFA-Überprüfung abzuschließen. Nach erfolgreicher Anmeldung und MFA-Überprüfung wird Prashob zurück zur Microsoft Entra-ID und dann zur Partner Center-Übersichtsseite umgeleitet.

4. Prashob versucht, auf eine der MFA-geschützten Partner Center-Seiten zuzugreifen. Da Prashob während der Anmeldung bereits die MFA-Überprüfung abgeschlossen hat, kann er auf die geschützte MFA-Seite zugreifen, ohne dass die MFA-Überprüfung erneut durchlaufen werden muss.

5. Prashob wechselt dann zur Dienstverwaltungsseite, um Benutzer in der Microsoft Entra-ID von Contoso hinzuzufügen. Da Prashob den entra-kompatiblen Authentifizierungsanbieter mit starker Authentifizierung verwendet hat, können sie ohne Probleme auf den Kundenmandanten zugreifen.

Die Empfehlung für Prashob in diesem Beispiel besteht darin, die mehrstufige Microsoft Entra-Authentifizierungslösung oder einen entra-kompatiblen Authentifizierungsanbieter zu verwenden, damit sie den Mandanten des Kunden erfolgreich verwalten können.

Beispiel 3: Partner hat MFA nicht implementiert

1. Ein CSP-Partner namens Fabrikam hat noch keine MFA implementiert. Microsoft empfiehlt, eine von Microsoft Entra ID unterstützte MFA-Lösung zu implementieren.

2. John arbeitet für Fabrikam. Fabrikam hat MFA für benutzer unter dem Fabrikam-Partnermandanten nicht implementiert.

3. John startet eine neue Browsersitzung und wechselt zur Partner Center-Übersichtsseite (die nicht MFA-geschützt ist). Partner Center leitet John an die Microsoft Entra-ID um, um sich anzumelden.

4. Nach der erfolgreichen Anmeldung wird John zurück zur Partner Center-Übersichtsseite umgeleitet, da er die MFA-Überprüfung nicht abgeschlossen hat.

5. John versucht, auf eine der durch MFA geschützten Seiten im Partner Center zuzugreifen. Da John die MFA-Überprüfung nicht abgeschlossen hat, leitet Partner Center John zu Microsoft Entra ID um, um die MFA-Überprüfung abzuschließen. Da John zum ersten Mal MFA abschließen muss, wird John auch aufgefordert, sich für MFA zu registrieren. Nach erfolgreicher MFA-Registrierung und MFA-Überprüfung kann John auf die MFA-geschützte Seite zugreifen.

6. An einem anderen Tag startet John eine neue Browsersitzung, bevor Fabrikam MFA für jeden Benutzer implementiert, und wechselt zur Partner Center-Übersichtsseite (die nicht MFA-geschützt ist). Partner Center leitet John an die Microsoft Entra-ID weiter, um sich ohne MFA-Aufforderung anzumelden.

7. John versucht, auf eine der durch MFA geschützten Seiten im Partner Center zuzugreifen. Da John die MFA-Überprüfung nicht abgeschlossen hat, leitet Partner Center John zu Microsoft Entra ID um, um die MFA-Überprüfung abzuschließen. Da John MFA registriert hat, wird er diesmal nur aufgefordert, die MFA-Überprüfung abzuschließen.

Beispiel 4: Partner hat nicht-Microsoft MFA implementiert, die nicht mit Microsoft Entra kompatibel ist

1. Trent arbeitet für einen CSP mit dem Namen Wingtip. Wingtip hat MFA für alle benutzer unter Wingtip-Partnermandanten implementiert, die nicht von Microsoft MFA in ihrer Cloudumgebung mit bedingtem Zugriff verwendet werden.

2. Trent startet eine neue Browsersitzung und geht zur Partner Center-Übersichtsseite (die nicht MFA-geschützt ist). Partner Center leitet Trent zu Microsoft Entra ID um, um sich anzumelden.

3. Da Wingtip eine nicht von Microsoft stammende MFA-Integration verwendet hat, die nicht mit der Microsoft Entra-ID kompatibel ist und keine starke Authentifizierung aufweist, wird Trent daran gehindert, auf alle MFA-geschützten Seiten und APIs im Partner Center zuzugreifen.

Da Trent auf die geschützten MFA-Seiten zugreift, muss er die MFA mit Strong Auth präsentieren, um Zugriff auf die geschützten MFA-Seiten zu erhalten.

Partner müssen einen Authentifizierungsanbieter verwenden, der mit der Microsoft Entra-ID kompatibel ist, die den Anspruch der Anmeldeinformationsmethode unterstützt ("amr-Anspruch" in access token claims reference – Microsoft Identity Platform, der den tatsächlich während der Authentifizierung bereitgestellten Anmeldeinformationstyp widerspiegelt.

Wir empfehlen CSP-Partnern dringend, MFA zu implementieren, die mit microsoft Entra ID kompatibel ist, um sofort die Sicherheitsgrundwerte Ihres Mandanten zu erhöhen.

Partner Center-API

Die Partner Center-API unterstützt sowohl die reine App-Authentifizierung als auch die Anwendungs- und Benutzerauthentifizierung ( App+Benutzer).

Wenn die App+Benutzerauthentifizierung verwendet wird, erfordert Partner Center eine MFA-Überprüfung. Genauer gesagt, wenn eine Partneranwendung eine API-Anforderung an Partner Center sendet, muss sie ein Zugriffstoken in den Autorisierungsheader der Anforderung einschließen.

Wenn Partner Center eine API-Anforderung mit einem Zugriffstoken empfängt, das mithilfe der App+Benutzerauthentifizierung abgerufen wurde, überprüft die Partner Center-API das Vorhandensein des MFA-Werts im Anspruch "Authentication Method Reference (AMR) ". Sie können einen JWT-Decoder verwenden, um zu überprüfen, ob ein Zugriffstoken den erwarteten AMR-Wert enthält:

{
  "aud": "https://api.partnercenter.microsoft.com",
  "iss": "https://sts.windows.net/df845f1a-7b35-40a2-ba78-6481de91f8ae/",
  "iat": 1549088552,
  "nbf": 1549088552,
  "exp": 1549092452,
  "acr": "1",
  "amr": [
    "pwd",
    "mfa"
  ],
  "appid": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "appidacr": "0",
  "family_name": "Adminagent",
  "given_name": "CSP",
  "ipaddr": "127.0.0.1",
  "name": "Adminagent CSP",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "scp": "user_impersonation",
  "tenant_region_scope": "NA",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
  "unique_name": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "upn": "Adminagent.csp@testtestpartner.onmicrosoft.com",
  "ver": "1.0"
}

• Wenn der Wert vorhanden ist, schließt Partner Center daraus, dass die MFA-Überprüfung abgeschlossen wurde, und verarbeitet die API-Anforderung.

• Wenn der Wert nicht vorhanden ist, lehnt die Partner Center-API die Anforderung mit der folgenden Antwort ab:

  HTTP/1.1 401 Unauthorized - MFA required
  Transfer-Encoding: chunked
  Request-Context: appId=cid-v1:11112222-bbbb-3333-cccc-4444dddd5555
  WWW-Authenticate: Bearer error="invalid_token"
  Date: Thu, 14 Feb 2019 21:54:58 GMT
  

Beim Aufrufen von Partner Center-APIs werden nur App-Zugriffstoken für Vorgänge unterstützt, für die keine GDAP-Rollenzuweisungen in einem Kundenmandanten erforderlich sind.

Weitere bewährte Methoden finden Sie unter API-Authentifizierung und Autorisierung – Übersicht.

Vom Partner delegierte Verwaltung

Partnermandanten sollten granulare delegierte Administratorrechte (GDAP) verwenden, um Kundenressourcen über Microsoft Online Services-Portale (portal.azure.com oder admin.microsoft.com), Befehlszeilenschnittstelle (CLI) und APIs (mit App+Benutzerauthentifizierung) zu verwalten. Weitere Informationen finden Sie unter unterstützten MFA-Optionen.

Verwenden von Dienstportalen

CSP-Partner können ihre Kunden über das Partner Center-Portal über die Dienstverwaltungsschnittstelle verwalten. Partner können zum Kunden navigieren und service management auswählen, um einen bestimmten Dienst für den Kunden verwalten zu können. Partner müssen den Richtlinien für die GDAP-Rolle folgen, um die richtige GDAP-Rolle für die Verwaltung ihrer Kunden zu erhalten.

Beim Zugriff auf Microsoft Online Services-Portale mit partner delegierten Administratorrechten (Admin-On-Behalf-Of) zum Verwalten von Kundenressourcen müssen viele dieser Portale das Partnerkonto interaktiv authentifizieren, wobei der Microsoft Entra-Mandant des Kunden als Authentifizierungskontext festgelegt ist. Das Partnerkonto ist erforderlich, um sich beim Kundenmandanten anzumelden.

Für die Microsoft Entra-ID-Authentifizierung muss ein Benutzer die MFA-Überprüfung abschließen, wenn eine Richtlinie MFA erfordert. Je nachdem, ob es sich bei dem Partnerkonto um eine verwaltete oder eine Verbundidentität handelt, gibt es zwei Möglichkeiten:

• Wenn das Partnerkonto eine verwaltete Identität ist, fordert microsoft Entra-ID den Benutzer direkt auf, die MFA-Überprüfung abzuschließen. Wenn sich das Partnerkonto noch nicht für MFA mit der Microsoft Entra-ID registriert hat, wird der Benutzer aufgefordert, zuerst die MFA-Registrierung abzuschließen.

• Wenn es sich bei dem Partnerkonto um eine Verbundidentität handelt, hängt die Erfahrung davon ab, wie der Partneradministrator den Partnerverbund in der Microsoft Entra-ID konfiguriert hat. Beim Einrichten des Partnerverbunds in der Microsoft Entra-ID kann der Partneradministrator an Microsoft Entra-ID angeben, ob der Verbundidentitätsanbieter MFA unterstützt oder nicht.

  • Wenn ja, leitet Die Microsoft Entra-ID den Benutzer an den Verbundidentitätsanbieter weiter, um die MFA-Überprüfung abzuschließen.
  • Wenn nicht, fordert microsoft Entra-ID den Benutzer direkt auf, die MFA-Überprüfung abzuschließen. Wenn sich das Partnerkonto noch nicht für MFA mit der Microsoft Entra-ID registriert hat, wird der Benutzer aufgefordert, zuerst die MFA-Registrierung abzuschließen.

Die Gesamterfahrung ähnelt dem Szenario, in dem ein Endbenutzermandant MFA für seine Administratoren implementiert hat. Der Kundenmandant hat z. B. die Microsoft Entra-Sicherheitsstandardeinstellungen aktiviert, was erfordert, dass sich alle Konten mit Administratorrechten beim Kundenmandanten mit MFA-Überprüfung anmelden, einschließlich Administrator-Agents und Helpdesk-Agents.

Partner können zu Testzwecken die Microsoft Entra-Sicherheitsstandards im Kundenmandanten aktivieren und dann versuchen, partner granular delegierte Administrationsberechtigungen (GDAP) für den Zugriff auf den Kundenmandanten zu verwenden.

MFA-Registrierungsablauf

Wenn sich das Partnerkonto während der MFA-Überprüfung noch nicht für MFA registriert hat, fordert Microsoft Entra ID den Benutzer auf, zuerst die MFA-Registrierung abzuschließen.

Weitere Informationen zur Microsoft Authenticator-Methode finden Sie unter:

Nachdem der Benutzer "Weiter" ausgewählt hat, wird er aufgefordert, aus einer Liste der Überprüfungsmethoden auszuwählen.

Nach erfolgreicher Registrierung muss der Benutzer die MFA-Überprüfung mit der gewählten Überprüfungsmethode abschließen.

Häufige Probleme

Um zu verstehen, ob Ihre Anforderung gültig ist, überprüfen Sie die Liste der häufig auftretenden Probleme, die von anderen Partnern gemeldet wurden.

Problem 1: Partner benötigen mehr Zeit, um MFA für ihre Partner-Agents zu implementieren

Ein Partner hat noch nicht damit begonnen oder ist noch dabei, MFA für seine Partner-Agents zu implementieren, die Zugriff auf Portale für Microsoft-Onlinedienste benötigen, um Kundenressourcen mit vom Partner delegierten Verwaltungsberechtigungen zu verwalten. Der Partner benötigt mehr Zeit, um die MFA-Implementierung abzuschließen. Handelt es sich um einen gültigen Grund für eine technische Ausnahme?

Antwort: Nein. Ein Partner muss planen, MFA für seine Benutzer zu implementieren, um Unterbrechungen zu vermeiden.

Problem 2: Partner hat MFA nicht implementiert, da sie keinen Zugriff auf die Verwaltung von Kunden benötigen

Ein Partner verfügt über einige Benutzer in seinen Partnermandanten, die keinen Zugriff auf Microsoft Online Services Portale benötigen, um Kundenressourcen mithilfe von Delegierten Administratorrechten von Partnern zu verwalten. Der Partner ist gerade dabei, MFA für diese Benutzer zu implementieren, und benötigt mehr Zeit zum Abschließen des Vorgangs. Handelt es sich um einen gültigen Grund für eine technische Ausnahme?

Antwort: Nein. Da diese Benutzerkonten keine Administratorrechte von Partner zum Verwalten von Kundenressourcen verwenden, müssen sie sich nicht beim Kundenmandanten anmelden. Sie werden nicht von der Microsoft Entra-ID betroffen sein, die eine MFA-Überprüfung während der Anmeldung beim Kundenmandanten erfordert. Alle Benutzer müssen MFA auf Partner Center oder die Kundenarbeitslasten zugreifen, um die Kundenressourcen zu verwalten.

Problem 3: Partner hat MFA für Benutzerkonten nicht implementiert

Ein Partner verfügt über einige Benutzerkonten in seinen Partnermandanten, die von Geräten als Dienstkonten verwendet werden. Diese Konten mit niedriger Berechtigung erfordern keinen Zugriff auf Partner Center oder Microsoft Online Services Portale, um Kundenressourcen mithilfe delegierter Administratorrechte von Partnern zu verwalten. Ist dies ein gültiger Grund für eine technische Ausnahme?

Antwort: Nein. Da diese Benutzerkonten keine Delegierten Administratorrechte von Partner zum Verwalten von Kundenressourcen verwenden, müssen sie sich nicht beim Kundenmandanten anmelden. Sie werden nicht von der Microsoft Entra-ID betroffen sein, die eine MFA-Überprüfung während der Anmeldung beim Kundenmandanten erfordert. Wenn die API oder das Portal app+Benutzerauthentifizierung erforderlich ist, muss jeder Benutzer MFA für die Authentifizierung verwenden.

Problem 4: Partner kann MFA nicht mithilfe der Microsoft Authenticator-App implementieren

Ein Partner hat eine "Clean Desk"-Richtlinie, die es Mitarbeitern nicht erlaubt, ihre persönlichen mobilen Geräte in ihren Arbeitsbereich zu bringen. Ohne Zugriff auf ihre persönlichen mobilen Geräte können die Mitarbeiter die Microsoft Authenticator-App nicht installieren. Dies ist die einzige MFA-Überprüfung, die von Microsoft Entra-Sicherheitsstandarden unterstützt wird. Handelt es sich um einen gültigen Grund für eine technische Ausnahme?

Antwort: Nein. Der Partner sollte die folgende Alternative berücksichtigen, damit ihre Mitarbeiter die MFA-Überprüfung beim Zugriff auf Partner Center weiterhin abschließen können:

• Partner können sich auch für Microsoft Entra ID P1 oder P2 registrieren oder nicht von Microsoft stammende MFA-Lösungen verwenden, die mit Microsoft Entra ID kompatibel sind, die weitere Überprüfungsmethoden bereitstellen können. Weitere Informationen finden Sie unter "Unterstützte Authentifizierungsmethoden".

Problem 5: Partner kann MFA aufgrund der Verwendung von Legacyauthentifizierungsprotokollen nicht implementieren

Ein Partner arbeitet mit einigen Partner-Agents zusammen, die noch ältere Authentifizierungsprotokolle verwenden, die nicht mit MFA kompatibel sind. Beispielsweise verwenden die Benutzer noch Outlook 2010, das auf Legacyauthentifizierungsprotokollen basiert. Wenn MFA für diese Partner-Agents aktiviert wird, wird die Verwendung von Legacyauthentifizierungsprotokollen unterbrochen. Handelt es sich um einen gültigen Grund für eine technische Ausnahme?

Antwort: Nein. Partner werden ermutigt, sich von der Verwendung von Legacyauthentifizierungsprotokollen aufgrund potenzieller Sicherheitsauswirkungen zu entfernen, da diese Protokolle nicht mit der MFA-Überprüfung geschützt werden können und wesentlich anfälliger für die Kompromittierung von Anmeldeinformationen sind. Es wird empfohlen, alle älteren Authentifizierungen nicht mehr zu verwenden und Sicherheitsstandardwerte oder bedingten Zugriff zu verwenden. Wenn Sie sich darauf vorbereiten möchten, die Legacyauthentifizierung zu entfernen, überprüfen Sie die Anmeldungen mithilfe einer älteren Authentifizierungsarbeitsmappe und die Anleitungen zum Blockieren der Legacyauthentifizierung.

Um den neuesten Plan für die Unterstützung der Legacyauthentifizierung für Outlook zu verstehen, lesen Sie den Beitrag über die Standardauthentifizierung und Exchange Online , und folgen Sie dem Exchange-Teamblog , um die bevorstehenden Neuigkeiten zu erhalten.

Problem 6: Partner hat eine nicht von Microsoft stammende MFA implementiert, die von der Microsoft Entra-ID nicht erkannt wird

Ein Partner hat MFA für ihre Benutzer mithilfe einer nicht von Microsoft stammenden MFA-Lösung implementiert. Der Partner kann die Nicht-Microsoft MFA-Lösung jedoch nicht ordnungsgemäß konfigurieren, um die MFA-ID an Microsoft Entra-ID weiterzuleiten, dass die MFA-Überprüfung während der Benutzerauthentifizierung abgeschlossen wurde. Handelt es sich um einen gültigen Grund für eine technische Ausnahme?

Antwort: Nein, Partner müssen einen Authentifizierungsanbieter verwenden, der mit der Microsoft Entra-ID kompatibel ist, die den Anspruch auf Anmeldeinformationen ("AMR"), Zugriffstokenansprüchereferenz – Microsoft Identity Platform, die den tatsächlichen Anmeldeinformationstyp während der Authentifizierung unterstützt.

Wir empfehlen Ihnen dringend, MFA zu implementieren, die sofort mit Microsoft Entra ID kompatibel ist, um die Sicherheitsgrundwerte Ihres Mandanten zu erhöhen.

Zugehöriger Inhalt

• Status der Partnersicherheitsanforderungen