Konfigurieren der Kerberos-Authentifizierung für Clientzugriffsserver mit Lastenausgleich

 

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

Zum Verwenden der Kerberos-Authentifizierung mit einem Lastenausgleichsarray aus Clientzugriffsservern müssen mehrere Schritte zur Konfiguration ausgeführt werden. Weitere Informationen zur Verwendung von Kerberos bei einem Clientzugriffsserver-Array oder einer Lastenausgleichslösung finden Sie unter Verwenden von Kerberos mit einem Clientzugriffsserver-Array oder einer Lastenausgleichslösung.

Erstellen von alternativen Dienstkontoanmeldeinformationen in Active Directory

Alle Computer innerhalb des Clientzugriffsserver-Arrays müssen das gleiche Dienstkonto gemeinsam nutzen. Zusätzlich müssen alle Clientzugriffsserver, die möglicherweise in einem Datacenteraktivierungsszenario aufgerufen werden, das gleiche Dienstkonto gemeinsam nutzen. Im Allgemeinen ist in einzelnes Dienstkonto pro Gesamtstruktur ausreichend. Dieses Konto wird als alternative Dienstkontoanmeldeinformationen (ASA-Anmeldeinformationen) bezeichnet.

Anmeldeinformationstypen

Sie können ein Computer- oder Benutzerkonto für das alternative Dienstkonto erstellen. Da ein Computerkonto keine interaktive Anmeldung zulässt, verfügt es möglicherweise über einfachere Sicherheitsrichtlinien als ein Benutzerkonto und ist daher die bevorzugte Lösung für die ASA-Anmeldeinformationen. Wenn Sie ein Computerkonto erstellen, läuft das Kennwort nicht ab, es wird jedoch empfohlen, das Kennwort regelmäßig zu aktualisieren. In den lokalen Gruppenrichtlinien kann ein maximales Kontoalter für Computerkonten angeben sein, und möglicherweise sind Skripts geplant, mit denen regelmäßig Computerkonten gelöscht werden, die die aktuellen Richtlinien nicht erfüllen. Indem Sie die Kennwörter für Computerkonten regelmäßig aktualisieren, können Sie sicherstellen, dass Ihre Computerkonten nicht aufgrund von Verstößen gegen lokale Richtlinien gelöscht werden. Die lokale Sicherheitsrichtlinie bestimmt, wann das Kennwort geändert werden muss.

Name der Anmeldeinformationen

Es gibt keine speziellen Anforderungen für den Namen der ASA-Anmeldeinformationen. Sie können einen beliebigen Namen verwenden, der dem Namensschema entspricht.

Gruppen und Rollen

Die ASA-Anmeldeinformationen müssen nicht über besondere Sicherheitsberechtigungen verfügen. Wenn Sie ein Computerkonto für die ASA-Anmeldeinformationen bereitstellen, muss das Konto nur Mitglied der Sicherheitsgruppe "Domain Computers" sein. Wenn Sie ein Benutzerkonto für die ASA-Anmeldeinformationen bereitstellen, muss das Konto nur Mitglied der Sicherheitsgruppe "Domain Users" sein.

Kennwort

Das von Ihnen beim Erstellen eines Kontos verwendete Kennwort wird niemals benutzt werden. Stattdessen wird das Skript das Kennwort zurückzusetzen. Also können Sie beim Erstellen des Kontos ein beliebiges Kennwort verwenden, das den Kennwortrichtlinien Ihrer Organisation entspricht.

Gesamtstrukturübergreifende Szenarien

Bei einer gesamtstrukturübergreifenden oder Ressourcengesamtstruktur-Bereitstellung mit Benutzern außerhalb der Active Directory-Gesamtstruktur, die Exchange enthält, müssen gesamtstrukturübergreifende Vertrauensstellungen und Routingnamensuffixe konfiguriert werden. Weitere Informationen finden Sie unter Zugreifen auf Ressourcen über Gesamtstrukturen und Gesamtstrukturübergreifendes Routing von Namensuffixen.

Identifizieren der Dienstprinzipalnamen, die den alternativen Dienstkontoanmeldeinformationen zugeordnet werden sollen

Nach dem Erstellen eines alternativen Dienstkontos müssen Sie die Exchange-Dienstprinzipalnamen (Service Principal Names, SPNs) ermitteln, die den ASA-Anmeldeinformationen zugeordnet werden. Die Liste der Exchange-SPNs variiert je nach Konfiguration. Sie sollte jedoch mindestens folgende Angaben enthalten:

• http   Verwenden Sie diesen Dienstprinzipalnamen für Exchange-Webdienste, Offlineadressbuch-Downloads und den AutoErmittlungsdienst.

• exchangeMDB   Verwenden Sie diesen Dienstprinzipalnamen für den RPC-Clientzugriff.

• exchangeRFR   Verwenden Sie diesen Dienstprinzipalnamen für den Adressbuchdienst.

• exchangeAB   Verwenden Sie diesen Dienstprinzipalnamen für den Adressbuchdienst.

Die SPN-Werte müssen so konfiguriert sein, dass sie dem Dienstnamen entsprechen, der für den Netzwerklastenausgleich und nicht auf einzelnen Servern verwendet wird.

Betrachten Sie die folgenden konzeptionellen Szenarien, damit diese Ihnen bei der Planung helfen, welche SPN-Werte bereitgestellt werden sollen:

1. Einzelner Active Directory-Standort

2. Mehrere Active Directory-Standorte

3. Mehrere Active Directory-Standorte mit Ausfallsicherheit für DAG-Standorte (Database Availability Group)

In jedem dieser Szenarien wird angenommen, dass vollqualifizierte Domänennamen (Fully Qualified Domain Name, FQDN) mit Lastenausgleich für die internen URLs, externen URLs und für die AutoErmittlung des internen URIs bereitgestellt wurden, die von Mitgliedern des Clientzugriffsservers verwendet werden. Weitere Informationen finden Sie unter Grundlegendes zu Proxyfunktion und Umleitung.

Einzelner Active Directory-Standort

Wenn Sie über einen einzelnen Active Directory-Standort verfügen, ähnelt Ihre Umgebung möglicherweise der Umgebung in der folgenden Abbildung.

Auf Basis der vollqualifizierten Domänennamen, die von den internen Outlook-Clients in der vorherigen Abbildung verwendet werden, müssen die folgenden Dienstprinzipalnamen für die ASA-Anmeldeinformationen bereitgestellt werden:

• http/mail.corp.contoso.com

• http/autod.corp.contoso.com

• exchangeMDB/outlook.corp.contoso.com

• exchangeRFR/outlook.corp.contoso.com

• exchangeAB/outlook.corp.contoso.com

Externe oder internetbasierte Clients, die Outlook Anywhere nutzen, verwenden keine Kerberos-Authentifizierung. Daher müssen die von diesen Clients verwendeten vollqualifizierten Domänennamen nicht als Dienstprinzipalnamen zu den ASA-Anmeldeinformationen hinzugefügt werden.

Mehrere Active Directory-Standorte

Wenn Sie über mehrere Active Directory-Standorte verfügen, ähnelt Ihre Umgebung möglicherweise der Umgebung in der folgenden Abbildung.

Auf Basis der vollqualifizierten Domänennamen, die von den internen Outlook-Clients in der vorherigen Abbildung verwendet werden, müssen die folgenden Dienstprinzipalnamen für die ASA-Anmeldeinformationen bereitgestellt werden, die für den Clientzugriffsserver-Array mit dem Active Directory-Standort "ADSite1" verwendet werden:

• http/mail.corp.contoso.com

• http/autod.corp.contoso.com

• exchangeMDB/outlook.corp.contoso.com

• exchangeRFR/outlook.corp.contoso.com

• exchangeAB/outlook.corp.contoso.com

Auf Basis der vollqualifizierten Domänennamen, die von den internen Outlook-Clients in der vorherigen Abbildung verwendet werden, müssen die folgenden Dienstprinzipalnamen für die ASA-Anmeldeinformationen bereitgestellt werden, die für den Clientzugriffsserver-Array innerhalb des Active Directory-Standorts "ADSite2" verwendet werden:

• http/mailsdc.corp.contoso.com

• http/autodsdc.corp.contoso.com

• exchangeMDB/outlooksdc.corp.contoso.com

• exchangeRFR/outlooksdc.corp.contoso.com

• exchangeAB/outlooksdc.corp.contoso.com

Mehrere Active Directory-Standorte mit Ausfallsicherheit für DAG-Standorte

Wenn Sie über mehrere Active Directory-Standorte mit Ausfallsicherheit für DAG-Standorte verfügen, ähnelt Ihre Umgebung möglicherweise der Umgebung in der folgenden Abbildung.

Da diese Architektur eine Database Availability Group einbezieht, die sich über beide Active Directory-Standorte erstreckt, müssen Sie einzelne ASA-Anmeldeinformationen bereitstellen, die von Mitgliedern der Clientzugriffsserver-Arrays in "ADSite1" und "ADSite2" verwendet werden. Wenn Sie keine einzelnen ASA-Anmeldeinformationen verwenden, treten bei den Clients Kerberos-Authentifizierungsprobleme auf, wenn Sie einen Datacenterswitchover ausführen, da die Mitglieder des Clientzugriffsserver-Arrays des sekundären Datacenters das Kerberos-Sitzungsticket nicht entschlüsseln können. Weitere Informationen zum Aktivieren des sekundären Datacenters finden Sie unter Datencenterswitchover.

Auf Basis der vollqualifizierten Domänennamen, die von den internen Outlook-Clients in der vorherigen Abbildung verwendet werden, müssen die folgenden Dienstprinzipalnamen für die ASA-Anmeldeinformationen bereitgestellt werden, die für die Clientzugriffsserver-Arrays in "ADSite1" und "ADSite2" verwendet werden:

• http/mail.corp.contoso.com

• http/autod.corp.contoso.com

• exchangeMDB/outlook.corp.contoso.com

• exchangeRFR/outlook.corp.contoso.com

• exchangeAB/outlook.corp.contoso.com

• http/mailsdc.corp.contoso.com

• http/autodsdc.corp.contoso.com

• exchangeMDB/outlooksdc.corp.contoso.com

• exchangeRFR/outlooksdc.corp.contoso.com

• exchangeAB/outlooksdc.corp.contoso.com

Konvertieren des virtuellen Offlineadressbuch-Verzeichnisses in eine Anwendung

Standardmäßig ist das virtuelle Offlineadressbuch-Verzeichnis keine Webanwendung, sodass es nicht vom Microsoft Exchange-Dienst für den Diensthost gesteuert wird. Daher können Kerberos-Authentifizierungsanforderungen an das virtuelle Offlineadressbuch-Verzeichnis nicht von ASA-Anmeldeinformationen entschlüsselt werden.

Zum Konvertieren von virtuellen Offlineadressbuch-Verzeichnissen in Webanwendungen müssen Sie das Skript ConvertOABDir.ps1 auf jedem Clientzugriffsservermitglied ausführen. Mit dem Skript wird außerdem ein neuer Anwendungspool für das virtuelle Offlineadressbuch-Verzeichnis erstellt. Das Skript befindet sich im Skriptverzeichnis von Exchange 2010 SP2. Alternativ können Sie es auch hier herunterladen.

Bereitstellen der alternativen Anmeldeinformationen für das Dienstkonto

Nachdem Sie die ASA-Anmeldeinformationen erstellt haben, überprüfen Sie, ob das Konto auf alle Domänencontroller innerhalb aller Active Directory-Standorte repliziert wurden, die die Clientzugriffsserver enthalten, die diese ASA-Anmeldeinformationen verwenden.

Sie können das Anmeldeinformationsskript "AlternateServiceAccount" in der Exchange-Verwaltungsshell ausführen. Weitere Informationen finden Sie unter Verwenden des Skripts "RollAlternateserviceAccountCredential.ps1" in der Shell. Nach der Ausführung des Skripts sollten Sie überprüfen, ob alle Zielserver ordnungsgemäß aktualisiert wurden.

Hilfe zur Problembehandlung bei Skriptfehlern finden Sie unter Problembehandlung für das Skript "RollAlternateServiceAccountCredential.ps1".

In der folgenden Beispielausgabe des Skripts "RollAlternateServiceAccountPassword.ps1" wird ein Computerkonto verwendet, das für die ASA-Anmeldeinformationen erstellt wurde. Die Bezeichnung des Kontos lautet "contoso/newSharedServiceAccountName". Im folgenden Beispiel werden die Einstellungen für die Anmeldeinformationen vom Skript auf alle Mitglieder eines Clientzugriffsserver-Arrays mit der Bezeichnung "outlook.corp.contoso.com" angewendet.

Führen Sie das Skript mithilfe des folgenden Befehls aus.

RollAlternateServiceAccountPassword.ps1 -ToArrayMembers outlook.corp.contoso.com -GenerateNewPasswordFor contoso\newSharedServiceAccountName$

Nachdem Sie das Skript ausgeführt haben, sollten Sie die folgende Ausgabe erhalten. Sie werden aufgefordert, die Änderung des Kennworts zu genehmigen.

========== Started at 08/02/2010 15:48:09 ==========Destination servers that will be updated:Name----CASACASBCredentials that will be pushed to every server in the specified scope (recent first):UserName                               Password--------                               --------contoso\newSharedServiceAccountName$                System.Security.SecureStringPrior to pushing new credentials, all existing credentials that are invalid or no longer work will be removed from the destination servers.Pushing credentials to server CASAPushing credentials to server CASBSetting a new password on Alternate Service Account in Active DirectoryPassword changeDo you want to change password for contoso\newSharedServiceAccountName$ in Active Directory at this time?[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): yPreparing to update Active Directory with a new password for contoso\newSharedServiceAccountName$ ...Resetting a password in the Active Directory for contoso\newSharedServiceAccountName$ ...New password was successfully set to Active Directory.Retrieving the current Alternate Service Account configuration from servers in scopeAlternate Service Account properties:StructuralObjectClass QualifiedUserName       Last Pwd Update     --------------------- -----------------       ---------------     computer              contoso\newSharedServiceAccountName$ 8/2/2010 3:49:05 PM SPNs-----Per-server Alternate Service Account configuration as of the time of script completion:   Array: outlook.corp.contoso.comIdentity  AlternateServiceAccountConfiguration--------  ------------------------------------NAE14CAS  Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>NAE14CAS2 Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$          Previous: <Not set>

Außerdem werden zwei Ereignis-IDs in den Ereignisprotokollen angezeigt. Ein Ereignis betrifft den Start des Skripts und das andere den erfolgreichen Abschluss. Nachfolgend ist ein Ausschnitt des Ereignisses für den erfolgreichen Abschluss aufgeführt.

Log Name:      ApplicationSource:        MSExchange Management ApplicationEvent ID:      14002Task Category: KerberosLevel:         InformationDescription:Maintenance of the Alternate Service Accounts succeeded.

Überprüfen der Bereitstellung von ASA-Anmeldeinformationen

Führen Sie in der Exchange-Verwaltungsshell den folgenden Befehl aus, um die Einstellungen auf den Clientzugriffsservern zu überprüfen.

Get-ClientAccessServer -IncludeAlternateServiceAccountCredentialStatus | fl name,*alter*

Das Ergebnis dieses Befehls sollte wie folgt aussehen.

Name                                 : CASAAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:38 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>Name                                 : CASBAlternateServiceAccountConfiguration : Latest: 8/2/2010 3:48:51 PM, contoso\newSharedServiceAccountName$                                       Previous: <Not set>

Wenn Sie das Skript mehrfach ausführen und Änderungen vorgenommen haben, zeigt der Eintrag "Previous" an, wann die letzte Änderung vorgenommen wurde.

Name                                 : NAE14CASAlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$Name                                 : NAE14CAS2AlternateServiceAccountConfiguration : Latest: 8/2/2010 4:32:38 PM, contoso\newSharedServiceAccountName$                                       Previous: 8/2/2010 4:32:24 PM, contoso\sharedkerbacct$

Zuordnen von Dienstprinzipalnamen zu alternativen Dienstkontoanmeldeinformationen

Überprüfen Sie vor der Konfiguration der SPNs, dass die Ziel-SPNs nicht bereits auf einem anderen Konto in der Gesamtstruktur konfiguriert wurden. Die ASA-Anmeldeinformationen müssen das einzige Konto in der Gesamtstruktur darstellen, denen diese SPNs zugeordnet sind. Sie können überprüfen, ob einem anderen Konto in der Gesamtstruktur die SPNs zugeordnet sind, indem Sie den Befehl setspn mit den Parametern –q und –f an der Befehlszeile ausführen. Im folgenden Beispiel wird gezeigt, wie dieser Befehl ausgeführt wird. Der Befehl sollte nichts zurückgeben. Wenn ein Wert zurückgegeben wird, ist bereits ein anderes Konto dem zugedachten SPN zugeordnet.

Setspn -q -f exchangeMDB/outlook.corp.contoso.com

Der folgende Befehl stellt ein Beispiel bereit, wie die SPNs für die freigegebenen ASA-Anmeldeinformationen festgelegt werden. Der Befehl "setspn" muss mit dieser Syntax einmal für jeden von Ihnen identifizierten Ziel-SPN ausgeführt werden.

Setspn -S exchangeMDB/outlook.corp.contoso.com contoso\newSharedServiceAccountName$

Überprüfen Sie nach dem Festlegen der SPNs mithilfe des folgenden Befehls, ob sie hinzugefügt wurden.

Setspn -L contoso\newSharedServiceAccountName$

Überprüfen der Kerberos-Authentifizierung des Exchange-Clients

Überprüfen Sie nach der erfolgreichen Konfiguration von Kerberos und der Bereitstellung des Skripts "RollAlternateServiceAccountPasswordl.ps1", ob die Clients erfolgreich authentifiziert werden können.

Überprüfen, ob der Microsoft Exchange-Diensthost ausgeführt wird

Der Microsoft Exchange-Diensthost auf den Clientzugriffsservern ist für die Verwaltung der ASA-Anmeldeinformationen zuständig. Wenn dieser Dienst nicht aktiv ist, kann die Kerberos-Authentifizierung nicht verwendet werden. Der Dienst ist standardmäßig so konfiguriert, dass er automatisch beim Start des Computers gestartet wird. Stellen Sie sicher, dass Sie Exchange Server 2010 SP1 Rollup 3 oder eine spätere Version auf allen Clientzugriffsservern in Ihrer Umgebung installiert haben.

Überprüfen der Outlook-Authentifizierung

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass Outlook mit den Clientzugriffsservern mit der Kerberos-Authentifizierung verbunden werden kann:

1. Stellen Sie sicher, dass Outlook so konfiguriert ist, dass es auf das korrekte Lastenausgleich-Clientzugriffsserver-Array verweist.

2. Konfigurieren Sie die Sicherheitseinstellungen für den E-Mail-Kontenserver, sodass als Netzwerksicherheit bei der Anmeldung die Negotiate-Authentifizierung verwendet wird. Sie können den Client auch für die Verwendung der Kerberos-Kennwortauthentifizierung konfigurieren. Wenn die SPNs jedoch irgendwann entfernt werden, können die Clients keine Authentifizierung durchführen, bis Sie als Authentifizierungsmechanismus wieder die Negotiate-Authentifizierung festlegen.

3. Stellen Sie sicher, dass Outlook Anywhere für den Client nicht aktiviert ist. Wenn die Authentifizierung mit Kerberos für Outlook fehlschlägt, wird ein Fallback auf Outlook Anywhere versucht, sodass Outlook Anywhere für diesen Test deaktiviert werden sollte.

4. Starten Sie Outlook neu.

5. Wenn auf Ihrem Desktopcomputer Windows 7 ausgeführt wird, können Sie klist.exe ausführen, um anzuzeigen, welche Kerberos-Tickets erteilt wurden und verwendet werden. Wenn Sie nicht Windows 7 ausführen, erhalten Sie "klist.exe" im Windows Server 2003 Resource Kit.

Überprüfen mit dem Cmdlet "Test-OutlookConnectivity"

Verwenden Sie zum Testen, ob Kerberos funktioniert, das Cmdlet Test-OutlookConnectivity. So können Sie am besten feststellen, ob eine TCP-Verbindung hergestellt werden kann. Standardmäßig verwendet das Cmdlet eine Aushandlungsauthentifizierung für eine TCP-Verbindung. Wenn Kerberos konfiguriert ist, wird es verwendet. Die Datei "klist.exe" kann verwendet werden, um Kerberos-Tickets auf einem Computer anzuzeigen. Sie kann direkt auf dem Clientzugriffsserver oder über ein automatisiertes Überwachungstool, z. B. SCOM, ausgeführt werden. Stellen Sie beim Verwenden des Cmdlets Test-OutlookConnectivity sicher, dass für die Postfachdatenbank die Eigenschaft RPCClientAccessServer auf den Namen des Clientzugriffsserver-Arrays festgelegt ist. Nur so wird mit dem Cmdlet die Funktionalität für freigegebene ASA-Anmeldeinformationen getestet.

Test-OutlookConnectivity -Identity administrator -MailboxCredential $c -Protocol tcp

Zeigen Sie die Datei "klist.exe" an, um sicherzustellen, dass die Verbindung mit Kerberos hergestellt wurde, und um festzustellen, ob Kerberos-Tickets den neuen hinzugefügten SPNs zugeordnet wurden.

Überprüfen von Kerberos vom Clientzugriffsserver

Sie können die Protokolle untersuchen, um sicherzustellen, dass Kerberos vom Clientzugriffsserver ordnungsgemäß funktioniert und die Kerberos-Verbindungen erfolgreich hergestellt werden. Sie können diese Protokolle zusätzlich zu anderen Überprüfungsmöglichkeiten verwenden, um sicherzustellen, dass Kerberos verwendet wird.

• Untersuchen Sie die Adressbuchprotokolle auf dem Clientzugriffsserver. Diese Protokolle befinden sich in der Regel unter dem folgenden Pfad: C:\Programme\Microsoft\Exchange Server\v14\Logging\AddressBook Service.

• Suchen Sie in der neuesten Protokolldatei das Wort "Kerberos" nachdem das Skript ausgeführt wurde. Wenn Kerberos-Datenverkehr angezeigt wird, wurde eine Verbindung erfolgreich hergestellt. Die Zeile in der Protokolldatei sollte der folgenden ähneln.

  2010-06-11T22:58:49.799Z,9,0,/o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Administrator,,2001:4898:f0:3031:99f:ce35:750a:8b09,EXCH-A-363,ncacn_ip_tcp,Bind,,6,,,Kerberos,
  

Wenn das Wort "Kerberos" angezeigt wird, erstellt der Server erfolgreich Verbindungen mit der Kerberos-Authentifizierung. Weitere Informationen zum Adressbuchdienstprotokoll finden Sie unter Grundlegendes zum Adressbuchdienst.

Problembehandlung von Authentifizierungsfehlern

Es gibt verschiedene häufige Probleme, die möglicherweise bei der Konfiguration der Kerberos-Authentifizierung auftreten.

Für die Kerberos-Authentifizierung konfigurierte Outlook-Clients können keine Verbindung herstellen

Wenn der für die alleinige Verwendung der Kerberos-Authentifizierung konfigurierte Outlook-Client keine Verbindung herstellen kann, führen Sie die folgenden Schritte zur Problembehandlung durch:

1. Konfigurieren Sie Outlook für die alleinige Verwendung der NTLM-Authentifizierung, und überprüfen Sie anschließend die Konnektivität. Wenn keine Verbindung hergestellt werden kann, überprüfen Sie, ob das Clientzugriffsserver-Array verfügbar und die Netzwerkverbindung stabil ist.

   Wenn die NTLM-Verbindung erfolgreich ist, die Kerberos-Verbindung jedoch nicht, überprüfen Sie, ob SPNs auf einem anderen Konto als dem alternativen Dienstkonto registriert sind. Stellen Sie sicher, dass die Exchange-SPNs auf dem Konto registriert sind, das vom gemeinsam genutzten, alternativen Dienstkonto verwendet wird, indem Sie den Abfragebefehl "setSPN" wie weiter oben in diesem Thema beschrieben verwenden.

2. Stellen Sie sicher, dass das Kennwort zwischen allen Clientzugriffsservern und Active Directory koordiniert wurde. Führen Sie dafür das Skript im beaufsichtigten Modus aus, und generieren Sie ein neues Kennwort.

3. Stellen Sie sicher, dass der Microsoft Exchange-Adressbuchdienst auf den Clientzugriffsservern ausgeführt wird.

4. Wenn die Authentifizierung noch immer nicht erfolgreich ist, stellen Sie sicher, dass für die virtuellen Verzeichnisse für die Dienste, auf die Sie mit Kerberos zugreifen möchten, die integrierte Windows-Authentifizierung aktiviert ist. Mithilfe der Cmdlets "Get-VirtualDirectory" können Sie die Authentifizierungsmethoden überprüfen. Weitere Informationen zu virtuellen Verzeichnissen finden Sie unter Grundlegendes zu virtuellen Outlook Web App-Verzeichnissen und Grundlegendes zu den virtuellen Verzeichnissen der Exchange-Webdienste.

Fehler des AutoErmittlungsdiensts

Wenn Sie den folgenden Fehler des AutoErmittlungsdiensts feststellen, ist die Ursache dafür meist ein großes Kerberos-Authentifizierungsticket in der Kopfzeile der AutoErmittlungsdienst-Serviceanfrage, wodurch die Kopfzeilengröße den vom Server der Internetinformationsdienste (IIS) konfigurierten Grenzwert überschreitet. Der Fehler ist ähnlich dem folgenden.

HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=us-ascii
Server: Microsoft-HTTPAPI/2.0
Date: Tue, 09 Mar 2010 18:06:18 GMT
Connection: close
Content-Length: 346

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""https://www.w3.org/TR/html4/strict.dtd">

<HTML><HEAD><TITLE>Bad Request</TITLE>

<META HTTP-EQUIV="Content-Type" Content="text/html; charset=us-ascii"></HEAD>

<BODY><h2>Bad Request - Request Too Long</h2>

<hr><p>HTTP Error 400. The size of the request headers is too long.</p>

</BODY></HTML>

Erhöhen Sie den Grenzwert der IIS-Kopfzeile, um diesen Fehler zu beheben. Weitere Informationen finden Sie unter IIS-Dokumentation (möglicherweise in englischer Sprache).

Fortlaufende Wartung von ASA-Anmeldeinformationen

Wenn das lokale Kennwort der gemeinsam genutzten ASA-Anmeldeinformationen regelmäßig aktualisiert werden muss, finden Sie Anweisungen zum Einrichten einer geplanten Aufgabe für die regelmäßige Kennwortwartung unter Verwenden des Skripts "RollAlternateserviceAccountCredential.ps1" in der Shell. Stellen Sie sicher, dass die geplante Aufgabe für die rechtzeitigen Kennwortrollover überwacht wird und mögliche Authentifizierungsausfälle verhindert werden.

Deaktivieren der Kerberos-Authentifizierung

Um für das Clientzugriffsserver-Array wieder festzulegen, dass Kerberos nicht verwendet wird, entfernen Sie die SPNs vom gemeinsam genutzten Dienstkonto. Nach dem Entfernen der SPNs versuchen die Clients keine Kerberos-Authentifizierung, und Clients, für die die Negotiate-Authentifizierung konfiguriert ist, verwenden NTLM. Clients, für die ausschließlich die Verwendung von Kerberos konfiguriert ist, können keine Verbindung herstellen. Nach dem Entfernen der SPNs sollten Sie auch das gemeinsam genutzte Dienstkonto entfernen. Sie können das Wartungsskript verwenden, um Anmeldeinformationen von allen Mitgliedern des Clientzugriffsserver-Arrays zu löschen. Verwenden Sie dazu den Parameter toEntireForest und den Parameter "-copy from server", um einen Server ohne Kerberos-Anmeldeinformationen anzugeben. Außerdem sollten Sie möglicherweise alle Clientcomputer neu starten, um den Inhalt des Kerberos-Ticketcache zu löschen.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.