因此,我有一台服务器,每次用户或服务帐户登录到该机器时,系统日志中都会生成一个错误事件:
A Kerberos Error Message was received:
on logon session DOMAIN\serviceaccount
Client Time:
Server Time: 12:44:21.0000 10/9/2012 Z
Error Code: 0x19 KDC_ERR_PREAUTH_REQUIRED
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN
Server Name: krbtgt/DOMAIN
Target Name: krbtgt/DOMAIN@DOMAIN
Error Text:
File: e
Line: 9fe
Error Data is in record data.
因此我当然会在 Google 上搜索这个问题,而我得到的唯一信息是“这并不一定表示存在问题,通常可以忽略它”。
嗯,太棒了,但是这些错误每分钟都会在我的系统日志中出现一次,我真的很想让它们停止。有什么想法吗?
来自 Microsoft AskDS 博客:
KDC_ERR_PREAUTH_REQUIRED
如果您在跟踪中看到此错误,这并不表示存在任何问题。客户端请求了票证,但未包含预身份验证数据。您通常会看到再次发送相同的请求,其中包含数据和发出票证的域控制器。Windows 使用此技术来确定支持的加密类型。
答案1
我无法帮你阻止它们;恐怕我是 Linux 用户。我至少可以解释它们。理解此消息需要稍微了解一下 Kerberos 身份验证的工作原理。
Kerberos 的基本身份验证过程是客户端从 KDC 请求加密的 TGT,然后使用其本地密钥解密。然而,如果实施得当,攻击者可以下载您所在域中每个用户的 TGT,然后在攻击者空闲时尝试通过暴力攻击解密它们。因此,Kerberos 添加了一种称为预身份验证的机制。
预认证的工作方式是,当 KDC 收到 TGT 请求时,它会发回预认证质询,而不仅仅是发回 TGT。预认证质询可以采用多种形式,但最常见的形式是要求客户端发送在客户端密钥中加密的当前时间。然后,KDC 在发送 TGT 之前确认客户端可以这样做(这表明客户端密钥有一定的知识)。
但是,部分原因是添加了预身份验证,部分原因是客户端不知道将发送什么预身份验证质询,因此客户端始终发送基本 TGT 请求,然后 KDC 始终使用预身份验证质询拒绝该请求。这些日志消息是 Active Directory 记录的事实,即它收到了未进行预身份验证的 TGT 请求并发回了质询。
关于为什么要记录这一点,您的猜测与我的一样好,因为这是协议的正常部分,而且并不十分有趣,但所有基于 Linux 的 KDC 都做同样的事情。
答案2
我的服务器上也遇到了同样的问题,导致服务器中充斥着错误。我HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
在 Microsoft 支持知识库 (https://support.microsoft.com/en-us/kb/262177) 并将其删除,现在它似乎运行良好。
答案3
初始 Kerberos AS 请求返回 KDC_ERR_PREAUTH_REQUIRED。默认情况下,Windows Kerberos 客户端不会在第一个请求中包含预身份验证信息。响应包含有关 KDC 上支持的加密类型的信息,如果是 AES,则包含用于加密密码哈希的盐。
建议:始终忽略此错误代码。
https://support.microsoft.com/en-us/help/262177/how-to-enable-kerberos-event-logging
答案4
虽然用户@Tony 已经回答了这个问题,但是实际原因还不够清楚:
有一天,有人在服务器上启用了 Kerberos 事件的详细日志记录。要禁用它,您应该删除以下内容注册表值:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Registry Value: LogLevel
Value Type: REG_DWORD
事实上,完全删除指定的注册表项也可以,但这不是最好的主意。
首先,它可能包含在某些情况下可能至关重要的任何其他重要设置(例如,MaxTokenSize,当用户帐户属于大量域组时,它可以解决身份验证问题)。
但主要原因是这个注册表项存在于干净的 Windows 安装中,尽管它不包含任何值。因此,最好将其保留为原始状态(空),而不是删除它。空和不存在绝对不是一回事。
我 99% 确信删除这个特定的密钥不会在将来造成任何麻烦,但是您甚至开发人员自己都不知道在您执行一些意外的事情后事情会发生什么变化 :)