Exchange 2013: Authentifizierung auf Kerberos umstellen

In der Standardeinstellung werden Verbindungen von Outlook zu Exchange 2013 mit NTLM authentifiziert. In Umgebungen mit mehreren CAS-Servern und vielen Clients erzeugt NTLM allerdings unnötig Last auf den DCs, gerade weil Loadbalancer sich nicht mehr um Persistenz kümmern müssen. Hier sollte die Authentifizierung besser mit Kerberos erfolgen, damit nicht jeder CAS-Server die Verbindung neu authentifizieren muss. In diesem Howto wird die Authentifizierung auf Kerberos mit Fallback auf NTLM umgestellt. Meine Testumgebung enthält aktuell nur einen Exchange 2013 Server in der Standard Konfiguration.

Im ersten Screenshot sieht man das Verbindungen via NTLM authentifiziert werden und Outlook aktuell den FQDN (ex1.frankysweb.local) als Proxyserver nutzt:

1

Zunächst sollte also ein allgemeiner Zugriffspunkt für Outlook definiert werden. Dazu lege ich den Host-A Record „outlook.frankysweb.local“ an und gebe als IP-Adresse die IP meines Exchange Servers an. Wenn mehrere CAS-Sever zum Einsatz kommen, kann dieser Eintrag entweder mit mehrfach mit den jeweiligen IPs der Exchange CAS Server angelegt werden (DNS Round Robin), oder wenn ein Loadbalancer genutzt wird, die IP des Loadbalancers eingetragen werden

2

Sobald der DNS Eintrag erstellt wurde und von den Clients aufgelöst werden kann, können die Exchange Webservices auf den neuen Namen konfiguriert werden:

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/owa“
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/ecp“
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/EWS/exchange.asmx“
Get-OabVirtualDirectory | Set-OabVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/OAB“
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory -InternalUrl „https://outlook.frankysweb.local/Microsoft-Server-ActiveSync“
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname outlook.frankysweb.local -InternalClientsRequireSsl:$true

3

Autodiscover verteilt die neuen Einstellungen nach einiger Zeit automatisch an die Clients (siehe weiter unten, Event 3025), sodass Outlook nun über „outlook.frankysweb.local“ auf Exchange zugreift. Dieser DNS-Name muss natürlich auch auf dem Zertifikat vorhanden sein, damit es nicht zu Warnungen kommt.

4

Um Keberos als Authentifizierungsmethode nutzen zu können, ist ein Computer Konto erforderlich. Daher erstelle ich ein neues Computer Konto im Active Directory mit dem Namen „CASASA“ in der OU „Microsoft Exchange Security Groups“. Mit welchem Namen oder in welcher OU das Konto erstellt wird, spielt keine Rolle, Hauptsache es wird nicht gelöscht oder verändert.

Kerberos

Damit das neue Computer Konto genutzt werden kann, braucht das Konto ein Passwort. Aktuell verfügt das Konto über kein Passwort, da kein Computer mit dem Namen CASASA dem Active Directory beigetreten ist. Um ein Passwort für das Computer Konto zu vergeben, wird der „DistinguishedName“ des Kontos benötigt:

6

Die folgenden Zeilen VBS-Code können dazu benutzt werden das Passwort zu vergeben, einfach den DN ersetzen und ein entsprechendes Passwort wählen. Der Text kann dann in eine .VBS Datei eingefügt werden.

Set objComputer = GetObject _
(„LDAP://CN=CASASA,OU=Microsoft Exchange Security Groups,DC=frankysweb,DC=local„)
objComputer.SetPassword „MeinPasswort

Jetzt noch das VBS Script ausführen:

cscript .\computerpassword.vbs

Für das Computerkonto wird jetzt noch ein Service Principal Name (SPN) im Active Directory registriert. das passiert mit folgendem Befehl:

setspn -a HTTP/outlook.frankysweb.local FrankysWeb\CASASA$

7

Jetzt kann der Alternate Service Account (ASA bzw. unser neues Computerkonto) an die Client Access Server gebunden werden, dazu können folgende Befehle verwendet werden:

$creds = Get-Credential -Credential „FrankysWeb\CASASA$“
Set-ClientAccessServer EX1 -AlternateServiceAccountCredential $creds

8

Mit dem folgenden Befehl kann überprüft werden, ob das Konto erfolgreich an die Client Access Server gebunden wurde:

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialPassword | fl

9

Jetzt ist es an der Zeit die Authentifizierungsmethode umzustellen. Die Authentifizierung wird auf „Aushandeln (Negotiate)“ festgelegt, da wir nun über einen SPN und ein Alternate Service Account (ASA) verfügen, ist Exchange in der Lage Kerberos auszuhandeln. Falls die Kerberosaushandlung fehlschlagen sollte, wird NTLM als Fallback gewählt. Um die Authentifizierung umzustellen wird der folgende Befehl eingegeben:

Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate -IISAuthenticationMethods Negotiate,NTLM

10

Autodiscover wird die Outlook Profile automatisch umstellen, es dauert allerdings etwas bis Autodiscover die Änderungen mitbekommt. Spätestens nach 15 Minuten sollte sich im Event Log das Ereignis 3025 zu finden sein. Die Konfiguration wurde somit aktualisiert:

11

Es kann allerdings noch einmal bis zu 2 Stunden dauern bis die Outlook Profile umgestellt werden. Hier ist Geduld eine Tugend, oder man klickt im Outlook Profil auf „Reparieren“… (aber bitte erst nach dem Event 3025)

(Ich musste in meiner Testumgebung nach dem Klick auf „Reparieren“ Outlook wieder in den Online Modus schalten)

15

Nachdem das Konto also auf den aktuellen Stand ist, kann überprüft werden, ob die Authentifizierung auch tatsächlich mit Kerberos erfolgt, dazu werden am besten alle Keberos Tickets gelöscht, damit neu authentifiziert werden muss:

klist purge

13

Outlook zeigt jetzt als Authentifizierung „Nego“ an, das ist soweit in Ordnung:

12

Mit dem Befehl „klist“ können wir uns die Keberos Tickets anzeigen lassen

klist

Wenn alles geklappt hat, wird ein Ticket angezeigt, das auf den zuvor konfigurierten SPN zeigt:

14

Sollte das Ticket noch nicht angezeigt werden… Geduld ist eine Tugend Smiley

13 Kommentare zu “Exchange 2013: Authentifizierung auf Kerberos umstellen”

  1. Hi Franky,
    danke für den Artikel! Beim ausführen des VBS-Scripts erhalte ich den Fehler:
    „CASASA-Computer-PW.vbs(2, 2) Microsoft VBScript compilation error: Invalid character“
    Die VBS Datei ist als ANSI Formatiert/gespeichert!
    Kannst Du da Helfen?
    Danke!
    Gruß Jörg

  2. Hi Franky,

    danke für diese Anleitung. Hast du auch eine für das Zertifikat, das ich jetzt anpassen muss?

    Vielen Dank
    Gruß
    Daniel

  3. Hi Franky,

    kurze Frage, kannst Du etwas zum Impact sagen, den diese Änderung mit sich bringt für User die aktuell keine Verbindung zum Corporate Network haben? Bekommen die einfach irgendwann die „Der Administrator hat eine Änderung vorgenommen -> Outlook neu starten“ Meldung, können das Extern machen und gut, oder besteht die Gefahr, dass die User die zum Zeitpunkt der Umstellung extern sind die Gefahr, dass sie komplett abgehangen und auf Outlook Web App beschränkt sind, bis sie wieder am Coporate Network hängen?

    Vielen Dank & Gruß,
    Markus

    1. Hi Markus,
      ein Outlook Neustart ist nicht erforderlich. NTLM wird weiterhin als Fallback angeboten, es sollte also zu keinerlei Auswirkungen kommen.
      Gruß, Frank

  4. Hi Frank, tolle Anleitung!

    was müsste denn im Outlook-Verbindungsstatus stehen, wenn er einen Fallback auf NTLM macht?
    Was bedeutet das „Authn: Nego [Anonym] Verschlüsseln: SSL [Nein] „? Ist die Verbindung dann unsicher?

    Gruß
    Dominik

  5. Hallo Frank,

    super Anleitung! Allerdings wird in meinem Verbindungsstatus (ebenso wie bei Dominik vom 04.11.16) „Authn: Nego [Anonym] Verschlüsseln: SSL [Nein] “ angezeigt – was hat „Anonym“ uns insb. „SSL [Nein]“ zu bedeuten?

    Danke & Gruß
    Philipp

  6. Hm.. geht das auch für die exchange Powershell… ich bastel mir das gerade über einen Kemp Loadmaster.

    Die Basisauthentifizierung läuft schon… hm…

  7. Danke für die gute Anleitung! Soweit funktioniert auch alles. Zu Problem kommt es allerdings dann, wenn man ein Postfach einbinden möchte, welches sich von dem angemeldeten Domain User unterscheidet. D.h. User A meldet sich an der Domäne an und stafrte Outlook – alles gut; Bindet man unter dem Domain Profil von User A allerdings ein MAPI Profil von User B ein, erscheint bei jedem Outlookm Start eine Passwortabfrage. Selbiges gillt auch wenn User A sich das Postfach von User B manuell ins selbe MAPI Profil hinzufügt – ständige Password Abfragen. Bei Shared mailboxen tritt es aber nicht auf…
    Über einen Tipp wäre ich dankbar! :)

  8. Hallo Frank,
    echt toll, wie ausfürhlich die Themen hier behandelst :) Mich interessiert ob du es in deinen Umgebungen jemals hinbekommen hast, Kerberos mit NTLM Fallback für MAPI über Http für Domänen-Computer die sich ausserhalb des internen Netzwerks aufhalten hinzubekommen, ohne dass die Benutzer bei jeden Outlook Start nach dem Kennwort gefragt werden wenn sie nicht abspeichern.

    Für Outlook Anywhere ist dies kein Problem :( Ich bin nach Monaten bei dem Thema wirklich mit meinem Latein am Ende und überlege grundsätzlich einfach nur NTLM für MAPI über HTTP zu verwenden, da dass Problem beim Entfernen von Negotiate aus der Konfiguration nicht auftritt…

    Gruß

    Benjamin

  9. Hallo Frank,

    Mich würde interessieren ob du Kerberos auch bei mapi über http für Clients außerhalb des Domänen Netzwerks bereitstellst, bzw. das Thema schon mal behandelt hast. Ich verfolge da nämlich einen Ansatz mittels Kerberos Proxy, der sehr sehr gut funktioniert, sicherer als NTLM für Remote User ist und lästige Passwort Prompts bei Abwesenheit vom internen Netz vollends eliminiert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.