我需要更新一些AD查询代码，并希望使用新的.NET 3.5 System.DirectoryServices.AccountManagement对象以托管方式查询AD，而不是使用当前使用LDAP的方法。
我在阅读UserPrincipal.Guid值时遇到了一个奇怪的问题。事实证明它与我们通过LDAP使用的Guids相似但不同。
起初他们看起来完全不同，但是在第二次拍摄时，我看到后半部分是相同的，前半部分只是换位，即：
新（.NET 3.5）方法GUID： 01234567-89ab-CDEF-0123-456789abcdef
上一个（LDAP）方法GUID： 67452301-ab89-EFCD-0123-456789abcdef
我检查了LDAP代码，看到我们使用了SearchResult.GetDirectoryEntry（）。NativeGuid字段来获取Old Guid。
它有一个名为SearchResult.GetDirectoryEntry（）的不同属性.Guid与我使用新的.Net 3.5类检索的GUID相同。
我的问题是，为什么它们（有点）不同，我应该使用哪种？
答案 0 :(得分：22)
正如您所猜测的那样，它们都是完全相同值的表示。区别在于格式; DirectoryEntry.NativeGUID以小端顺序显示（没有短划线），这是它在目录服务中“本地”存储的方式，UserPricipal.GUID/DirectoryEntry.GUID以big-endian顺序显示（带有破折号）。有关详细信息，请参阅Endianess上的维基百科文章。
因此，当您打印出NativeGUID（字符串）的值时，除非您使用字符串作为输入（Guid ng = new Guid(de.NativeGuid);）创建新的GUID，否则它不应显示任何破折号（如您的示例所示）。这会造成一些混乱......
重要的是，在将GUID存储在外部数据源中或将NativeGUID存储为big-endian GUID时，不要将两者混合使用。
所以我会选择UserPricipal.GUID / DirectoryEntry.GUID，因为这是使用大多数Windows管理工具（例如Active Directory用户和计算机和ADSI Edit）显示objectGUID属性的方式，以及它在SQL中的存储和显示方式使用uniqueidentifier数据类型时的服务器。也;你需要在“UserPrincipal（GetUnderlyingObject()）下面”获取NativeGUID值（或将UserPrincipal.GUID属性转换为little-endian）。
所以我猜你必须决定是将现有的“外部”数据迁移到GUID格式还是继续使用NativeGUID格式。现在我猜你介于两者之间。