VNX: DOMAIN_CONTROLLER_NOT_FOUND efter opgradering af kode, der understøtter sikker SMB2-kanalkommunikation

Koden blev opgraderet til en af ovenstående versioner.

Efter opgradering til en af følgende koder begyndte der at blive vist fejlmeddelelser i logfilerne, der angiver, at domænecontrolleren var nede:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Meddelelsen ser sådan ud:

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

De førnævnte koder er alle tilføjet i en ny funktion, der gør det muligt for NAS-serveren eller dataflytteren at kommunikere med domænecontrollerne i SMB2. Før denne kode blev domænecontrollerkommunikation alle håndteret i SMB1 (selvom klienter stadig kunne tale med os i SMB2 / SMB3).
Med ændringen til SMB2 serialiseres vores kommandoer ikke alle til domænecontrollerne. Dette ser ud til at føre til, at nogle kommandoer kører samtidigt parallelt.
Et eksempel er forsøget på at åbne det navngivne lsarpc-navngivne rør.

I denne fejlmeddelelse er det vigtigt at bemærke den tjeneste, vi forsøger at binde til:

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

Fra fejlmeddelelsen kan vi se, at den forsøger at åbne LSA (fremhævet med rødt.) Det er her, problemet kommer ind. Vi forsøger at åbne lsarpc-navngivet rør flere gange samtidigt, før vi modtager et svar fra DC. Den første anmodning er vellykket, men de efterfølgende mislykkes. Vi ser fejlmeddelelserne, der angiver STATUS_PIPE_NOT_AVAILABLE, og logger den DOMAIN_CONTROLLER_NOT_FOUND meddelelse i logfilerne.

Det er vigtigt at bemærke, at disse meddelelser ikke altid angiver dette problem. DOMAIN_CONTROLLER_NOT_FOUND fejl kan have mange årsager.
Denne særlige vil sandsynligvis have mange af følgende informative meddelelser i logfilerne:

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

Hvis der er spørgsmål om, hvorvidt problemet svarer til problemet, kan det bekræftes i en pakkesporing. I sporingen ville vi se flere samtidige anmodninger om at åbne lsarpc, før vi modtog et svar på nogen af dem, efterfulgt af den første, der lykkes, og efterfølgende, der mislykkes med STATUS_PIPE_NOT_AVAILABLE, når DC svarer.

Dette problem opstår normalt hovedsageligt på systemer, der kræver mange SID-opslag på domænecontrolleren. Hvis der er forældreløse SID er i miljøet, har det en tendens til at logge mange flere af disse fejl. Dette skyldes mængden af trafik, der sendes til DC, hver gang en ACL åbnes, skal vi sende en anmodning til DC for at bede om identiteten af eventuelle SID'er, vi ikke har i vores SID-cache. Forældreløse SID'er er aldrig i SID-cachen og forsøges slået op, hver gang vi øger antallet af åbninger, vi skal gøre med det lsarpc-navngivne rør.

Da det første åbne forsøg lykkes, er dette en ikke-virkningsfuld begivenhed, og disse meddelelser kan ignoreres.

Permanent rettelse:
Engineering er opmærksom på problemet og arbejder på en rettelse i en fremtidig udgivelse af kode. Dette er et ikke-forstyrrende problem og kan ignoreres sikkert i mellemtiden. Men hvis du vil forsøge at reducere eller fjerne meddelelsen, er der nogle tilgængelige løsninger.

Løsning 1:
Der er et par måder at forsøge at forhindre disse meddelelser i at forekomme i logfilerne. Da flere samtidige åbne forsøg på lsarpc-røret forårsager problemet, er den nemmeste måde at reducere meddelelserne på at reducere mængden af nødvendige SID-opslag.

Forældreløse SID'er forårsager disse overdrevne opslag. Følgende parameter kan ændres for at tvinge opslag til at se på secmap-cache for ukendte sider og bør reducere mængden af trafik, der går til 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

Dette oversættes til følgende info:
Bit0 = Gemmer ukendt sid.
Bit1 = Gemmer sid uden UNIX-tilknytning.
Bit2 = Aktiverer fejlfindingsspor.
Bit3 = Foretag kun opslag i cache (secmap- eller globalSid-cache eller pr. forbindelse SID-cache)

Hvis bit 0 og 1 er indstillet (0x3 som en værdi), kan forældreløse SID er muligvis gemmes på filsystemets ACL'er (som standard er de ikke.). Det foreslås at ændre værdien fra 0x3 til 0x11, dette tænder bit 0,1 og 3. Det betyder, at du gemmer ukendte SID'er uden unix-kortlægning og kun ser i secmap og globale SID-cacher. Hvis den er indstillet til 0x8 eller en anden kombination, hvor bit 0 og 1 er slukket, må forældreløse sider ikke gemmes, og der skal ikke foretages nogen ændring af denne parameter.

Hvis du vil ændre parameteren, kan følgende kommando køres:

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

Dette reducerer sandsynligvis forekomsterne, men kan eller måske ikke eliminere dem helt.

Løsning 2:
Den sikre måde at slippe af med disse fejl i logfilerne er at vende DC-kommunikationsadfærden tilbage til, hvad den var før de nye koder (hvilket betyder, at vi kun taler med domænecontrollerne i SMB1.)

Hvis du vil vende tilbage til SMB1 for dc-kommunikation (den gamle VNX-funktion), skal du kontakte Dell Support og se denne vidensbaseartikel.