VNX: DOMAIN_CONTROLLER_NOT_FOUND po uaktualnieniu kodu obsługującego bezpieczny kanał komunikacyjny SMB2

Kod został uaktualniony do jednej z wersji wymienionych powyżej.

Po uaktualnieniu do jednego z poniższych kodów w dziennikach zaczęły pojawiać się komunikaty o błędach wskazujące, że kontroler domeny nie działa:
VNX2:
8.1.9.211
VNX1:
7.1.82.0

Komunikat wygląda następująco:

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

Wyżej wymienione kody zostały dodane w nowej funkcji, która umożliwia serwerowi NAS lub przenoszeniu danych komunikację z kontrolerami domeny w protokole SMB2. Przed wprowadzeniem tego kodu cała komunikacja kontrolera domeny była obsługiwana w protokole SMB1 (chociaż klienci nadal mogli komunikować się z nami w protokole SMB2/SMB3).
Po zmianie na SMB2 nie wszystkie nasze polecenia są serializowane do kontrolerów domeny. Wydaje się, że prowadzi to do tego, że niektóre polecenia działają równolegle.
Przykładem jest próba otwarcia nazwanego potoku lsarpc.

W tym komunikacie o błędzie należy zwrócić uwagę na usługę, z którą próbujemy się powiązać:

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

Z komunikatu o błędzie wynika, że próbuje on otworzyć LSA (oznaczony kolorem czerwonym). I tu pojawia się problem. Próbujemy otworzyć nazwany potok lsarpc wiele razy jednocześnie przed otrzymaniem odpowiedzi z kontrolera domeny. Pierwsze żądanie kończy się pomyślnie, ale kolejne kończą się niepowodzeniem. Wyświetlane są komunikaty o błędach wskazujące na STATUS_PIPE_NOT_AVAILABLE i rejestrujemy komunikat DOMAIN_CONTROLLER_NOT_FOUND w dziennikach.

Należy pamiętać, że te komunikaty nie zawsze wskazują na ten problem. DOMAIN_CONTROLLER_NOT_FOUND błędy mogą mieć wiele przyczyn.
Ten konkretny prawdopodobnie będzie miał wiele z następujących komunikatów informacyjnych w dziennikach:

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

Jeśli pojawią się jakiekolwiek pytania dotyczące tego, czy problem pasuje do problemu, można to potwierdzić w śledzeniu pakietów. W śladzie widzimy wiele jednoczesnych żądań otwarcia lsarpc przed otrzymaniem odpowiedzi na którekolwiek z nich, po czym pierwsze z nich kończy się niepowodzeniem, a kolejne kończą się niepowodzeniem z STATUS_PIPE_NOT_AVAILABLE, gdy kontroler domeny odpowiada.

Ten problem występuje głównie w systemach, które wymagają wielu wyszukiwań identyfikatora SID na kontrolerze domeny. Jeśli w środowisku znajdują się osierocone identyfikatory SID, zwykle rejestruje się znacznie więcej takich błędów. Jest to spowodowane ilością ruchu wysyłanego do kontrolera domeny. Za każdym razem, gdy uzyskiwany jest dostęp do listy ACL, musimy wysłać żądanie do kontrolera domeny, aby zapytać o tożsamość wszystkich identyfikatorów SID, których nie mamy w naszej pamięci podręcznej SID. Osierocone identyfikatory SID nigdy nie znajdują się w pamięci podręcznej SID i za każdym razem próbuje się je wyszukać, zwiększając liczbę otwarć, które musimy wykonać dla potoku o nazwie lsarpc.

Ponieważ pierwsza próba otwarcia zakończy się powodzeniem, jest to zdarzenie bez wpływu i te komunikaty można zignorować.

Trwałe rozwiązanie:
Inżynierowie są świadomi tego problemu i pracują nad poprawką w przyszłej wersji kodu. Jest to problem niezakłócający pracy i w międzyczasie można go bezpiecznie zignorować. Jeśli jednak chcesz spróbować zmniejszyć lub wyeliminować komunikat, dostępnych jest kilka obejść.

Obejście 1:
Istnieje kilka sposobów zapobiegania pojawianiu się tych komunikatów w dziennikach. Ponieważ wiele jednoczesnych prób otwarcia potoku lsarpc powoduje problem, najprostszym sposobem zmniejszenia liczby komunikatów jest zmniejszenie liczby potrzebnych wyszukiwań SID.

Osierocone identyfikatory SID powodują nadmierną liczbę wyszukiwań. Następujący parametr można zmodyfikować, aby wymusić wyszukiwania w celu sprawdzenia pamięci podręcznej secmap pod kątem nieznanych identyfikatorów sid i powinien zmniejszyć ilość ruchu przechodzącego do kontrolera domeny:

[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

Przekłada się to na następujące informacje:
Bit0 = Przechowuje nieznany identyfikator.
Bit1 = Przechowuje identyfikator sid bez mapowania UNIX.
Bit2 = Włącza ślady debugowania.
Bit3 = Wykonuj wyszukiwanie tylko w pamięci podręcznej (secmap lub globalSid cache lub pamięć podręczna SID dla połączenia)

Jeśli ustawiono bity 0 i 1 (0x3 jako wartość), osierocone identyfikatory SID mogą być przechowywane na listach ACL systemu plików (domyślnie nie są). Sugerowana byłaby zmiana wartości z 0x3 na 0x11, co włącza bit 0,1 i 3. Oznacza to, że przechowujesz nieznane identyfikatory SID bez mapowania uniksa i szukaj tylko w secmap i globalnych pamięciach podręcznych SID. Jeśli jest ustawiony na 0x8 lub inną kombinację, w której bity 0 i 1 są wyłączone, to osierocone identyfikatory SID nie mogą być przechowywane i nie należy wprowadzać żadnych zmian w tym parametrze.

Jeśli chcesz zmodyfikować parametr, możesz uruchomić następujące polecenie:

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

To prawdopodobnie zmniejsza liczbę wystąpień, ale może, ale nie musi, całkowicie je wyeliminować.

Obejście 2:
Niezawodnym sposobem na pozbycie się tych błędów w dziennikach jest przywrócenie zachowania komunikacji kontrolera domeny do stanu sprzed wprowadzenia nowych kodów (co oznacza, że komunikujemy się tylko z kontrolerami domeny w protokole SMB1).

Jeśli chcesz przywrócić protokół SMB1 dla komunikacji DC (stare zachowanie VNX), skontaktuj się z działem pomocy technicznej firmy Dell i powołaj się na ten artykuł bazy wiedzy.