☰

使用 userProxyFull 时正确将 sAMAccountName 添加到 AD LDS 架构

tag-icon • tag-icon ad-lds
使用 userProxyFull 时正确将 sAMAccountName 添加到 AD LDS 架构

应用程序要工作需要sAMAccountName填充属性。但我还希望将此 LDS 实例作为 AD DS 目录的同步子集。除非我也尝试同步此属性，否则同步将有效。我已经弄清楚userProxyFull缺少此属性user（当然还有其他属性）。

我已使用架构编辑器手动修改了架构userProxyFull，并将此属性添加为可选属性。我还重新启动了 LDS 实例。同步完成，日志中没有错误，并且我有这样的条目，这应该意味着该属性已同步：

处理条目：第 1 页，第 1 帧，第 69 条目，计数 1，USN 0 处理源条目 <guid=a6c70d306402384fb002bdb96b227fff> 处理范围内的条目 a6c70d306402384fb002bdb96b227fff。（sourceobjectguid=\a6\c7\0d\30\64\02\38\4f\b0\02\bd\b9\6b\22\7f\ff）存在​​于目标中。将对象创建转换为对象修改。将目标对象 CN=Operator 1,OU=SCADA,DC=zenon,DC=local 重命名为 CN=Operator 1,<GUID=6ac9bd3146955e43bade7381afa2c37a>。修改属性：displayName，账户名称，userPrincipalName，lastagedchange，上一个条目耗时 0 秒（0，0）进行处理

sAMAccountName但是，我在目标用户对象中找不到具有 ADSI 的属性，只能在组对象中找到。我做错了什么？

[更新]

这似乎是一个工具问题，因为 Sysinternal 的 ADExplorer 列出了该属性。

新的问题是：sAMAccountName有没有比我所做的更“规范”的方式来转移属性？

答案1

向 AD LDS 实例添加自定义属性是一种受支持的方法，并且您已经通过使用架构编辑器将 sAMAccountName 属性作为可选属性添加到 userProxyFull 对象类，采取了正确的步骤。

同步完成且没有错误，并且您可以在 ADExplorer 中看到 sAMAccountName 属性，这表明该属性正在正确同步。由于缓存或其他因素，使用 ADSI 时该属性可能不可见。

如果要以更“规范”的方式将 sAMAccountName 属性传输到 AD LDS 实例，可以尝试使用其他工具或方法执行同步。例如，可以使用 Microsoft 的身份集成功能包 (IIFP) 在 AD DS 和 AD LDS 之间同步数据，也可以使用 Microsoft Identity Manager (MIM) 或 Azure Active Directory (Azure AD) Connect 工具。

相关内容