[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
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."
Anzeige
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.
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\16.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\16.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
Anzeige
Office 2016 und man wundert sich? Auch das war lange genug angekündigt. https://learn.microsoft.com/de-de/deployoffice/endofsupport/microsoft-365-services-connectivity
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.
Im Entra bei jedem einzelnen Benutzer auf "Sitzung widerrufen" oder wie?
"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…
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!
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!)
> … 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.
> 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
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…
Es ist erstaunlich, welches Gefrickel und wie oft man dies inzwischen anwenden muss, damit man einfach nur arbeiten und sein System nutzen kann.
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.
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!
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.
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
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^^
Gibt es hier eigentlich Neuigkeiten / neue Entwicklungen? Bei uns – Mittelstand, global agierend – treten ähnliche Probleme zunehmend auf. Wir beziehen uns hier hauptsächlich auf Geräte, die Hybrid AAD Joined sind, also lokal einer Domäne angehören und gleichzeitig eine gesync'te Identität im M$-Tenant haben. Damit haben wir eh schon keinen klassischen WorkplaceJoin sondern eine Device-Registrierung mit hybridem Join, dessen Aktivierung über eine Anmeldung mit Cloud-Account entweder direkt am Gerät – oder – im Office Apps for Enterprise erfolgt (bei Geräten von Tochterfirmen mit eigenständiger Domäne).
Vor dem Hintergrund ist mir überhaupt nicht klar, wie Microsoft's DMA-Implementierung funktionieren soll – und – was bringt der Reg-Patch hier?… im Grunde warten wir nun auch auf einen Patch zu https://admin.microsoft.com/Adminportal/Home?#/windowsreleasehealth/knownissues/:/issue/WI789502