NetApp 错误:STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT

NetApp 错误:STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT

自从将整个站点的桌面系统升级到 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.

这似乎专门触发了,rename所以我们认为正在发生的事情是病毒检查程序正在查看一个“新”文件,并尝试进行访问时扫描。病毒检查程序 - 之前以 LocalSystem 身份运行,因此发送身份验证null请求,现在看起来更像是 DOS 攻击,并导致文件管理器暂时列入黑名单。这 5 秒锁定每个“访问尝试”在大多数情况下都是小麻烦,但对于某些操作来说确实非常重要 - 例如大文件传输,每个文件需要 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 用户:options 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 身份验证(为什么它不起作用,是否应该起作用)。

答案1

我会修改您的防病毒策略,使其不扫描通过网络共享的文件。您可能会有十几个客户端同时尝试通过 AV 扫描网络上的同一文件。

因此在 Windows 2000、2003、Windows XP、Vista 和 2008 中,默认行为如下:

  • 网络安全: 允许本地系统使用计算机身份进行 NTLM
    • 已禁用:以本地系统运行的服务在恢复到 NTLM 身份验证时使用协商将进行匿名身份验证。

但在 Windows 7 和 2008 R2 及更高版本中,默认行为已更改为:

  • 网络安全: 允许本地系统使用计算机身份进行 NTLM
    • 已启用:以本地系统运行并使用协商的服务将使用计算机标识。

来源:http://technet.microsoft.com/en-us/library/jj852275.aspx

您说您想避免更改站点范围的安全选项,但是当您将所有客户端升级到 Windows 7 时您已经进行了更改。

至于为什么您一开始不使用 Kerberos,这是一个完全不同的问题,您没有给我们足够的数据来回答。要使 Kerberos 正常工作,CIFS 服务需要与域和注册的服务主体名称建立信任关系,并且客户端必须使用主机名或 FQDN(而不是 IP 地址)来寻址服务。

您的 Filers 域是否已加入?如果已加入,它们是否具有 CIFS/* SPN?

答案2

我已经完成了这一步,现在知道为什么会发生这种情况。

总之:

  • 自 Windows 7/2008 以来,客户端计算机上“LocalSystem”的默认行为发生了变化。以前,它会使用“空”登录,但现在它使用计算机帐户进行 NTLM。

  • 由于我们在两个 AD 林之间穿行,因此不使用 Kerberos。这是设计使然。http://technet.microsoft.com/en-us/library/cc960648.aspx“Kerberos 身份验证在林中的域之间使用透明传递信任,但它无法在不同林中的域之间进行身份验证”

    • Sophos 正在扫描由重命名触发的“访问时”文件。出于安全策略原因,这包括网络驱动器。

    • 由于 Sophos 以 LocalSystem 身份运行,因此它通过 NTLM 向文件管理器显示计算机帐户。然后该帐户被拒绝,并显示 STATUS_NOLOGON_WORKSTATION_TRUST_ACCOUNT,重试 10 次后文件管理器将触发锁定。

    • 由于此锁定,后续病毒扫描尝试每次尝试都会停滞 5 秒。这就是问题的根源,因为我们的进程复制并重命名了数百个文件,在第 10 个文件之后,每个文件都需要 5 秒。

这给我们留下了以下解决方案:

  • 修改安全策略选项如上所述:网络安全:允许本地系统使用计算机身份进行NTLM:已禁用

    • 在网络驱动器病毒检查器中应用排除

    • 将您的独立域合并到同一个林中,这样 Kerberos 就可以正常工作了。(另一个选项概述如下:http://xitnotes.wordpress.com/2012/03/29/kerberos-in-an-active-directory-forest-trust-vs-external-trust/这涉及升级域之间的关系,以便 Kerberos 再次发挥作用。

    • 使用 vfilers 和 CIF 将其加入到其他域。

    • 文件管理器上还有一个选项可以增加在发生锁定之前的重试次数 - 这是一个隐藏选项,我手边没有精确的语法。

相关内容