Konfigurieren der Kerberos-Authentifizierung für Clientzugriffsdienste mit Lastenausgleich

  • Artikel

Damit Sie die Kerberos-Authentifizierung mit Postfachservern mit Lastenausgleich verwenden können, auf denen Clientzugriffsdienste ausgeführt werden, müssen Sie die in diesem Artikel beschriebenen Konfigurationsschritte ausführen.

Erstellen von alternativen Dienstkontoanmeldeinformationen in Active Directory Domain Services

Alle Exchange-Server, auf denen Clientzugriffsdienste mit denselben Namespaces und URLs ausgeführt werden, müssen die gleichen anmeldeinformationen für das Dienstkonto oder (ASA-Anmeldeinformationen) verwenden. Im Allgemeinen ist es ausreichend, über ein einziges Konto für eine Gesamtstruktur für jede Version von Exchange zu verfügen.

Wichtig

Exchange 2010 und Exchange 2016 können nicht dieselben ASA-Anmeldeinformationen gemeinsam nutzen. Wenn Ihre ASA-Anmeldeinformationen für Exchange 2010 erstellt wurden, müssen Sie eine neue für Exchange 2016 erstellen.

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.

Hinweis

Gruppenverwaltete Dienstkonten (Group Managed Service Accounts, gMSA) werden in lokalen Exchange Server Umgebungen nicht unterstützt und können daher in diesem Szenario nicht verwendet werden.

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 Domänencomputer sein. Wenn Sie ein Benutzerkonto verwenden, muss das Konto nur Mitglied der Sicherheitsgruppe Domänenbenutzer 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

  1. 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

  2. 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 EXCH2016ASA -AccountPassword (Read-Host 'Enter password' -AsSecureString) -Description 'Alternate Service Account credentials for Exchange' -Enabled:$True -SamAccountName EXCH2016ASA

    Exch2016ASA 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 EXCH2016ASA, muss in Ihrem Verzeichnis eindeutig sein.

  3. 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 EXCH2016ASA -add @{"msDS-SupportedEncryptionTypes"="28"}

    Exch2016ASA ist der Name des Kontos, und das zu ändernde Attribut ist 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

Wenn Sie über eine gesamtstruktur- oder ressourcenübergreifende Bereitstellung verfügen und Benutzer außerhalb der Active Directory-Gesamtstruktur vorhanden sind, die Exchange enthält, müssen Sie Gesamtstruktur-Vertrauensstellungen zwischen den Gesamtstrukturen konfigurieren. Außerdem müssen Sie für jede Gesamtstruktur in der Bereitstellung eine Routingregel einrichten, die eine Vertrauensstellung zwischen allen Namenssuffixen innerhalb der Gesamtstruktur und gesamtstrukturübergreifend ermöglicht. 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 mit dem Dienstnamen auf dem Netzwerklastenausgleich und nicht mit einzelnen Servern übereinstimmen. Betrachten Sie die folgenden Szenarios, damit diese Ihnen bei der Planung helfen, welche SPN-Werte verwendet werden sollen:

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 mit Clientzugriffsdiensten verwendet werden.

Einzelner Active Directory-Standort

Wenn Sie einen einzelnen Active Directory-Standort haben, kann Ihre Umgebung der in der folgenden Abbildung entsprechen:

mehrere AD-Websites.

Basierend auf den FQDNs, die von den internen Outlook-Clients in der vorherigen Abbildung 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:

mehrere AD-Websites.

Basierend auf den FQDNs, die von den Outlook-Clients in der vorherigen Abbildung verwendet werden, müssten Sie die folgenden SPNs den ASA-Anmeldeinformationen zuordnen, die von den Postfachservern verwendet werden, die Clientzugriffsdienste in ADSite 1 ausführen:

  • http/mail.corp.tailspintoys.com
  • http/autodiscover.corp.tailspintoys.com

Sie müssten auch die folgenden SPNs den ASA-Anmeldeinformationen zuordnen, die von den Postfachservern verwendet werden, die Clientzugriffsdienste in ADSite 2 ausführen:

  • http/mailsdc.corp.tailspintoys.com
  • http/autodiscoversdc.corp.tailspintoys.com

Konfigurieren und Überprüfen der Konfiguration der ASA-Anmeldeinformationen auf den einzelnen Servern mit Clientzugriffsdiensten

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 Server vorhanden sein, auf dem Clientzugriffsdienste ausgeführt werden, die die ASA-Anmeldeinformationen verwenden. Danach konfigurieren Sie das Konto als ASA-Anmeldeinformationen auf den einzelnen Servern mit Clientzugriffsdiensten in der 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-Server, auf dem Clientzugriffsdienste ausgeführt werden
  • Bereitstellen der ASA-Anmeldeinformationen auf nachfolgenden Exchange-Servern, auf denen Clientzugriffsdienste ausgeführt werden

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-Server, auf dem Clientzugriffsdienste ausgeführt werden

  1. Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2016- oder Exchange 2019-Server.

  2. Wechseln Sie zum <Exchange 2016-Installationsverzeichnis>\V15\Scripts.

  3. Führen Sie den folgenden Befehl aus, um die ASA-Anmeldeinformationen auf dem ersten Exchange 2016- oder Exchange 2019-Server bereitzustellen, auf dem Clientzugriffsdienste ausgeführt werden:

    .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer cas-1.corp.tailspintoys.com -GenerateNewPasswordFor tailspin\EXCH2016ASA$

  4. 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/2016 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\EXCH2016ASA$
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 mbx-1
Setting a new password on Alternate Service Account in Active Directory
Password change
Do you want to change password for tailspin\EXCH2016ASA$ 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\EXCH2016ASA$ ...
Resetting a password in the Active Directory for tailspin\EXCH2016ASA$ ...
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\EXCH2016ASA$   1/12/2016 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/2016 10:19:22 AM, tailspin\EXCH2016ASA$
          ...
========== Finished at 01/12/2016 10:20:00 ==========
        THE SCRIPT HAS SUCCEEDED

Bereitstellen der ASA-Anmeldeinformationen auf einem anderen Exchange-Server, auf dem Clientzugriffsdienste ausgeführt werden

  1. Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2016- oder Exchange 2019-Server.

  2. Wechseln Sie zum <Exchange 2016-Installationsverzeichnis>\V15\Scripts.

  3. Führen Sie den folgenden Befehl aus, um die ASA-Anmeldeinformationen auf einem anderen Exchange 2016- oder Exchange 2019-Server bereitzustellen, auf dem Clientzugriffsdienste ausgeführt werden:

    .\RollAlternateServiceAccountPassword.ps1 -ToSpecificServer cas-2.corp.tailspintoys.com -CopyFrom cas-1.corp.tailspintoys.com

  4. Wiederholen Sie Schritt 3 für jeden Server mit Clientzugriffsdiensten, für den 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/2016 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\EXCH2016ASA$
System.Security.SecureString
Prior to pushing new credentials, all existing credentials will be removed from the destination servers.
Pushing credentials to server mbx-2
Retrieving the current Alternate Service Account configuration from servers in scope
Alternate Service Account properties:
StructuralObjectClass QualifiedUserName Last Pwd Update       SPNs
--------------------- ----------------- ---------------       ----
computer              tailspin\EXCH2016ASA$   1/12/2016 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/2016 10:37:59 AM, tailspin\EXCH2016ASA$
          ...
========== Finished at 01/12/2016 10:38:13 ==========
        THE SCRIPT HAS SUCCEEDED

Überprüfen der Bereitstellung von ASA-Anmeldeinformationen

  • Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2016- oder Exchange 2019-Server.

  • Führen Sie den folgenden Befehl aus, um die Einstellungen auf dem Server mit Clientzugriffsdiensten zu überprüfen:

    Get-ClientAccessServer CAS-3 -IncludeAlternateServiceAccountCredentialStatus | Format-List Name, AlternateServiceAccountConfiguration

  • Wiederholen Sie Schritt 2 für jeden Server mit Clientzugriffsdiensten, auf dem Sie die Bereitstellung von 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/2016 10:19:22 AM, tailspin\EXCH2016ASA$
                                       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/2016 10:19:22 AM, tailspin\EXCH2016ASA$
                                       Previous: 7/15/2015 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-Server mit Clientzugriffsdiensten beschrieben. Andernfalls treten Kerberos-Authentifizierungsfehler auf.

Bevor Sie die SPNs den ASA-Anmeldeinformationen zuordnen, müssen Sie überprüfen, ob die Ziel-SPNs nicht bereits einem anderen Konto in der Gesamtstruktur zugeordnet sind. Die ASA-Anmeldeinformationen müssen das einzige Konto in der Gesamtstruktur sein, dem 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

  1. Klicken Sie auf Start. Geben Sie im Feld Suchen das Wort Eingabeaufforderung ein, und wählen Sie dann in der Ergebnisliste Eingabeaufforderung aus.

  2. 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"

  1. Klicken Sie auf Start. Geben Sie im SuchfeldEingabeaufforderung ein, und wählen Sie dann In der Ergebnisliste Eingabeaufforderung aus.

  2. 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\EXCH2016ASA$

    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

  1. Klicken Sie auf Start. Geben Sie im SuchfeldEingabeaufforderung ein, und wählen Sie dann In der Ergebnisliste Eingabeaufforderung aus.

  2. 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\EXCH2016ASA$

    Sie müssen diesen Befehl nur einmal ausführen.

Aktivieren von Kerberos-Authentifizierung für Outlook-Clients

  1. Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2016- oder Exchange 2019-Server.

  2. Führen Sie zum Aktivieren der Kerberos-Authentifizierung für Outlook Anywhere-Clients den folgenden Befehl auf Ihrem Exchange 2016- oder Exchange 2019-Server aus, auf dem Clientzugriffsdienste ausgeführt werden:

    Get-OutlookAnywhere -Server CAS-1 | Set-OutlookAnywhere -InternalClientAuthenticationMethod  Negotiate

  3. Um die Kerberos-Authentifizierung für MAPI über HTTP-Clients zu aktivieren, führen Sie den folgenden Befehl auf Ihrem Exchange 2016- oder Exchange 2019-Server aus, auf dem Clientzugriffsdienste ausgeführt werden:

    Get-MapiVirtualDirectory -Server CAS-1 | Set-MapiVirtualDirectory -IISAuthenticationMethods Ntlm,Negotiate

    Führen Sie in Hybridumgebungen mit Exchange Online oder wenn Sie OAuth intern verwenden, die folgenden Befehle auf Ihrem Exchange 2016- oder Exchange 2019-Server aus, auf dem Clientzugriffsdienste ausgeführt werden:

    $mapidir = Get-MapiVirtualDirectory -Server CAS-1
$mapidir | Set-MapiVirtualDirectory -IISAuthenticationMethods ($mapidir.IISAuthenticationMethods +='Negotiate')

  4. Wiederholen Sie die Schritte 2 und 3 für jeden Exchange 2016- oder Exchange 2019-Server, auf dem Clientzugriffsdienste ausgeführt werden, für die 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 clients erfolgreich authentifiziert werden können, wie in diesen Aufgaben beschrieben.

Überprüfen, ob der Dienst für den Microsoft Exchange-Diensthost ausgeführt wird

Der Microsoft Exchange-Diensthostdienst (MSExchangeServiceHost) auf dem Server, auf dem Clientzugriffsdienste ausgeführt werden, ist für die Verwaltung der ASA-Anmeldeinformationen verantwortlich. Wenn MSExchangeServiceHost nicht ausgeführt wird, kann die Kerberos-Authentifizierung nicht verwendet werden. 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

  1. Klicken Sie auf Start, geben Sie services.msc ein, und wählen Sie dann services.msc in der Liste aus.

  2. Suchen Sie im Fenster Dienste den Dienst Microsoft Exchange-Diensthost in der Liste der Dienste.

  3. 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 auf dem Server, auf dem Clientzugriffsdienste ausgeführt werden

Wenn Sie die ASA-Anmeldeinformationen auf jedem Server konfiguriert haben, auf dem Clientzugriffsdienste ausgeführt werden, haben Sie das Cmdlet Set-ClientAccessServer ausgeführt. Nachdem Sie dieses Cmdlet ausgeführt haben, können Sie die Protokolle verwenden, um erfolgreiche Kerberos-Verbindungen zu überprüfen.

Überprüfen Sie mithilfe der HttpProxy-Protokolldatei, ob Kerberos ordnungsgemäß funktioniert.

  1. Wechseln Sie in einem Text-Editor zu dem Ordner, in dem das HttpProxy-Protokoll gespeichert ist. Standardmäßig befindet sich das Protokoll im folgenden Ordner:

    %ExchangeInstallPath%\Logging\HttpProxy\RpcHttp

  2. Öffnen Sie die neueste Protokolldatei, und suchen Sie dann nach dem Wort Aushandeln. 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 sehen, dass der Wert AuthenticationTypeNegotiate lautet, erstellt der Server erfolgreich kerberos-authentifizierte Verbindungen.

Beibehalten der ASA-Anmeldeinformationen

Wenn Sie das Kennwort für die ASA-Anmeldeinformationen regelmäßig aktualisieren müssen, führen Sie die Schritte zum Konfigurieren der ASA-Anmeldeinformationen in diesem Artikel aus. 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 Ihre Server, auf denen Clientzugriffsdienste ausgeführt werden, so zu konfigurieren, dass sie kerberos nicht mehr verwenden, trennen Sie die Zuordnung der SPNs aus den ASA-Anmeldeinformationen. Wenn die SPNs entfernt werden, wird die Kerberos-Authentifizierung von Ihren Clients nicht versucht, und Clients, die für die Verwendung der Negotiate-Authentifizierung konfiguriert sind, verwenden stattdessen NTLM. Clients, die so konfiguriert sind, dass nur Kerberos verwendet wird, können keine Verbindung herstellen. Nachdem die SPNs entfernt wurden, sollten Sie auch das Konto löschen.

So entfernen die ASA-Anmeldeinformationen

  1. Öffnen Sie die Exchange-Verwaltungsshell auf einem Exchange 2016- oder Exchange 2019-Server, und führen Sie den folgenden Befehl aus:

    Set-ClientAccessServer CAS-1 -RemoveAlternateServiceAccountCredentials

  2. Obwohl dies nicht sofort erforderlich ist, sollten Sie alle Clientcomputer neu starten, um den Kerberos-Ticketcache von den Computern zu löschen.