VNX: DOMAIN_CONTROLLER_NOT_FOUND etter oppgradering av kode som støtter sikker SMB2-kanalkommunikasjon

Koden ble oppgradert til en av versjonene som er oppført ovenfor.

Etter oppgradering til en av følgende koder, begynte feilmeldinger å vises i loggene som indikerer at domenekontrolleren var nede:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Meldingen ser slik ut:

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

De nevnte kodene er alle lagt til i en ny funksjon som lar NAS-serveren eller dataflytteren kommunisere med domenekontrollerne i SMB2. Før denne koden ble domenekontrollerkommunikasjon alle håndtert i SMB1 (selv om klienter fortsatt kunne snakke med oss i SMB2/SMB3).
Med endringen til SMB2 blir ikke alle kommandoene våre serialisert til domenekontrollerne. Dette ser ut til å føre til at noen kommandoer kjører samtidig parallelt.
Et eksempel er forsøket på å åpne den navngitte lsarpc-navngitte røret.

I denne feilmeldingen er det viktig å merke seg tjenesten vi prøver å binde til:

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

Fra feilmeldingen kan vi se at den prøver å åpne LSA (uthevet i rødt.) Det er her problemet kommer inn. Vi forsøker å åpne lsarpc navngitt rør flere ganger samtidig før vi får svar fra DC. Den første forespørselen er vellykket, men de påfølgende mislykkes. Vi ser feilmeldingene som indikerer STATUS_PIPE_NOT_AVAILABLE og logger den DOMAIN_CONTROLLER_NOT_FOUND meldingen i loggene.

Det er viktig å merke seg at disse meldingene ikke alltid indikerer dette problemet. DOMAIN_CONTROLLER_NOT_FOUND feil kan ha mange årsaker.
Dette bestemte vil sannsynligvis ha mange av følgende informasjonsmeldinger i loggene:

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 det er spørsmål om problemet samsvarer med problemet eller ikke, kan det bekreftes i et pakkespor. I sporingen vil vi se flere samtidige forespørsler om å åpne lsarpc før vi mottar svar på noen av dem, etterfulgt av den første som lykkes og påfølgende som mislykkes med STATUS_PIPE_NOT_AVAILABLE når DC svarer.

Dette problemet oppstår vanligvis på systemer som krever mange SID-oppslag på domenekontrolleren. Hvis det er foreldreløse SID i miljøet, har det en tendens til å logge mange flere av disse feilene. Dette er på grunn av mengden trafikk som sendes til DC, hver gang en ACL er tilgjengelig, må vi sende en forespørsel til DC for å be om identiteten til eventuelle SID vi ikke har i vår SID cache. Foreldreløse SID er aldri i SID cache og er forsøkt å bli slått opp hver gang øke mengden åpner vi har å gjøre til lsarpc navngitt pipe.

Når det første åpne forsøket lykkes, er dette en ikke-virkningsfull hendelse, og disse meldingene kan ignoreres.

Permanent løsning:
Teknisk avdeling er klar over problemet og jobber med å finne en løsning i en fremtidig utgivelse av kode. Dette er et ikke-forstyrrende problem som trygt kan ignoreres i mellomtiden. Men hvis du vil prøve å redusere eller eliminere meldingen, er det noen løsninger tilgjengelig.

Løsning 1:
Det er et par måter å prøve å stoppe disse meldingene fra å forekomme i loggene. Siden flere samtidige åpne forsøk på lsarpc-røret forårsaker problemet, er den enkleste måten å redusere meldingene på å redusere mengden SID-oppslag som trengs.

Isolerte SID forårsaker disse overdrevne oppslagene. Følgende parameter kan endres for å tvinge oppslag til å se på secmap cache for ukjente SIDS og bør redusere mengden trafikk som 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 oversettes til følgende info:
Bit0 = Lagrer ukjent sid.
Bit1 = Lagrer sid uten UNIX-tilordning.
Bit2 = Aktiverer feilsøkingsspor.
Bit3 = Bare gjøre oppslag i cache (secmap eller globalSid cache eller per tilkobling SID cache)

Hvis bitene 0 og 1 er angitt (0x3 som en verdi), kan isolerte SID lagres på filsystemets ACLer (som standard er de ikke det.). Det vil bli foreslått å endre verdien fra 0x3 til 0x11, dette slår på bit 0,1 og 3. Det betyr å lagre ukjente SID uten unix-tilordning og bare se i secmap og globale SID-cacher. Hvis den er satt til 0x8 eller en annen kombinasjon der bits 0 og 1 er slått av, kan ikke foreldreløse sider lagres, og det bør ikke gjøres endringer i denne parameteren.

Hvis du vil endre parameteren, kan følgende kommando kjøres:

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

Dette reduserer sannsynligvis forekomstene, men kan eller ikke eliminere dem helt.

Løsning 2:
Den sikre måten å kvitte seg med disse feilene i loggene er å tilbakestille DC-kommunikasjonsadferden til hva den var før de nye kodene (noe som betyr at vi bare snakker med domenekontrollerne i SMB1.)

Hvis du vil gå tilbake til SMB1 for DC-kommunikasjon (Den gamle VNX-virkemåten), kontakter du Dells kundestøtte og ser denne kunnskapsartikkelen.