Konfigurieren der Kerberos-Authentifizierung für Clientzugriffsserver mit Lastenausgleich
Gilt für: Exchange Server 2013
Zusammenfassung: Beschreibt die Verwendung der Kerberos-Authentifizierung mit Clientzugriffsservern mit Lastenausgleich in Exchange 2013.
Damit Sie die Kerberos-Authentifizierung mit Clientzugriffsservern mit Lastenausgleich verwenden können, müssen Sie die in diesem Artikel beschriebenen Konfigurationsschritte ausführen.
Erstellen von alternativen Dienstkontoanmeldeinformationen in Active Directory Domain Services
Alle Clientzugriffsserver, die dieselben Namespaces und URLs verwenden, müssen die gleichen anmeldeinformationen für das alternative Dienstkonto verwenden. Im Allgemeinen ist es ausreichend, über ein einziges Konto für eine Gesamtstruktur für jede Version von Exchange zu verfügen. Alternative Dienstkontoanmeldeinformationen oder ASA-Anmeldeinformationen.
Wichtig
Exchange 2010 und Exchange 2013 können nicht dieselben ASA-Anmeldeinformationen verwenden. Sie müssen neue ASA-Anmeldeinformationen für Exchange 2013 erstellen.
Wichtig
CNAME-Datensätze werden für freigegebene Namespaces zwar unterstützt, Microsoftempfiehlt jedoch die Verwendung von A-Datensätzen. Dadurch wird sichergestellt, dass der Client ordnungsgemäß eine Kerberos-Ticketanforderung basierend auf dem freigegebenen Namen und nicht auf dem Server-FQDN ausstellt.
Wenn Sie die ASA-Anmeldeinformationen einrichten, beachten Sie diese Richtlinien:
Kontotyp: Es wird empfohlen, anstelle eines Benutzerkontos ein Computerkonto zu erstellen. Ein Computerkonto lässt die interaktive Anmeldung nicht zu und hat möglicherweise einfachere Sicherheitsrichtlinien als ein Benutzerkonto. Wenn Sie ein Computerkonto erstellen, läuft das Kennwort nicht ab, es wird jedoch empfohlen, das Kennwort regelmäßig zu aktualisieren. Sie können eine lokale Gruppenrichtlinie verwenden, um ein Höchstalter für das Computerkonto und Skripts anzugeben, um Computerkonten, die den aktuellen Richtlinien nicht entsprechen, regelmäßig zu löschen. Ihre lokale Sicherheitsrichtlinie bestimmt auch, wann Sie das Kennwort ändern müssen. Obwohl Sie ein Computerkonto verwenden sollten, können Sie auch ein Benutzerkonto erstellen.
Kontoname: Es gibt keine Anforderungen für den Namen des Kontos. Sie können einen beliebigen Namen verwenden, der dem Namensschema entspricht.
Kontogruppe: Das Konto, das Sie für die ASA-Anmeldeinformationen verwenden, benötigt keine besonderen Sicherheitsberechtigungen. Wenn Sie ein Computerkonto verwenden, muss das Konto nur Mitglied der Sicherheitsgruppe "Domain Computers" sein. Wenn Sie ein Benutzerkonto verwenden, muss das Konto nur Mitglied der Sicherheitsgruppe "Domain Users" sein.
Kontokennwort: Das Kennwort, das Sie beim Erstellen des Kontos angeben, wird verwendet. Daher sollten Sie beim Erstellen des Kontos ein komplexes Kennwort verwenden und sicherstellen, dass das Kennwort den Kennwortrichtlinien Ihrer Organisation entspricht.
So erstellen Sie ASA-Anmeldeinformationen als Computerkonto
Führen Sie auf einem Domänencomputer Windows PowerShell oder die Exchange-Verwaltungsshell aus.
Verwenden Sie das Import-Module -Cmdlet, um das Active Directory-Modul zu importieren.
Import-Module ActiveDirectory
Verwenden Sie das New-ADComputer -Cmdlet, um ein neues Active Directory-Computerkonto mithilfe dieser Cmdlet-Syntax zu erstellen:
New-ADComputer [-Name] <string> [-AccountPassword <SecureString>] [-AllowReversiblePasswordEncryption <System.Nullable[boolean]>] [-Description <string>] [-Enabled <System.Nullable[bool]>]
Beispiel:
New-ADComputer -Name EXCH2013ASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2013ASA
Exch2013ASA ist der Name des Kontos, die Beschreibung alternativer Dienstkontoanmeldeinformationen für Exchange entspricht dem gewünschten Wert, und der Wert für den Parameter SamAccountName, in diesem Fall EXCH2013ASA, muss in Ihrem Verzeichnis eindeutig sein.
Verwenden Sie das Set-ADComputer -Cmdlet, um mithilfe der folgenden Cmdlet-Syntax die Unterstützung des AES 256-Verschlüsselungsverfahrens zu aktivieren, das von Kerberos verwendet wird:
Set-ADComputer [-Name] <string> [-add @{<attributename>="<value>"]
Beispiel:
Set-ADComputer EXCH2013ASA -add @{"msDS-SupportedEncryptionTypes"="28"}
Dabei ist EXCH2013ASA der Name des Kontos und das zu ändernde Attribut msDS-SupportedEncryptionTypes mit einem Dezimalwert von 28, was die folgenden Verschlüsselungen ermöglicht: RC4-HMAC, AES128-CTS-HMAC-SHA1-96, AES256-CTS-HMAC-SHA1-96.
Weitere Informationen zu diesen Cmdlets finden Sie unter Import-Module und New-ADComputer.
Gesamtstrukturübergreifende Szenarios
Bei einer gesamtstrukturübergreifenden oder Ressourcengesamtstruktur-Bereitstellung mit Benutzern außerhalb der Active Directory-Gesamtstruktur, die Exchange enthält, müssen Sie eine Gesamtstruktur-Vertrauensstellung zwischen den Gesamtstrukturen konfigurieren. Außerdem müssen Sie für jede Gesamtstruktur in der Bereitstellung eine Weiterleitungsregel einrichten, die die Vertrauensstellung zwischen allen Namenssuffixes innerhalb der Gesamtstruktur und gesamtstrukturübergreifend aktiviert. Weitere Informationen zum Verwalten gesamtstrukturübergreifender Vertrauensstellungen finden Sie unter Konfigurieren von Partnerorganisationen.
Identifizieren der zu den ASA-Anmeldeinformationen gehörenden Dienstprinzipalnamen
Nachdem Sie die ASA-Anmeldeinformationen erstellt haben, müssen Sie den ASA-Anmeldeinformationen Exchange-Dienstprinzipalnamen (SPNs) zuordnen. Die Liste der Exchange-SPNs kann je nach Konfiguration variieren, sollte aber mindestens Folgendes enthalten:
http/: Verwenden Sie diesen SPN für Outlook Anywhere, MAPI über HTTP, Exchange Web Services, AutoErmittlung und Offlineadressbuch.
Die SPN-Werte müssen dem Dienstnamen im Netzwerklastenausgleich anstatt auf den einzelnen Servern entsprechen. Betrachten Sie die folgenden Szenarios, damit diese Ihnen bei der Planung helfen, welche SPN-Werte verwendet werden sollen:
Single Active Directory site
Multiple Active Directory sites
Gehen Sie in jedem dieser Szenarien davon aus, dass die vollqualifizierten Domänennamen (FQDNs) mit Lastenausgleich für die internen URLs, externen URLs und den internen URI der AutoErmittlung bereitgestellt wurden, die von den Clientzugriffsservermitgliedern verwendet werden. Weitere Informationen finden Sie unter Grundlegendes zu Proxying und Umleitung.
Einzelner Active Directory-Standort
Wenn Sie einen einzelnen Active Directory-Standort haben, kann Ihre Umgebung der in der folgenden Abbildung entsprechen:
Basierend auf den FQDNs, die von den internen Outlook-Clients in der Abbildung oben verwendet werden, müssen Sie die folgenden SPNs den ASA-Anmeldeinformationen zuordnen:
http/mail.corp.tailspintoys.com
http/autodiscover.corp.tailspintoys.com
Mehrere Active Directory-Standorte
Wenn Sie mehrere Active Directory-Standorte haben, kann Ihre Umgebung der in der folgenden Abbildung entsprechen:
Basierend auf den FQDNs, die von den Outlook-Clients in der vorherigen Abbildung verwendet werden, müssen Sie die folgenden SPNs den ASA-Anmeldeinformationen zuordnen, die von den Clientzugriffsservern in ADSite 1 verwendet werden:
http/mail.corp.tailspintoys.com
http/autodiscover.corp.tailspintoys.com
Sie müssen auch die folgenden SPNs den ASA-Anmeldeinformationen zuordnen, die von den Clientzugriffsservern in ADSite 2 verwendet werden:
http/mailsdc.corp.tailspintoys.com
http/autodiscoversdc.corp.tailspintoys.com
Konfigurieren und überprüfen Sie dann die Konfiguration der ASA-Anmeldeinformationen auf jedem Clientzugriffsserver.
Nachdem Sie das Konto erstellt haben, müssen Sie überprüfen, ob das Konto auf alle AD DS-Domänencontroller repliziert wurde. Insbesondere muss das Konto auf jedem Clientzugriffsserver vorhanden sein, der die ASA-Anmeldeinformationen verwendet. Als Nächstes konfigurieren Sie das Konto als ASA-Anmeldeinformationen auf jedem Clientzugriffsserver in Ihrer Bereitstellung.
Sie konfigurieren die ASA-Anmeldeinformationen mithilfe der Exchange-Verwaltungsshell, wie in einer dieser Verfahrensweisen beschrieben wird:
Bereitstellen der ASA-Anmeldeinformationen auf dem ersten Exchange 2013-Clientzugriffsserver
Bereitstellen der ASA-Anmeldeinformationen auf nachfolgenden Exchange 2013-Clientzugriffsservern
Die einzige unterstützte Methode für die Bereitstellung der ASA-Anmeldeinformationen ist die Verwendung des Skripts RollAlternateServiceAcountPassword.ps1. Weitere Informationen und erforderliche Berechtigungen zum Ausführen des Skripts finden Sie unter Verwenden des RollAlternateserviceAccountCredential.ps1-Skripts in der Shell. Nach der Ausführung des Skripts sollten Sie überprüfen, ob alle Zielserver ordnungsgemäß aktualisiert wurden.
Bereitstellen der ASA-Anmeldeinformationen auf dem ersten Exchange 2013-Clientzugriffsserver
Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2013-Server.
Führen Sie die folgenden Befehle aus, um die ASA-Anmeldeinformationen auf dem ersten Exchange 2013-Clientzugriffsserver bereitzustellen:
Cd $env:ExchangeInstallPath\Scripts .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer cas-1.corp.tailspintoys.com -GenerateNewPasswordFor tailspin\EXCH2013ASA$
Wenn Sie gefragt werden, ob Sie das Kennwort für das alternative Dienstkonto ändern möchten, antworten Sie Ja.
Im Folgenden finden Sie ein Beispiel der Ausgabe, die beim Ausführen des Skripts RollAlternateServiceAccountPassword.ps1 angezeigt wird.
========== Starting at 01/12/2015 10:17:47 ==========
Creating a new session for implicit remoting of "Get-ExchangeServer" command...
Destination servers that will be updated:
Name PSComputerName
---- --------------
cas-1 cas-1.corp.tailspintoys.com
Credentials that will be pushed to every server in the specified scope (recent first):
UserName
Password
--------
--------
tailspin\EXCH2013ASA$
System.Security.SecureString
Prior 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 cas-1
Setting a new password on Alternate Serice Account in Active Directory
Password change
Do you want to change password for tailspin\EXCH2013ASA$ in Active Directory at this time?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y
Preparing to update Active Directory with a new password for tailspin\EXCH2013ASA$ ...
Resetting a password in the Active Directory for tailspin\EXCH2013ASA$ ...
New password was successfully set to Active Directory.
Retrieving the current Alternate Service Account configuration from servers in scope
Alternate Service Account properties:
StructuralObjectClass QualifiedUserName Last Pwd Update SPNs
--------------------- ----------------- --------------- ----
computer tailspin\EXCH2013ASA$ 1/12/2015 10:19:53 AM
Per-server Alternate Service Account configuration as of the time of script completion:
Array: {mail.corp.tailspintoys.com}
Identity AlternateServiceAccountConfiguration
-------- ------------------------------------
cas-1 Latest: 1/12/2015 10:19:22 AM, tailspin\EXCH2013ASA$
...
========== Finished at 01/12/2015 10:20:00 ==========
THE SCRIPT HAS SUCCEEDED
Bereitstellen der ASA-Anmeldeinformationen auf einem anderen Exchange 2013-Clientzugriffsserver
Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2013-Server.
Ändern Sie das Verzeichnis in
$env:\Scripts
.Führen Sie den folgenden Befehl aus, um die ASA-Anmeldeinformationen auf einem anderen Exchange 2013-Clientzugriffsserver bereitzustellen:
.\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer cas-2.corp.tailspintoys.com -CopyFrom cas-1.corp.tailspintoys.com
Wiederholen Sie Schritt 3 für jeden Clientzugriffsserver, auf dem Sie die ASA-Anmeldeinformationen bereitstellen möchten.
Im Folgenden finden Sie ein Beispiel der Ausgabe, die beim Ausführen des Skripts RollAlternateServiceAccountPassword.ps1 angezeigt wird.
========== Starting at 01/12/2015 10:34:35 ==========
Destination servers that will be updated:
Name PSComputerName
---- --------------
cas-2 cas-2.corp.tailspintoys.com
Credentials that will be pushed to every server in the specified scope (recent first):
UserName
Password
--------
--------
tailspin\EXCH2013ASA$
System.Security.SecureString
Prior to pushing new credentials, all existing credentials will be removed from the destination servers.
Pushing credentials to server cas-2
Retrieving the current Alternate Service Account configuration from servers in scope
Alternate Service Account properties:
StructuralObjectClass QualifiedUserName Last Pwd Update SPNs
--------------------- ----------------- --------------- ----
computer tailspin\EXCH2013ASA$ 1/12/2015 10:19:53 AM
Per-server Alternate Service Account configuration as of the time of script completion:
Array: cas-2.corp.tailspintoys.com
Identity AlternateServiceAccountConfiguration
-------- ------------------------------------
cas-2 Latest: 1/12/2015 10:37:59 AM, tailspin\EXCH2013ASA$
...
========== Finished at 01/12/2015 10:38:13 ==========
THE SCRIPT HAS SUCCEEDED
Überprüfen der Bereitstellung von ASA-Anmeldeinformationen
Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2013-Server.
Führen Sie den folgenden Befehl aus, um die Einstellungen auf einem Clientzugriffsserver zu überprüfen:
Get-ClientAccessServer CAS-3 -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration
Wiederholen Sie Schritt 2 auf jedem Clientzugriffsserver, auf dem Sie die Bereitstellung der ASA-Anmeldeinformationen überprüfen möchten.
Im Folgenden finden Sie ein Beispiel der Ausgabe, die angezeigt wird, wenn Sie den obigen Get-ClientAccessServer-Befehl ausführen und keine früheren ASA-Anmeldeinformationen festgelegt wurden.
Name : CAS-1
AlternateServiceAccountConfiguration : Latest: 1/12/2015 10:19:22 AM, tailspin\EXCH2013ASA$
Previous: <Not set>
...
Im Folgenden finden Sie ein Beispiel der Ausgabe, die angezeigt wird, wenn Sie den obigen Get-ClientAccessServer-Befehl ausführen und frühere ASA-Anmeldeinformationen festgelegt wurden. Die früheren ASA-Anmeldeinformationen und das Datum und die Uhrzeit, zu denen sie festgelegt wurden, werden zurückgegeben.
Name : CAS-3
AlternateServiceAccountConfiguration : Latest: 1/12/2015 10:19:22 AM, tailspin\EXCH2013ASA$
Previous: 7/15/2014 12:58:35 PM, tailspin\oldSharedServiceAccountName$
...
Zuordnen von Dienstprinzipalnamen (Service Principal Names, SPNs) zu den ASA-Anmeldeinformationen
Wichtig
Ordnen Sie SPNs erst mit ASA-Anmeldeinformationen zu, wenn Sie diese Anmeldeinformationen auf mindestens einem Exchange Server bereitgestellt haben, wie weiter oben unter Bereitstellen der ASA-Anmeldeinformationen auf dem ersten Exchange 2013-Clientzugriffsserver beschrieben. Andernfalls treten Kerberos-Authentifizierungsfehler auf.
Bevor Sie die SPNs den ASA-Anmeldeinformationen zuordnen, müssen Sie sicherstellen, dass die Ziel-SPNs noch keinem anderen Konto in der Gesamtstruktur zugeordnet sind. 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 setspn-Befehl an der Befehlszeile ausführen.
Überprüfen Sie durch Ausführen des Befehls "setspn", ob bereits ein SPN einem Konto in einer Gesamtstruktur zugeordnet ist
Klicken Sie auf Start. Geben Sie im Feld Suchen das Wort Eingabeaufforderung ein, und wählen Sie dann in der Ergebnisliste Eingabeaufforderung aus.
Geben Sie an der Eingabeaufforderung den folgenden Befehl ein:
setspn -F -Q <SPN>
Wobei <SPN> der Dienstprinzipalname ist, den Sie den ASA-Anmeldeinformationen zuordnen möchten. Beispiel:
setspn -F -Q http/mail.corp.tailspintoys.com
Der Befehl sollte nichts zurückgeben. Wenn er etwas zurückgibt, ist bereits ein anderes Konto dem SPN zugeordnet. Wiederholen Sie diesen Schritt einmal für jeden SPN, den Sie den ASA-Anmeldeinformationen zuordnen möchten.
Zuordnen eines SPN zu den ASA-Anmeldeinformationen mithilfe des Befehls "setspn"
Klicken Sie auf Start. Geben Sie im Feld Suchen das Wort Eingabeaufforderung ein, und wählen Sie dann in der Ergebnisliste Eingabeaufforderung aus.
Geben Sie an der Eingabeaufforderung den folgenden Befehl ein:
setspn -S <SPN> <Account>$
Wobei <SPN> der Dienstprinzipalname ist, den Sie den ASA-Anmeldeinformationen zuordnen möchten, und <Account> das Konto ist, das den ASA-Anmeldeinformationen zugeordnet ist. Beispiel:
setspn -S http/mail.corp.tailspintoys.com tailspin\EXCH2013ASA$
Führen Sie diesen Befehl einmal für jeden SPN aus, den Sie den ASA-Anmeldeinformationen zuordnen möchten.
Überprüfen mithilfe des Befehls "setspn", ob Sie die SPNs den ASA-Anmeldeinformationen zugeordnet haben
Klicken Sie auf Start. Geben Sie im Feld Suchen das Wort Eingabeaufforderung ein, und wählen Sie dann in der Ergebnisliste Eingabeaufforderung aus.
Geben Sie an der Eingabeaufforderung den folgenden Befehl ein:
setspn -L <Account>$
Wobei <Account> das Konto ist, das den ASA-Anmeldeinformationen zugeordnet ist. Beispiel:
setspn -L tailspin\EXCH2013ASA$
Diesen Befehl müssen Sie nur einmal ausführen.
Aktivieren von Kerberos-Authentifizierung für Outlook-Clients
Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2013-Server.
Führen Sie den folgenden Befehl auf Ihrem Clientzugriffsserver aus, um die Kerberos-Authentifizierung für Outlook Anywhere-Clients zu aktivieren:
Get-OutlookAnywhere -server CAS-1 | Set-OutlookAnywhere -InternalClientAuthenticationMethod Negotiate
Um die Kerberos-Authentifizierung für MAPI über HTTP-Clients zu aktivieren, führen Sie Folgendes auf Ihrem Exchange 2013-Clientzugriffsserver aus:
Get-MapiVirtualDirectory -Server CAS-1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm, Negotiate
Wiederholen Sie die Schritte 2 und 3 für jeden Exchange 2013-Clientzugriffsserver, auf dem Sie die Kerberos-Authentifizierung aktivieren möchten.
Überprüfen der Kerberos-Authentifizierung des Exchange-Clients
Nachdem Sie Kerberos und die ASA-Anmeldeinformationen erfolgreich konfiguriert haben, überprüfen Sie, ob sich Clients wie in diesen Aufgaben beschrieben authentifizieren können.
Überprüfen, ob der Dienst für den Microsoft Exchange-Diensthost ausgeführt wird
Der Microsoft Exchange-Diensthostdienst (MSExchangeServiceHost) auf dem Clientzugriffsserver ist für die Verwaltung der ASA-Anmeldeinformationen verantwortlich. Wenn dieser Dienst nicht ausgeführt wird, ist die Kerberos-Authentifizierung nicht möglich. Der Dienst ist standardmäßig so konfiguriert, dass er automatisch beim Start des Computers gestartet wird.
Überprüfen, ob der Dienste für den Microsoft Exchange-Diensthost gestartet wurde
Klicken Sie auf Start, geben Sie services.msc ein, und wählen Sie dann services.msc in der Liste aus.
Suchen Sie im Fenster Dienste den Dienst Microsoft Exchange-Diensthost in der Liste der Dienste.
Der Status des Diensts sollte Gestartet lauten. Wenn der Status nicht Gestartet lautet, klicken Sie mit der rechten Maustaste auf den Dienst, und klicken Sie dann auf Starten.
Überprüfen von Kerberos über den Clientzugriffsserver
Wenn Sie die ASA-Anmeldeinformationen auf jedem Clientzugriffsserver konfiguriert haben, haben Sie das Cmdlet set-ClientAccessServer ausgeführt. Sobald Sie dieses Cmdlet ausgeführt haben, können Sie die Protokolle verwenden, um erfolgreiche Kerberos-Verbindungen zu überprüfen.
So überprüfen Sie mithilfe der HttpProxy-Protokolldatei, ob Kerberos ordnungsgemäß funktioniert
Navigieren Sie zu dem Ordner, in dem das HttpProxy-Protokoll gespeichert ist, indem Sie den folgenden Pfad verwenden:
%ExchangeInstallPath%Logging\HttpProxy\RpcHttp
Öffnen Sie die neueste Protokolldatei, und suchen Sie das Wort Negotiate. Die Zeile in der Protokolldatei sollte der folgenden ähneln:
2014-02-19T13:30:49.219Z,e19d08f4-e04c-42da-a6be-b7484b396db0,15,0,775,22,,RpcHttp,mail.corp.tailspintoys.com,/rpc/rpcproxy.dll,,Negotiate,True,tailspin\Wendy,tailspintoys.com,MailboxGuid~ad44b1e0-e44f-4a16-9396-3a437f594f88,MSRPC,192.168.1.77,EXCH1,200,200,,RPC_OUT_DATA,Proxy,exch2.tailspintoys.com,15.00.0775.000,IntraForest,MailboxGuidWithDomain,,,,76,462,1,,1,1,,0,,0,,0,0,16272.3359,0,0,3,0,23,0,25,0,16280,1,16274,16230,16233,16234,16282,?ad44b1e0-e44f-4a16-9396-3a437f594f88@tailspintoys.com:6001,,BeginRequest=2014-02-19T13:30:32.946Z;BeginGetRequestStream=2014-02-19T13:30:32.946Z;OnRequestStreamReady=2014-02-19T13:30:32.946Z;BeginGetResponse=2014-02-19T13:30:32.946Z;OnResponseReady=2014-02-19T13:30:32.977Z;EndGetResponse=2014-02-19T13:30:32.977Z;,PossibleException=IOException;
Wenn Sie feststellen, dass der Wert von AuthenticationTypeNegotiate ist, erstellt der Server erfolgreich von Kerberos authentifizierte Verbindungen.
Beibehalten der ASA-Anmeldeinformationen
Wenn Sie das Kennwort für die ASA-Anmeldeinformationen regelmäßig aktualisieren müssen, verwenden Sie die Schritte für das Konfigurieren der ASA-Anmeldeinformationen in diesem Artikel. Sie können auch eine geplante Aufgabe einrichten, um das Kennwort regelmäßig zu warten. 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 Ihren Clientzugriffsserver so zu konfigurieren, dass er Kerberos nicht verwendet, heben Sie die Zuordnung der SPNs aus den ASA-Anmeldeinformationen auf oder entfernen sie. Nach dem Entfernen der SPNs versuchen die Clients keine Kerberos-Authentifizierung, und Clients, für die die Negotiate-Authentifizierung konfiguriert ist, verwenden stattdessen 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 Konto löschen.
So entfernen die ASA-Anmeldeinformationen
Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2013-Server, und führen Sie den folgenden Befehl aus:
Set-ClientAccessServer CAS-1 -RemoveAlternateServiceAccountCredentials
Obwohl dies nicht sofort erforderlich ist, sollten Sie alle Clientcomputer neu starten, um den Kerberos-Ticketcache von den Computern zu löschen.