Outlook Kennwort-Abfrage trotz Kerberos Ticket

[winmadness 79]

Ich habe ein Problem mit der Outlook Authentifizierung. Outlook verlangt die Eingabe des Benutzerkennwortes, obwohl ein Kerberos-Ticket für Outlook existiert. Wenn ich die Kennwort-Eingabe abbreche startet Outlook normal und ich habe Zugriff auf alle Outlook Elemente / Ordner. Aber es wird immer wieder die Eingabe eines Kennwortes verlangt (bei Abbruch der Anforderung).
Folgende Konfiguration:
•    Windows Server 2016 mit allen Patches – eine VM als DC und eine VM mit Exchange Server 2016 mit allen Patches
•    Client Windows 10 mit allen Patches
•    MS Office 2016 mit allen Patches
•    VPN Verbindung über OpenVPN mit SSL (als UTM einmal WatchGuard VM und einmal OPNSense VM – bei beiden der gleiche Fehler)
•    Anmeldung an der UTM über einen VPN Benutzer
•    Kerberos Ticket wird über Benutzer Zertifikat (im AD beim Benutzer hinterlegt) gezogen
•    Das Benutzer Zertifikat ist im Windows Client in den Systemsteuerungen -> Windows-Anmeldeinformationen als „Zertifikatbasierte Anmeldeinformationen“ für die Domain hinterlegt
•    Zugriff auf Netzfreigaben über das Benutzer-Zertifikat / Kerberos-Tickt ohne Probleme möglich
•    Outlook Profil mehrmals neu angelegt, mit und ohne Exchange Cache
•    Outlook Verbindung über MAPIoverHTTP
•    In der Registry den Key „AuthenticationService„ unter „Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Security“ auf 16 = Kerberos-Kennwortauthentifizierung angelegt
•    Im ECP unter Server -> Virtuelle Verzeichnisse für die Authentifizierungs-Methode für Server-Typ „mapi“ nur „Windows-Authentifizierung – Kerberos“ aktiviert.

 

In der Outlook Übersicht „Verbindungsstatus“ wird mir unter Servername nur https://<exchange-server>/mapi/... und als Protokoll nur „http“ angezeigt. In der Spalte „Authn“ steht „Nego*“. Bei Abbruch der Passwort-Abfrage steht in der Outlook Statusleiste „Kennwort erforderlich“. Nach Betätigung des Buttons „Verbindung wiederherstellen“ im Verbindungsstatus-Fenster  kann ich normal weiterarbeiten – bis zur nächsten Kennwort-Abfrage z.B. bei Wechsel eines Ordners innerhalb meines Postfaches.
Ich kann trotz fehlender Kennwort-Eingabe ganz normal und fehlerfrei mit Outlook arbeiten.

 

[NorbertFe 2.027]

Deaktivier mal o365 im autodiscover.

https://melbits.com.au/kb/how-to-disable-office-365-autodiscover-exchange-self-hosted/
 

geht auch per Policy.

[winmadness 79]

Danke für den Tipp. Ist bereits deaktiviert, da ansonsten Autodiscover nicht funktionieren würde. Bis auf "ExcludeHttpsAutoDiscoverDomain" sind alle "Exclude..." Schlüssel deaktiviert.

Ich denke ich habe eine Spur. Unser Domainname lautet intern.de. Somit ist der UPN name@intern.de und hierüber erfolgt auch die Anmeldung am AD und die Erstellung / Anmeldung des Outlook Profils. Auch das Kerberos Ticket weist unter "Client" den Eintrag "name@intern.de" aus. Die primäre SMTP-Adresse (AD Feld "mail") ist name@firma.de (unsere offizielle Firmen-Domain). Auch in Outlook wird das Postfach unter "name@firma.de" angezeigt. Wenn ich nun über Outlook den "E-Mail-Autokonfiguration" Test durchführe muss über bei Eingabe der Adresse "name@intern.de" kein Passwort eingeben. Wenn ich aber den Test mit "name@firma.de" durchführe dann verlangt Outlook die Eingabe eines Passwortes. Ich trage dann als Benutzer name@intern.de und das entsprechende Passwort ein. Dann läuft der Test ohne Probleme.

Die Frage wie löse ich das Problem. Den UPN kann ich nicht ändern. Welche Auswirkungen hätte die Änderung der Mail-Adresse (AD Feld mail)?

bearbeitet 11. März 2023 von winmadness

[NorbertFe 2.027]

vor 2 Minuten schrieb winmadness:

Den UPN kann ich nicht ändern.

Warum nicht? Eigentlich ist es best practice Mailadresse und upn gleichlautend zu konfigurieren.

[winmadness 79]

UPN auf name@firma.de geändert und Outlook Profil angelegt. Das Benutzer Zertfikat neu erstellt und in Windows Anmeldeinformationen hinterlegt. Leider das gleiche Verhalten, nach wie vor Kennwortabfrage, diesmal mit "name@firma.de" als Benutzer.

[NorbertFe 2.027]

tritt das auch im Outlook abgesicherten Modus auf? Nicht, dass dir irgendwie ein Add-in oder so dazwischenfunkt.

[winmadness 79]

Gute Idee, leider auch im abgesicherten Modus kommt die Abfrage. Und auch der "E-Mail-Autokonfiguration" Test verlangt bei der Adresse name@firma.de nach wie das Kennwort. Bei name@intern.de keine Kennwortabfrage.

Noch eine Frage, das Kerberos Ticket wird nach wie vor für den Client "name@intern.de", also auf den Domainnamen des DC, ausgestellt. Ich denke hier liegt das Problem.

[Nobbyaushb 1.464]

Wo hast du den UPN für den einen User eingestellt?

 

Das macht man eigentlich Domänen-weit

[NorbertFe 2.027]

vor 24 Minuten schrieb winmadness:

Und auch der "E-Mail-Autokonfiguration" Test verlangt bei der Adresse name@firma.de nach wie das Kennwort.

Ich mußte da bei einer AD integrierten Windows Installation noch nie das Passwort eingeben.

 

vor 3 Stunden schrieb winmadness:

 In der Registry den Key „AuthenticationService„ unter „Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\Security“ auf 16 = Kerberos-Kennwortauthentifizierung angelegt

Schmeiß den doch mal raus. Der wird doch gar nicht benötigt, oder seh ich grad was falsch?

[winmadness 79]

vor 7 Minuten schrieb Nobbyaushb:

Wo hast du den UPN für den einen User eingestellt?

Auf dem DC im AD / User.

 

vor 4 Minuten schrieb NorbertFe:

Ich mußte da bei einer AD integrierten Windows Installation noch nie das Passwort eingeben.

Der Windows Client ist kein Domain-Mitglied. Die Verbindung erfolgt über VPN und dann wird über das Benutzer-Zertifikat ein Kerberos Ticket gezogen. D.h. eine Anmeldung im AD erfolgt nicht.

 

vor 5 Minuten schrieb NorbertFe:

Schmeiß den doch mal raus. Der wird doch gar nicht benötigt, oder seh ich grad was falsch?

War nur für Testzwecke, habe ich bereits gelöscht.

 

Ich habe jetzt im AD das Feld "mail" und "UPN" auf name@intern.de geändert. Damit kommt in Outlook keine Kennwort-Abfrage mehr. Mal sehen welche Side-Effekts damit auftreten. Die primäre Mail-Adresse in Exchange-Postfach steht nach wie vor auf name@firma.de, also keine Auswirkungen auf den Mail-Verkehr.

[NorbertFe 2.027]

Gerade eben schrieb winmadness:

Der Windows Client ist kein Domain-Mitglied. Die Verbindung erfolgt über VPN und dann wird über das Benutzer-Zertifikat ein Kerberos Ticket gezogen. D.h. eine Anmeldung im AD erfolgt nicht.

 

Ah, dann hab ich das falsch verstanden.

 

Gerade eben schrieb winmadness:

Ich habe jetzt im AD das Feld "mail" und "UPN" auf name@intern.de geändert.

Das ist aber relativ "unsicher", weil dir das ggf. der Exchange wieder überschreibt.

[cj_berlin 1.306]

Gerade eben schrieb winmadness:

also keine Auswirkungen auf den Mail-Verkehr.

Doch, doch, die kommen später.

Und im Kerberos-Ticket, das Du beim Benutzer sieht, steht der korrekte UPN und auch der korrekte SPN für HTTP/exchange? 

Kannst Du anhand der IIS-Logs sehen, welches virtuelle Verzeichnis die erneute Authentifizierung verlangt?

[winmadness 79]

Danke für die Hinweise, hatte ich befürchtet

Werde den "steinigen" Weg gehen und das Passwort bei der Profil-Erstellung in Windows speichern. Wollte ich vermeiden und nur mit User-Zertifikaten arbeiten.

[NorbertFe 2.027]

Welcher Name steht denn eigentlich im Zertifikat?

[winmadness 79]

Zertifikats-Daten:

Aussteller: ..., DC = intern DC = de

 

Daten im Zertifikat für UPN = name@intern.de, mail = name@firma.de

• Antragssteller: E = name@firma.de, CN = <Displayname>, OU = User <firma>, DC = intern, DC = de
• Alternativer Antragsstellername: Prinzipalname=<name>@intern.de, RFC822-Name=<name>@firma.de

Daten im Zertifikat für UPN = name@firma.de, mail = name@firma.de

• Antragssteller: E = name@firma.de, CN = <Displayname>, OU = User <firma>, DC = intern, DC = de
• Alternativer Antragsstellername: Prinzipalname=<name>@firma.de, RFC822-Name=<name>@firma.de