MAPI over HTTPs Neg...
 
Benachrichtigungen
Alles löschen

[Gelöst] MAPI over HTTPs Negotiation macht kein Kerberos , sondern nur NTLM

2 Beiträge
1 Benutzer
0 Reactions
4,363 Ansichten
(@docheadshot)
New Member
Beigetreten: Vor 4 Jahren
Beiträge: 2
Themenstarter  

Hallo liebe Community,

ich bin zurzeit mit meiner Exchange Umgebung in der Koexistenzphase zwischen EX2010 und EX2016.

Alle Postfächer sind bereits auf den EX2016 Servern migriert worden.

Mein Problem ist, dass die Outlook 2016 Clients, trotz eingestellter negotiate Authentifizierung im MapiVirtualDirectory und korrekt konfigurierter Kerberos Constrained Delegation (nach Microsoft Anleitung) keine Kerberos Authentifizierung aushandeln.

SPN Settings:

Setspn -L contoso\EXCH2016ASA$
Registrierte Dienstprinzipalnamen (SPN) für CN=EXCH2016ASA,OU=Exchange,OU=Server,DC=contoso,DC=de:
http/autodiscover
http/exchange
http/autodiscover.contoso.de
http/exchange.contoso.de

Im Verbindungstest sieht es so aus:

 

Es wird versucht auszuhandeln, anscheinend gibt es aber einen Fallback auf NTLM.

Die Virtual Directory ist wie folgt konfiguriert:

Get-MapiVirtualDirectory | select Server,*auth*

Server IISAuthenticationMethods InternalAuthenticationMethods ExternalAuthenticationMethods
------ ------------------------ ----------------------------- -----------------------------
SW0123 {Ntlm, Negotiate} {Ntlm, Negotiate} {Ntlm, Negotiate}
SW0124 {Ntlm, Negotiate} {Ntlm, Negotiate} {Ntlm, Negotiate}
SW0125 {Ntlm, Negotiate} {Ntlm, Negotiate} {Ntlm, Negotiate}
SW0126 {Ntlm, Negotiate} {Ntlm, Negotiate} {Ntlm, Negotiate}

 

Über KLIST wird kein passendes Kerberos Ticket auf den Clients angezeigt bzw. erstellt !

Das ist für mich, wie auch oft beschrieben, der eindeutige Indikator, dass keine Kerberos Authentifizierung verwendet wird.

Kann mir da jemand von euch evtl. einen Gedankenanstoß geben, wo ich nach dem Problem suchen soll.

 

Viele Grüße

Daniel

 

 

 Datenschutz kritische Einträge wurden durch contoso ersetzt.

 

 


   
Zitat
(@docheadshot)
New Member
Beigetreten: Vor 4 Jahren
Beiträge: 2
Themenstarter  

Erkenntnis:

Die Problematik beruht auf dem Phänomen, dass Microsoft das KLIST Tool im Vergleich zu Windows 7 grundlegend umgebaut hat.

Um Kerberos Tickes auf Windows 10 im Benutzerkontext anzeigen zu lassen, muss man zuerst die User-Session mit " KLIST Sessions " finden

Ergebnis: [8] Sitzung 2 0:0xec7ed Somäne\Username Negotiate:RemoteInteractive

Dann muss man die Usertickets mit " KLIST Tickets -li <SessionsID> " anzeigen lassen. (ohne die führende 0 und dem Doppelpunkt)

z.B. klist tickets -li 0xec7ed

Das  http/exchange Kerberos Ticket wird daraufhin angezeigt. Alles funktioniert einwandfrei.

Windows 7 hat im Gegensatz zu Windows 10 über KLIST einfach alle Kerberos Tickets angezeigt ohne die Session zu spezifizieren.

Der Thread kann bitte geschlossen werden.


   
AntwortZitat

Teilen: