VNX: DOMAIN_CONTROLLER_NOT_FOUND efter uppgradering av kod som stöder SMB2-kommunikation med säkra kanaler

Koden har uppgraderats till en av de versioner som anges ovan.

Efter uppgradering till någon av följande koder började felmeddelanden visas i loggarna som indikerade att domänkontrollanten var nere:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Meddelandet ser ut så här:

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

De tidigare nämnda koderna läggs alla till i en ny funktion som gör det möjligt för NAS-servern eller dataöverföraren att kommunicera med domänkontrollanterna i SMB2. Före den här koden hanterades domänkontrollantkommunikation i SMB1 (även om klienter fortfarande kunde prata med oss i SMB2/SMB3).
Med ändringen till SMB2 serialiseras inte alla våra kommandon till domänkontrollanterna. Detta verkar leda till att vissa kommandon körs samtidigt parallellt.
Ett exempel är försöket att öppna den namngivna lsarpc med namnet pipe.

I det här felmeddelandet är det viktigt att notera den tjänst vi försöker binda till:

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

Från felmeddelandet kan vi se att det försöker öppna LSA (markerat i rött.) Det är här problemet kommer in. Vi försöker öppna lsarpc med namnet pipe flera gånger samtidigt innan vi får något svar från domänkontrollanten. Den första begäran lyckas, men de efterföljande misslyckas. Vi ser felmeddelanden som anger STATUS_PIPE_NOT_AVAILABLE och loggar det DOMAIN_CONTROLLER_NOT_FOUND meddelandet i loggarna.

Det är viktigt att notera att dessa meddelanden inte alltid indikerar detta problem. DOMAIN_CONTROLLER_NOT_FOUND fel kan ha många orsaker.
Just den här kommer sannolikt att ha många av följande informationsmeddelanden i loggarna:

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

Om det finns några frågor om huruvida problemet matchar problemet eller inte kan det bekräftas i en paketspårning. I spårningen skulle vi se flera samtidiga begäranden om att öppna lsarpc innan vi får ett svar på någon av dem, följt av att den första lyckas och efterföljande misslyckas med STATUS_PIPE_NOT_AVAILABLE när domänkontrollanten svarar.

Det här problemet tenderar främst att uppstå på system som kräver många SID-sökningar på domänkontrollern. Om det finns överblivna SID i miljön tenderar det att logga många fler av dessa fel. Detta beror på mängden trafik som skickas till domänkontrollanten, varje gång en ACL används måste vi skicka en begäran till domänkontrollanten för att be om identiteten för alla SID som vi inte har i vår SID-cache. Överblivna SID finns aldrig i SID-cachen och försök att slås upp varje gång vi ökar antalet öppningar vi måste göra till lsarpc med namnet pipe.

När det första öppna försöket lyckas är detta en icke-påverkande händelse och dessa meddelanden kan ignoreras.

Permanent korrigering:
Teknikerna är medvetna om problemet och arbetar med en korrigering i en framtida version av koden. Detta är ett icke-störande problem och kan ignoreras under tiden. Men om du vill försöka minska eller eliminera meddelandet finns det några lösningar tillgängliga.

Lösning 1:
Det finns ett par sätt att försöka stoppa dessa meddelanden från att visas i loggarna. Eftersom flera samtidiga öppna försök på lsarpc-röret orsakar problemet är det enklaste sättet att minska meddelandena att minska mängden SID-sökningar som behövs.

Överblivna SID orsakar dessa överdrivna sökningar. Följande parameter kan ändras för att tvinga sökningar att titta på secmap-cachen efter okända SID och bör minska mängden trafik som går till domänkontrollanten:

[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

Detta översätts till följande info:
Bit0 = Lagrar okänt sid.
Bit1 = Lagrar sid utan UNIX-mappning.
Bit2 = Aktiverar felsökningsspår.
Bit3 = Gör endast sökning i cache (secmap eller globalSid cache eller per anslutning SID-cache)

Om bitarna 0 och 1 anges (0x3 som ett värde) tillåts överblivna SID att lagras på filsystemets ACL:er (som standard är de inte det.). Det skulle föreslås att ändra värdet från 0x3 till 0x11, detta slår på bit 0,1 och 3. Det innebär att du lagrar okända SID utan unix-mappning och bara tittar i secmap- och globala SID-cacheminnen. Om den är inställd på 0x8 eller någon annan kombination där bitarna 0 och 1 är inaktiverade får inte överblivna SID lagras och ingen ändring bör göras i den här parametern.

Om du vill ändra parametern kan följande kommando köras:

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

Detta minskar sannolikt förekomsterna, men kan eliminera dem helt.

Lösning 2:
Det säkra sättet att bli av med dessa fel i loggarna är att återställa DC-kommunikationsbeteendet till vad det var före de nya koderna (vilket innebär att vi bara pratar med domänkontrollanterna i SMB1.)

Om du vill återgå till SMB1 för DC-kommunikation (det gamla VNX-beteendet) kontaktar du Dells support och läser den här kunskapsbasartikeln.