VNX : DOMAIN_CONTROLLER_NOT_FOUND après la mise à niveau du code qui prend en charge les communications de canal sécurisé SMB2

Le code a été mis à niveau vers l’une des versions répertoriées ci-dessus.

Après la mise à niveau vers l’un des codes suivants, des messages d’erreur ont commencé à apparaître dans les journaux indiquant que le contrôleur de domaine était en panne :
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Le message se présente comme suit :

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

Les codes mentionnés ci-dessus sont tous ajoutés dans une nouvelle fonctionnalité qui permet au serveur NAS ou au logiciel de transfert de données de communiquer avec les contrôleurs de domaine dans SMB2. Avant ce code, les communications du contrôleur de domaine étaient toutes gérées dans SMB1 (bien que les clients puissent toujours nous parler dans SMB2/SMB3).
Avec le passage à SMB2, nos commandes ne sont pas toutes sérialisées sur les contrôleurs de domaine. Cela semble conduire à l’exécution simultanée de certaines commandes en parallèle.
Un exemple est la tentative d’ouverture du canal nommé lsarpc nommé.

Dans ce message d’erreur, il est important de noter le service auquel nous essayons de lier :

2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND

Le message d’erreur indique qu’il tente d’ouvrir LSA (en surbrillance rouge). C’est là que le bât blesse. Nous essayons d’ouvrir le canal nommé lsarpc plusieurs fois simultanément avant de recevoir une réponse du contrôleur de domaine. La première demande aboutit, mais les suivantes échouent. Les messages d’échec indiquent STATUS_PIPE_NOT_AVAILABLE et consignons le message DOMAIN_CONTROLLER_NOT_FOUND dans les journaux.

Il est important de noter que ces messages n’indiquent pas toujours ce problème. DOMAIN_CONTROLLER_NOT_FOUND erreurs peuvent avoir de nombreuses causes.
Celui-ci est susceptible d’avoir un grand nombre des messages d’information suivants dans les journaux :

2017-06-28 14:37:45: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened
2017-06-28 14:37:47: 26041909248: SMB: 6:[NASSERVER1] sendLookupSIDs pipe lsarpc reopened

S’il y a des doutes sur la correspondance ou non du problème, cela peut être confirmé dans une trace de paquets. Dans la trace, nous verrions plusieurs demandes simultanées d’ouverture de lsarpc avant de recevoir une réponse à l’une d’entre elles, suivies de la première qui réussit et des suivantes qui échouent avec STATUS_PIPE_NOT_AVAILABLE lorsque le contrôleur de domaine répond.

Ce problème se produit principalement sur les systèmes qui nécessitent un grand nombre de recherches SID sur le contrôleur de domaine. S’il existe des SID orphelins dans l’environnement, il a tendance à consigner beaucoup plus de ces erreurs. Cela est dû à la quantité de trafic envoyée au contrôleur de domaine. Chaque fois que nous accédons à une ACL, nous devons envoyer une demande au contrôleur de domaine pour demander l’identité de tous les SID que nous n’avons pas dans notre cache SID. Les SID orphelins ne sont jamais dans le cache SID et sont tentés d’être recherchés à chaque fois que nous augmentons le nombre d’ouvertures que nous devons faire sur le canal nommé lsarpc.

Si la première tentative d’ouverture réussit, il s’agit d’un événement sans impact et ces messages peuvent être ignorés.

Correctif permanent :
Les ingénieurs ont connaissance du problème et travaillent à un correctif dans une future version du code. Il s’agit d’un problème sans perturbation qui peut être ignoré en toute sécurité dans l’intervalle. Toutefois, si vous souhaitez réduire ou éliminer le message, il existe des solutions de contournement.

Solution de contournement 1 :
Il existe plusieurs façons d’empêcher ces messages de s’afficher dans les journaux. Étant donné que plusieurs tentatives d’ouverture simultanées sur le canal lsarpc sont à l’origine du problème, le moyen le plus simple de réduire les messages consiste à réduire le nombre de recherches SID nécessaires.

Les SID orphelins sont à l’origine de ces recherches excessives. Le paramètre suivant peut être modifié pour forcer les recherches à examiner le cache secmap pour les SID inconnus et devrait réduire la quantité de trafic allant vers le contrôleur de domaine :

[nasadmin@CS0 ~]$ server_param server_2 -f cifs -i acl.mappingErrorAction -v
server_2 :
name                    = acl.mappingErrorAction
facility_name           = cifs
default_value           = 8
current_value           = 8
configured_value        = 8
user_action             = none
change_effective        = immediate
range                   = (0,31)
description             = Define rules for an unknown SID/UID/GID mapping

detailed_description
Defines the rules for unknown mapping between SID/UID/GID on ACL settings. Two kinds of errors might occur: the SID set in the ACL is unknown to the Domain Controllers we are using, or the username is not yet mapped to a UID/GID. 0x01: Stores unknown sid. 0x02: Stores sid with no UNIX mapping. 0x04: Enables debug traces. 0x08: Only do lookup in cache (secmap or globalSid cache or per connection SID cache) 0x08 is HIGHLY RECOMMENDED WITH OPTION=0x01. 0x10: Disable log displayed when an unknown SID resolution takes too much time.Maximum value = 0x1F Refer to param cifs.acl.retryAuthSID

Cela se traduit par les informations suivantes :
Bit0 = Stocke le SID inconnu.
Bit1 = Stocke sid sans mappage UNIX.
Bit2 = active les traces de débogage.
Bit3 = Effectuer uniquement la recherche dans le cache (cache secmap ou globalSid ou cache SID par connexion)

Si les bits 0 et 1 sont définis (0x3 comme valeur), les SID orphelins sont autorisés à être stockés sur les listes ACL du système de fichiers (ce qui n’est pas le cas par défaut). Il est suggéré de changer la valeur de 0x3 à 0x11, cela active les bits 0, 1 et 3. C’est-à-dire stocker les SID inconnus sans mappage unix et ne chercher que dans les caches secmap et SID globaux. S’il est défini sur 0x8 ou une autre combinaison où les bits 0 et 1 sont désactivés, alors les SID orphelins ne sont pas autorisés à être stockés et aucune modification ne doit être apportée à ce paramètre.

Si vous souhaitez modifier le paramètre, vous pouvez exécuter la commande suivante :

server_param server_2 -f cifs -m acl.mappingErrorAction -v 11

Cela réduira probablement le nombre d’occurrences, mais ne les éliminera peut-être pas complètement.

Solution de contournement 2 :
Le moyen infaillible de se débarrasser de ces erreurs dans les journaux consiste à rétablir le comportement de communication du contrôleur de domaine à ce qu’il était avant les nouveaux codes (ce qui signifie que nous ne communiquons qu’avec les contrôleurs de domaine dans SMB1).

Si vous souhaitez revenir à SMB1 pour les communications CC (ancien comportement VNX), contactez le support Dell et consultez cet article de la base de connaissances.