VNX: DOMAIN_CONTROLLER_NOT_FOUND después de actualizar el código que admite comunicaciones de canal seguro SMB2
Summary: DOMAIN_CONTROLLER_NOT_FOUND mensajes después de actualizar el código que admite comunicaciones de canal seguro SMB2 con DC. (Corregible por Dell)
Symptoms
El código se actualizó a una de las versiones enumeradas anteriormente.
Después de actualizar a uno de los siguientes códigos, comenzaron a aparecer mensajes de error en los registros que indicaban que la controladora de dominio estaba inactiva:
VNX2:
8.1.9.211
VNX1:
7.1.82.0
El mensaje se ve así:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Cause
Todos los códigos mencionados anteriormente se agregan en una nueva característica que permite que el servidor NAS o el administrador de transferencia de datos se comuniquen con las controladoras de dominio en SMB2. Antes de esto, las comunicaciones del controlador de dominio de código se manejaban en SMB1 (aunque los clientes aún podían hablar con nosotros en SMB2/SMB3).
Con el cambio a SMB2, no todos nuestros comandos se serializan en las controladoras de dominio. Esto parece llevar a que algunos comandos se ejecuten simultáneamente en paralelo.
Un ejemplo es el intento de abrir la canalización denominada lsarpc.
En este mensaje de error, es importante tener en cuenta el servicio al que intentamos enlazarnos:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
En el mensaje de error, podemos ver que está intentando abrir LSA (resaltado en rojo). Aquí es donde entra el problema. Intentamos abrir la canalización denominada lsarpc varias veces simultáneamente antes de recibir una respuesta de la DC. La primera solicitud se realiza correctamente, pero las siguientes fallan. Vemos los mensajes de falla que indican STATUS_PIPE_NOT_AVAILABLE y registramos el mensaje de DOMAIN_CONTROLLER_NOT_FOUND en los registros.
Es importante tener en cuenta que estos mensajes no siempre indican este problema. DOMAIN_CONTROLLER_NOT_FOUND errores pueden tener muchas causas.
Es probable que este en particular tenga muchos de los siguientes mensajes informativos en los registros:
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
Si hay alguna pregunta sobre si el problema coincide o no con el problema, se puede confirmar en un seguimiento de paquetes. En el seguimiento, veríamos varias solicitudes simultáneas para abrir lsarpc antes de recibir una respuesta a cualquiera de ellas, seguidas de la primera que se realiza correctamente y las posteriores que fallan con STATUS_PIPE_NOT_AVAILABLE cuando la DC responde.
Este problema tiende a ocurrir principalmente en sistemas que requieren una gran cantidad de búsquedas de SID en la controladora de dominio. Si hay SID huérfanos en el entorno, tiende a registrar muchos más de estos errores. Esto se debe a la cantidad de tráfico que se está enviando a la DC, cada vez que se accede a una ACL tenemos que enviar una solicitud a la DC para solicitar la identidad de cualquier SID que no tengamos en nuestra caché de SID. Los SID huérfanos nunca están en la caché de SID y se intentan buscar cada vez que aumentan la cantidad de aperturas que tenemos que hacer en la canalización denominada lsarpc.
Como el primer intento abierto se realiza correctamente, este es un evento sin impacto y estos mensajes se pueden ignorar.
Resolution
Corrección permanente:
El equipo de ingeniería está al tanto del problema y está trabajando para encontrar una corrección en una versión futura del código. Este es un problema no disruptivo y, mientras tanto, se puede ignorar de manera segura. Sin embargo, si desea intentar reducir o eliminar el mensaje, hay algunas soluciones alternativas disponibles.
Solución alternativa 1:
Hay un par de maneras de intentar detener la aparición de estos mensajes en los registros. Dado que varios intentos de apertura simultáneos en la canalización lsarpc causan el problema, la manera más sencilla de reducir los mensajes es reducir la cantidad de búsquedas de SID necesarias.
Los SID huérfanos causan estas búsquedas excesivas. El siguiente parámetro se puede modificar para forzar las búsquedas para buscar sids desconocidos en la caché de secmap y debe reducir la cantidad de tráfico que va a la 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
Esto se traduce en la siguiente información:
Bit0 = almacena sid desconocido.
Bit1 = almacena sid sin mapeo de UNIX.
Bit2 = habilita los seguimientos de depuración.
Bit3 = solo realizar una búsqueda en la caché (caché secmap o globalSid o caché SID por conexión)
Si los bits 0 y 1 se configuran (0x3 como un valor), se permite que los SID huérfanos se almacenen en las ACL del sistema de archivos (de manera predeterminada, no lo hacen). Se sugiere cambiar el valor de 0x3 a 0x11, esto enciende los bits 0,1 y 3. Esto significa almacenar SID desconocidos sin mapeo de Unix y solo buscar en cachés de SID globales y secmap. Si se establece en 0x8 u otra combinación en la que los bits 0 y 1 están desactivados, no se permite almacenar sid huérfanos y no se debe realizar ningún cambio en este parámetro.
Si desea modificar el parámetro, se puede ejecutar el siguiente comando:
server_param server_2 -f cifs -m acl.mappingErrorAction -v 11
Es probable que esto reduzca las instancias, pero puede o no eliminarlas por completo.
Solución alternativa 2:
La manera segura de deshacerse de estos errores en los registros es revertir el comportamiento de comunicación de DC a lo que era antes de los nuevos códigos (lo que significa que solo nos comunicamos con los controladores de dominio en SMB1).
Si desea volver a SMB1 para las comunicaciones de DC (el comportamiento antiguo de VNX), comuníquese con el soporte de Dell y consulte este artículo de la base de conocimientos.