ASP.NET - Get the Principal / Relative Identifier (RID) for a DirectoryEntry / SID

Question

I am using Active Directory in a custom MembershipProvider class to authenticate users in an ASP.NET 2.0 intranet application and associate their sid with a profile for the application.

When the ActiveDirectoryMembershipProvider is used, the ProviderUserKey object for the MembershipUser is as follows

SecurityIdentifier sid = (SecurityIdentifier)Membership.GetUser().ProviderUserKey;
string sidValue = sid.ToString();

/* sidValue = "S-1-5-21-XXXX-XXXX-XXXX-YY"  */

As I understand it, YY is the principal within the namespace (also referred to as a group/domain).

When using the custom MembershipProvider, I can get the sid using the objectSid property of a DirectoryEntry object

DirectoryEntry entry = new DirectoryEntry(path, username, password);
SecurityIdentifier sid = new SecurityIdentifier((byte[])entry.Properties["objectSid"].Value, 0);
string sidValue = sid.ToString();

/* sidValue = "S-1-5-21-XXXX-XXXX-XXXX"  */

The sidValue in this case is identical, except it does not contain the principal YY.

My question is two-fold

1. Is the principal required in order to uniquely identify an individual?
2. Is it possible to obtain the principal from the DirectoryEntry object (or through any other classes available in System.DirectoryServices)?

EDIT:

Having done some further reading ({1} {2}), I now know that the sid can change if the user is moved from one group/domain to another. In light of this, would using the GUID defined in the DirectoryEntry Properties["objectGUID"] be a better choice for uniquely identifying a user?

Answer 1

The objectGUID is the best choice for identifying a user account. I highlight this because the objectGUID is unique and fixed for an instance of an account. If you delete and recreate the account with the same distinguishedName you'll get a different objectGUID. So, objectGUID doesn't identify the user, it identifies the account.

So, if you want to identify the account, use objectGUID.

Sometimes, accounts can be deleted and recreated by admins to solve problems. If you need to identify the user even after this has happened, you need to pick something else on the account object. That will probably have to depend on your account definition policies. Maybe you have sAMAccountNames that are not based on the user's name? Maybe the admins populate employeeid or employeeNumber? Maybe they enforce uniqueness for displayNames?

Here's a link to AD attribute info. Here's a link to DirectoryEntry Properties.