E2010CAS und Kerberos

Auslöser für diese Seite war der Blogeintrag  http://blogs.technet.com/b/exchange/archive/2011/04/15/recommendation-enabling-kerberos-authentication-for-mapi-clients.aspx im Exchange Team Blog, bei dem Microsoft den Einsatz von Kerberos für Exchange 2010 CAS-Server empfiehlt.

Voraussetzung ist die Installation von Exchange 2010 SP1!

Achtung Migrationen: Exchange 2016/2019 können das gleiche ASA-Konto nutzen aber nicht mit Exchange 2013 oder früher. Hier brauchen Sie separate ASA-Konten

Auch wenn MS im Blog den Einsatz von Kerberos empfiehlt und ich Kerberos natürlich auch präferiere, so ist dies im Falle des Exchange CAS-Server eher ein Thema für größere Umgebungen mit eine gewissen Anzahl paralleler Anmeldevorgänge pro Zeiteinheit. der klassische "Small Business"-Einsatz oder Kunden mit wenigen Hundert Anwendern wird die beschriebenen Grenzen vermutlich gar nicht erreichen. Wenn Sie jedoch mit Kerberos Delegation arbeiten wollen, dann ist die Einrichtung erforderlich.

Frühere Exchange Versionen haben schon Kerberos zur Authentifizierung genutzt, während dies bei Exchange 2010 RTM nicht mehr möglich war. Outlook und andere Clients sind dann auf NTLM zurück geschwenkt.

Exchange 2003 hat dies schon länger genutzt, wie folgender Artikel belegt

Exchange 2013/2016

Die Nutzung von Kerberos ist auch mit Exchange 20130und 2016 Frontend Rollen möglich und ratsam. Allerdings unterscheidet sich die Konfiguration ein wenig, wenn gleich nicht um viel. Bitte lesen und verstehen Sie den Inhalt dieser Seite als Grundlagenvermittlung

NTLM oder Kerberos und warum was ist mit Exchange 2010 SP1 anders?

Da stellt sich natürlich die Frage, warum Kerberos mit Exchange 2010 nicht mehr verwendet wurde. Kerberos ist wie NTLM ein Authentifizierungsverfahren. Anders als NTLM funktioniert es aber nicht so, dass das eigene Kennwort sicher an den Server übertragen wird, der es dann gegen einen DC prüft, sondern der Client holt sich von einem KDC (Kerberos Distribution Center) ein "Ticket", welches mit kryptografischen Methoden gesichert ist. Es ist z.B. vom ausstellenden Server digital signiert und zudem verschlüsselt.

Zur Verschlüsselung nutzt der KDC nun einen asymmetrischen Code. Dazu nimmt der KDC den angefragten Namen, sucht im AD nach einem passenden SPN und verschlüsselt mit der dort hinterlegten öffentlichen Information das Ticket und gibt es an den Client.

Der Client greift nun mit dem Ticket als Authentifizierung auf den Dienst zu. Der angesprochene Server entschlüsselt das Ticket mit seinem geheimen Schlüssel und prüft die Signatur und kann so sicherstellen, dass er der richtige Empfänger ist und das Ticket nicht verändert wurde. Damit ist aber auch klar, dass ein Ticket nur für den gewünschten Zielserver funktioniert.

Und da wird es nun knifflig, wenn es mehrere Server gibt, die unter dem gleichen Namen zu erreichen ist. Und das ist bei Exchange 2010 mit dem CASArray nun eher die Regel denn die Ausnahme. Hier erscheinen mehreren Server unter dem gleichen Namen. Damit die nun auch alle mit dem gleichen Kerberos-Ticket etwas anfangen können, müssen Sie alle die gleiche "geheime" Information können. Das funktioniert natürlich nicht, wenn die geheime Information des Computerkontos genutzt wird. Ein Service Principal Name (SPN) darf es nur genau einmal im Active Directory geben.

Die Lösung heißt also wieder, dass entweder extra Dienstkonto oder Computerkonto (Wie z.B., beim Cluster) angelegt wird. Dann müssen aber die Dienste alle daraus getrimmt werden, mit diesem Dienst zu arbeiten. Und genau diese Funktion ist mit Exchange 2010 SP1 endlich enthalten. Nur wenn Sie genau einen Server betreiben, ist dieser Kniff nicht erforderlich.

Übrigens: Es findet weiterhin aus "Aushandlung" des Authentifizierungsverfahren statt, d.h. nur weil ein Server Kerberos anbietet, muss es der Client nicht nutzen (z.B. wenn er aus dem Internet kein Ticket bekommen kann oder ein Proxy den Einsatz vereitelt (oft bei NTLM))

Warum ist Kerberos besser als NTLM?

Nun könnten Sie natürlich fragen, warum Sie manuell etwas tun sollten. NTLM funktioniert doch schon jahrzehntelang und das Kennwort ist doch auch sicher. Zudem hat es sogar noch die Einschränkung, dass es nur "intern" funktioniert, da der Client sich ja vom KDC ein Ticket holen muss. Und welcher DC ist schon aus dem Internet erreichbar ?

Da haben Sie auch recht und kleinere Firmen werden auch mit NTLM problemlos arbeiten. Aber NTLM hat Prinzip bedingt auch ein Problem. Der Client verschlüsselt einen vom Server gesendete Zufallszahl und der Server muss diese Anmeldung gegen den Domaincontroller verifizieren, d.h. jede für jede Anmeldung eines Clients am Dienstserver muss dieser zum Domaincontroller gehen. Das ist im LAN noch einfach aber wenn die Anmeldung durch einen Trust erfolgt oder der DC des Benutzers einfach weiter weg steht, kann das schon länger dauern. Das wäre aber nicht das Problem.

Kritischer ist hier eher die Belastung der DCs zu sehen, wenn ein CAS-Server z.B. 10.000 Benutzer bedient, die sich alle in kurzer Zeit morgens anmelden oder nach einem Ausfall der CAS wieder startet und dann alle Clients kommen. Der Engpass ist hier nämlich der DC, welcher nur eine bestimmte beschränkte Anzahl von Ressourcen für die Authentifizierung bereit stellt. Das ist eine "Schutzfunktion" aber natürlich auch ein Risiko. Eine solche Situation kann man sehr einfach im Eventlog erkennen:

Event ID : 5783
Category : None
Source : NETLOGON
Type : Error
Message : The session setup to the Windows NT or Windows 2000 Domain Controller 
\\DC01.msxfaq.de für the domain MSXFAQ is not responsive. The current RPC call 
from Netlogon on \\DC01 to \\DC01.msxfaq.de has been cancelled.

Suchen Sie einfach nach dem Eventlog Eintrag 5783 und der Quelle "NetLogon"

Über Kerberos ist aber auch "Delegation" möglich, d.h. der Einsatz einer Vorauthentifizierung an einer Firewall (z.B. TMG) wird einfacher möglich.

  • Kerberos
  • Kerberos Grundlagen
  • Constraint Delegation
  • 928576 New performance counters für Windows Server 2003 let you monitor the performance of Netlogon authentication
    by Default sind nur zwei (2) Threads für die Anmeldungen zuständig. Das kann bis auf 10 (oder 150 ab Windows 2008) hochgesetzt werden, hat aber andere Effekte (Angreifbarkeit)
  • 975363 A time-out error occurs when many NTLM authentication requests are sent from a computer that is running Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2
  • 326040 How to configure an ISA Server computer für a very large number of authentication requests
  • 928576 New performance counters für Windows Server 2003 let you monitor the performance of Netlogon authentication
  • NTLM: Alte Zöpfe abschneiden ist nicht so einfach
    http://blogs.technet.com/b/deds/archive/2010/10/28/ntlm-alte-z-246-pfe-abschneiden-ist-nicht-so-einfach.aspx

Exchange CAS-Dienste und Kerberos

Nun ist es ja nicht so, dass Exchange nur genau einen Dienst bereit stellt. Eine ganze Farm von Diensten und Zugriffswegen werden von Exchange für die Clients angeboten. Aber erst, wenn es im Active Directory einen passenden "SPN" gibt, kann ein Client überhaupt erst ein Ticket erhalten und Kerberos versuchen. Es hängt dann aber immer noch vom Server ab, ob er dem Client überhaupt "negotiate" anbietet, so dass dieser nach einem Ticket nachfragt.

Funktion Dienst Authentifizierung

RPC Client Access (MAPI per RPC)

MSExchangeRPC

NTLM, Kerberos nach Konfiguration

OWA

IIS

NTLM, Basic, Formbased, Kerberos nach Konfiguration

EWS

IIS

NTLM, Basic, Formbased, Kerberos nach Konfiguration

OAB-Download

IIS

NTLM, Basic, Formbased, Kerberos nach Konfiguration

RPC/HTTP

RPC-Proxy.DLL im IIS

NTLM, Offiziell geht Kerberos nicht, d.h. der RPCProxy bietet es nicht an

Bei Exchange 2010 RTM ist Kerberos nicht möglich und ab Exchange 2010 SP1 können Sie es aktivieren.

Wenn Sie Kerberos verwenden, müssen Sie als ersten Konfigurationsschritt ein Array mit bestimmten Dienstprinzipalnamen für die Clientzugriffsdienste einrichten. Sobald das Array eingerichtet ist, versuchen E-Mail-Clients, die für die Negotiate-Authentifizierung konfiguriert sind, die Kerberos-Authentifizierung durchzuführen. Sie rufen im Rahmen des Arrays Kerberos-Diensttickets ab, um diese dem Clientzugriffsserver vorzulegen. Im Allgemeinen werden Exchange-Dienste auf Clientzugriffsservern jedoch im Kontext des lokalen System- oder Netzwerkdienstkontos ausgeführt. Sie versuchen, die Kerberos-Diensttickets in diesem Kontext und nicht im Kontext des Arrays zu authentifizieren. Dies führt zu einem Kontextkonflikt und damit zu einem Kerberos-Authentifizierungsfehler. Aufgrund der erweiterten Sicherheit von Kerberos kehren für die Negotiate-Authentifizierung konfigurierte Clients nicht einfach zur NTLM-Authentifizierung zurück. Stattdessen verwenden sie entweder standardmäßig Outlook Anywhere (falls verfügbar), oder sie können Authentifizierung und Verbindung nicht durchführen.
Quelle: http://technet.microsoft.com/de-de/library/ff808313.aspx

Schritt 1: Dienstkonto einrichten

Damit alle CAS-Server das Kerberos Ticket decodieren können, müssen alle die gleiche "geheime" Information nutzen. Dazu müssen sie im Active Directory ein Dienstkonto einrichten. Das kann ein Benutzer oder Computerkonto sein. Ein Computerkonto hat den Vorteil, dass man es nicht zur "interaktiven Anmeldung" verwenden kann und das "CAS-ARRAY" ist ja auch eher ein Computer denn ein Benutzer. Ich lege daher bevorzugt ein Computerkonto in der OU "Microsoft Exchange System Objects" an.

Wenn Sie mehrere Standorte mit mehreren CAS-Arrays haben, dann können sie dennoch für alle CAS-Server das gleiche Dienstkonto nutzen. Achten Sie aber darauf, dass nicht ein Prozess im Hintergrund nach "ungenutzten" Computern fahndet und diese deaktiviert oder löscht. Der Effekt wäre dann, dass der KDC den SPN wieder nicht findet, der Client kein Ticket bekommt und sich dann wieder per NTLM anmeldet.

Zudem können Sie seit Windows 2008 verfügbaren "Managed Serviceaccounts" nicht nutzen. Diese funktionieren nur auf einem Computer aber nicht in einer Farm.

Schritt 2: Dienstkonto bei den CAS-Servern eintragen

Dazu hat Microsoft das Skript "RollAlternateServiceAccountPassword.ps1" im Scripts-Verzeichnis des Exchange Servers mit dem SP1 bereit gestellt. Damit kann der "Alternate Service Acccount (ASA)" gesetzt werden.

Achtung
Das ganze funktioniert nur, wenn es auch ein CASArray gibt.

# Initiales setzen des ASA Accounts
.\RollAlternateserviceAccountPassword.ps1 `
   -ToEntireForest `
   -GenerateNewPasswordFor "E2010\CAS-ASA$" `
   -Verbose 

Wenn Sie nur einen neuen CAS-Server in ein bestehendes CASArray addieren oder einen wiederhergestellten Server konfigurieren wollten, dann reicht das Kopieren der Daten von einem bestehenden Server des CAS-Array

.\RollAlternateServiceAccountPassword.ps1 `
   -CopyFrom ServerA `
   -ToSpecificServers ServerB `
   -Verbose

Die Ausgaben sind schon ziemlich "Farbig"

Aber besser ein paar Details mehr als zu wenig. Sie sehen hier, dass das Skript das Computerkonto auch gefunden hat und auch das CAS-Array, was in meiner Demo-VM natürlich auch aus nur einem Server besteht.

Achtung
Wenn Sie später weitere CAS-Server addieren, dann müssen diese auch erst die neuen ASA-Einstellungen erhalten, ehe Sie diese per Loadbalancer dann auch mit Last beaufschlagen.

Welche CAS-Server welche Konfiguration verwenden, können Sie ebenfalls per PowerShell auslesen.

# Anzeigen der aktuellen Konfiguration
Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialstatus |Fl Name, AlternateServiceAccountConfiguration

Schritt 3: OAB Virtual Directory anpassen

Ich kann es mir nicht anders erklären, als dass Microsoft es schlicht und einfach übersehen hat, dass das OAB Virtual Directory auch mit auf Kerberos umgestellt sein sollte. Zugegeben, so viele Zugriffe passieren nicht und per Default ist ja nicht mal ein eigener Application Pool, der für die Angabe von alternativen Anmeldedaten. Mittlerweile gibt es dazu aber ein PowerShell-Skript, welches genau diese Änderung nachreicht.

Hinweis: Exchange 2010 SP2
Das Skript ist seit Exchange 2010 SP2 im Verzeichnis "Scripts" im Exchange Programmverzeichnis enthalten.

Der Aufruf auf dem jeweiligen CAS-Server ist unspektakulär.

Im Hintergrund legt das PowerShell-Skript einen neuen Application Pool an und schreibt dort eine "web.config" in "$ExchangeInstallPath\ClientAccess\OAB\web.config". Diese enthält z.B. dann: 

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <modules>
      <add name="Microsoft.Exchange.OABAuth" type="Microsoft.Exchange.OABAuth.OABAuthModule" />
    </modules>

Nun sollte auch das OAB per Kerberos abrufbar sein.

Schritt 4: SPN eintragen

Noch sind aber alle Änderungen nur auf dem Server durchgeführt worden aber solange der KDC keine Tickets ausstellen kann, werden die Clients kein Kerberos nutzen, selbst wenn der Exchange Server auch "Negotiate" anbietet. Wenn der Client auf den Service zugreifen will, und um eine Anmeldung per Negotiate gebeten wird, dann fordert dieser vom KDC ein Ticket an (Siehe auch Kerberos Grundlagen).

Damit der KDC ein Ticket ausstellen kann, müssen diese im Active Directory an das Computerobjekt gebunden werden. Das kann per ADSIEDIT oder SETSPN erfolgen.

Achtung
Ein SPN darf es immer genau einmal im Active Directory Forest geben !

Folgende Namen sind dazu erforderlich. (Achtung: es ist wirklich nur ein "/" und kein http://....). Es wird angenommen, dass "casarrayname.firma.tld" der Name des CAS Array ist, welcher auch für die Webservices genutzt wird.

SPN erforderlich Beschreibung

exchangeMDB/casarrayname.firma.tld

Ja

Zugriff auf Postfächer

exchangeRFR/casarrayname.firma.tld

Ja

Zugriff auf "Referral"-Dienst

exchangeAB/casarrayname.firma.tld

Ja

Zugriff auf Adressbuchdienst

http/casarrayname.firma.tld

Ja

Zugriff auf Webservices

http/autodiscover.firma.tld

Optional

Autodiscover kann Kerberos und wird genutzt, wenn die Clients nicht per Service Connection Point (LDAP) die URL ermitteln

All diese Einträge werden alle an das eine Computerkonto (der ASA Account) gebunden.

setspn -a exchangeMDB/casarray.e2010.local cas-asa
setspn -a exchangeRFR/casarray.e2010.local cas-asa
setspn -a exchangeAB/casarray.e2010.local cas-asa
setspn -a http/casarray.e2010.local cas-asa

In der DOS-Box sieht das dann wie folgt aus:

Wer weitere Hostnamen über den Zugriff auf die Exchange Dienste oder andere CAS-Arrays hat, muss diese natürlich auch noch ergänzen. Nach dem Eintragen sollten Sie die Einstellungen wie angezeigt überprüfen. In größeren Umgebungen heißt es dann noch die AD-Replikation abzuwarten, ehe der KDC dann entsprechende Tickets vergibt.

Extern URLs sind nicht relevant
Wenn Sie für den Zugriff von Extern andere URLs verwenden (also ExternalURL <> InternalURL), dann brauchen Sie diese Adressen in der Regel nicht addieren, da externe Clients hoffentlich nie ihren KDC erreichen. Wenn Sie diese aber dennoch eintragen, dann stört das aber auch nicht.

Prüfen

Ob ihr Client dann tatsächlich sich per Kerberos anmeldet, können Sie am besten mit dem Programm KLIST oder KerbTray ermitteln. Beide Programme zeigen ihnen die Tickets an, die Sie aktuell in ihrer Session habe. Details dazu finden sie auch auf Kerberos Debugging.

Sollte Kerberos nicht funktionieren, weil der Client z.B. den KDC nicht erreicht, der SPN falsch eingetragen ist oder der Client über einen anderen Namen (Alias, CNAME, Hosts etc.) arbeitet und daher der SPN nicht gefunden wird, dann machen die Clients einen Fallback auf NTLM.

Was ist mit Outlook Anywhere?

Outlook Anywhere, also das Tunneln von RPC-Paketen über den RPCProxy-Dienst wird durch die Änderungen von Exchange 2010 SP1 NICHT betroffen. Es gilt weiterhin.

Use Basic Authentication or Windows Integrated Authentication to authenticate to the RPC Proxy?
RPC over HTTP currently supports only NTLM – it doesn't support Kerberos. Also, if there is an HTTP Proxy or a firewall between the RPC over HTTP client and the RPC Proxy which inserts the via pragma in the HTTP header, NTLM authentication will not work. When that is not the case, organizations can choose between Basic and NTLM authentication. The advantage of Basic authentication is that it is faster and simpler, and therefore offers less opportunity für denial of service attacks. But NTLM is more secure. Depending on an organization's priorities, it can choose Basic, NTLM, or allow its Users to choose between the two. If only one is chosen, it is best to turn off the other from the RPC Proxy virtual directory to reduce risk of attack.
http://msdn.microsoft.com/en-us/library/aa378641(v=vs.85).aspx

Diese Aussage ist so aber falsch. Nach Rücksprache und Analysen habe ich folgendes feststellen können.

  1. RPC unterstützt Kerberos
    Der Serverdienst auf dem Exchange CAS kann sehr wohl Negotiate anbieten und tut dies auch, wenn Sie im Exchange Server die Einstellungen auf NTLM gestellt haben.
  2. Outlook macht nur NTLM oder Basic
    Der RPC-Client, der quasi in Windows/Outlook genutzt wird, nutzt nur BASIC oder NTLM aber kein Kerberos. Das ist aber in den meisten Fällen auch kein Problem, denn ein Outlook im Internet wird in den wenigsten Fällen Kontakt zu seinem KDC bekommen, um ein Ticket zu erhalten.

Sie müssen dies natürlich auf dem CAS Server auch einrichten

Der Outlook Anyere-Service unterstützt aber noch viel mehr Authentifizierungsverfahren, die aber nur per PowerShell einstellen können.

  • Basic (Basic authentication)
  • Ntlm (NTLM authentication)
  • Digest (Digest authentication)
  • Fba (forms-based authentication)
  • WindowsIntegrated (Integrated Windows authentication)
  • LiveIdFba (Windows Live ID forms-based authentication)
  • LiveIdBasic (Windows Live ID Basic authentication)
  • WSSecurity (Windows SharePoint Security)
  • Certificate
  • NegoEx Negotiate Ex authentication is an authentication type reserved für future Microsoft use and shouldn't be used. Use of this setting will cause authentication to fail.
  • MaxValidValue
  • Misconfigured

Relevant sind aber nur Basic und NTLM. Achtung vor der dritten Option "Negotiate Ex Authentication"

Negotiate Ex authentication Do not click this button. Negotiate Ex authentication is an authentication type reserved für future Microsoft use and shouldn't be used. Use of this setting will cause authentication to fail.
Quelle: Configure Client Access Server Properties shttp://technet.microsoft.com/en-us/library/bb124503.aspx

Letztlich bedeutet dies aktuell (Stand Apr 2011), dass ein Outlook im internen Netzwerk bei einer Verbindung per RPC/HTTP trotz Kerberos auf dem CAS oder CAS-ARRAY weiterhin NTLM nutzt. Es bedeutet aber auch, dass ein TMG-Server per "Constraint Delegation" sehr wohl von extern ein Outlook per NTLM- oder BASIC-Authentication verifizieren kann und dann per Contraints Delegation den Zugriff zum CAS-Server weiter geben kann.

Forefront TMG?

Interessant wird das ganze nun, wenn die Dienste per Forefront TMG veröffentlicht werden. Zwar wissen wir nun, dass RPC/HTTP eben nicht Kerberos unterstützt und damit auch für Constraint Delegation ausfällt und wer OWA über die Formularanmeldung bei TMG als Vorauthentifizierung betreibt, hat auch keinen Bedarf. Hier "kennt" der TMG ja die Credentials des Benutzers und kann diese auch für NTLM nutzen. Aber für Autodiscover, EWS, OAB etc. kann es schon interessant sein, hier eine Vorauthentifizierung zu nutzen.

Publishing Outlook Anywhere using NTLM Authentication With Forefront TMG or Forefront UAG
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=040b31a0-9a69-4278-9808-e52f08ffaee3
Sehr lesenswertes Whitepaper

TMG kann beim Einsatz von Kerberos Delegation auf interne Dienste jede Authentifizierung aus dem Internet annehmen, d.h. Basic, NTLM aber auch Zertifikat und sogar Kerberos, wenn der Client denn ein Ticket vorweisen kann. Aber selbst beim Einsatz von NTLM oder Basic, welches die meist verwendeten Anmeldeverfahren im Internet sein dürften, kann der TMG dennoch nach hinten per "Delegation" arbeiten, wenn es denn vom Administrator erlaubt wurde.

„In NTLM delegation, Forefront TMG delegates the credentials by using the NTLM challenge/response authentication protocol”

“When you select Negotiate as a delegation method, Forefront TMG first attempts to obtain a Kerberos ticket für the client from the domain controller. If Forefront TMG does not receive the Kerberos ticket, it uses the negotiate scheme to delegate the credentials by using NTLM.”

Quelle: „Forefront TMG - About delegation of credentials „ http://technet.microsoft.com/en-us/library/cc995215.aspx

Wenn man also NTLM nutzen will, muss man dem TMG die Anmeldung für “/RPC” wegnehmen und die Authentifizierung innen machen lassen. Auch der ISA 2006 unterstützt schon diese Delegierung

Acceleration (ISA) Server 2006. ISA Server 2006 allows NTLM authentication to be used with Outlook Anywhere. Negotiate Ex authentication

Beachten Sie aber in allen Fällen einen kleinen unterschied bei der Veröffentlichung.

WebFarm oder Loadbalancer
Der TMG/ISA kann selbst eine Webseite auf einen internen Namen veröffentlichen, der z.B. per NLB oder Loadbalancer dann auf mehrere CAS-Server verteilt wird. Dabei muss aber beachtet werden, dass der Loadbalancer nicht per "SourceIP" verteilt, da dies immer der ISA/TMG ist.
Der TMG kann aber auch selbst auf eine "WebFarm" verteilen und so selbst als "Loadbalancer" agieren. Dann ist das "CASArray" aber nicht mehr maßgeblich. Der TMG/ISA geht dann direkt auf die einzelnen CAS-Server und nutzt deren Server-SPN.

Abschalten

Wenn Sie die Anmeldung per Kerberos sehr schnell verhindern wollen, dann löschen Sie einfach den SPN bei dem Dienstkonto.

setspn -d http/casarray.domain.tld

Schon kann der KDC keine Tickets mehr erstellen, d.h. die Clients bekommen kein Ticket mehr und versuchen gar nicht mehr per Kerberos sich anzumelden. Allerdings werden natürlich die Clients, die schon ein Ticket haben, diese noch einsetzen, bis es verfällt (default 6h)

Weitere Links