Active Directory 中 NativeGuid 和 Guid 的区别 [英] Difference between NativeGuid and Guid in Active Directory

问题描述

我需要更新一些 AD 查询代码，并希望使用新的 .NET 3.5 System.DirectoryServices.AccountManagement 对象以托管方式查询 AD，而不是我们当前使用 LDAP 的方法.

I need to update some AD querying code and want to use the new .NET 3.5 System.DirectoryServices.AccountManagement objects to query AD in a managed way as opposed to our current method of using LDAP.

我在读取 UserPrincipal.Guid 值时遇到了一个奇怪的问题.事实证明，它与我们一直通过 LDAP 使用的 Guid 相似但又不同.

I encountered an odd problem when reading the UserPrincipal.Guid value. It turns out that it is similar to but different from the Guids we have been using via LDAP.

一开始它们看起来完全不同，但在第二次拍摄时，我看到后半部分是相同的，而前半部分只是简单地换位了，即:

At first they looked completely different, but on a second take, I saw that the last half are identical and the first half are simply transposed ie:

新 (.NET 3.5) 方法 GUID:01234567-89ab-cdef-0123-456789abcdef
上一个 (LDAP) 方法 GUID:67452301-ab89-efcd-0123-456789abcdef

New (.NET 3.5) Method GUID: 01234567-89ab-cdef-0123-456789abcdef
Prev (LDAP) Method GUID: 67452301-ab89-efcd-0123-456789abcdef

我检查了 LDAP 代码，发现我们正在使用 SearchResult.GetDirectoryEntry().NativeGuid 字段来获取旧 Guid.

I checked the LDAP code and saw that we were using the SearchResult.GetDirectoryEntry().NativeGuid field to get the Old Guid.

它有一个名为 SearchResult.GetDirectoryEntry().Guid 的不同属性，它与我使用新的 .Net 3.5 类检索的 GUID 相同.

It has a different property called SearchResult.GetDirectoryEntry().Guid which is identical to the GUID I retrieve using the new .Net 3.5 classes.

我的问题是，为什么它们(有点)不同，我应该使用哪个?

My question is, why are they (sort of) different and which should I use?

推荐答案

正如您已经猜到的，它们都是完全相同的值的表示.不同之处在于格式；DirectoryEntry.NativeGUID 以 little-endian 顺序(无破折号)显示，这是它在目录服务中本地"存储的方式，并且显示 UserPricipal.GUID/DirectoryEntry.GUID按大端顺序(带破折号).有关详细信息，请参阅关于 Endianess 的维基百科文章.

As you've guessed they are both representations of the exact same value. The difference is in the formatting; DirectoryEntry.NativeGUID is displayed in little-endian order (without dashes) which is how it's stored "natively" in the directory service and UserPricipal.GUID/DirectoryEntry.GUID is displayed in big-endian order (with dashes). See the Wikipedia article on Endianess for details.

因此，当您打印出 NativeGUID(一个字符串)的值时，它不应该显示任何破折号(就像您的示例那样)，除非您使用该字符串作为输入创建一个新的 GUID(Guid ng = new Guid(de.NativeGuid);).这会造成一些混乱...

So when you print out the value for NativeGUID (a string) it should not show any dashes (like your example does) unless you create a new GUID using the string as input (Guid ng = new Guid(de.NativeGuid);). That will create some confusion...

在将 GUID 存储在外部数据源中或将 NativeGUID 存储为大端 GUID 时，重要的是不要将两者混合.

The important thing is not to mix the two when storing the GUIDs in an external data source or storing a NativeGUID as a big-endian GUID.

所以我会选择 UserPricipal.GUID/DirectoryEntry.GUID，因为这是使用大多数 Windows 管理工具(例如 Active Directory 用户和计算机以及 ADSI 编辑)显示 objectGUID 属性的方式以及它在 SQL 中的存储和显示方式当您使用 uniqueidentifier 数据类型时的服务器.还;您需要低于"UserPrincipal (GetUnderlyingObject()) 以获取 NativeGUID 值(或将 UserPrincipal.GUID 属性转换为 little-endian).

So I'd go for the UserPricipal.GUID/DirectoryEntry.GUID because that's how the objectGUID attribute is displayed using most Windows management tools (such as Active Directory Users and Computers and ADSI Edit) and how it's stored and displayed in SQL Server when you use the uniqueidentifier data type. Also; you'll need to go "below" UserPrincipal (GetUnderlyingObject()) to get the NativeGUID-value (or convert the UserPrincipal.GUID property to little-endian).

所以我猜您必须决定是将现有的外部"数据迁移到 GUID 格式还是继续使用 NativeGUID 格式.现在我猜你介于两者之间.

So I guess you'll have to decide whether to migrate your existing "external" data to the GUID-format or to continue using the NativeGUID-format. Right now I'm guessing you're somewhere in between.

这篇关于Active Directory 中 NativeGuid 和 Guid 的区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！