在Active Directory中NativeGuid和GUID的区别 [英] Difference between NativeGuid and Guid in Active Directory
问题描述
我需要更新一些广告查询code和要使用新的.NET 3.5 System.DirectoryServices.AccountManagement对象中，而不是我们目前使用LDAP的方法管理的方式查询AD。
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
preV（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 code，看到我们使用的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，这是相同的GUID我检索使用新的.NET 3.5类。
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?
推荐答案
正如你已经猜到它们都重新完全相同的价值presentations。所不同的是在格式化; DirectoryEntry.NativeGUID 显示在little-endian顺序（不带破折号），这是它是如何存储的本机，在目录服务和 UserPricipal.GUID / DirectoryEntry.GUID 显示在大端顺序（用破折号）。查看字节序维基百科的文章的详细信息。
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 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，因为这是如何objectGUID属性是使用大多数Windows管理工具（如Active Directory用户和计算机和ADSI编辑），以及如何显示它的存储和SQL显示服务器当您使用的唯一标识符的数据类型。也;你需要去的UserPrincipal（ GetUnderlyingObject（））来获得NativeGUID值（或UserPrincipal.GUID财产转换为小端）。
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屋！
