☰

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

tag-icon • tag-icon active-directory ldap python spn
Active Directory 2012 LDAP 集成服务主体名称条目正在消失？

创建 Python 服务以查询 AD 属性

我正在将我们的 AD 与在 Linux 上运行 Python 的 Web 服务集成，使用 SASL（DIGEST-MD5）上的 Python-LDAP 来查询 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() 的 Python-LDAP 服务，仅将 SPN 添加到本地计算机 SPN 列表即可。我还应该注意，如果我使用 simple_bind_s()，则可以跳过 SPN 步骤，但此方法以明文形式发送凭据，这是不可接受的。

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

黑客攻击

现在我有一个计划任务重新运行命令以将记录保留在列表中，以便我的服务能够恰当地命名“SPN 黑客”

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

直到我能找出为什么 SPN 被从列表中删除。

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

我为什么需要黑客攻击？

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

更新

在与系统管理员交谈后，他同意在黑客攻击的基础上构建服务并不是解决方案，因此他允许我启动一个带有端点加密的本地服务，我可以将其用于我的目的，结果是一样的。我会留意是什么导致 SPN 被清除。使用 Python-LDAP 时，本地绑定不是问题，本地服务在大约一小时后就已经启动并运行。不幸的是，我基本上是在包装内置于 LDAP 中的功能，但我们必须做我们必须做的事情。

答案1

这是一个真正有趣（且令人讨厌）的现象，我坚持要找出这里发生了什么。

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

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

找出 SPN 修改发生的位置：

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

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

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

启用 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. 输入“Everyone”作为目标主体
  3. 选择“成功”作为类型
  4. 在属性下向下滚动并选中“写入 servicePrincipalName”
  5. 按OK添加条目并退出ADUC

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

重现错误

从你的问题来看，SPN 似乎每隔一分钟左右就会被删除，所以这可能是最简单的步骤。1分钟音乐课同时。

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

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

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

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

确定造成更改的“主体”并查看其来源。用火烧毁该进程/机器/帐户！

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

相关内容