![Active Directory 2012 LDAP 集成服务主体名称条目正在消失?](https://linux22.com/image/621189/Active%20Directory%202012%20LDAP%20%E9%9B%86%E6%88%90%E6%9C%8D%E5%8A%A1%E4%B8%BB%E4%BD%93%E5%90%8D%E7%A7%B0%E6%9D%A1%E7%9B%AE%E6%AD%A3%E5%9C%A8%E6%B6%88%E5%A4%B1%EF%BC%9F.png)
创建 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做到了这一点。为此,我们需要:
- 找出 SPN 修改发生的位置
- 启用 AD DS 对象更改审核
- 在对象上设置审核 ACE
- 重现错误
- 检查有问题的 DC 上的安全日志
找出 SPN 修改发生的位置:
在域控制器上打开提升的命令提示符并发出以下命令:
repadmin /showobjmeta . "CN=computerAccount,DC=domain,DC=local"|findstr servicePricipalName
输出将包含最初编写当前版本的 servicePrincipalName 属性值的域控制器的名称:
启用 AD DS 对象更改审核:
如果尚未定义全局审计策略,您可以对上一步中确定的域控制器上的本地安全策略进行此更改
打开组策略管理控制台(gpmc.msc
)并找到Default Domain Controllers Policy
并编辑它。
- 去
Computer Configuration -> Windows Settings -> Security Settings
- 选择并扩展
Local Policies -> Security Options
- 确保审计:强制审计策略子类别设置...被设定为已启用
- 选择并扩展
Advanced Audit Policy -> Audit Policies -> DS Access
- 确保审计目录服务变更设置为至少成功
在对象上设置审计 ACE:
打开 Active Directory 用户和计算机 ( dsa.msc
) 并检查“查看”菜单中的“高级功能”设置。
导航到计算机帐户对象,右键单击它并选择属性。选择安全选项卡,然后点击“高级”按钮。
在提示中,选择审计选项卡并确保“写入所有属性”正在接受审核每个人。如果没有,或者您有疑问,请添加新条目:
- 按添加。
- 输入“Everyone”作为目标主体
- 选择“成功”作为类型
- 在属性下向下滚动并选中“写入 servicePrincipalName”
- 按OK添加条目并退出ADUC
(如果你懒的话,可以选择“写入所有属性”)
重现错误
从你的问题来看,SPN 似乎每隔一分钟左右就会被删除,所以这可能是最简单的步骤。1分钟音乐课同时。
检查有问题的 DC 上的安全日志
现在一分钟已经过去了,让我们检查一下在步骤 1 中标识为发起者的域控制器上的安全日志。这在大型域中可能会很麻烦,但过滤可以帮助解决这个问题:
- 打开事件查看器并导航至
Windows Logs -> Security
- 在右侧窗格中,选择过滤当前日志
<All Event IDs>
在标有“ ”的输入框中输入5136(这是目录对象修改的事件 ID)
现在您应该能够找到servicePrincipalName
计算机帐户属性的每个更改的事件条目。
确定造成更改的“主体”并查看其来源。用火烧毁该进程/机器/帐户!
如果主题被标识为SYSTEM
或ANONYMOUS LOGON
类似的通用描述,则我们正在处理域控制器本身的内部处理,并且我们需要打开一些 NTDS 诊断日志来找出发生了什么。如果是这种情况,请更新问题