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

创建Python服务以查询AD属性

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

错误：digest-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的主要管理员，管理员能否运行正在运行的服务，该服务会将SPN与AD上的其他服务同步，并且不知道它？我的名字叫Web Developer，不是作为借口，而是为了解释我对Active Directory的无知。有人告诉我要使AD成为主用户数据库，我已经读了很多东西，但是我找不到任何地方出现人们对SPN定期“覆盖”或“清除”的问题，而且都没有管理员对SQLServer条目之外的SPN非常熟悉。

为什么需要骇客？

到目前为止，我的骇客似乎并未对任何用户或服务造成任何问题，也未产生任何错误，因此管理员表示他将让其运行，我将继续寻找。但是后来我发现自己处于编写服务的不稳定状态，该服务的实现建立在该服务之上，本质上是cron hack / shiver ...因此，我们将不胜感激。

更新资料

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

这是一个非常有趣（而且很烦人）的现象，我坚持认为我们要了解发生了什么。

幸运的是，在Windows Server具有一定的细粒度审计的政策自2008年以来，我们可以使用审核来追查谁这样做。为此，我们需要：

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. 确保审核目录服务更改设置为至少成功

在对象上设置审核ACE：

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

在提示中，选择“ 审核”选项卡，并确保正在为“ 所有人 ”审核“写所有属性” 。如果不是，或者有疑问，请添加一个新条目：

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

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

重现错误

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

检查有问题的DC上的安全日志

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

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

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

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

如果受试者被鉴定为SYSTEM，ANONYMOUS LOGON或类似一般的描述，我们正在处理的域控制器本身内部处理，而我们需要打破一些NTDS诊断日志记录，以找出发生了什么事情。如果是这种情况，请更新问题