VNX: DOMAIN_CONTROLLER_NOT_FOUND po upgradu kódu, který podporuje komunikaci zabezpečeného kanálu SMB2

Kód byl upgradován na jednu z výše uvedených verzí.

Po upgradu na jeden z následujících kódů se v protokolech začaly zobrazovat chybové zprávy oznamující, že řadič domény je mimo provoz:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Zpráva vypadá takto:

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

Všechny výše uvedené kódy jsou přidány do nové funkce, která umožňuje serveru NAS nebo přenašeči dat komunikovat s řadiči domény v SMB2. Před tímto kódem byla veškerá komunikace řadiče domény zpracovávána v SMB1 (i když klienti s námi mohli stále komunikovat v SMB2/SMB3).
Se změnou na protokol SMB2 nejsou všechny naše příkazy serializovány do řadičů domény. Zdá se, že některé příkazy běží paralelně současně.
Příkladem je pokus o otevření pojmenovaného kanálu lsarpc.

V této chybové zprávě je důležité si uvědomit službu, ke které se pokoušíme vytvořit vazbu:

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

Z chybové zprávy vidíme, že se pokouší otevřít LSA (zvýrazněno červeně). Zde nastává problém. Pokusíme se otevřít kanál s názvem lsarpc vícekrát současně, než obdržíme odpověď z řadiče domény. První požadavek je úspěšný, ale další selžou. Zobrazí se chybové zprávy označující STATUS_PIPE_NOT_AVAILABLE a zapíšeme zprávu DOMAIN_CONTROLLER_NOT_FOUND do protokolů.

Je důležité si uvědomit, že tyto zprávy ne vždy indikují tento problém. DOMAIN_CONTROLLER_NOT_FOUND chyby mohou mít mnoho příčin.
Tento konkrétní bude mít pravděpodobně v protokolech mnoho následujících informačních zpráv:

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

Pokud existují nějaké dotazy ohledně toho, zda problém odpovídá problému, lze jej potvrdit v trasování paketů. V trasování bychom viděli několik souběžných požadavků na otevření lsarpc před přijetím odpovědi na některý z nich, následovaných prvním úspěšným a následnými selháním s STATUS_PIPE_NOT_AVAILABLE, když řadič domény odpoví.

K tomuto problému dochází hlavně v systémech, které vyžadují velké množství vyhledávání SID na řadiči domény. Pokud jsou v prostředí osamocené SID, má tendenci protokolovat mnohem více těchto chyb. To je způsobeno objemem provozu odesílaného do řadiče domény. Při každém přístupu k seznamu ACL je nutné řadiči domény odeslat požadavek na zjištění identity všech identifikátorů SID, které nemáme v mezipaměti SID. Osamocené identifikátory SID nejsou nikdy v mezipaměti identifikátorů SID a jsou vyhledány pokaždé, když se zvýší počet otevření, které musíme provést v pojmenovaném kanálu lsarpc.

Jelikož první pokus o otevření proběhne úspěšně, jedná se o událost, která nemá žádný vliv a tyto zprávy je možné ignorovat.

Trvalá oprava:
Technický tým si je tohoto problému vědom a pracuje na opravě v budoucí verzi kódu. Jedná se o nerušivý problém, který lze do té doby bezpečně ignorovat. Pokud se však chcete pokusit zprávu omezit nebo odstranit, jsou k dispozici některá řešení.

Zástupné řešení 1:
Existuje několik způsobů, jak zabránit výskytu těchto zpráv v protokolech. Vzhledem k tomu, že problém způsobuje více souběžných pokusů o otevření na kanálu lsarpc, nejjednodušší způsob, jak snížit počet zpráv, je snížit množství potřebných vyhledávání SID.

Osamocená identifikátoru SID způsobuje toto nadměrné vyhledávání. Následující parametr lze upravit tak, aby vynutil vyhledávání tak, aby hledalo v mezipaměti secmap neznámé identifikátory SID, a měl by snížit množství provozu směřujícího do řadiče domény:

[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

To se překládá jako následující informace:
Bit0 = Ukládá neznámý identifikátor sid.
Bit1 = Ukládá identifikátor sid bez mapování na UNIX.
Bit2 = Povolí trasování ladění.
Bit3 = Vyhledávání pouze v mezipaměti (secmap nebo mezipaměť globalSid nebo mezipaměť SID pro připojení)

Jsou-li nastaveny bity 0 a 1 (0x3 jako hodnota), pak mohou být osamocené identifikátory SID uloženy v seznamech ACL systému souborů (ve výchozím nastavení tomu tak není). Doporučuje se změnit hodnotu z 0x3 na 0x11, tím se zapne bit 0,1 a 3. To znamená, že ukládejte neznámé identifikátory SID bez mapování systému Unix a hledejte pouze v mezipaměti secmap a globálních identifikátorů SID. Pokud je nastaven na 0x8 nebo jinou kombinaci, kde jsou bity 0 a 1 vypnuty, pak osiřelé identifikátory SID není povoleno ukládat a v tomto parametru by neměla být prováděna žádná změna.

Pokud chcete parametr upravit, lze spustit následující příkaz:

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

To pravděpodobně snižuje výskyt, ale může, ale nemusí je zcela eliminovat.

Alternativní řešení 2:
Spolehlivým způsobem, jak se těchto chyb v protokolech zbavit, je vrátit chování komunikace řadiče domény do stavu, v jakém bylo před novými kódy (to znamená, že mluvíme pouze s řadiči domény v protokolu SMB1).

Pokud se chcete pro stejnosměrnou komunikaci vrátit k protokolu SMB1 (staré chování VNX), obraťte se na podporu společnosti Dell a odkažte se na tento článek znalostní databáze.