Office 365 auf Windows (RDS) Server ist plötzlich „nicht lizenziert“ und das Office Anmeldefenster verschwindet einfach

Problem

Office 365 wurde korrekt und mit aktiviertem „Shared Computer Activation“ installiert. Nach einer Weile berichten Benutzer von „unlizenziertem Office“ und das man seine Lizenz nicht mehr aktivieren könne.

Das Anmelde-Feld erscheint zwar, man kann hier seine E-Mail Adresse auch eingebene, aber dann verschwindet es wieder und Office wird nicht aktiviert. Es gibt keine Fehler und sogar die Ereignisanzeige bleibt leer.

Lösung

Standardmäßig verwendet Microsoft Office 365 ProPlus (seit Version 2016) die Frameworkbasierte Authentifizierung der Azure Active Directory-Authentifizierungsbibliothek („ADAL“). Nach der Umstellung auf die neue „modern Authentication“ via „WAM“ passieren aber leider häufiger mal Fehler.

Es hilft zuverlässig, WAM und ADAL einfach zu überspringen:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableADALatopWAMOverride"=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity]
"DisableAADWAM"=dword:00000001

Das geht natürlich auch per Gruppenrichtlinie (GPO) im Benutzerkontext (Benutzerkonfiguration) und benötigt nicht mal einen reboot.

Erlärung

Ab Build 16.0.7967 verwendet Office nun den „moderneren“ Web Account Manager („WAM“) für Office-Anmelde-Workflows. Es war auch mal wieder Zeit für neue TLAs. Selbiger bringt, wie immer, einige spannende neue „Eigenheiten“ mit.

WAM sucht beim Start nach den neuen Voraussetzungen für den Identity Providers (IdP), die beim Zusammenführen von Office 365 Konten verwendet werden (IdP IDReg_Match). Für synchronisierte Domänen an sich ein segen – es funktioniert nun auch der lokale UPN. Theoretisch.

Wenn Windows 10 oder Windows Server 2019 mit einem lokalen Active Directory verbunden ist, muss der IdP für WAM/O365 nun aber das sogenannte „WS-Trust-Protokoll“ (respektive Flag) unterstützen. Dies geschieht aber nicht automatisch in allen Konfigurationen; warum das oft nicht der Fall ist, haben wir noch nicht herausgefunden. Wenn beispielsweise das Authentifizierungstoken eines Benutzers ungültig wurde, zum Beispiel beim Kennwort-Zurücksetzen oder deaktivieren eines Nutzers, versucht das WAM den Benutzer erneut zu authentifizieren. Soweit idst das ja auch richtig – aber man erwartet hier nun das altbekannte Popup-Fenster des IdP, das bei einem fehlgeschlagenen Zugriff aber nur kurz geöffnet und dann sofort wider geschlossen wird wenn das Flag nicht korrekt/lesbar/vorhanden ist.

Schreibe einen Kommentar

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

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.