Desde a atualização de todo o site para o Windows 7 no computador, comecei a ter um problema com a verificação de vírus.
Especificamente - ao fazer uma operação de renomeação em um compartilhamento CIFS (arquivado hospedado). O verificador de vírus parece estar acionando um conjunto de mensagens no arquivador:
[filerB: auth.trace.authenticateUser.loginTraceIP:info]: AUTH: Login attempt by user server-wk8-r2$ of domain MYDOMAIN from client machine 10.1.1.20 (server-wk8-r2).
[filerB: auth.dc.trace.DCConnection.statusMsg:info]: AUTH: TraceDC- attempting authentication with domain controller \MYDC.
[filerB: auth.trace.authenticateUser.loginRejected:info]: AUTH: Login attempt by user rejected by the domain controller with error 0xc0000199: STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT.
[filerB: auth.trace.authenticateUser.loginTraceMsg:info]: AUTH: Delaying the response by 5 seconds due to continuous failed login attempts by user server-wk8-r2$ of domain MYDOMAIN from client machine 10.1.1.20.
Isso parece ser acionado especificamente em rename , então o que achamos que está acontecendo é que o verificador de vírus está vendo um arquivo "novo" e tentando fazer uma varredura ao acessar. O verificador de vírus - anteriormente executado como LocalSystem e, portanto, enviando null como solicitação de autenticação, agora está parecendo um ataque do DOS e fazendo com que o arquivador fique temporariamente na lista negra.
Este 5s bloqueia cada 'tentativa de acesso' é um incômodo menor na maior parte do tempo, e realmente bastante significativo para algumas operações - por exemplo, grandes transferências de arquivos, onde cada arquivo leva 5s
Tendo feito algumas pesquisas, isso parece estar relacionado à autenticação NLTM:
Symptoms
Error message:
System error 1808 has occurred.
The account used is a computer account. Use your global user account or local user account to access this server.
A packet trace of the failure will show the error as:
STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT (0xC0000199)
Cause
Microsoft has changed the functionality of how a Local System account identifies itself
during NTLM authentication. This only impacts NTLM authentication. It does not impact
Kerberos Authentication.
Solution
On the host, please set the following group policy entry and reboot the host.
Network Security: Allow Local System to use computer identity for NTLM: Disabled
Defining this group policy makes Windows Server 2008 R2 and Windows 7 function like Windows Server 2008 SP1.
Então, agora temos algumas soluções alternativas que não são particularmente legais - uma delas é alterar essa opção de segurança.
Uma delas é desativar a verificação de vírus ou, de outra forma, isentar parte da infraestrutura.
E aqui é onde eu chego ao meu pedido de assistência do ServerFault - qual é o melhor caminho para a frente? Eu não tenho experiência no Windows para ter certeza do que estou vendo.
Não sei bem por que o NTLM faz parte dessa imagem em primeiro lugar - achei que estávamos usando a autenticação Kerberos. Não sei como começar a diagnosticar ou solucionar problemas. (Nós estamos indo cross domain - contas de máquina de estação de trabalho estão em um domínio AD e DNS separado para o meu arquivador. Autenticação de usuário normal funciona bem no entanto.)
E, na falta disso, alguém pode sugerir outras linhas de pesquisa? Gostaria de evitar uma alteração de opção de segurança ampla no site ou, se eu fizer isso, precisarei fornecer um raciocínio detalhado. Da mesma forma - desabilitar a verificação de vírus funciona como uma solução temporária de curto prazo, e aplicar exclusões may ajuda ... mas eu prefiro não, e não acho que isso resolve o problema subjacente.
EDITAR:
Filers no AD ldap possuem SPNs para:
nfs/host.fully.qualified.domain
nfs/host
HOST/host.fully.qualified.domain
HOST/host
(Desculpe, tenho que ofuscar esses).
Poderia ser que sem um 'cifs / host.fully.qualified.domain' não vai funcionar? (ou algum outro SPN?)
Edit: Como parte da pesquisa que fiz, descobri:
link
O que sugere que vários tipos de criptografia foram desativados por padrão no Win7 / 2008R2. Este pode ser pertinente, já que definitivamente tivemos um problema similar com o Keberized NFSv4.
Há uma opção oculta que pode ajudar alguns futuros usuários do Keberos:
opções nfs.rpcsec.trace em
(Isso ainda não me deu nada, então pode ser apenas específico do NFS).
Editar:
Outra escavação me faz rastreá-lo de volta para autenticação de domínio cruzado. Parece que minha estação de trabalho do Windows 7 (em um domínio) não está recebendo tíquetes Kerberos para o outro domínio, no qual meu arquivador NetApp é associado ao CIFS.
Eu fiz isso separadamente contra um servidor autônomo (Win2003 e Win2008) e não obtive bilhetes Kerberos para aqueles também.
O que significa que acho que o Kerberos pode estar corrompido, mas não tenho ideia de como solucionar problemas.
Editar: Uma atualização adicional: parece que os tíquetes Kerberos não podem ser emitidos em vários domínios. Isso, então, aciona o fallback do NTLM, que é executado nesse problema (desde o Windows 7). O primeiro porto de escala será investigar o lado do Kerberos, mas em nenhum dos casos temos algo apontando para o Filer sendo a causa raiz. Como tal - como o engenheiro de armazenamento - está fora de minhas mãos.
No entanto, se alguém puder me apontar a direção da solução de problemas do Kerberos que abrange dois domínios do Windows AD (Kerberos Realms), isso seria apreciado.
Opções que vamos considerar para a resolução:
- Altere a opção de política em todas as estações de trabalho por meio do GPO (como acima).
- Conversando com o fornecedor de antivírus sobre a varredura de acionamento de renomeação.
- Conversando com o fornecedor de antivírus relacionado à execução do antivírus como conta de serviço.
- investigando a autenticação do Kerberos (por que não está funcionando, se deveria ser).