Azure Entra ID: Probleme mit Single Sign On (SSO) (seit März 2024)

[English]Seit März 2024 (ca. Ostern) beklagen sich diverse Administratoren aus der Leserschaft des Blogs, dass es  sporadische Probleme beim Single Sign On (SSO) unter Microsofts Azure Entra ID gebe. Die Nutzer können sich plötzlich nicht mehr unter ihren Microsoft 365-Apps anmelden. Inzwischen haben einige Leser Workarounds im Blog gepostet, so dass ich das Thema nochmals aufgreifen und den Workaround vorstellen will.


Anzeige

Probleme mit Single Sign On (SSO)

Mit Single Sign-On (SSO) sollen die Zugriffe auf die verwendeten  SaaS-Apps (Software-as-a-Service), Cloud-Apps oder lokalen Apps vereinfacht werden. Es gibt eine Anmeldung an Microsoft Entra ID, die dann für alle verwendeten Apps gelten soll. Microsoft hat das Thema auf dieser Microsoft Support-Seite erläutert und verspricht: "Mit SSO benötigen Ihre Teams nur einen Satz von Anmeldeinformationen, um bequem auf alle ihre Apps zuzugreifen. So muss sich niemand mehr verschiedene Varianten merken oder Kennwörter wiederholt eingeben."

Es soll aber 2024 Änderungen für Nutzer in Europa geben, um die Einhaltung der Auflagen des Digital Markets Act (DMA) im Europäischen Wirtschaftsraum (EWR) sicherzustellen. Dazu sollen die Anwender in der Theorie einmalig bei der ersten Anmeldung unter Windows (sofern die Maschine im Europäischen Wirtschaftsraum läuft) gefragt werden, ob sie sich bei der Anwendung mit denselben Anmeldedaten anmelden möchten, die auch für die Anmeldung bei Windows verwendet werden.

Microsoft 365 Entra ID-Anmeldung hängt
Microsoft 365 Entra ID-Anmeldung hängt

Allerdings haben sich Blog-Leser gemeldet, deren Nutzer von Fehlern beim Single Sign On (SSO) genervt sind. Die Nutzer können sich sporadisch nicht mehr mit den Microsoft Desktop Apps wie Excel, Word und Co. anmelden. Die Anmeldung hängt dann, wie in obigen Screenshot zu sehen. Der betroffene Administrator schrieb mir dazu: "Wenn ich im Log in Azure nachsehe, dann steht im Log des entsprechenden Benutzers: Failure reason User is required to permit SSO."

Ich hatte diesen Sachverhalt im Blog-Beitrag Gibt es Probleme mit Single Sign On (SSO) bei Maschinen mit Azure Entra ID? angesprochen. Es gab von einigen Administratoren die Bestätigung, die diesen Fehler bei Nutzern oder Kunden sporadisch gesehen haben. Weiterhin tauchen bei mir im Blog Leser bzw. Administratoren auf (siehe diesen Kommentar im Blog-Beitrag Anmeldefehler 700003 bei Microsoft 365 (10. – 11.3.2024) auf), die von Problemen beim Single Sign On mit 2FA berichten, obwohl diese eingerichtet ist (siehe auch meinen Beitrag Microsoft 365/Exchange Online erzwingt plötzlich MFA per Microsoft Authenticator-App). Keine Ahnung, ob diese Fehlerbilder zusammen hängen – mich beschleicht jedenfalls eine Ahnung.

Ein möglicher Workaround

Ein anonym bleiben wollender Administrator hat sich in den Kommentaren dieses Blogs gemeldet (danke dafür) und schreibt, dass bei ihm der Microsoft-Support folgenden Workaround geliefert habe.

  • Die betroffenen Anwender müssen sich bei ihren Office-Apps komplett abmelden.
  • Dann sind die nachfolgend beschriebenen Korrekturen in der Registrierung unter Windows vorzunehmen.

In der Registrierung ist unter folgendem Schlüssel der 32-Bit-DWORD-Wert BlockAADWorkplaceJoin einzutragen und auf 1 zu setzen.


Anzeige

HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin

Anschließend ist unter nachfolgendem folgendem Schlüssel der 32-Bit-DWORD-Wert DisableADALatopWAMOverride einzutragen und auf 1 zu setzen.

HKEY_CURRENT_USER\Software\Microsoft\Office.0\Common\Identity

Im letzten Schritt ist unter nachfolgendem folgendem Schlüssel der 32-Bit-DWORD-Wert DisableAADWAM einzutragen und auf 1 zu setzen.

HKEY_CURRENT_USER\Software\Microsoft\Office.0\Common\Identity

Weiterhin sollen die Einträge (der Leser spricht von Keys) im (Unter-)Schlüssel Identities gelöscht werden. Mit dieser Korrektur sollte die Single-Sign-On-Benutzeranmeldung unter Microsoft Office wieder funktionieren. Die obigen Registrierungseinträge signalisieren mir, dass sich das Ganze auf Microsoft Office 2016 beziehen dürfte.

Leser ToWa, der das Problem ebenfalls in diesem Kommentar bestätigte und bei administrator.de im Beitrag  Microsoft Problem SSO (AD – Entra)? behandelt, hat sich den obigen Workaround ebenfalls angesehen und schreibt hier im Blog und hier auf administrator.de, dass dieser Workaround für das klassische Office (wohl 2016) funktioniert. Soll bei gesetzten Registrierungseinträgen auch bei einem neuen Profil für Office-Programme funktionieren. Aber beim Microsoft Edge tue sich nichts, und der neue Microsoft Teams Client fragt bei der Anmeldung erneut das Kennwort ab, wobei die Meldung aber über die Weiter-Schaltfläche übergangen werden könne. Das ist in diesem Kommentar hier im Blog ebenfalls als Beobachtung beschrieben worden.

Ähnliche Artikel:
Gibt es Probleme mit Single Sign On (SSO) bei Maschinen mit Azure Entra ID?
Anmeldefehler 700003 bei Microsoft 365 (10. – 11.3.2024)
Microsoft 365/Exchange Online erzwingt plötzlich MFA per Microsoft Authenticator-App


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Azure, Cloud, Problemlösung abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

15 Antworten zu Azure Entra ID: Probleme mit Single Sign On (SSO) (seit März 2024)

  1. Anonymous sagt:

    Uns hat geholfen, in Entra ID bei den betroffenen Usern "Revoke all active sign-ins" (o.ä.) zu machen. Dann ist zwar überall einmal eine Neuanmeldung erforderlich, aber danach ist Ruhe.

  2. 1ST1 sagt:

    "Die obigen Registrierungseinträge signalisieren mir, dass sich das Ganze auf Microsoft Office 2016 beziehen dürfte. "

    Das stimmt nicht. O2016 ist ja nicht an die Cloud angebunden. Aber O365 (und 2019, 2021, 2023, ff) verwendet vielfach die gleichen Reg-Keys und Gruppenrichtlinien wie O2016.

    Spannend an obigem Lösungsweg mit den Regkeys finde ich, wie man das auf einer Terminalserver-Umgebung umsetzt, denn da müssten ja alle Nutzer sich in O365 abmelden, bevor die Regkeys gesetzt werden…

  3. Simon sagt:

    Ich war einer der Ersten dessen Kunden davon betroffen waren. Egal ob SSO mit AD, ohne AD oder Privatkonten. Einfach alles ist davon betroffen und mein Telefon hat die letzten zwei Wochen quasi durchgängig wegen dem Problem geklingelt.

    An welche Stelle bei Microsoft darf ich meine Rechnung stellen? Oder darf ich die Kosten für die Lizenzen kürzen?

    Das ist eine ernst gemeinte Frage! Immer wieder muss man deren Mist ausbügeln, es reicht!

    • 1ST1 sagt:

      Ich bin mir da jetzt nicht sicher, ob das das selbe Problem ist, gerade bei Privataccounts bezweifle ich das. (Davon abgesehen, hier mal wieder bei unserem privaten Family-Account und bei der Arbeit keine Probleme, irgendwas muss ich wohl falsch machen, dass ich in das allgemeine Wehklagen nicht einstimmen kann… Mennoooo!)

    • Anonym sagt:

      > … war einer der Ersten dessen Kunden davon betroffen waren … An welche Stelle bei Microsoft darf ich meine Rechnung stellen? <

      Wer hat denn bei Ihnen die Verträge geschrieben? Wollen Sie nicht noch mal Ihren Chef fragen? Die Rechnung sollen Sie dem Kunden stellen, der hat sie ja angerufen und um Hilfe bzw. Dienstleistung angefragt. Der muss seine Ansprüche dann gegen Microsoft – dem Lizenzgeber – geltend machen.

      Wenn Sie selbst Ihren Kunden in die Cloud resp. zu Azure Entra ID gedrängt haben, verstehe ich natürlich Ihr Unwohlsein.

  4. Anonym sagt:

    > Im letzten Schritt ist unter nachfolgendem folgendem Schlüssel der 32-Bit-DWORD-Wert DisableAADWAM einzutragen und auf 1 zu setzen. <

    Diese Empfehlung stammt – wie oben beschrieben – vom ad hoc kontaktierten Microsoft Support.

    Bei sowas könnte ich – mit Verlaub – kotzen (nicht gegen Herrn Born gerichtet). Das Microsoft Engineering hat qua (1) eine klare Empfehlung gegen "Disabling ADAL or WAM" ausgesprochen – eigentlich fast schon ein Verbot. Im Zweifelsfall ist dem Engineering mehr zu trauen als irgendeinem 1st Level Supporter, der einfach nur Ruhe haben will und mit der Schrotflinte draufhält.

    (1)
    learn.microsoft.com/en-us/microsoft-365/troubleshoot/administration/disabling-adal-wam-not-recommended

    • Klaus sagt:

      Kann ich nur unterschreiben, und das gilt für mich für alle genannten Registry-Einträge.

      Wir hatten das auch schon mehrmals und bisher hat immer geholfen, alle Office-Anwendungen einschl. Teams zu beenden (Abmelden war nie notwendig), die gespeicherten Anmeldungen aus der Windows-Anmeldeinformationsverwaltung zu löschen (dürfte dem "Schlüssel Identities löschen" entsprechen) und den Rechner neu zu starten.

      Ach ja, Office 2016/2019/2021/365 laufen alle unter Version 16, nur mit anderen Build-Nummern. 1ST1 hat das weiter oben ja schon angesprochen. War für mich das erste Mal auch verwirrend, die Gruppenrichtlinien für Office 365 zu installieren und dann nur welche für Office 2016 vorzufinden…

  5. Twinker sagt:

    Es ist erstaunlich, welches Gefrickel und wie oft man dies inzwischen anwenden muss, damit man einfach nur arbeiten und sein System nutzen kann.

    • 1ST1 sagt:

      COMMODORE 64

      Da brauchst du nicht zu frickeln, da meldet sich BASIC 2.0 direkt nach dem Einschalten. Kannst du sofort loslegen.

      Kann ich dir empfehlen.

      • Twinker sagt:

        Also, da hast Du schon uneingeschränkt Recht: ggü. einem aktuellen Betriebssystem aus dem Hause Microsoft hat ein Commodore 64 erhebliche Vorteile!
        Zum Glück gibt es schon lange sehr gute Alternativen, wo all das Gefrickel unnötig ist. Sonst hätte ich mich doch jetzt glatt auf die Suche nach einem C64 machen müssen, meiner ist nämlich schon lange entsorgt – leider. ;-)

        Trotzdem, danke für deine wichtige Empfehlung!

  6. Blubmann sagt:

    Erfahrungen der letzten Wochen. Mit Workarounds bekommen wir Office zum Laufen. Das neue Teams scheitert aber immer mit Fehler 1001. Das alte Teams klappt zu 80%,wird dann aber nach eienr gewissen Zeit auf den neuen Client aktualisiert. Ticketsystem ist zugespamt, Telefon nehmen ich schon gar nicht mehr ab. Prio 1 Ticket bei Micro(Schrott) ist offen, aber bisher ohne Erfolg. Also im Grunde wieder so eine Softwarerotze bei dem der Hersteller keine Ahnung vom eigenen System hat. Ich bin als Sysadmin eigentlich nur noch da die Pflaster auf miserable und qualitativ grotige Software zu kleben. Es wird Zeit, das Softwarehersteller für so ein Gemurkse und die ganzen Ausfallzeiten zur Verantwortung gezogen werden.

  7. Marco sagt:

    Ich kann das in allen möglichen Kombinationen von Win 10/11 M365/ Teams & Co. bestätigen.

    Vollkommen willkürlich treten diese Probleme auf. Mit willkürlich Auswirkungen. Vollkommen abstrus. Angefangen bei verlorenen Aktivierungen von Office 365 in Word / Excel / Access – und zwar getrennt von einander. Mit Office gehts, aber dafür Teams nicht. Dann bin ich in Teams und plötzlich kommt oben der rote Balken mit dem Hinweis "Leider konnte keine Verbindung aufgebaut werden", bin parallel aber noch in einem Teams meeting. Hier fehlt dafür dann mein Profilbild… und … und… und….

    Grü0e Marco

  8. Drinkout sagt:

    Bin mittlerweile auch über das Problem bei einem Kunden gestolpert. Bekannt sind 3 Benutzer, bei denen das Problem tagtäglich auftritt. Wir haben bereits Folgendes versucht:
    – Aktive Sitzungen über Entra vom jeweiligen Benutzer getrennt, damit eine
    Neuanmeldung nötig ist
    – Manuell alle Office Applikationen auf dem Client geschlossen + Credential Manager bereinigt von Office Credentials
    – Registry Keys gesetzt + Keys unter Identities entfernt

    Leider alles ohne Erfolg. Problem tritt am Folgetag dann immer wieder auf. Das einzige, was wohl übrig bleibt, ist ein Ticket bei MS zu eröffnen. Laut Kommentaren wird MS hierbei wohl keine große Hilfe sein^^

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.