Support for programming with SIDs is new in version 2.0 of the .NET Framework. There are two new classes that represent a user or group account. The first, SecurityIdentifier, represents a machine-readable SID like I described in WhatIsASID. The second, NTAccount, represents a human-readable user or group account name. The base class for both of these is IdentityReference, and you can easily translate back and forth between SID and name. Under the covers, the Translate method calls a low level function in the local security authority (LSA), which translates names to SIDs or vice versa. If a domain controller needs to be contacted, this low-level function can batch up requests and translate many names in one round trip. It's great to see this support being built into the framework.

 using System;
 using System.Security.Principal;


 class NamesAndSIDs {
   const string userAccount = @"acme\bob";
   static void Main(string[] args) {
     NTAccount name = new NTAccount(userAccount);
     Console.WriteLine(name);
     SecurityIdentifier sid = (SecurityIdentifier)
       name.Translate(typeof(SecurityIdentifier));
     Console.WriteLine(sid);
     name = (NTAccount)sid.Translate(typeof(NTAccount));
     Console.WriteLine(name);
   }
 }

When run, this program displays the following output:

  v-xp-vs2005\NormalUser
  S-1-5-21-1409082233-1060284298-1343024091-1006
  V-XP-VS2005\NormalUser

When you use some of the new security classes, you'll find that many of them give you the choice of whether you want human-readable names for accounts or SIDs. For example, if you wanted to enumerate a DACL (WhatIsAnAccessControlList) and print out which users and groups were granted permissions, you might write code that looks like this:

 using System;
 using System.IO;
 using System.Security.Principal;
 using System.Security.AccessControl;


 class EnumerateDACL {
   const string path = @"c:\work\test.txt";
   static void Main(string[] args) {
     FileSecurity sd = File.GetAccessControl(path);
     foreach (FileSystemAccessRule ace in
       sd.GetAccessRules(true, true, typeof(NTAccount))) {


       // since we asked for a type of NTAccount,
       // all identity references will be of that type
       // so this cast should always succeed here
       NTAccount name = (NTAccount)ace.IdentityReference;
       Console.WriteLine(name);
     }
   }

You'll see more code like this when I show how to program ACLs in HowToProgramACLs, but for now, note the call to GetAccessRules. Because this is going to return a list that will contain IdentityReferences, you get to choose what form those references will take: SID or human-readable name. If you ask for names, realize that this might incur round-trips to domain controllers, but at least the requests are batched as I mentioned earlier, which will help reduce the overhead.

Another thing I really like about these new classes is the ease of representing well-known user accounts and groups. The WellKnownSidType enumeration is very complete and makes it trivial to compute well-known SIDs without having to rely on human-readable names, which change depending on the regional settings of the computer on which your program is running.

 using System;
 using System.Security.Principal;


 class WellKnownSids {
   static void Main() {
     SecurityIdentifier sid =
       new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null);
     Console.WriteLine(sid.Translate(typeof(NTAccount)));
   }
 }

The output from this program looks like this on my US English installation of Windows XP:

 BUILTIN\Administrators

Having a managed representation of a SID will make it much easier to wrap more and more of the security functionality on the Windows platform, and I'm really looking forward to that. Being able to write security tools in C# is so much more palatable than having to drop down into C or C++. The day I write my last line of C code will be a very happy day for me!

PortedBy TommyWilliams