Active Directory 2012 LDAP 集成服务主体名称条目正在消失？

Question

创建 Python 服务来查询 AD 属性

我正在使用 Python-LDAP over SASL(DIGEST-MD5) 将我们的 AD 与在 Linux 上运行 Python 的 Web 服务集成，以查询 AD 2012 用户属性（部门、部门、电话分机、电子邮件等）。在针对 AD 2003 解决特定于我的服务的问题后，我开始遇到针对我们的新 AD 2012 的 SPN 错误，即摘要 uri 与服务器上的任何 SPN 都不匹配。我已经交叉引用了两台服务器的 SPN 列表，它们包含彼此相同的类似物。

错误：摘要 uri 与为此服务器注册的任何 LDAP SPN 都不匹配

修复？

这是通过运行修复的：

setspn -A ldap/<Domain_Name> <Computer_Name>

请注意，即使运行以下命令，创建服务帐户也无法修复我的 SPN 错误：

setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>

simple_bind_s() 不需要 SPN，sasl_interactive_bind_s() 需要 SPN

仅使用 sasl_interactive_bind_s() 将 SPN 添加到本地机器 SPN 列表才适用于我的 Python-LDAP 服务。我还应该注意，如果我使用 simple_bind_s() 可以跳过 SPN 步骤，但此方法以明文形式发送凭据，这是不可接受的。

但是我注意到该记录只在 SPN 列表上停留了大约一分钟然后消失了？运行 setspn 命令时没有错误，事件日志完全为空，任何地方都没有重复项，在基本 dn 上使用 -F 森林范围搜索进行检查，什么也没有。我已经添加并尝试重新添加和删除并将 SPN 从一个对象移到另一个对象以验证它没有隐藏在任何地方，但是第二次我将对象添加到任何地方然后尝试重新添加它会通知我重复。所以我非常有信心没有隐藏在某处的重复项。

黑客

现在我有一个计划任务重新运行命令以将记录保留在列表中，因此我的服务将恰当地命名为“SPN Hack”

cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"

直到我能找出 SPN 被从列表中清除的原因。

我不是这个特定 AD 的主要管理员，管理员是否可以运行一个服务来同步来自 AD 上的另一个服务的 SPN 而没有意识到这一点？我的头衔是 Web 开发人员，这不是一个借口，而是为了解释我对 Active Directory 问题的无知。我被告知要将 AD 设为主用户数据库，并且我已经阅读了很多内容，但是我找不到任何地方人们遇到 SPN 被定期“覆盖”或“清理”的问题并且没有任何问题管理员非常熟悉 SQLServer 条目之外的 SPN。

为什么我需要黑客？

到目前为止，我的 hack 似乎没有给任何用户或服务造成任何问题，也没有产生任何错误，所以管理员说他会让它运行，我会继续寻找。但是后来我发现自己处于编写一个服务的危险境地，该服务的实现是建立在本质上是一个 cron hack / shiver ......所以，任何帮助将不胜感激。

---

更新

在与系统管理员交谈后，他同意在 hack 之上构建服务不是解决方案，因此他允许我使用端点加密启动本地服务，我可以将其用于我的目的，结果是一样的. 我会密切关注导致 SPN 清除的原因。使用 Python-LDAP 本地绑定不是问题，并且本地服务仅在一个小时左右后就已启动并运行。不幸的是，我本质上是在包装 LDAP 中内置的功能，但我们做我们必须做的事情。

Answer 1

这是一个真正有趣（且烦人）的现象，我坚持让我们找出这里发生的事情。

幸运的是，自 2008 年以来，Windows Server 有一些细粒度的审计策略，我们可以使用审计来追踪是谁做的。为此，我们需要：

1. 找出 SPN 修改发生的位置
2. 启用 AD DS 对象更改审核
3. 在对象上设置审计 ACE
4. 重现错误
5. 检查违规 DC 上的安全日志

找出发生 SPN 修改的位置：

在域控制器上打开提升的命令提示符并发出以下命令：

repadmin /showobjmeta . "CN=computerAccount,DC=domain,DC=local"|findstr servicePricipalName

输出将包含最初编写 servicePrincipalName 属性值的当前版本的域控制器的名称：

启用 AD DS 对象更改审核：

如果尚未定义全局审核策略，则可以对上一步中标识的域控制器上的本地安全策略进行此更改

打开组策略管理控制台 ( gpmc.msc) 并找到Default Domain Controllers Policy并编辑它。

1. 去 Computer Configuration -> Windows Settings -> Security Settings
2. 选择并展开 Local Policies -> Security Options
3. 确保审核：强制审核策略子类别设置...设置为已启用
4. 选择并展开 Advanced Audit Policy -> Audit Policies -> DS Access
5. 确保Audit Directory Service Changes至少设置为Success

在对象上设置审计 ACE：

打开 Active Directory 用户和计算机 ( dsa.msc) 并检查“查看”菜单中的“高级功能”设置。
导航到计算机帐户对象，右键单击它并选择属性。选择“安全”选项卡，然后点击“高级”按钮。

在提示中，选择Auditing选项卡并确保正在为Everyone审核“Write all properties” 。如果没有，或者您有疑问，请添加一个新条目：

1. 按添加。
2. 输入“Everyone”作为目标主体
3. 选择“成功”作为类型
4. 在属性下向下滚动并选中“Write servicePrincipalName”
5. 按确定添加条目并退出 ADUC

（如果你很懒，你可以选择“写入所有属性”）

重现错误

从您的问题来看，似乎每分钟左右都会删除 SPN，因此这可能是最简单的步骤。同时参加1 分钟的音乐课。

检查违规 DC 上的安全日志

现在一分钟过去了，让我们检查在步骤 1 中标识为发起者的域控制器上的安全日志。 这在大型域中可能会很痛苦，但过滤可以帮助解决这个问题：

1. 打开事件查看器并导航到 Windows Logs -> Security
2. 在右侧窗格中，选择过滤当前日志
3. 在输入栏输入“ <All Event IDs>”，输入5136（这是目录对象修改的事件id）

您现在应该能够为servicePrincipalName计算机帐户上的每个属性更改找到一个事件条目。

确定负责更改的“主题”并查看更改的来源。用火杀死那个进程/机器/帐户！

如果主题被标识为SYSTEM，ANONYMOUS LOGON或类似的通用描述，我们正在处理域控制器本身的内部处理，我们需要打破一些 NTDS 诊断日志以找出发生了什么。如果是这种情况，请更新问题