RDS + MS 365: ständige Authentifizierungsaufforderungen

[qiller]

Hu zusammen,

hab hier einen RDS, wo MS 365 installiert ist. Benutzerprofile inkl. %localappdata% (Speicherort diverser Lizenz-/Auth-Infos und Token für MS365) werden in UPDs abgelegt. Die Domäne ist nicht irgendwie mit der Entra ID Cloud verbandelt (z.B. per Hybrid Join). Jeder RDS-Nutzer bekommt beim ersten Öffnen von MS Office Produkten brav das Anmeldefenster, loggt sich mit seinen MS365 Zugangsdaten ein (die anschließende Aufforderung zum WorkplaceJoin hab ich schon per Reg-Eintrag deaktiviert) und alles scheint erstmal gut zu sein.

Nach ein paar mal Ab- und wieder Anmelden des benutzers vom RDS passiert es aber, dass in den MS Office Anwendungen rechts oben bei der Nutzeranmeldung für MS365 ein gelbes Ausrufezeichen kommt und irgendwas von "Kontofehler" faselt und man solle die "Anmeldung reparieren". Die Anwendungen funktionieren dann trotzdem noch eine Weile, aber irgendwann kommt dann wieder die Aufforderung zur MS365-Authentifizierung. Lokal auf den Geräten passiert das übrigens nicht, nur in den Sitzungen auf dem RDS.

Hat jemand eine Idee, wie man das behebt, ohne die Domäne mit Entra ID zu verheiraten (das ist der vielversprechenste, von mir bisher gefundene Hinweis, der wohl zusammen mit Single Sign On das Problem garantiert behebt)?

danke schonmal für den Input.

 

[BFF]

Das liest sich grausam nach:
https://www.computerbase.de/news/be...-fehler-bei-teams-und-onedrive-fuehren.96624/

 

[qiller]

Teams/Onedrive ist auf dem RDS nicht installiert und das Problem ist auch schon länger so.

 

[derlorenz]

Gibt es denn Fehler im eventlog bei der Abmeldung? Ggf mal über Fslogix nachdenken.

 

[qiller]

Gibt es denn Fehler im eventlog

Event Id 1098 taucht unter "Anwendungs- und Dienstprotokolle->Microsoft->Windows->AAD->Operational" sehr häufig auf.

Spoiler

Error: 0xCAA100D8 A login hint was sent that doesn't match any WebAccount in the system.
Exception of type 'class Exception' at GetTokenSilentlyBrokerOperation.cpp, line: 214, method: GetTokenSilentlyBrokerOperation::UpdateAcquireTokenFlags.

Log: 0xcaa5011e A token task failed with an exception.
Logged at GetTokenBrokerOperationBase.cpp, line: 431, method: GetTokenBrokerOperationBase::ExecuteImpl::<lambda_c31474b14359272d976d8c8f11c58019>::operator ().

Es gibt da auch nur Fehlermeldungen mit Benutzern, die auf jeden Fall sich mit ihrem MS365 Account authentifiziert haben. Mein Admin-Account (der keine MS 365 Apps for Business Premium Lizenz hat) produziert z.B. keine Event ID 1098 Fehlermeldungen. Also müssen diese irgendwie damit zusammenhängen.

Ergänzung (21. März 2026)

Ggf mal über Fslogix nachdenken

Die UPDs sind nicht das Problem (das dachte ich auch erst). Die wichtigen Ordner unter %localappdata% werden alle korrekt in die UPD übertragen, sonst hätte ich ja wirklich bei JEDEM Ab- und Anmelden das Problem (dazu gibts auch diverse Tips bzgl. FSLogix, wo das nämlich dann wirklich bei jedem Ab- und wieder Anmelden auftreten kann).

So sieht das übrigens aus, wenn ich jetzt Word mit meinem Testbenutzer auf dem RDS starte:

MS365 hatte ich bei diesem Testnutzer gestern erst authentifiziert.

 

[qiller]

Ich hab mal die UPD vom Testbenutzer gelöscht, nochmal anlegen lassen und mich nochmals bei MS365 angemeldet. Werde morgen mal gucken, ob die MS365-Anmeldung aktiviert bleibt.

 

[qiller]

So, gestern ja das Profil des Testbenutzers auf der UPD nochmal neu angelegt und mit einem MS365-Konto die Office-Produkte aktiviert. Danach dann sauber abgemeldet. Eben wieder angemeldet und bekomme direkt wieder den "Kontofehler". MS Office funktioniert aber trotzdem erstmal.

Edit: Nochmal die UPD-Settings überprüft, es wird alles gesichert.

Werde jetzt trotzdem nochmal ohne UPDs und mit der Profilspeicherung direkt auf dem Server testen. Wobei das keine Lösung wäre, da auf dem Server nicht genug Platz ist. Aber um die UPDs komplett auszuschließen reichts.

 

[qiller]

Hm, ok man gut, dass ich das nochmal getestet hatte (obwohl ich das eigt. schonmal gecheckt hatte). Mit der Speicherung des Benutzerprofils direkt unter C:\Users auf der System-Platte des Servers ohne UPDs gibts bisher keine Kontofehler.

UPDs (denke das wird mit FSLogix genauso sein) werden ja beim Anmelden des Benutzers gemountet und beim Abmelden wieder unmounted, so dass das Benutzerprofil nach dem Abmelden des Benutzers lokal für das System gar nicht mehr verfügbar ist. Im Gegensatz zur Speicherung direkt auf dem Systemlaufwerk. Vlt. will im Hintergrund irgendnen Dienst in die Profile reingucken und die Lizenzen/Token checken und kommt da natürlich nicht ran, wenn die Nutzer abgemeldet sind (Benutzerordner gibts ja mit UPDs unter c:\users nicht).

Werd das mal nächstes WE weiter beobachten. Bisher trau ich dem Braten noch nicht. Muss ja ein Grund gehabt haben, warum ich UPDs beim ersten Check ausgeschlossen hatte.

 

[Tito_2000]

Habt ihr auch Microsoft Entra seamless single sign-on (ehemals Azure AD Pass through authentication) im Einsatz?

https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sso

Über die SSO-Funktion erreichen wir, dass ein Anwender alle Microsoft 365 Anwendungen als auch Anmeldungen im Browser problemlos ohne weiteren Anmeldedialog nutzen können.

https://www.msxfaq.de/cloud/authentifizierung/seamless_single_sign-on_authentifizierung.htm

 

[qiller]

Hab ich ja auch im ersten Post schon geschrieben, dass das die am meisten zu findende und wohl garantiert funktionierende Lösung sein soll/wird. Nur geht es hier gerade darum, keine Entra ID Authentifizierung für die Domäne zu nutzen oder einen Hybrid Join zu machen.

Ich kann aber bis hierher schonmal sagen, dass es mit hoher Wahrscheinlichkeit an den UPDs liegt. Mein Testnutzer hat bisher noch keinen Kontofehler ausgeworfen.