Isilon : Échec de l’authentification sur FQDN, erreur « KRB5KRB_AP_ERR_MODIFIED »

L’authentification sur FQDN échoue avec le message d’erreur suivant dans lsassd.log:
 

Ce message indique que : Isilon n’est pas en mesure de reconnaître le client qui demande l’un des services qu’elle propose. Cela entraîne un basculement de l’authentification sur Kerberos, car le client ne dispose pas d’un ticket valide qu’Isilon peut reconnaître et déchiffrer. 

Le même message peut être interprété sur les traces réseau, lorsque vous voyez Isilon [10.17.0.154] renvoyer le paquet « KRB5KRB_AP_ERR_MODIFIED» au client [10.106.12.162] pour une demande d’installation de session :


 

Cela peut se produire pour plusieurs raisons, mais les plus courantes sont énumérées ci-dessous :

• Il existe un compte avec le même SPN dans la forêt. Parfois, le KDC renvoie une erreur de KRB_S_PRINCIPAL_UNKNOWN, mais dans certains cas, il génère un ticket Kerberos que le service [dans notre cas, il s’agit d’Isilon] ne peut pas déchiffrer et obtient donc un KRB5KRB_AP_ERR_MODIFIED.

• Le nom principal de service se trouve sur le mauvais compte Active Directory (ordinateur ou utilisateur). Il s’agit là encore d’un cas de SPN en double.

• Le compte Active Directory qui exécute le service a mis à jour/modifié son mot de passe et vous rencontrez le problème en raison d’un problème de latence de réplication Active Directory ou Active Directory.

Ici, le client tente d’accéder à un partage Isilon à l’aide du FQDN "mixed.isilon.com".

Jetons maintenant un coup d’œil à la trace réseau de cette tentative.


 


1. Nous voyons la résolution de nom appropriée, pour « mixed.isilon.com » et la réponse du serveur DNS avec l’adresse IP de 10.17.0.156 (trames 5042 et 5049)

2. La machine reçoit alors un TGT du contrôleur de domaine (voir l’AS-REQ et l’AS-REP) (trames 5082 et 5093)

3. La machine demande et obtient alors un ticket de service pour « mixed.isilon.com » (trames 5101 et 5104). Comme vous pouvez le voir ci-dessous, la machine demandait un ticket Kerberos de « mixed.isilon.com ».


CName signifie Nom du client et SName signifie Nom




du service 4.  La machine retourne ensuite à Isilon et tente de s’authentifier à l’aide du ticket Kerberos qu’elle vient d’obtenir du contrôleur de domaine (images 5107 et 5111). Lors de l’authentification, Isilon répond par KRB5KRB_AP_ERR_MODIFIED (image 5111).


À l’étape 3, le client reçoit le ticket Kerberos du royaume « ISILON.COM », tandis que le cluster est joint à son domaine de confiance dans ce scénario à « CORP.COM ». Cela signifie qu’il existe un SPN en double enregistré dans ISILON.COM et qu’Isilon ne peut pas déchiffrer le ticket présenté par le client, car le cluster utilise CORP.COM pour s’authentifier. Cela entraîne l’échec de l’authentification.

Exemple de présence de SPN :

SPN en double répertoriés respectivement dans ISILON.COM et CORP.COM 
 

Recherchez les domaines de confiance et les SPN en double sur le domaine auquel Isilon est joint et le domaine de confiance :

- Pour vérifier les domaines de confiance :

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

- Pour lister les SPN présents dans un domaine :
 

Si des SPN en double sont présents et que seul le domaine principal est utilisé pour l’authentification, supprimez le SPN suivant l’article de la base de connaissances OneFS : Recherche de noms principaux de service (SPN) en double dans Active Directory empêchant les clients SMB de s’authentifier auprès du cluster.