VNX: DOMAIN_CONTROLLER_NOT_FOUND após o upgrade do código compatível com comunicações de canal seguro SMB2
Summary: DOMAIN_CONTROLLER_NOT_FOUND mensagens após o upgrade do código compatível com comunicações de canal seguro SMB2 com DCs. (Corrigível pela Dell)
Symptoms
O código foi atualizado para uma das versões listadas acima.
Depois de fazer upgrade para um dos seguintes códigos, mensagens de erro começaram a aparecer nos logs indicando que o controlador de domínio estava inativo:
VNX2:
8.1.9.211
VNX1:
7.1.82.0
A mensagem tem a seguinte aparência:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Cause
Todos os códigos mencionados acima foram adicionados em um novo recurso que permite que o servidor NAS ou o Data Mover se comunique com os controladores de domínio no SMB2. Antes desse código, as comunicações do controlador de domínio eram todas tratadas no SMB1 (embora os clientes ainda pudessem falar conosco no SMB2/SMB3).
Com a mudança para SMB2, nossos comandos não são todos serializados para os controladores de domínio. Isso parece estar levando a alguns comandos executados simultaneamente em paralelo.
Um exemplo é a tentativa de abrir o lsarpc chamado pipe nomeado.
Nessa mensagem de erro, é importante observar o serviço ao qual estamos tentando vincular:
2017-06-20 20:51:27: SMB: 3:[NASSERVER1] OpenAndBind[LSA] DC=DC01 failed: Bind_OpenXFailed DOMAIN_CONTROLLER_NOT_FOUND
Na mensagem de erro, podemos ver que ele está tentando abrir o LSA (realçado em vermelho). É aí que entra o problema. Tentamos abrir o lsarpc nomeado pipe várias vezes simultaneamente antes de receber uma resposta do DC. A primeira solicitação é bem-sucedida, mas as subsequentes falham. Nós vemos as mensagens de falha indicando STATUS_PIPE_NOT_AVAILABLE e registramos a mensagem DOMAIN_CONTROLLER_NOT_FOUND nos logs.
É importante observar que essas mensagens nem sempre indicam esse problema. DOMAIN_CONTROLLER_NOT_FOUND erros podem ter muitas causas.
É provável que este em particular tenha muitas das seguintes mensagens informativas nos 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
Se houver alguma dúvida sobre se o problema corresponde ou não ao problema, isso pode ser confirmado em um rastreamento de pacote. No rastreamento, veríamos várias solicitações simultâneas para abrir lsarpc antes de receber uma resposta a qualquer uma delas, seguidas pela primeira com sucesso e as subsequentes falhando com STATUS_PIPE_NOT_AVAILABLE quando o DC responde.
Esse problema tende a ocorrer principalmente em sistemas que exigem muitas pesquisas de SID no controlador de domínio. Se houver SIDs órfãos no ambiente, ele tende a registrar muito mais desses erros. Isso se deve à quantidade de tráfego que está sendo enviado para o DC, cada vez que uma ACL é acessada, temos que enviar uma solicitação ao DC para solicitar a identidade de algum SID que não temos em nosso cache de SID. Os SIDs órfãos nunca estão no cache de SID e são tentados a ser procurados toda vez que aumenta a quantidade de aberturas que precisamos fazer no lsarpc chamado pipe.
Quando a primeira tentativa aberta é bem-sucedida, esse é um evento sem impacto e essas mensagens podem ser ignoradas.
Resolution
Correção permanente:
A engenharia está ciente do problema e está trabalhando para uma correção em uma versão futura do código. Esse é um problema não disruptivo e pode ser ignorado com segurança enquanto isso. No entanto, se você quiser tentar reduzir ou eliminar a mensagem, há algumas soluções temporárias disponíveis.
Solução temporária 1:
Há algumas maneiras de tentar impedir que essas mensagens ocorram nos logs. Como várias tentativas abertas simultâneas no tubo lsarpc causam o problema, a maneira mais fácil de reduzir as mensagens é reduzir a quantidade de pesquisas de SID necessárias.
Os SIDs órfãos causam essas pesquisas excessivas. O parâmetro a seguir pode ser modificado para forçar as pesquisas a procurar sids desconhecidos no cache secmap e deve reduzir a quantidade de tráfego que vai para o 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
Isso se traduz nas seguintes informações:
Bit0 = armazena o SID desconhecido.
Bit1 = armazena o sid sem mapeamento UNIX.
Bit2 = ativa rastreamentos de depuração.
Bit3 = somente fazer pesquisa no cache (cache secmap ou globalSid ou cache SID por conexão)
Se os bits 0 e 1 forem definidos (0x3 como um valor), os SIDs órfãos poderão ser armazenados em ACLs do file system (por padrão, eles não são). Seria sugerido alterar o valor de 0x3 para 0x11, isso ativa os bits 0,1 e 3. Isso significa armazenar SIDs desconhecidos sem mapeamento unix e procurar apenas em caches secmap e SID global. Se ele estiver definido como 0x8 ou outra combinação em que os bits 0 e 1 são desativados, os SIDs órfãos não podem ser armazenados e nenhuma alteração deve ser feita nesse parâmetro.
Se você quiser modificar o parâmetro, o seguinte comando pode ser executado:
server_param server_2 -f cifs -m acl.mappingErrorAction -v 11
Isso provavelmente reduz as ocorrências, mas pode ou não eliminá-las completamente.
Solução temporária 2:
A maneira infalível de se livrar desses erros nos logs é reverter o comportamento de comunicação do DC para o que era antes dos novos códigos (o que significa que só falamos com os controladores de domínio no SMB1).
Se você quiser reverter para SMB1 para comunicações dc (o antigo comportamento do VNX), entre em contato com o suporte Dell e consulte este artigo da base de conhecimento.