PowerScale: OneFS: I client non sono in grado di autenticarsi o connettersi ai nodi quando il dominio AD mostra "Offline"

I client non sono in grado di eseguire l'autenticazione per alcuni o tutti i nodi del cluster, causando una non disponibilità dei dati (DU) intermittente o totale. L'accesso su qualsiasi protocollo è influenzato se l'utente si affida a un provider AD offline, anche se il più comune è SMB. Esistono molte circostanze che potrebbero potenzialmente portare a questo scenario, a livello di cluster o su base specifica del nodo. I client SMB non possono connettersi ai nodi del cluster quando il servizio LSASS ( Local Security Authority Subsystem Service ) perde la connessione con il controller di dominio.

Quando LSASS perde la connessione con il controller di dominio, nel file /var/log/lsassd.log vengono visualizzati errori simili ai seguenti:

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

In alternativa, se lo stato di Active Directory viene esaminato con isi auth status, è possibile visualizzare un output simile:

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

Il servizio sottosistema dell'autorità di sicurezza locale (LSASS, Local Security Authority Subsystem Service) può perdere la connessione al controller di dominio connesso a causa di problemi hardware, problemi di connettività o avvelenamento della cache DNS. In alternativa, ciò può accadere perché un nodo è stato aggiunto al cluster e il nodo non dispone di connettività di rete. Se il controller di dominio non è disponibile per qualsiasi motivo, quando un nodo viene riavviato o LSASS, alcune informazioni di dominio potrebbero rimanere non popolate. In genere, il GUID di dominio per il dominio primario rimane non popolato. Di conseguenza, l'autenticazione non può essere completata per gli utenti che si connettono a tale nodo.

Soluzione alternativa 1: analizzare i problemi di connettività hardware:

• Cercare i problemi di connettività hardware nel file /var/log/messages . I messaggi nel file di registro indicano se la porta di rete del nodo è in stato "Up" o meno. Esaminare il file /var/log/messages sugli altri nodi del cluster per determinare se il problema di connettività di rete si verifica a livello di cluster.
• Esaminare i registri eventi del sistema e delle applicazioni nel controller di dominio. Questi file di registro potrebbero includere errori relativi a driver o problemi hardware correlati alla perdita della connettività di rete.

Soluzione alternativa 2: analizzare l'avvelenamento della cache DNS:

Se il problema di connettività di rete non è correlato all'hardware, è necessario ispezionare i record del servizio (SRV) per la zona DNS _mscds per i domini Active Directory. Una traccia di pacchetti della richiesta DNS dal cluster al server DNS mostra informazioni errate o mancanti. Se nei record SRV vengono registrate informazioni errate o se i controller di dominio non dispongono di tutti i record nella zona DNS _mscds, i nodi del cluster segnalano che il dominio è offline quando tentano di contattare il controller di dominio. L'aggiornamento dei record SRV con le informazioni correnti o il passaggio a un server DNS diverso dovrebbe risolvere il problema di avvelenamento della cache DNS.

Esempio 1

Questa traccia dei pacchetti mostra l'elenco dei server DNS e dei record SRV restituiti ai nodi del cluster. Le informazioni sul record SRV non erano disponibili per dc2.domain.com.

No. Ora Origine Destinazione Lunghezza Protocollo Informazioni
5 16:40:19.061003 1.1.1.1 1.1.1.2 DNS 110 Query standard SRV _ldap._tcp.dc._msdcs.domain.com
6 16:40:19.062626 1.1.1.2 1.1.1.1 DNS 1270 Risposta standard alle query 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 Query standard A dc2.domain.com
8 16:40:20.797403 1.1.1.2 1.1.1.1 DNS 146 Risposta standard alla query, nessun nome

Esempio 2

In questa traccia dei pacchetti, un nodo cerca il record SRV per _ldap._tcp.dc._msdcs.domain.com, ma nessuna informazione viene restituita al client.

No. Ora Origine Destinazione Protocollo Lunghezza 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 Risposta standard alla query, nessun nome di questo tipo

In questa situazione, collaborare con il team di rete e Active Directory per assicurarsi che i record DNS SRV siano accurati e risolti nel controller di dominio.

Soluzione alternativa 3: aggiornare LSASS:

1. Aprire una connessione SSH al nodo e accedere utilizzando l'account "root".
2.  Verificare che il daemon di autenticazione non sia connesso ad AD, dove <nodeID> è il numero del nodo aggiunto di recente:
   
   isi_for_array -n <nodeID> 'isi auth ads list'
   
   Se il nodo è aggiunto al dominio, viene visualizzato un output simile al seguente:
    
   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.  Verificare che il GUID di dominio non sia popolato. Se lsass non recupera correttamente la configurazione, non popolerà un valore GUID di dominio:
   
   isi_for_array -n <nodeID> /usr/likewise/bin/lw-lsa get-status | egrep -A 12 "Domain:" | egrep "Domain (SID|GUID)"
   
   Viene visualizzato un output simile al seguente:
    
   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. Eseguire il seguente comando sul nodo appena aggiunto:
   
   isi_for_array -n < node_range> /usr/similar/bin/lwsm refresh lsass
    
5. Verificare che il nuovo nodo segnali la connessione a un provider AD.
   
   isi_for_array -n < node_range> 'isi auth ads list -v'
    
6.  Verificare che venga visualizzato il valore GUID:
   
   isi_for_array -n <node_range> /usr/likewise/bin/lw-lsa get-status | egrep -A 12 "Domain:" | egrep "Domain (SID|GUID)"
   
   Viene visualizzato un output simile al seguente:
    
   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. Sul client Windows, verificare che l'utente possa eseguire l'autenticazione al cluster eseguendo il mapping di un'unità, specificando l'indirizzo IP del nodo appena aggiunto.

Soluzione alternativa 4: riavviare LSASS:

1. Aprire una connessione SSH al nodo aggiunto di recente e accedere utilizzando l'account "root".
2. Elencare i controller di dominio disponibili, dove <domain_name> è il nome di dominio completo (FQDN) del dominio a cui viene aggiunto il cluster:

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

3. Connettersi forzatamente a un controller di dominio, dove <domain_name> è l FQDN del dominio a cui viene aggiunto il cluster e <dc_name> è l FQDN del controller di dominio:

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

4. Aggiorna stato AD:

isi_classic auth ads status --refresh --all

Lo stato dovrebbe cambiare in online come mostrato di seguito:
 

5. Se lo stato viene ancora visualizzato come offline, riavviare il daemon di autenticazione (si noti che ciò interromperà l'autenticazione al nodo per un massimo di un minuto): 

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. Ripetere il passaggio 4.
7. Sul client Windows, verificare che l'utente possa eseguire l'autenticazione al cluster eseguendo il mapping di un'unità, specificando l'indirizzo IP del nodo su cui è stato riavviato LSASS.

Nota per la risoluzione dei problemi di connettività del dominio:
Se si esce e si ricongiunge il dominio, verificare che il provider Active Directory venga visualizzato nell'elenco dei provider di autenticazione per l'area pertinente dopo il ricongiungimento.

Questo dominio example.com deve essere aggiunto nuovamente poiché è stato rimosso dalla sezione 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

WebUI potrebbe essere il modo più semplice per aggiungerlo nuovamente e assicurarsi che venga eseguita la ricerca nell'ordine desiderato. Consultare la guida all'amministrazione applicabile in base alla versione di OneFS in uso. Hub di informazioni su PowerScale OneFS