Neuerungen bei der Authentifizierung

Microsoft erweitert und ändert regelmäßig die Features und Funktionen von Microsoft Identitätsplattform, um Sicherheit, Benutzerfreundlichkeit und Standardkonformität zu verbessern.

Sofern nicht anders angegeben, gelten die hier beschriebenen Änderungen nur für Anwendungen, die nach dem angegebenen Gültigkeitsdatum der Änderung registriert wurden.

Überprüfen Sie diesen Artikel regelmäßig, um Informationen zu folgenden Änderungen zu erhalten:

• Bekannte Probleme und Korrekturen
• Protokolländerungen
• Veraltete Funktionen

August 2024

Verbundidentitätsanmeldeinformationen verwenden jetzt den Abgleich zwischen Groß- und Kleinschreibung.

Gültigkeitsdatum: September 2024

Protokoll betroffen: Workload-Identitätsverbund

Ändern

Zuvor wurde beim Abgleichen der Verbundidentitäts-Anmeldeinformationen (FIC) issuersubjectund audience der Werte mit den entsprechenden issuerWerten subjectund audience Werten, die im Token enthalten sind, verwendet, das von einem externen IdP an die Microsoft Entra-ID gesendet wurde, die Groß-/Kleinschreibung wird verwendet. Um Kunden eine präzisere Kontrolle zu bieten, wechseln wir zum Erzwingen der Groß-/Kleinschreibung.

Ungültiges Beispiel:

• Tokenbetreff: repo:contoso/contoso-org:ref:refs/heads/main
• FIC-Betreff: repo:Contoso/Contoso-Org:ref:refs/heads/main

Bei diesen beiden Betreffwerten wird die Groß-/Kleinschreibung nicht beachtet, daher schlägt die Überprüfung fehl. Auf und audience Validierung wird derselbe Mechanismus angewendetissuer.

Diese Änderung wird zunächst auf Anwendungen oder verwaltete Identitäten angewendet, die nach August 14th, 2024dem Erstellen erstellt wurden. Inaktive Anwendungen oder verwaltete Identitäten, die durch null Workload Identity Federation-Anforderungen bestimmt werden, die von der genannten Anwendung oder verwalteten Identität zwischen dem Zeitraum August 1st, 2024 August 31st, 2024vorgenommen wurden, sind erforderlich, um den Abgleich September 27th, 2024zwischen Groß- und Kleinschreibung zu verwenden. Bei aktiven Anwendungen erfolgt die Berücksichtigung der Groß-/Kleinschreibung zu einem späteren Zeitpunkt, der kommuniziert wird.

Um Fehler aufgrund der Groß-/Kleinschreibung besser hervorzuheben, wird die Fehlermeldung neu für AADSTS700213. Sie wird jetzt angeben;

`AADSTS700213: No matching federated identity record found for presented assertion subject '{subject}'. Please note that matching is done using a case-sensitive comparison. Check your federated identity credential Subject, Audience, and Issuer against the presented assertion.` 

Der Platzhalter '{subject}' stellt den Wert des Antragstelleranspruchs bereit, der im Token enthalten ist, das von der externen IDP an die Microsoft Entra-ID gesendet wird. Diese Fehlervorlage wird auch für Fehler issuer bei Der Groß- und audience Kleinschreibung verwendet. Wenn dieser Fehler auftritt, sollten Sie die Verbundidentitäts-Anmeldeinformationen finden, die dem issuersubjectFehler entsprechen oder audience im Fehler aufgeführt sind, und bestätigen Sie, dass die entsprechenden Werte aus sicht der Groß-/Kleinschreibung gleichwertig sind. Wenn ein Konflikt vorliegt, müssen Sie den aktuellen issuersubject, oder audience Wert im FIC durch den , oder audience den Wert ersetzen, der issuersubjectin der Fehlermeldung enthalten war.

Juni 2024

Anwendungen müssen in einem Verzeichnis registriert werden.

Gültig ab: Juni 2024

Betroffene Endpunkte: v2.0 und v1.0

Betroffenes Protokoll: Alle Flows

Ändern

Beim Registrieren einer Anwendung mit der Microsoft Entra-App-Registrierungsoberfläche konnten sie sich zuvor entscheiden, ob der Benutzer mit ihrem persönlichen Microsoft-Konto (MSA) angemeldet war, die Anwendung nur ihrem persönliches Konto zuzuordnen. Dies bedeutet, dass die Anwendung keinem Verzeichnis zugeordnet oder enthalten wäre (auch als "Mandant" oder "Organisation" bezeichnet). Ab Juni 2024 müssen alle Anwendungen in einem Verzeichnis registriert werden. Dies kann ein vorhandenes Verzeichnis oder ein neues Verzeichnis sein, das der persönliche Microsoft-Kontobenutzer erstellt, um seine Microsoft Entra-Anwendungen und andere Microsoft-Ressourcen zu speichern. Benutzer können problemlos ein neues Verzeichnis für diesen Zweck erstellen, indem Sie dem Microsoft 365-Entwicklerprogramm beitreten oder sich für Azure registrieren.

Das Registrieren einer Anwendung in einem Verzeichnis, anstatt sie nur einem persönliches Konto zuzuordnen, hat verschiedene Vorteile. Dazu gehören:

• In einem Verzeichnis registrierte Anwendungen stehen ihnen weitere Features zur Verfügung, z. B. die Möglichkeit, der App mehrere Besitzer hinzuzufügen, und die Möglichkeit, die App zu überprüfen .
• Die Anwendung befindet sich an demselben Ort wie andere Microsoft-Ressourcen, die der Entwickler verwendet, z. B. Azure-Ressourcen.
• Die Anwendung erhält verbesserte Resilienzvorteile.

Dies wirkt sich nicht auf vorhandene Anwendungen aus, einschließlich vorhandener Anwendungen, die nur einem persönliches Konto zugeordnet sind. Es ist nur die Möglichkeit betroffen, neue Anwendungen zu registrieren.

Oktober 2023

Aktualisierte RemoteConnect UX-Eingabeaufforderung

Gültig ab: Oktober 2023

Betroffene Endpunkte: v2.0 und v1.0

Betroffenes Protokoll: RemoteConnect

RemoteConnect ist ein geräteübergreifender Flow, der für Microsoft-Authentifizierungsbroker und Microsoft Intune-bezogene Szenarien mit primären Aktualisierungstoken verwendet wird. Um Phishingangriffe zu verhindern, empfängt der RemoteConnect-Fluss aktualisierte UX-Sprache, um herauszurufen, dass das Remotegerät (das Gerät, das den Fluss initiiert hat) nach erfolgreichem Abschluss des Flusses auf alle Anwendungen zugreifen kann, die von Ihrer Organisation verwendet werden.

Die angezeigte Eingabeaufforderung sieht ungefähr wie folgt aus:

Juni 2023

Weglassen von E-Mail-Ansprüchen an einen nicht überprüften Domänenbesitzer

Gültig ab: Juni 2023

Betroffene Endpunkte: v2.0 und v1.0

Änderung

Bei Anwendungen mit mehreren Mandanten werden E-Mails, die nicht durch den Domänenbesitzer überprüft sind, standardmäßig ausgelassen, wenn der optionale email-Anspruch in einer Token-Nutzlast angefordert wird.

Eine E-Mail gilt unter folgenden Umständen als vom Domänenbesitzer überprüft:

1. Die Domäne gehört zu dem Mandanten, in dem sich das Benutzerkonto befindet, und der Mandantenadministrator hat die Domäne überprüft.
2. Die E-Mail stammt von einem Microsoft-Konto (MSA).
3. Die E-Mail stammt von einem Google-Konto.
4. Die E-Mail wurde für die Authentifizierung mit dem One-Time-Passcode (OTP) verwendet.

Beachten Sie auch, dass Facebook- und SAML/WS-Fed-Konten keine verifizierten Domains aufweisen.

Mai 2023

Die Rolle „Power BI-Administrator“ wird in „Fabric-Administrator“ umbenannt.

Gültig ab: Juni 2023

Betroffene Endpunkte:

• List roleDefinitions – Microsoft Graph v1.0
• List directoryRoles – Microsoft Graph v1.0

Ändern

Die Power BI-Administratorrolle wird in Fabric-Administrator umbenannt.

Am 23. Mai 2023 stellte Microsoft Microsoft Fabric vor, das eine Data Factory-basierte Datenintegrationsumgebung, Synapse-gestützte Datentechnik, Data Warehousing, Data Science und Echtzeitanalysen sowie Business Intelligence (BI) mit Power BI bietet – all das gehostet in einer Data Lake-orientierten SaaS-Lösung. Die Mandanten- und Kapazitätsverwaltung für diese Umgebungen werden im Fabric-Verwaltungsportal (zuvor Power BI-Verwaltungsportal) zentralisiert.

Ab Juni 2023 wird die Power BI-Administratorrolle in Fabric-Administrator umbenannt, um den sich ändernden Umfang und die Verantwortung dieser Rolle auszurichten. Alle Anwendungen, einschließlich Microsoft Entra ID, Microsoft Graph APIs, Microsoft 365 und GDAP, werden im Laufe der nächsten Wochen den neuen Rollennamen anzeigen.

Zur Erinnerung: In Anwendungscode und -skripts sollten keine Entscheidungen auf Grundlage eines Rollen- oder Anzeigenamens getroffen werden.

Dezember 2021

AD FS-Benutzer erhalten zusätzliche Anmeldeaufforderungen, um sicherzustellen, dass der richtige Benutzer angemeldet ist.

Gültig ab: Dezember 2021

Betroffene Endpunkte: integrierte Windows-Authentifizierung

Betroffenes Protokoll: integrierte Windows-Authentifizierung

Änderung

Wenn ein Benutzer heute zur Authentifizierung an AD FS gesendet wird, wird er automatisch bei jedem Konto angemeldet, das bereits über eine Sitzung mit AD FS verfügt. Die automatische Anmeldung erfolgt auch dann, wenn sich der Benutzer bei einem anderen Benutzerkonto anmelden wollte. Um die Häufigkeit dieser fehlerhaften Anmeldung zu verringern, wird Microsoft Entra ID ab Dezember den prompt=login-Parameter an AD FS senden, wenn der Web Account Manager in Windows während der Anmeldung Microsoft Entra ID ein login_hint zur Verfügung stellt, das angibt, dass ein bestimmter Benutzender für die Anmeldung gewünscht wird.

Wenn die oben genannten Voraussetzungen erfüllt sind (WAM wird verwendet, um den Benutzenden zur Anmeldung an Microsoft Entra ID zu senden, ein login_hint ist enthalten, und die AD FS-Instanz für die Domäne des Benutzenden unterstützt prompt=login), wird der Benutzende nicht stillschweigend angemeldet, sondern aufgefordert, einen Benutzernamen anzugeben, um die Anmeldung bei AD FS fortzusetzen. Wenn Benutzer sich bei ihrer vorhandenen AD FS-Sitzung anmelden möchten, können sie die Option "Fortfahren als aktueller Benutzer" auswählen, die unter der Anmeldeaufforderung angezeigt wird. Andernfalls können sie mit dem Benutzernamen fortfahren, mit dem sie sich anmelden möchten.

Diese Änderung wird im Dezember 2021 über mehrere Wochen hinweg eingeführt. Dies ändert das Anmeldeverhalten nicht für:

• Anwendungen, die IWA direkt verwenden
• Anwendungen mit OAuth
• Domänen, die nicht im Verbund mit einer AD FS-Instanz enthalten sind

Oktober 2021

Der Fehler 50105 wurde behoben, damit während der interaktiven Authentifizierung interaction_required nicht zurückgegeben wird.

Gültig ab: Oktober 2021

Betroffene Endpunkte: v2.0 und v1.0

Betroffenes Protokoll: Alle Benutzerabläufe für Apps, für die eine Benutzerzuweisung erforderlich ist

Änderung

Fehler 50105 (die aktuelle Bezeichnung) wird ausgegeben, wenn nicht zugewiesene Benutzer*innen versuchen, sich bei einer App zu anzumelden, für die Administrator*innen eine Benutzerzuweisung als erforderlich markiert haben. Dies ist ein gängiges Zugriffssteuerungsmuster, und Benutzer*innen müssen häufig Administrator*innen finden, um die Zuweisung zum Entsperren des Zugriffs anzufordern. Dabei gab es einen Fehler, der endlose Schleifen in gut codierten Anwendungen verursachte, die die interaction_required-Fehlerantwort ordnungsgemäß verarbeiteten. interaction_required weist eine Anwendung an, eine interaktive Authentifizierung durchzuführen, aber auch danach würde Microsoft Entra ID eine interaction_required-Fehlerantwort zurückgeben.

Das Fehlerszenario wurde aktualisiert, sodass die App während der nicht-interaktiven Authentifizierung (bei der prompt=none zum Ausblenden von UX verwendet wird) angewiesen wird, die interaktive Authentifizierung mithilfe einer interaction_required-Fehlerantwort durchzuführen. Bei der anschließenden interaktiven Authentifizierung hält Microsoft Entra ID den Benutzenden nun fest und zeigt direkt eine Fehlermeldung an, um eine Schleife zu verhindern.

Zur Erinnerung: Ihr Anwendungscode sollte keine Entscheidungen basierend auf Fehlercodezeichenfolgen wie AADSTS50105 treffen. Befolgen Sie stattdessen unsere Fehlerbehandlungsanleitungen und verwenden Sie die standardisierten Authentifizierungsantworten wie interaction_required und login_required, die sich im Standardfeld error der Antwort befinden. Die anderen Antwortfelder sind nur für Benutzer vorgesehen, die Probleme beheben möchten.

Sie können den aktuellen Text des Fehlers 50105 und mehr im Dienst für Fehlersuche überprüfen: https://login.microsoftonline.com/error?code=50105.

Der AppId-URI in Anwendungen mit einem Mandanten erfordert die Verwendung des Standardschemas oder überprüfter Domänen.

Gültig ab: Oktober 2021

Betroffene Endpunkte: v2.0 und v1.0

Betroffenes Protokoll: Alle Flows

Ändern

Bei Anwendungen mit einem Mandanten wird beim Hinzufügen oder Aktualisieren des AppId-URIs überprüft, ob die Domäne im HTTPS-Schema-URI in der Liste der verifizierten Domänen im Kundenmandanten aufgeführt ist oder ob der Wert das von Microsoft Entra ID bereitgestellte Standardschema (api://{appId}) verwendet. Dies könnte verhindern, dass Anwendungen einen AppId-URI hinzufügen, wenn sich die Domäne nicht in der Liste der überprüften Domänen befindet oder der Wert nicht das Standardschema verwendet. Weitere Informationen zu überprüften Domänen finden Sie in der Dokumentation Benutzerdefinierte Domänen.

Die Änderung wirkt sich nicht auf vorhandene Anwendungen aus, die nicht überprüfte Domänen in ihrem AppID-URI verwenden. Die Überprüfung erfolgt nur für neue Anwendungen oder wenn eine vorhandene Anwendung einen Bezeichner-URI aktualisiert oder der identifierUri-Sammlung einen neuen hinzufügt. Die neuen Einschränkungen gelten nur für URIs, die der identifierUris-Sammlung einer App nach dem 15. Oktober 2021 hinzugefügt wurden. AppId-URIs, die sich bereits in der identifierUris-Sammlung einer Anwendung befinden, wenn die Einschränkung am 15. Oktober 2021 gültig wird, funktionieren auch dann weiterhin, wenn Sie dieser Sammlung neue URIs hinzufügen.

Wenn eine Anforderung bei der Überprüfung fehlschlägt, gibt die Anwendungs-API für die Erstellung/Aktualisierung 400 badrequest an den Client zurück, womit HostNameNotOnVerifiedDomain angegeben wird.

Für Anwendungs-IDs auf Basis von API- oder HTTP-Schemas werden die folgenden URI-Formate unterstützt. Ersetzen Sie die Platzhalterwerte anhand der Liste, die im Anschluss an die Tabelle aufgeführt ist.

Unterstützte Anwendungs-ID URI-Formate	URIs für Beispiel-App-IDs
api://<appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi

• <appId>: Die AppId-Eigenschaft (Anwendungsbezeichner) des Anwendungsobjekts.
• <string>: Der Zeichenfolgenwert für den Host oder das API-Pfadsegment.
• <tenantId>: Eine von Azure generierte GUID, die den Mandanten in Azure repräsentiert.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, wobei <tenantInitialDomain> der anfängliche Domänenname ist, den der Mandantenersteller bei der Mandantenerstellung angegeben hat.
• <verifiedCustomDomain> – eine überprüfte benutzerdefinierte Domäne, die für Ihren Microsoft Entra-Mandanten konfiguriert ist.

August 2021

Bedingter Zugriff wird nur für explizit angeforderte Bereiche ausgelöst.

Gültig ab: August 2021, wobei ab April ein schrittweises Rollout erfolgt.

Betroffene Endpunkte: v2.0

Betroffenes Protokoll: Alle Flows, in denen dynamische Einwilligung verwendet wird

Anwendungen, in denen derzeit dynamische Einwilligung verwendet wird, werden alle Berechtigungen erteilt, für die sie die Einwilligung erhalten haben, auch wenn sie im Parameter scope nicht namentlich angefordert wurden. Eine App, die nur user.read anfordert, kann aber mit Einwilligung für files.read dazu gezwungen werden, die z. B. für files.read zugewiesene bedingte Zugriffsanforderung zu übergeben.

Um die Anzahl der unnötigen Eingabeaufforderungen zu bedingtem Zugriff zu reduzieren, ändert Microsoft Entra ID die Art und Weise, wie Bereiche für Anwendungen bereitgestellt werden, sodass nur explizit angeforderte Bereiche den bedingten Zustand auslösen. Anwendungen, die sich auf das frühere Verhalten von Microsoft Entra ID verlassen, alle Bereiche in das Token aufzunehmen – ob angefordert oder nicht – können aufgrund fehlender Bereiche nicht funktionieren.

Apps erhalten jetzt Zugriffstoken mit einer Kombination von Berechtigungen: angeforderte Token sowie bewilligte Berechtigungen, für die jedoch keine Eingabeaufforderung für bedingten Zugriff erforderlich sind. Der Zugriffsbereich für das Token wird im Parameter scope der Tokenantwort angegeben.

Diese Änderung wird für alle Apps durchgeführt, mit Ausnahme derjenigen, die eine beobachtete Abhängigkeit von diesem Verhalten aufweisen. Entwickler erhalten entsprechende Informationen, wenn sie von dieser Änderung ausgenommen sind, da sie möglicherweise von zusätzlichen Eingabeaufforderungen für bedingten Zugriff abhängig sind.

Beispiele

Eine App verfügt über die Einwilligung für user.read , files.readwrite und tasks.read. Richtlinien für bedingten Zugriff werden nur auf files.readwrite und nicht auf die anderen beiden Berechtigungen angewendet. Wenn eine App eine Tokenanforderung für scope=user.read ausführt und der derzeit angemeldete Benutzer keine Richtlinien für bedingten Zugriff übergeben hat, gilt das resultierende Token für die Berechtigungen user.read und tasks.read. tasks.read ist enthalten, da die App über die Einwilligung für diese Berechtigung verfügt und für sie keine Richtlinie für bedingten Zugriff erzwungen werden muss.

Wenn die App dann scope=files.readwrite anfordert, wird der bedingte Zugriff ausgelöst, den der Mandant erfordert. Dies erzwingt, dass in der App eine interaktive Authentifizierungsanforderung angezeigt wird, mit der die Richtlinie für bedingten Zugriff erfüllt werden kann. Das zurückgegebene Token enthält alle drei Bereiche.

Wenn die Anwendung dann eine letzte Anforderung für einen der drei Bereiche stellt (z. B. scope=tasks.read), erkennt Microsoft Entra ID, dass der Benutzende die Richtlinien für den bedingten Zugriff, die für files.readwrite erforderlich sind, bereits ausgefüllt hat, und stellt erneut ein Token mit allen drei Berechtigungen aus.

Juni 2021

Der UX-Gerätecodeflow enthält jetzt eine Eingabeaufforderung zur App-Bestätigung

Gültig ab: Juni 2021.

Betroffene Endpunkte: v2.0 und v1.0

Betroffenes Protokoll: Der Gerätecodeflow

Um Phishingangriffe zu verhindern, enthält der Gerätecodeflow jetzt eine Aufforderung, die überprüft, ob sich der Benutzer bei der erwarteten App anmeldet.

Die angezeigte Eingabeaufforderung sieht wie die folgende aus:

Mai 2020

Fehlerbehebung: Microsoft Entra ID kodiert den Status-Parameter nicht mehr doppelt in die URL

Gültig ab: Mai 2021

Betroffene Endpunkte: v1.0 und v2.0

Betroffenes Protokoll: alle Flows, die den /authorize Endpunkt aufrufen (impliziter Fluss-und Autorisierungs-Code-Fluss)

Ein Fehler wurde in der Microsoft Entra-Autorisierungsantwort gefunden und behoben. Während der /authorize Authentifizierung wird der state-Parameter aus der Anforderung in die Antwort eingeschlossen, um den App-Status beizubehalten und CSRF-Angriffe zu verhindern. Microsoft Entra ID hat den state-Parameter fälschlicherweise URL-kodiert, bevor er in die Antwort eingefügt wurde, wo er noch einmal kodiert wurde. Dies würde dazu führen, dass Anwendungen die Antwort von Microsoft Entra ID fälschlicherweise ablehnen.

Microsoft Entra ID wird diesen Parameter nicht mehr doppelt kodieren, so dass Anwendungen das Ergebnis korrekt analysieren können. Diese Änderung wird für alle Anwendungen vorgenommen.

Azure Government-Endpunkte werden geändert

Gültigkeitsdatum: 5. Mai 2020 (Fertigstellung Juni 2020)

Betroffene Endpunkte: All

Betroffenes Protokoll: Alle Flows

Am 1. Juni 2018 wurde die offizielle Microsoft Entra Authority für Azure Government von https://login-us.microsoftonline.com zu https://login.microsoftonline.us geändert. Diese Änderung gilt auch für Microsoft 365 GCC High und DoD, die Azure Government Microsoft Entra ID ebenfalls bedient. Wenn Sie eine Anwendung in einem US Government-Mandanten besitzen, müssen Sie Ihre Anwendung aktualisieren, damit die Benutzer am .us-Endpunkt angemeldet werden.

Am 5. Mai 2020 wird Microsoft Entra ID damit beginnen, die Änderung des Endpunkts durchzusetzen und Government-Benutzender daran zu hindern, sich über den öffentlichen Endpunkt (microsoftonline.com) bei Anwendungen anzumelden, die in den Mandanten der US-Regierung gehostet werden. Bei betroffenen Apps wird der Fehler AADSTS900439 - USGClientNotSupportedOnPublicEndpoint angezeigt. Dieser Fehler weist darauf hin, dass die App versucht, einen US Government-Benutzer beim öffentlichen Cloudendpunkt anzumelden. Wenn sich Ihre App in einem Mandanten in der öffentlichen Cloud befindet und US Government-Benutzer unterstützen soll, müssen Sie Ihre App zur expliziten Unterstützung aktualisieren. Dies setzt möglicherweise das Erstellen einer neuen App-Registrierung in der US Government-Cloud voraus.

Die Erzwingung dieser Änderung erfolgt über einen schrittweisen Rollout, der sich danach richtet, wie oft sich Benutzer der US Government-Cloud bei der Anwendung anmelden. Bei Apps, die US Government-Benutzer eher selten anmelden, erfolgt die Durchsetzung zuerst. Apps, die US Government-Benutzer sehr häufig anmelden, sind zuletzt von der Durchsetzung betroffen. Wir gehen davon aus, dass die Erzwingung für alle Apps im Juni 2020 abgeschlossen ist.

Weitere Einzelheiten finden Sie im Azure Government-Blogbeitrag zu dieser Migration.

März 2020

Benutzerkennwörter werden auf 256 Zeichen beschränkt.

Gültigkeitsdatum: 13. März 2020

Betroffene Endpunkte: All

Betroffenes Protokoll: Alle Benutzerflows

Benutzende mit Kennwörtern, die länger als 256 Zeichen sind und sich direkt bei Microsoft Entra ID anmelden (nicht bei einem föderierten IDP wie AD FS), werden aufgefordert, ihre Kennwörter zu ändern, bevor sie sich anmelden können. Administrator*innen erhalten möglicherweise Anforderungen zum Zurücksetzen von Benutzerkennwörtern.

Der Fehler in den Anmeldeprotokollen sieht ähnlich aus wie AADSTS 50052: InvalidPasswordExceedsMaxLength.

Meldung: The password entered exceeds the maximum length of 256. Please reach out to your admin to reset the password.

Abhilfe:

Die Benutzer können sich nicht anmelden, da das Kennwort die zulässige maximale Länge überschreitet. Benutzer sollten sich an den Administrator wenden, damit das Kennwort zurückgesetzt wird. Wenn SSPR für den zugehörigen Mandanten aktiviert ist, können Benutzer das Kennwort über den Link „Kennwort vergessen“ zurücksetzen.

Februar 2020

An jede HTTP-Umleitung vom Endpunkt der Anmeldung werden leere Fragmente angehängt.

Gültigkeitsdatum: 8. Februar 2020

Betroffene Endpunkte: v1.0 und v2.0

Betroffenes Protokoll: OAuth-und OIDC-Flows, die response_type=query verwenden. Dies betrifft in einigen Fällen den Autorisierungscodeflow und den impliziten Flow.

Wenn eine Authentifizierungsantwort von login.microsoftonline.com über die HTTP-Umleitung an eine Anwendung gesendet wird, hängt der Dienst ein leeres Fragment an die Antwort-URL an. Dadurch wird eine Klasse von Umleitungsangriffen verhindert, indem sichergestellt wird, dass der Browser jedes vorhandene Fragment in der Authentifizierungsanforderung bereinigt. Keine App sollte eine Abhängigkeit von diesem Verhalten aufweisen.

August 2019

POST-Formularsemantik wird strenger erzwungen – Leerzeichen und Anführungszeichen werden ignoriert.

Gültigkeitsdatum: 2. September 2019

Betroffene Endpunkte: v1.0 und v2.0

Betroffenes Protokoll: Überall dort, wo POST verwendet wird (Clientanmeldeinformationen, Einlösung von Autorisierungscodes, ROPC, OBO und Einlösung von Aktualisierungstoken)

Seit dem 2. September 2019 werden Authentifizierungsanforderungen, die die POST-Methode verwenden, mit strengeren HTTP-Standards überprüft. Insbesondere werden Leerzeichen und doppelte Anführungszeichen (") nicht mehr aus den Anforderungsformularwerten entfernt. Es ist nicht zu erwarten, dass diese Änderungen bestehende Clients beeinträchtigen. Sie stellen sicher, dass an Microsoft Entra ID gesendete Anforderungen jedes Mal zuverlässig bearbeitet werden. In Zukunft (siehe oben) planen wir, doppelte Parameter zusätzlich abzulehnen und die BOM innerhalb von Anforderungen zu ignorieren.

Beispiel:

Heute wird ?e= "f"&g=h wie ?e=f&g=h analysiert, also e == f. Durch diese Änderung würde die Analyse jetzt so durchgeführt, dass e == "f". Es ist unwahrscheinlich, dass es sich dabei um ein gültiges Argument handelt, und die Anforderung würde jetzt fehlschlagen.

Juli 2019

Reine App-Token für Anwendungen mit einem einzigen Mandanten werden nur ausgegeben, wenn die Client-App im Ressourcenmandanten vorhanden ist.

Gültigkeitsdatum: 26. Juli 2019

Betroffene Endpunkte:v1.0 und v2.0

Betroffenes Protokoll:Clientanmeldeinformationen (reine App-Token)

Am 26. Juli 2019 wurde eine Sicherheitsänderung wirksam, mit der die Ausstellung von reinen App-Token (über die Zuweisung von Clientanmeldeinformationen) geändert wurde. Bisher konnten Anwendungen Token zum Aufruf einer beliebigen anderen App abrufen, unabhängig vom Vorhandensein im Mandanten oder von genehmigten Rollen für diese Anwendung. Dieses Verhalten wurde aktualisiert, sodass für Ressourcen (gelegentlich auch Web-APIs genannt) mit einem einzigen Mandanten (Standard) die Clientanwendung jetzt innerhalb des Ressourcenmandanten vorliegen muss. Eine vorhandene Zustimmung zwischen Client und API ist weiterhin nicht erforderlich. Ferner müssen Apps weiterhin eigene Autorisierungsüberprüfungen durchführen, um sicherzustellen, dass ein roles-Anspruch vorhanden ist und den erwarteten Wert für die API enthält.

Die Fehlermeldung für dieses Szenario lautet aktuell folgendermaßen:

The service principal named <appName> was not found in the tenant named <tenant_name>. This can happen if the application has not been installed by the administrator of the tenant.

Um dieses Problem zu beseitigen, verwenden Sie die Benutzeroberfläche für die Administratorzustimmung, um den Dienstprinzipal der Clientanwendung in Ihrem Mandanten zu erstellen, oder erstellen Sie diesen manuell. Durch diese Anforderung wird sichergestellt, dass der Mandant der App die Berechtigung zum Betrieb innerhalb des Mandanten erteilt hat.

Beispielanforderung

https://login.microsoftonline.com/contoso.com/oauth2/authorize?resource=https://gateway.contoso.com/api&response_type=token&client_id=00001111-aaaa-2222-bbbb-3333cccc4444&... In diesem Beispiel lautet der Ressourcenmandant (Autorität) contoso.com, die Ressourcen-App ist eine Einzelmandanten-App namens gateway.contoso.com/api für den Contoso-Mandanten, und die Client-App ist 00001111-aaaa-2222-bbbb-3333cccc4444. Wenn die Client-App über einen Dienstprinzipal innerhalb von contoso.com verfügt, kann diese Anforderung fortgesetzt werden. Falls nicht, ist die Anforderung nicht erfolgreich, und es wird der oben gezeigte Fehler gemeldet.

Wenn es sich bei der Contoso-Gateway-App um eine mehrinstanzenfähige App handelt, wird die Anforderung unabhängig davon fortgesetzt, ob die Client-App über einen Dienstprinzipal innerhalb von contoso.com verfügt.

Umleitungs-URIs können jetzt Abfragezeichenfolgenparameter enthalten

Gültigkeitsdatum: 22. Juli 2019

Betroffene Endpunkte: v1.0 und v2.0

Betroffenes Protokoll: Alle Flows

Gemäß RFC 6749 können Microsoft Entra-Anwendungen jetzt Redirect-URIs (Antwort-URIs) mit statischen Abfrageparametern (wie z. B. https://contoso.com/oauth2?idp=microsoft) für OAuth 2.0-Anforderungen registrieren und verwenden. Dynamische Umleitungs-URIs sind weiterhin untersagt, weil sie ein Sicherheitsrisiko darstellen und nicht dazu verwendet werden können, statische Informationen über eine Authentifizierungsanforderung hinweg beizubehalten. Verwenden Sie in diesem Fall den state-Parameter.

Der statische Abfrageparameter wird, ebenso wie jeder andere Bestandteil des Umleitungs-URI, einem Zeichenfolgenabgleich unterzogen. Wenn keine registrierte Zeichenfolge vorhanden ist, die dem URI-decodierten Umleitungs-URI entspricht, wird die Anforderung abgelehnt. Wird der Antwort-URI in der App-Registrierung gefunden, wird die gesamte Zeichenfolge – einschließlich des statischen Abfrageparameters – zum Umleiten des Benutzers verwendet.

Die Benutzeroberfläche zur App-Registrierung im Azure-Portal blockiert zum aktuellen Zeitpunkt (Ende Juli 2019) weiterhin Abfrageparameter. Sie können das Anwendungsmanifest jedoch manuell bearbeiten, um Abfrageparameter in Ihre App einzufügen und diese zu testen.

März 2019

In der Schleife befindliche Clients werden unterbrochen

Gültigkeitsdatum: 25. März 2019

Betroffene Endpunkte: v1.0 und v2.0

Betroffenes Protokoll: Alle Flows

Clientanwendungen können manchmal ein unerwünschtes Verhalten aufweisen und über einen kurzen Zeitraum Hunderte derselben Anmeldeanforderung ausgeben. Diese Anforderungen können erfolgreich oder nicht erfolgreich sein, aber sie alle tragen zu einer schlechten Benutzererfahrung und erhöhten Workloads für den IDP bei, was zu einer höheren Latenz für alle Benutzer und einer geringeren Verfügbarkeit des IDP führt. Die Ausführung dieser Anwendungen erfolgt außerhalb der Grenzen der normalen Nutzung. Sie sollten aktualisiert werden, um das ordnungsgemäße Verhalten aufzuweisen.

Clients, die doppelte Anforderungen ausgeben, erhalten einen invalid_grant-Fehler: AADSTS50196: The server terminated an operation because it encountered a loop while processing a request.

Das Verhalten der meisten Clients muss nicht geändert werden, um diesen Fehler zu vermeiden. Von diesem Fehler sind nur falsch konfigurierte Clients betroffen, also Clients ohne Zwischenspeicherung von Token oder Clients, die sich bereits in Prompt-Schleifen befinden. Clients werden pro Instanz lokal (über Cookie) anhand der folgenden Faktoren nachverfolgt:

• Benutzerhinweis, falls vorhanden

• Angeforderte Bereiche oder Ressourcen

• Client-ID

• Umleitungs-URI

• Antworttyp und -modus

Apps, die innerhalb kurzer Zeit (5 Minuten) mehrere Anforderungen (15 und mehr) senden, erhalten einen invalid_grant-Fehler, der erklärt, dass sie sich in einer Schleife befinden. Die angeforderten Token haben eine ausreichend lange Lebensdauer (mindestens 10 Minuten, standardmäßig 60 Minuten), sodass in diesem Zeitraum keine wiederholten Anforderungen erforderlich sind.

Alle Apps sollten invalid_grant verarbeiten, indem sie eine interaktive Eingabeaufforderung anzeigen, statt automatisch ein Token anzufordern. Um diesen Fehler zu vermeiden, sollte für die Clients sichergestellt werden, dass sie die empfangenen Token ordnungsgemäß zwischenspeichern.

Oktober 2018

Autorisierungscodes können nicht mehr wiederverwendet werden.

Gültigkeitsdatum: 15. November 2018

Betroffene Endpunkte: v1.0 und v2.0

Betroffenes Protokoll:Codeflow

Ab dem 15. November 2018 wird Microsoft Entra ID keine zuvor verwendeten Authentifizierungscodes für Anwendungen mehr akzeptieren. Diese Sicherheitsänderung trägt dazu bei, Microsoft Entra ID mit der OAuth-Spezifikation in Einklang zu bringen und wird sowohl auf den v1- als auch auf den v2-Endpunkten durchgesetzt.

Wenn Ihre App Autorisierungscodes zum Abrufen von Token für mehrere Ressourcen wiederverwendet, sollten Sie den Code für das Abrufen eines Aktualisierungstokens verwenden. Verwenden Sie dieses Aktualisierungstoken anschließend, um die zusätzlichen Token für andere Ressourcen abzurufen. Autorisierungscodes können nur einmal verwendet werden, Aktualisierungstoken hingegen können mehrere Male und für mehrere Ressourcen verwendet werden. Für jede neue App, die einen Authentifizierungscode im OAuth-Codefluss erneut verwenden möchte, wird ein Fehler vom Typ „invalid_grant“ zurückgegeben.

Weitere Informationen zu Aktualisierungstoken finden Sie unter Aktualisieren der Zugriffstoken. Wenn Sie ADAL oder MSAL verwenden, wird dies automatisch von der Bibliothek erledigt: ersetzen Sie die zweite Instanz von AcquireTokenByAuthorizationCodeAsync durch AcquireTokenSilentAsync.

Mai 2018

ID-Token können nicht für den OBO-Fluss verwendet werden.

Datum: 1. Mai 2018

Betroffene Endpunkte: v1.0 und v2.0

Betroffene Protokolle: Impliziter Ablauf und „im Auftrag von“-Ablauf

Seit dem 1. Mai 2018 können ID-Token nicht mehr als Assertion in einem OBO-Fluss für neue Anwendungen verwendet werden. Stattdessen müssen Zugriffstoken zum Schützen von APIs genutzt werden (auch zwischen einem Client und der mittleren Ebene der gleichen Anwendung). Vor dem 1. Mai 2018 registrierte Apps funktionieren weiterhin und können ID-Token gegen Zugriffstoken austauschen. Dieses Muster wird jedoch nicht empfohlen.

Sie können die folgenden Schritte ausführen, um diese Änderung zu umgehen:

1. Erstellen Sie eine Web-API für Ihre Anwendung mit einem oder mehreren Bereichen. Dieser explizite Einstiegspunkt ermöglicht eine differenziertere Kontrolle und höhere Sicherheit.
2. Vergewissern Sie sich im App-Manifest, im Azure-Portal oder im App-Registrierungsportal, dass die App Zugriffstoken über den impliziten Fluss ausgeben darf. Dies wird durch den Schlüssel oauth2AllowImplicitFlow gesteuert.
3. Wenn Ihre Clientanwendung ein ID-Token über response_type=id_token anfordert, fordern Sie zusätzlich ein Zugriffstoken (response_type=token) für die oben erstellte Web-API an. Daher sollte bei Verwendung des v2.0-Endpunkts der scope-Parameter etwa wie folgt aussehen: api://GUID/SCOPE. Auf dem v1.0-Endpunkt sollte der resource-Parameter der App-URI der Web-API sein.
4. Übergen Sie anstelle des ID-Tokens dieses Zugriffstoken an die mittlere Ebene.