PowerScale : Échec de l’authentification d’attribut non défini après la mise à niveau vers OneFS 9.5 ou version ultérieure pour les utilisateurs Active Directory

Si un cluster est mis à niveau vers OneFS 9.5 et que la valeur de l’attribut compte de machine msDS-SupportedEncryptionTypes n’est pas défini, l’authentification peut échouer. Le fournisseur Active Directory peut sembler sans style ou être absent de isi auth Sortie status.

Par défaut, cette valeur est définie sur 31 (ou 0xF1 en hexadécimal) lorsque le cluster rejoint Active Directory pour la première fois. D’après le Guide de configuration de la sécurité de OneFS 9.5, disponible sur la page produit du support technique Dell PowerScale OneFS, de nombreux types de chiffrement sont pris en charge pour SMB et Kerberos.
 

Figure 1 : La valeur de msDS-SupportedEncryptionTypes s’affiche comme <non défini>.

Exemple tiré de PowerShell :

DistinguishedName : CN=NINEFIVEOH,CN=Computers,DC=testdomain,DC=local
DNSHostName       : ninefiveoh.testdomain.local
Enabled           : True
Name              : NINEFIVEOH
ObjectClass       : computer
ObjectGUID        : 8dbed342-6a12-41ff-889f-8249cc39b673
SamAccountName    : NINEFIVEOH$
SID               : S-1-5-21-3532647020-1821455699-3245163308-1110
UserPrincipalName :

La sortie ci-dessus n’inclut pas de champ pour l’attribut msDS-SupportedEncryptionTypes, qui rapporterait généralement une valeur entière.

Vous trouverez ci-dessous un exemple d’un autre cluster où nous voyons que la valeur set est renseignée pour l’attribut :

DistinguishedName             : CN=COREBUDDY,CN=Computers,DC=testdomain,DC=local
DNSHostName                   : corebuddy.testdomain.local
Enabled                       : True
msDS-SupportedEncryptionTypes : 31   <<<<<<<<<<<<<<<<
Name                          : COREBUDDY
ObjectClass                   : computer
ObjectGUID                    : e29236a7-cc36-4686-bca9-010ba4143ca3
SamAccountName                : COREBUDDY$
SID                           : S-1-5-21-3532647020-1821455699-3245163308-1104
UserPrincipalName             :

Un autre symptôme est qu’il y a des messages spécifiques qui s’affichent /var/log/lsass.d.log comme indiqué ci-dessous :

2023-04-14T02:40:07.877593+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Failed to read msDS-SupportedEncryptionTypes for account CN=NINEFIVEOH,CN=Computers,DC=testdomain,DC=local
2023-04-14T02:40:07.877656+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Error 40044 (symbol: LW_ERROR_NO_SUCH_DOMAIN) occurred while putting an LDAP connection back in the domain free list.
2023-04-14T02:40:23.903189+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Failed to read msDS-SupportedEncryptionTypes for account CN=NINEFIVEOH,CN=Computers,DC=testdomain,DC=local
2023-04-14T02:40:23.903268+00:00 <30.3> ninefiveoh-1(id1) lsass[13628]: [lsass] Error 40044 (symbol: LW_ERROR_NO_SUCH_DOMAIN) occurred while putting an LDAP connection back in the domain free list.

Pour confirmer qu’il s’agit bien du problème, l’administrateur doit vérifier l’objet du compte de machine pour le cluster dans Active Directory. Pour ce faire, vous pouvez utiliser l’une des deux méthodes suivantes :

• Sur un contrôleur de domaine, ouvrez Active Directories Users and Computers (ADUC).
  1. Dans le ruban supérieur de la fenêtre, sélectionnez Afficher , puis cliquez sur Fonctionnalités avancées.
  2. Cliquez avec le bouton droit de la souris sur l’objet et accédez à l’onglet Éditeur d’attributs , puis faites défiler pour trouver l’objet msDS-SupportedEncryptionTypes attribut.
  3. Double-cliquez sur le champ Attribute et examinez le nombre décimal indiqué dans la nouvelle fenêtre.
• Utilisez la commande Powershell suivante sur un contrôleur de domaine avec le nom de compte de machine approprié.

  Get-ADComputer -Identity <machine account name> -Properties msDS-SupportedEncryptionTypes

Pour ce qui précède, les administrateurs doivent utiliser un compte Active Directory disposant de privilèges au niveau du domaine pour résoudre le problème.

Suppression manuelle de l' msDS-SupportedEncryptionTypes sur l’objet de compte de machine du cluster, Active Directory signale une valeur NULL. Cela fait échouer les vérifications dans le code le plus récent dans le cadre d’une série d’améliorations pour une meilleure prise en charge de la sécurité.

Les clusters plus anciens qui ont rejoint Active Directory sans définir cette valeur peuvent également être concernés par ce problème. Cela est dû au fait qu’aucune valeur n’est définie tant qu’aucune réintégration à Active Directory n’a été effectuée.

Solution de contournement :
Remplacez l’attribut par une valeur autre qu’une valeur vide. Une option sûre consiste à choisir la valeur par défaut 31 ou 24, en fonction des exigences de sécurité. Cette opération s’effectue via l’interface utilisateur ou par Powershell. 

Vous trouverez la liste des valeurs et les types de chiffrement qu’elles prennent en charge sur le blog du site Web de Microsoft.  

La commande suivante (avec le nom de compte de machine et le nombre entier appropriés insérés) peut être utilisée par un administrateur Active Directory sur un contrôleur de domaine au lieu de l’interface utilisateur pour attribuer une valeur à l’attribut.

Set-ADComputer -Identity COMPUTERNAME$ -Add @{'msDS-SupportedEncryptionTypes'="<INTEGER>"}

L’exemple ci-dessous définit l’attribut msDS-SupportedEncryptionTypes à la valeur par défaut 31 pour le compte de machine du cluster NINEFIVEOH$:

Set-ADComputer -Identity NINEFIVEOH$ -Add @{'msDS-SupportedEncryptionTypes'="31"}

Une fois les modifications appliquées, elles doivent être répliquées sur tous les contrôleurs de domaine au sein de l’environnement Active Directory. Une actualisation de l’authentification ou un redémarrage LSASS ciblé sur le cluster peut être nécessaire pour effacer la condition après. 

Les ingénieurs Dell ont publié des améliorations de code dans OneFS 9.5.0.3 qui résolvent ce problème. Les administrateurs peuvent toujours voir les vérifications préalables à la mise à niveau IOCA échouer s’ils n’ont pas de valeur définie avant la mise à niveau. Si un administrateur a limité les privilèges de cluster dans AD pour modifier les attributs, il DOIT mettre à jour manuellement l’attribut avant toute activité de mise à niveau. L’échec de la mise à jour de l’attribut avant la mise à niveau lorsque le cluster ne dispose pas de privilèges suffisants entraîne une indisponibilité des données.

Voici quelques ressources recommandées sur ce sujet qui pourraient vous intéresser :

• PowerScale : exécution de l’outil Isilon On-Cluster Analysis 
• Correctifs actuels PowerScale OneFS