badger
Goto Top

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 bei jedem 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

Content-ID: 458426

Url: https://administrator.de/forum/outlook-2013-modern-authentification-passwort-wird-nur-kurzfristig-gespeichert-458426.html

Ausgedruckt am: 22.12.2024 um 06:12 Uhr

Badger
Badger 02.06.2019 um 20:41:45 Uhr
Goto Top
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

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.

screenshot

Werde morgen noch den "Microsoft Support- und Wiederherstellungs-Assistent für Office 365" laufen lassen. Aber mein Optimismus hält sich in Grenzen...
Badger
Badger 03.06.2019 aktualisiert um 07:06:59 Uhr
Goto Top
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
Badger
Badger 13.06.2019 um 09:19:00 Uhr
Goto Top
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:
  • 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 /Q

Logoff-Script:
@echo off
xcopy %LOCALAPPDATA%\Microsoft\Credentials %APPDATA%\Microsoft\LocalCredentials\ /H /Y /C

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