VNX: DOMAIN_CONTROLLER_NOT_FOUND dopo l'aggiornamento del codice che supporta le comunicazioni di canale protette SMB2
Summary: DOMAIN_CONTROLLER_NOT_FOUND messaggi dopo l'aggiornamento del codice che supporta le comunicazioni di canale sicure SMB2 con i controller di dominio. (correggibile da Dell)
Symptoms
Il codice è stato aggiornato a una delle versioni elencate in precedenza.
Dopo l'aggiornamento a uno dei seguenti codici, nei registri cominciavano a essere visualizzati messaggi di errore che indicavano che il controller di dominio era inattivo:
VNX2:
8.1.9.211
VNX1:
7.1.82.0
Il messaggio è simile al seguente:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Cause
Tutti questi codici vengono aggiunti in una nuova funzione che consente al server NAS o al data mover di comunicare con i controller di dominio in SMB2. Prima di questo codice, tutte le comunicazioni del controller di dominio venivano gestite in SMB1 (anche se i client potevano ancora comunicare con noi in SMB2/SMB3).
Con la modifica a SMB2, i comandi non sono tutti serializzati nei controller di dominio. Ciò sembra portare all'esecuzione simultanea di alcuni comandi in parallelo.
Un esempio è il tentativo di aprire la named pipe lsarpc denominata.
In questo messaggio di errore, è importante annotare il servizio a cui si sta tentando di eseguire l'associazione:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Dal messaggio di errore si evince che sta tentando di aprire LSA (evidenziato in rosso). È qui che entra in gioco il problema. Tentiamo di aprire la named pipe lsarpc più volte contemporaneamente prima di ricevere una risposta dal DC. La prima richiesta ha esito positivo, ma le successive hanno esito negativo. Vengono visualizzati i messaggi di errore che indicano STATUS_PIPE_NOT_AVAILABLE e il messaggio di DOMAIN_CONTROLLER_NOT_FOUND viene registrato nei registri.
È importante notare che questi messaggi non sempre indicano questo problema. DOMAIN_CONTROLLER_NOT_FOUND errori possono avere molte cause.
È probabile che questo particolare messaggio contenga molti dei seguenti messaggi informativi nei registri:
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
In caso di domande sulla corrispondenza o meno tra il problema e il problema, è possibile confermarlo in una traccia dei pacchetti. Nella traccia, vedremmo più richieste simultanee di aprire lsarpc prima di ricevere una risposta a una di esse, seguite dalla prima che ha esito positivo e da quelle successive che non hanno esito negativo con STATUS_PIPE_NOT_AVAILABLE quando il controller di dominio risponde.
Questo problema tende a verificarsi principalmente su sistemi che richiedono molte ricerche SID sul controller di dominio. Se nell'ambiente sono presenti SID orfani, tende a registrare molti più di questi errori. Ciò è dovuto alla quantità di traffico inviato al controller di dominio, ogni volta che si accede a un ACL è necessario inviare una richiesta al controller di dominio per richiedere l'identità di tutti i SID non presenti nella cache SID. I SID orfani non sono mai presenti nella cache SID e viene tentata la ricerca ogni volta che aumenta la quantità di aperture che dobbiamo fare alla named pipe lsarpc.
Poiché il primo tentativo di apertura ha esito positivo, si tratta di un evento senza impatto e questi messaggi possono essere ignorati.
Resolution
Correzione permanente:
I tecnici sono a conoscenza del problema e stanno lavorando per una correzione in una futura versione del codice. Si tratta di un problema che non comporta interruzioni e nel frattempo può essere tranquillamente ignorato. Tuttavia, se si desidera provare a ridurre o eliminare il messaggio, sono disponibili alcune soluzioni alternative.
Soluzione alternativa 1:
Esistono un paio di modi per provare e impedire che questi messaggi si verifichino nei registri. Poiché il problema è causato da più tentativi aperti simultanei sulla pipe lsarpc, il modo più semplice per ridurre i messaggi consiste nel ridurre la quantità di ricerche SID necessarie.
I SID orfani causano queste ricerche eccessive. Il seguente parametro può essere modificato per forzare le ricerche a cercare sid sconosciuti nella cache secmap e ridurre la quantità di traffico verso il DC:
[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
Ciò si traduce nelle seguenti informazioni:
Bit0 = Archivia sid sconosciuto.
Bit1 = Archivia sid senza mapping UNIX.
Bit2 = Abilita le tracce di debug.
Bit3 = Eseguire solo la ricerca nella cache (cache secmap o globalSid o cache SID per connessione)
Se i bit 0 e 1 sono impostati (0x3 come valore), i SID orfani possono essere archiviati negli ACL del file system (per impostazione predefinita non lo sono). Si consiglia di modificare il valore da 0x3 a 0x11, questo attiva i bit 0,1 e 3. Ciò significa archiviare SID sconosciuti senza mapping UNIX e cercare solo nelle cache secmap e SID globali. Se è impostato su 0x8 o su un'altra combinazione in cui i bit 0 e 1 sono disattivati, non è possibile memorizzare i sid orfani e non apportare alcuna modifica a questo parametro.
Se si desidera modificare il parametro, è possibile eseguire il seguente comando:
server_param server_2 -f cifs -m acl.mappingErrorAction -v 11
Questo probabilmente riduce gli eventi, ma può eliminarli o meno del tutto.
Soluzione alternativa 2:
Il modo infallibile per eliminare questi errori nei registri consiste nel ripristinare il comportamento di comunicazione del controller di dominio a quello precedente ai nuovi codici (il che significa che parliamo solo con i controller di dominio in SMB1).
Se si desidera tornare a SMB1 per le comunicazioni dc (comportamento VNX precedente), contattare il supporto Dell e fare riferimento a questo articolo della Knowledge Base.