Windows – NetApp错误：STATUS_NOLOGON_WORKSTATION_TRUST_ACCO

自从在桌面上全站升级到 Windows 7后,我开始遇到病毒检查问题.
特别是 – 在(文件管理器托管的)CIFS共享上执行重命名操作时.病毒检查程序似乎在文件管理器上触发了一组消息：

[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.

这似乎特意触发重命名,因此我们认为正在进行的是病毒检查程序正在查看“新”文件,并尝试进行按访问扫描.病毒检查程序 – 以前作为LocalSystem运行并因此发送null作为其身份验证请求现在看起来更像是DOS攻击,并导致文件管理器暂时黑名单.
这种5s锁定每次“访问尝试”在大多数情况下都是轻微的麻烦,对于某些操作来说确实非常重要 – 例如大文件传输,每个文件需要5秒

做了一些挖掘,这似乎与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.

所以我们现在有一些不太特别好的解决方法 – 一个是改变这个安全选项.
一种是禁用病毒检查,或以其他方式豁免部分基础设施.

这就是我从ServerFault请求帮助的地方 – 最好的前进方式是什么？我缺乏Windows经验,以确保我所看到的.

我不完全确定为什么NTLM首先是这张图片的一部分 – 我以为我们正在使用Kerberos身份验证.我不确定如何开始诊断或排除故障. (我们将跨域 – 工作站计算机帐户位于我的文件管理器的单独AD和DNS域中.但普通用户身份验证工作正常.)

如果不这样做,有人可以建议其他调查线吗？我想避免网站范围的安全选项更改,或者如果我这样做,我需要能够提供详细的推理.同样地 – 禁用病毒检查可以作为短期解决方法,并且应用排除可能有所帮助……但我不愿意,并且不认为这解决了潜在的问题.

编辑：
AD ldap中的文件管理器具有以下SPN：

nfs/host.fully.qualified.domain
nfs/host
HOST/host.fully.qualified.domain
HOST/host

(对不起,必须混淆那些).

可能是没有’cifs / host.fully.qualified.domain’它不会起作用吗？ (或其他一些SPN？)

编辑：作为搜索的一部分,我一直在做我发现：
http://itwanderer.wordpress.com/2011/04/14/tread-lightly-kerberos-encryption-types/

这表明在Win7 / 2008R2中默认禁用了几种加密类型.这可能是相关的,因为我们肯定与Keberized NFSv4有类似的问题.
有一个隐藏的选项可能会帮助一些未来的Keberos用户：
选项nfs.rpcsec.trace on
(虽然这还没有给我任何东西,所以可能只是NFS特定的).

编辑：
进一步挖掘让我追溯到跨域身份验证.看起来我的Windows 7工作站(在一个域中)没有获得其他域的Kerberos票证,其中我的NetApp文件管理器是CIFS加入的.
我已经针对独立服务器(Win2003和Win2008)单独完成了此操作,并且没有获得这些服务器的Kerberos票证.

这意味着我认为Kerberos可能会被破坏,但我不知道如何进一步排除故障.

编辑：进一步更新：看起来这可能是关闭Kerberos门票没有跨域发布.然后,这会触发NTLM回退,然后会遇到此问题(从Windows 7开始).第一个调用端口是调查Kerberos方面的事情,但在这两种情况下,我们都没有任何指向Filer的根本原因.因此 – 作为存储工程师 – 它不在我的手中.

但是,如果任何人都可以指向我的方法来解决跨越两个Windows AD域(Kerberos领域)的Kerberos,那么将不胜感激.

我们将考虑解决的选项：

>通过GPO修改所有工作站的政策选项(如上所述).
>与AV供应商讨论重命名触发扫描.
>与AV供应商讨论将AV作为服务帐户运行的问题.
>调查Kerberos身份验证(为什么它不起作用,是否应该).