3
Outlook 2013: Modern Authentification: Passwort wird nur kurzfristig gespeichert
Hallo Leute,
folgendes Problem:
ich habe am WE unsere User auf Exchange Online migriert. Als Clients wird Outlook 2013 in Verbindung mit Modern Authentification verwendet.
Ich habe bei allen Usern das neue Profil eingerichtet. Habe mich daraufhin ein paar Mal direkt ab- und wieder angemeldet (direkt am Windows). Die Passwortabfrage kam aber nie. Somit war für mich das Thema eigentlich abgeschlossen.
Als ich nun nach 72 Stunden nochmal einen Test machte, musste ich feststellen, dass er beijedem vielen User wieder nach dem Passwort fragt.
Meine Frage nun an euch: Kann man da irgendwie einstellen, dass er sich das Passwort dauerhaft speichert? Oder habe ich da was falsch eingestellt? Oder ist das normal?
Hätte jetzt mal den RegKey "AllwaysUseMSOAuthForAutoDiscover" gesetzt. Keine Ahnung ob der was bringt.
Gleich vorweg: SSO geht (noch) nicht, da Windows-Anmeldename (noch) nicht der Anmeldename fürs Exchange Online ist.
Besten Dank für eure Hilfe
Grüße
Patrick
folgendes Problem:
ich habe am WE unsere User auf Exchange Online migriert. Als Clients wird Outlook 2013 in Verbindung mit Modern Authentification verwendet.
Ich habe bei allen Usern das neue Profil eingerichtet. Habe mich daraufhin ein paar Mal direkt ab- und wieder angemeldet (direkt am Windows). Die Passwortabfrage kam aber nie. Somit war für mich das Thema eigentlich abgeschlossen.
Als ich nun nach 72 Stunden nochmal einen Test machte, musste ich feststellen, dass er bei
Meine Frage nun an euch: Kann man da irgendwie einstellen, dass er sich das Passwort dauerhaft speichert? Oder habe ich da was falsch eingestellt? Oder ist das normal?
Hätte jetzt mal den RegKey "AllwaysUseMSOAuthForAutoDiscover" gesetzt. Keine Ahnung ob der was bringt.
Gleich vorweg: SSO geht (noch) nicht, da Windows-Anmeldename (noch) nicht der Anmeldename fürs Exchange Online ist.
Besten Dank für eure Hilfe
Grüße
Patrick
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 458426
Url: https://administrator.de/contentid/458426
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
3 Kommentare
Neuester Kommentar
Für mich ist ja dabei interessant, dass manche User das Passwort eingeben müssen und manche nicht. Alle arbeiten aber am gleichen Terminalserver mit dem gleichen GPOs und dem gleichen Office.
Diesen Link habe ich prinzipiell schon durch. Und genau das
trifft auf mich zu.
Werde morgen noch den "Microsoft Support- und Wiederherstellungs-Assistent für Office 365" laufen lassen. Aber mein Optimismus hält sich in Grenzen...
Diesen Link habe ich prinzipiell schon durch. Und genau das
Microsoft Outlook 2016 and some recent builds of Outlook 2013 are not affected by this issue. Those versions have been updated to prevent the problem that is described in the "Symptoms" section. These versions have the Logon network security setting disabled or removed from the Microsoft Exchange email account settings.
trifft auf mich zu.
Werde morgen noch den "Microsoft Support- und Wiederherstellungs-Assistent für Office 365" laufen lassen. Aber mein Optimismus hält sich in Grenzen...
Hätte jetzt mal den RegKey "AllwaysUseMSOAuthForAutoDiscover" gesetzt. Keine Ahnung ob der was bringt.
Das bringt mal nix...Als ich nun nach 72 Stunden nochmal einen Test machte
Konnte dieses Problem nun nach bereits 10h schon feststellen
Ich konnte nun endlich das Problem lösen.
Allerdings halfen mir die zahlreichen Tips im www (z.b. das oder das) nicht wirklich weiter.
Sie führen mich aber zum Hintergrund:
Und ab dieser Erkenntnis war mir das Problem klar:
Es gibt nun zwei Lösungsansätze:
1) Den Ordner C:\Users\{Username}\AppData\Local synchronisieren (was für mich definitiv keine Option war)
2) Den Inhalt des Ordners C:\Users\{Username}\AppData\Local\Microsoft\Credentials dort sichern, wo er auch synchronisiert wird
Für mich kam nur Lösung 2 in Frage:
Logon-Script:
Logoff-Script:
Ganz generell sollte man bei Lösung 2 aber noch berücksichtigen, dass Windows standardmäßig ein Verzögerung für Logon-Scripts hat. Dies muss ggf. angepasst werden.
Grüße
Patrick
Allerdings halfen mir die zahlreichen Tips im www (z.b. das oder das) nicht wirklich weiter.
Sie führen mich aber zum Hintergrund:
- die Modern Authentification nutzt ADAL
- bei Verwendung von ADAL werden die Zugangsdaten in der Anmeldeinformationsverwaltung (Credential Manager) gespeichert
- der Credential Manager legt für jedes Kennwort eine eigene Datei an. Der Pfad dazu ist C:\Users\{Username}\AppData\Local\Microsoft\Credentials (Es gibt da prinzipiell noch weitere Pfade, die man mittels cmdkey.exe und vaultcmd.exe auslesen kann. Sind aber in diesem Fall irrelevant)
Und ab dieser Erkenntnis war mir das Problem klar:
- Wir verwenden servergespeicherte Userprofile (Roaming Profiles)
- Da die User auf einem Terminalserver arbeiten, ist die GPO "zwischengespeicherte Kopien von servergespeicherten Profilen löschen" aktiv
- Nachdem der Ordner C:\Users\{Username}\AppData\Local standardmäßig nicht synchronisiert wird, "vergisst" Windows die gespeicherten Passwörter und es erscheint regelmäßig die Passwortabfrage
Es gibt nun zwei Lösungsansätze:
1) Den Ordner C:\Users\{Username}\AppData\Local synchronisieren (was für mich definitiv keine Option war)
2) Den Inhalt des Ordners C:\Users\{Username}\AppData\Local\Microsoft\Credentials dort sichern, wo er auch synchronisiert wird
Für mich kam nur Lösung 2 in Frage:
Logon-Script:
@echo off
xcopy %APPDATA%\Microsoft\LocalCredentials %LOCALAPPDATA%\Microsoft\Credentials\ /H /Y /C
rd %APPDATA%\Microsoft\LocalCredentials /S /QLogoff-Script:
@echo off
xcopy %LOCALAPPDATA%\Microsoft\Credentials %APPDATA%\Microsoft\LocalCredentials\ /H /Y /CGanz generell sollte man bei Lösung 2 aber noch berücksichtigen, dass Windows standardmäßig ein Verzögerung für Logon-Scripts hat. Dies muss ggf. angepasst werden.
Grüße
Patrick
