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.
Wenn wir nur den DisableADALatopWAMOverride Key setzen, funktioniert das bei uns wie beschrieben. Wir haben das Problem ausschließlich auf Terminalservern mit Server 2019 in Verbindung mit Farmen.
Ist schon bekannt, ob die lokale Domäne mit Azure AD Connect synchronisiert werden kann, wenn DisableADALatopWAMOverride auf 1 gesetzt wurde?
Gibt es hier schon eine andere Lösung?
Gibt es Wechselwirkungen mit SAML, WS-Ferderation, OAuth, MFA, Conditiona Access, wenn WAM und ADAL übersprungen werden?
Und warum tritt das Problem hauptsächlich bei Terminal Servern auf? Wird bei dem SharedComputer Verfahren die Lizenz anders abgerufen?
> Gibt es hier schon eine andere Lösung?
Nein, aber unter Server 2019 mit dem aktuellen Deployment Tool und SCA haben wir den Fehler bisher nicht wieder gesehen.
> Gibt es Wechselwirkungen mit SAML, WS-Ferderation, OAuth, MFA, Conditiona Access, wenn WAM und ADAL übersprungen werden?
Nein, das betrifft nur das Lizenzmanagement und wird auch von der MS Hotline als Workaround so empfohlen.
> Und warum tritt das Problem hauptsächlich bei Terminal Servern auf?
Weil man RDS mit SCA selten auf PCs und zuhause einsetzt 😉
> Wird bei dem SharedComputer Verfahren die Lizenz anders abgerufen?
Anders als bei Destop-Setups, ja. Das Problem kommt aber nicht von der SCA, sondern von der WAM im Zusammenhang mit dem UPN der Nutzers Der Fehler tritt auch nur bei nicht-ADConnecteten Domänen auf (bisher).
Wir konnten die Besonderheit mit dem ADAL+WAM nur in Verbindung mit ehemals! Azure AD Connect verbunden Domänen feststellen. Cloud Only ohne Azure AD Connect Vorgeschichte in zeigt kein Probleme
Beispiel:
Terminalserver 2012, AD mit Azure AD Connect verbunden
Umzug auf neue lokale Domäne ohne Migration, Azure AD Connect getrennt mit dem Befehl – Set-MsolDirSyncEnabled -EnableDirSync $false
Terminalserver 2019, AD ohne Azure AD Connect, Cloud Only Azure AD Benutzer, Fehler mit Anmeldung usw. wie oben beschrieben taucht auf. Habt Ihr ähnliche Probleme?
Zumindest haben wir eine Übereinstimmung: Passiert nur bei ADConnect-Synchronisierten Domänen und auch noch in der aktuellen Release der Office apps. Warum wissen natürlich nicht …