VNX: DOMAIN_CONTROLLER_NOT_FOUND nach dem Upgrade von Code, der die sichere SMB2-Kanalkommunikation unterstützt
Summary: DOMAIN_CONTROLLER_NOT_FOUND Meldungen nach dem Upgrade von Code, der die sichere SMB2-Kanalkommunikation mit DCs unterstützt. (von Dell korrigierbar)
Symptoms
Der Code wurde auf eine der oben aufgeführten Versionen aktualisiert.
Nach dem Upgrade auf einen der folgenden Codes wurden in den Protokollen Fehlermeldungen angezeigt, die darauf hinwiesen, dass der Domain Controller ausgefallen war:
VNX2:
8.1.9.211
VNX1:
7.1.82.0
Die Meldung sieht folgendermaßen aus:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Cause
Die oben genannten Codes werden alle in einer neuen Funktion hinzugefügt, die es dem NAS-Server oder Data Mover ermöglicht, mit den Domain Controllern in SMB2 zu kommunizieren. Vor diesem Code wurde die gesamte Domänencontrollerkommunikation in SMB1 verarbeitet (obwohl Clients weiterhin in SMB2/SMB3 mit uns kommunizieren konnten).
Mit der Umstellung auf SMB2 werden nicht alle unsere Befehle auf die Domain Controller serialisiert. Dies scheint dazu zu führen, dass einige Befehle parallel ausgeführt werden.
Ein Beispiel ist der Versuch, die benannte lsarpc benannte Pipe zu öffnen.
In dieser Fehlermeldung ist es wichtig, den Service zu notieren, an den wir binden möchten:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Aus der Fehlermeldung können wir ersehen, dass versucht wird, LSA zu öffnen (rot markiert). Hier kommt das Problem ins Spiel. Wir versuchen, die lsarpc named pipe mehrmals gleichzeitig zu öffnen, bevor wir eine Antwort vom DC erhalten. Die erste Anforderung ist erfolgreich, die nachfolgenden schlagen jedoch fehl. Die Fehlermeldungen weisen auf STATUS_PIPE_NOT_AVAILABLE hin und protokollieren die DOMAIN_CONTROLLER_NOT_FOUND Meldung in den Protokollen.
Beachten Sie, dass diese Meldungen nicht immer auf dieses Problem hinweisen. DOMAIN_CONTROLLER_NOT_FOUND Fehler können viele Ursachen haben.
In diesem speziellen Fall sind wahrscheinlich viele der folgenden Informationsmeldungen in den Protokollen enthalten:
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
Wenn es Fragen dazu gibt, ob das Problem mit dem Problem übereinstimmt, kann dies in einer Paketablaufverfolgung bestätigt werden. In der Ablaufverfolgung sehen wir mehrere gleichzeitige Anforderungen zum Öffnen von lsarpc, bevor wir eine Antwort auf eine davon erhalten, gefolgt von der ersten und nachfolgenden mit STATUS_PIPE_NOT_AVAILABLE, die fehlschlagen, wenn der DC antwortet.
Dieses Problem tritt in der Regel hauptsächlich auf Systemen auf, die viele SID-Suchen auf dem Domänencontroller erfordern. Wenn in der Umgebung verwaiste SIDs vorhanden sind, werden tendenziell viel mehr dieser Fehler protokolliert. Dies liegt an der Menge des Datenverkehrs, der an den DC gesendet wird. Jedes Mal, wenn auf eine ACL zugegriffen wird, müssen wir eine Anfrage an den DC senden, um nach der Identität von SIDs zu fragen, die sich nicht in unserem SID-Cache befinden. Verwaiste SIDs befinden sich nie im SID-Cache und werden jedes Mal versucht, nachgeschlagen zu werden, wodurch die Anzahl der Öffnungen in der lsarpc named pipe steigt.
Da der erste Öffnungsversuch erfolgreich ist, ist dies ein Ereignis ohne Auswirkung und diese Meldungen können ignoriert werden.
Resolution
Dauerhafte Lösung:
Die Technikabteilung ist sich des Problems bewusst und arbeitet an einer Korrektur in einer zukünftigen Codeversion. Hierbei handelt es sich um ein unterbrechungsfreies Problem, das in der Zwischenzeit ignoriert werden kann. Wenn Sie jedoch versuchen möchten, die Meldung zu reduzieren oder zu eliminieren, stehen einige Problemumgehungen zur Verfügung.
Problemumgehung 1:
Es gibt mehrere Möglichkeiten, um zu verhindern, dass diese Meldungen in den Protokollen angezeigt werden. Da mehrere gleichzeitige Open-Versuche auf der lsarpc-Pipe das Problem verursachen, besteht die einfachste Möglichkeit, die Meldungen zu reduzieren, darin, die Anzahl der erforderlichen SID-Abfragen zu reduzieren.
Verwaiste SIDs verursachen diese exzessiven Suchvorgänge. Der folgende Parameter kann geändert werden, um zu erzwingen, dass Suchvorgänge den secmap-Cache nach unbekannten SIDs durchsuchen, und sollte die Menge des Datenverkehrs zum DC reduzieren:
[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
Dies führt zu den folgenden Informationen:
Bit0 = Speichert unbekannte Sid.
Bit1 = Speichert SID ohne UNIX-Zuordnung.
Bit2 = Aktiviert Debug-Ablaufverfolgungen.
Bit3 = Nur Suche im Cache durchführen (secmap- oder globalSid-Cache oder SID-Cache pro Verbindung)
Wenn die Bits 0 und 1 festgelegt sind (0x3 als Wert), dürfen verwaiste SIDs auf Dateisystem-ACLs gespeichert werden (standardmäßig ist dies nicht der Fall). Es wird vorgeschlagen, den Wert von 0x3 auf 0x11 zu ändern, dies schaltet Bit 0,1 und 3 ein. Das bedeutet, dass Sie unbekannte SIDs ohne UNIX-Zuordnung speichern und nur in secmap und globalen SID-Caches suchen. Wenn er auf 0x8 oder eine andere Kombination festgelegt ist, bei der die Bits 0 und 1 deaktiviert sind, dürfen verwaiste SIDs nicht gespeichert werden und es sollte keine Änderung an diesem Parameter vorgenommen werden.
Wenn Sie den Parameter ändern möchten, kann der folgende Befehl ausgeführt werden:
server_param server_2 -f cifs -m acl.mappingErrorAction -v 11
Dies reduziert wahrscheinlich die Vorkommnisse, kann sie aber möglicherweise vollständig eliminieren, muss es aber nicht.
Problemumgehung 2:
Die todsichere Methode, diese Fehler in den Protokollen loszuwerden, besteht darin, das DC-Kommunikationsverhalten auf das Verhalten vor den neuen Codes zurückzusetzen (d. h., wir kommunizieren nur mit den Domain Controllern in SMB1).
Wenn Sie für die DC-Kommunikation zu SMB1 zurückkehren möchten (das alte VNX-Verhalten), wenden Sie sich an den Dell Support und verweisen Sie auf diesen Wissensdatenbank-Artikel.