Isilon: Authentifizierung über FQDN schlägt fehl, Fehler "KRB5KRB_AP_ERR_MODIFIED"

Die Authentifizierung über FQDN schlägt mit der folgenden Fehlermeldung fehl in lsassd.log:
 

Diese Meldung weist auf Folgendes hin: Isilon ist nicht in der Lage, den Kunden zu erkennen, der einen der von Isilon angebotenen Services anfordert. Dies führt dazu, dass die Authentifizierung ein Failover über Kerberos durchführt, da der Client kein gültiges Ticket erhält, das Isilon erkennen und entschlüsseln kann. 

Dieselbe Meldung kann über Netzwerk-Traces interpretiert werden, wenn Sie sehen, dass Isilon [10.17.0.154] das Paket "KRB5KRB_AP_ERR_MODIFIED" an den Client [10.106.12.162] für eine Anfrage zur Sitzungseinrichtung zurücksendet:


 

Dies kann aus verschiedenen Gründen passieren, aber die häufigsten sind unten aufgeführt:

• In der Gesamtstruktur ist ein Konto mit demselben SPN vorhanden. Manchmal gibt das KDC eine Fehlermeldung an KRB_S_PRINCIPAL_UNKNOWN zurück, aber es gibt auch Fälle, in denen es ein Kerberos-Ticket ausgibt, das der Service [in unserem Fall Isilon] nicht entschlüsseln kann und daher eine KRB5KRB_AP_ERR_MODIFIED erhält.

• Der Dienstprinzipalname befindet sich im falschen Active Directory-Konto (Computer oder Nutzer). Auch hier handelt es sich um eine doppelte SPN.

• Das Active Directory-Konto, auf dem der Dienst ausgeführt wird, hat sein Kennwort aktualisiert/geändert, und das Problem tritt aufgrund eines Active Directory-Replikationslatenz- oder Active Directory-Replikationsproblems auf.

Hier versucht der Client, mit dem FQDN "mixed.isilon.com".

Werfen wir nun einen Blick auf die Netzwerkablaufverfolgung dieses Versuchs.


 


1. Wir sehen eine korrekte Namensauflösung für "mixed.isilon.com" und die Antwort des DNS-Servers mit der IP-Adresse 10.17.0.156 (Frames 5042 und 5049)

2. Die Maschine erhält dann ein TGT vom Domänencontroller (siehe AS-REQ und AS-REP) (Frames 5082 und 5093)

3. Der Automat fordert dann ein Serviceticket für "mixed.isilon.com" (Rahmen 5101 & 5104) an und erhält es. Wie Sie unten sehen können, fragte der Computer nach einem Kerberos-Ticket von "mixed.isilon.com"


CName steht für Client Name und SName für Service Name




4.  Der Computer kehrt dann zu Isilon zurück und versucht, sich mit dem Kerberos-Ticket zu authentifizieren, das er gerade vom Domain Controller (Frames 5107 und 5111) erhalten hat. Während der Authentifizierung antwortet Isilon mit KRB5KRB_AP_ERR_MODIFIED (Frame 5111).


Wenn Sie in Schritt 3 sehen, erhält der Client das Kerberos-Ticket vom Bereich "ISILON.COM", während der Cluster in diesem Szenario mit seiner vertrauenswürdigen Domäne auf "CORP.COM" eingebunden wird. Dies bedeutet, dass ein doppelter SPN in ISILON.COM registriert ist und Isilon das vom Client vorgelegte Ticket nicht entschlüsseln kann, da der Cluster CORP.COM zur Authentifizierung verwendet. Dies führt dazu, dass die Authentifizierung fehlschlägt.

Beispiel für das Vorhandensein doppelter SPN:

SPNs sind in ISILON.COM bzw. CORP.COM aufgeführt 
 

Suchen Sie in der Domain, mit der Isilon verbunden ist, und in der vertrauenswürdigen Domain nach vertrauenswürdigen Domains und doppelten SPNs:

So überprüfen Sie die vertrauenswürdigen Domains:

# isi auth ads trusts list --provider-name=<Domain name cluster is joined to>

- So listen Sie die SPNs auf, die in einer Domäne vorhanden sind:
 

Wenn doppelte SPNs vorhanden sind und nur die primäre Domain für die Authentifizierung verwendet wird, löschen Sie den SPN gemäß dem Wissensdatenbank-Artikel OneFS: So finden Sie doppelte Service Principal Names (SPNs) in Active Directory, die verhindern, dass sich SMB-Clients beim Cluster authentifizieren.