PowerScale OneFS : Le fournisseur Active Directory disparaît après une tentative de rattachement pour le même domaine

Après avoir effectué une jonction AD avec le même nom que le fournisseur AD auquel le cluster est déjà joint, le fournisseur peut disparaître. Les administrateurs peuvent voir une erreur liée à la tentative de jonction, bien que cette erreur puisse varier en fonction de la cause.

Dans l’exemple ci-dessous, nous reproduisons le problème avec le fournisseur TESTDOMAIN.LOCAL En utilisant le mauvais compte pour faciliter la rejointure.

Sorties de isi auth status et isi auth ads list -v Affichez la présence du fournisseur avant d’exécuter la commande :

corebuddy-1# isi auth status
ID                                            Active Server                Status
----------------------------------------------------------------------------------
lsa-activedirectory-provider:TESTDOMAIN.LOCAL winserv2019.testdomain.local online
lsa-activedirectory-provider:DOMAIN2.LOCAL    domain2DC1.domain2.local     online
lsa-local-provider:System                     -                            active
lsa-local-provider:test                       -                            active
lsa-local-provider:domain2                    -                            active
lsa-file-provider:System                      -                            active
----------------------------------------------------------------------------------
Total: 6

corebuddy-1# isi auth ads list -v | grep -i testdomain
                     Name: TESTDOMAIN.LOCAL
           Primary Domain: TESTDOMAIN.LOCAL
                   Forest: testdomain.local
           NetBIOS Domain: TESTDOMAIN
                 Hostname: corebuddy.testdomain.local

Ci-dessous, nous exécutons la commande. Notez que le nom d’utilisateur répertorié est incorrect (dans notre exemple, nous avons utilisé le nom de groupe « Administrateurs » au lieu du compte administrateur ) :

corebuddy-1# isi auth ads create --name=TESTDOMAIN.LOCAL --user=administrators
password:
Failed to join domain 'TESTDOMAIN.LOCAL' account 'corebuddy' user 'administrators@TESTDOMAIN.LOCAL': (LW_ERROR_KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN) Client not found in Kerberos database

Le fournisseur est maintenant manquant. Dans l’interface utilisateur Web, cela peut s’afficher comme sans style, mais dans la CLI, il n’est pas dans la sortie pour isi auth status.

orebuddy-1# isi auth status
ID                                         Active Server            Status
---------------------------------------------------------------------------
lsa-activedirectory-provider:DOMAIN2.LOCAL domain2DC1.domain2.local online
lsa-local-provider:System                  -                        active
lsa-local-provider:test                    -                        active
lsa-local-provider:domain2                 -                        active
lsa-file-provider:System                   -                        active
---------------------------------------------------------------------------
Total: 5

Étant donné que l’état d’authentification isi peut indiquer qu’un fournisseur est manquant pour d’autres raisons, nous devons valider cela davantage. Il arrive que la commande isi auth ads list -v n’affiche aucune sortie correspondant au fournisseur TESTDOMAIN.LOCAL ci-dessous. Cela signifie que la configuration ne contient aucune entrée correspondant au domaine manquant.

corebuddy-1# isi auth ads list -v |grep -i test
corebuddy-1#

Les journaux LSASS affichent des erreurs similaires observées lors de l’exécution de la commande initiale :

2024-06-11T21:25:21.298318+00:00 <30.4> corebuddy-1(id1) lsass[5467]: [LwKrb5GetTgtImpl /b/mnt/src/isilon/fsp/lwadvapi/threaded/krbtgt.c:247] KRB5 Error code: -1765328378 (Message: Client 'administrators@TESTDOMAIN.LOCAL' not found in Kerberos database)
2024-06-11T21:25:21.299207+00:00 <30.4> corebuddy-1(id1) lsass[5467]: [lsass] Error occurred while joining domain: Error code: 41737 (symbol: LW_ERROR_KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN)

Le scénario ci-dessus ne se limite pas à l’utilisation d’informations d’identification incorrectes. Si une condition est présente et induirait un échec pour rejoindre le fournisseur AD, cet échec entraîne la suppression du fournisseur. Par exemple, si le même nom pour le compte d’ordinateur est utilisé ailleurs dans la forêt ou dans un domaine de confiance, cela induit une défaillance. La seule différence peut être l’erreur fournie.

Lors de l’exécution d’une jonction AD sur un domaine déjà joint, la présence de conditions qui induiraient une défaillance entraîne la suppression du fournisseur AD. Cela est prévu, car OneFS traite cette opération comme une tentative de « réintégration ». En cas de défaillance, toute configuration associée au fournisseur d’authentification spécifié est supprimée.

corebuddy-1# isi auth status
ID                                         Active Server            Status
---------------------------------------------------------------------------
lsa-activedirectory-provider:DOMAIN2.LOCAL domain2DC1.domain2.local online
lsa-local-provider:System                  -                        active
lsa-local-provider:test                    -                        active
lsa-local-provider:domain2                 -                        active
lsa-file-provider:System                   -                        active
---------------------------------------------------------------------------
Total: 5

Les noms des fournisseurs d’authentification sont globaux, de sorte que la présence de deux fournisseurs portant le même nom n’est pas prise en charge. S’il n’existe aucune autre condition en suspens qui empêcherait une opération de jonction, la réintégration du domaine résout le problème.

S’il est nécessaire de joindre le même fournisseur de domaine AD avec des comptes de machine distincts, la fonction d’instanciation multiple doit être utilisée. Vous trouverez plus de détails à ce sujet dans la section « Fournisseurs d’authentification spécifiques à une zone » des guides d’administration OneFS. N’oubliez pas que le fournisseur AD réintégré doit être ajouté à toutes les zones d’accès qui l’avaient précédemment pour restaurer l’accès.

Reportez-vous à l’article Hubs d’informations PowerScale OneFS pour obtenir de la documentation sur votre version de OneFS.