PowerScale : OneFS : Les clients ne peuvent pas s’authentifier ou se connecter aux nœuds lorsque le domaine AD affiche « Offline »

Les clients ne peuvent pas s’authentifier auprès de certains ou de tous les nœuds du cluster, ce qui entraîne une indisponibilité intermittente ou totale des données (DU). L’accès via n’importe quel protocole est affecté si l’utilisateur dépend d’un fournisseur AD hors ligne, bien que le plus courant que nous voyons soit SMB. De nombreuses circonstances peuvent potentiellement conduire à ce scénario, à l’échelle du cluster ou sur une base spécifique à un nœud. Les clients SMB ne peuvent pas se connecter aux nœuds du cluster lorsque le service LSASS ( Local Security Authority Subsystem Service ) perd sa connexion avec le contrôleur de domaine.

Lorsque le LSASS perd sa connexion avec le contrôleur de domaine, des erreurs similaires à ce qui suit apparaissent dans le fichier /var/log/lsassd.log :

2012-06-11T12:58:42-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now online
2012-06-11T13:03:57-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now offline
2012-06-12T21:05:03-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now online
2012-06-13T16:35:03-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now offline
2012-06-13T16:40:03-07:00 <30.6> cluster1-13(id13) lsassd[66251]: 0x28f016a0:Domain 'domain.com' is now online

Sinon, si l’état d’Active Directory est examiné avec l’état d’authentification isi, une sortie similaire peut être présentée :

testcluster-1# isi auth status
ID                                           Active Server      Status
-----------------------------------------------------------------------
lsa-activedirectory-provider:TESTDOMAIN.COM dc1.testdomain.com offline
lsa-local-provider:System                    -                  active
lsa-file-provider:System                     -                  active
-----------------------------------------------------------------------
Total: 3

# isi auth ads view <domain>

(Relevant output)
Hostname: isitest.example.lab.com
<snipped>
Machine Account: ISITEST$

dig @<DNS IP> SRV _ldap._tcp.dc._msdcs.domain.com

; <<>> DiG 9.10.0-P2 <<>> @<DNS IP> SRV _ldap._tcp.dc._msdcs.<domain>
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 52396
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.<domain>. IN SRV

;; Query time: 0 msec
;; SERVER: <IP>#53(<IP>)
;; WHEN: <date>
;; MSG SIZE rcvd: 59

Le service LSASS (Local Security Authority Subsystem Service) peut perdre sa connexion au contrôleur de domaine connecté en raison de problèmes matériels, de connectivité ou d’un empoisonnement du cache DNS. Cela peut également se produire parce qu’un nœud a été ajouté au cluster et que le nœud n’avait pas de connectivité réseau. Si le contrôleur de domaine n’est pas disponible pour une raison quelconque, lorsqu’un nœud est redémarré ou que LSASS est redémarré, certaines informations de domaine peuvent rester incomplètes. En général, le GUID de domaine du domaine principal reste vide. Cela empêche l’authentification pour les utilisateurs qui se connectent à ce nœud.

Solution de contournement 1 : examinez les problèmes de connectivité matérielle :

• Recherchez des problèmes de connectivité matérielle dans le fichier /var/log/messages . Les messages du fichier log indiquent si le port réseau du nœud est à l’état « Actif » ou non. Examinez le fichier /var/log/messages sur d’autres nœuds du cluster pour déterminer si le problème de connectivité réseau se produit à l’échelle du cluster.
• Examinez les journaux d’événements du système et des applications dans le contrôleur de domaine. Ces fichiers journaux peuvent contenir des erreurs concernant le pilote ou des problèmes matériels liés à la perte de connectivité réseau.

Solution de contournement 2 : examinez l’empoisonnement du cache DNS :

Si le problème de connectivité réseau n’est pas lié au matériel, vous devez inspecter les enregistrements de service (SRV) pour la zone DNS _mscds pour les domaines Active Directory. Une trace de paquet de la demande DNS du cluster vers le serveur DNS affiche des informations incorrectes ou manquantes. Si des informations incorrectes sont enregistrées dans les enregistrements SRV, ou si les contrôleurs de domaine ne disposent pas de tous les enregistrements dans la zone DNS _mscds, les nœuds du cluster signalent que le domaine est hors ligne lorsqu’ils tentent de contacter le contrôleur de domaine. La mise à jour des enregistrements SRV avec les informations actuelles ou le passage à un autre serveur DNS devrait résoudre l’empoisonnement du cache DNS.

Exemple 1

Ce suivi de paquets affiche la liste des serveurs DNS et des enregistrements SRV qui ont été renvoyés aux nœuds du cluster. Les informations sur les enregistrements SRV n’étaient pas disponibles pour dc2.domain.com.

Non. Time Source Destination Protocol Length Info
5 16:40:19.061003 1.1.1.1 1.1.1.2 DNS 110 Standard query SRV _ldap._tcp.dc._msdcs.domain.com
6 16:40:19.062626 1.1.1.2 1.1.1.1 DNS 1270 Standard query response SRV 0 100 389 dc1.domain.com SRV 0 100 389 dc2.domain.com SRV 0 100 389 SRV 0 100 389 dc3.domain.com
7 16:40:19.063146 1.1.1.1 1.1.1.2 DNS 87 Standard query A dc2.domain.com
8 16:40:20.797403 1.1.1.2 1.1.1.1 DNS 146 Standard query response, No such name

Exemple 2

Dans cette trace de paquets, un nœud recherche l’enregistrement SRV pour _ldap._tcp.dc._msdcs.domain.com, mais aucune information n’est renvoyée au client.

Non. Time Source Destination Protocol Length Info
15 16:40:21.458636 1.1.1.1 1.1.1.2 DNS 100 Standard query SRV _ldap._tcp.dc._msdcs.domain.com
16 16:40:21.783630 1.1.1.2 1.1.1.1 DNS 100 Standard query response, No such name

Dans ce cas, veuillez collaborer avec votre équipe de gestion réseau et Active Directory pour vous assurer que les enregistrements SRV DNS sont exacts et correspondent au contrôleur de domaine.

Solution de contournement 3 - Actualiser LSASS :

1. Ouvrez une connexion SSH au nœud et connectez-vous à l’aide du compte « root ».
2.  Vérifiez que le processus d’authentification n’est pas connecté à AD, où <nodeID> est le numéro du nœud récemment ajouté :
   
   isi_for_array -n <nodeID> 'isi auth ads list'
   
   Si le nœud est joint au domaine, un résultat semblable au suivant s’affiche :
    
   cluster-1: Name            Authentication Status DC Name Site
cluster-1: --------------------------------------------------------------------
cluster-1: LAB.EXAMPLE.COM Yes            online -       Default-First-Site-Name
cluster-1: --------------------------------------------------------------------
cluster-1: Total: 1
    
3.  Vérifiez que le GUID de domaine n’est pas renseigné. Si lsass ne récupère pas sa configuration correctement, il ne renseigne pas de valeur GUID de domaine :
   
   isi_for_array -n <nodeID> /usr/likewise/bin/lw-lsa get-status | egrep -A 12 "Domain:" | egrep "Domain (SID|GUID)"
   
   Un résultat similaire à celui qui suit apparaît :
    
   cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain GUID:
    
4. Exécutez la commande suivante sur le nœud nouvellement ajouté :
   
   isi_for_array -n < node_range> /usr/likewise/bin/lwsm refresh lsass
    
5. Vérifiez que le nouveau nœud signale qu’il est connecté à un fournisseur AD.
   
   isi_for_array -n < node_range> 'isi auth ads list -v'
    
6.  Assurez-vous que la valeur GUID s’affiche :
   
   isi_for_array -n <node_range> /usr/likewise/bin/lw-lsa get-status | egrep -A 12 "Domain:" | egrep "Domain (SID|GUID)"
   
   Un résultat similaire à celui qui suit apparaît :
    
   cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain SID: S-1-5-21-584721463-3180705917-972194821
cluster-1:   Domain GUID: 61b2a8c6-af25-1941-8d57-59073b7ceb19
    
7. Sur le client Windows, vérifiez que l’utilisateur peut s’authentifier auprès du cluster en mappant un lecteur, en spécifiant l’adresse IP du nœud nouvellement ajouté.

Solution de contournement 4 - Redémarrez LSASS :

1. Ouvrez une connexion SSH au nœud récemment ajouté et connectez-vous à l’aide du compte « root ».
2. Répertoriez les contrôleurs de domaine disponibles, où< domain_name> est le nom de domaine complet (FQDN) du domaine auquel le cluster est attaché :

isi auth ads trusts controllers list --provider=<domain_name> -v

3. Connexion forcée à un contrôleur de domaine, où< domain_name> est le FQDN du domaine auquel le cluster est relié et <dc_name> est le FQDN du contrôleur de domaine :

isi auth ads modify <domain_name> --domain-controller <dc_name> --v

4. Actualiser l’état AD :

isi_classic auth ads status --refresh --all

L’état doit passer à en ligne, comme indiqué ci-dessous :
 

5. Si l’état indique toujours que « hors ligne », redémarrez le processus d’authentification (notez que cela interrompt l’authentification sur le nœud pendant une minute maximum) : 

Single node:
pkill -f 'lw-container lsass'
Multiple nodes (nodes 1-3 here as an example):
isi_for_array -n1-3 'pkill -f "lw-container\ lsass"'

6. Répétez l’étape 4.
7. Sur le client Windows, vérifiez que l’utilisateur peut s’authentifier auprès du cluster en mappant un lecteur, en spécifiant l’adresse IP du nœud sur lequel LSASS a été redémarré.

Remarque de dépannage pour les problèmes de connectivité de domaine :
Si vous quittez le domaine et le rejoignez, vérifiez que le fournisseur Active Directory apparaît dans la liste des fournisseurs d’authentification de la zone concernée après avoir rejoint le domaine.

Pour ce domaine example.com, il doit être ajouté à nouveau, car il a été supprimé de la section Auth Providers :

isi zone zones list -v:

                       Name: accesszonedev1
                       Path: /ifs/accesszone1
                   Groupnet: groupnet0
              Map Untrusted: -
             Auth Providers:  lsa-ldap-provider:Primary, lsa-file-provider:System, lsa-local-provider:accesszone1 **No Active Directory Provider** <<<<<<<<<<<<<
               NetBIOS Name: -
         User Mapping Rules:
       Home Directory Umask: 0077
         Skeleton Directory: /usr/share/skel
         Cache Entry Expiry: 4H
Negative Cache Entry Expiry: 1m
                    Zone ID: 2

L’interface utilisateur Web peut être le moyen le plus simple de le rajouter et de s’assurer qu’il est recherché dans l’ordre souhaité. Reportez-vous au guide d’administration correspondant à votre version de OneFS. Hubs d’informations PowerScale OneFS