Geeks With Blogs
Tex-blog Mobile and other stuff

While reading on Users Authentication and Authorization, I wrote a simple test code sample that didn't work at first as I would suppose it should. The code looks as follows:

using System;
using System.Security;
using System.Security.Permissions;
using System.Security.Principal;

// ...

public static void TestPrincipal(string role) {
  System.AppDomain.CurrentDomain.SetPrincipalPolicy(

    PrincipalPolicy.WindowsPrincipal);
 
  try {
    PrincipalPermission sp = new PrincipalPermission(null, role, true);
    sp.Demand();
  }
  catch (SecurityException ex) {
    Console.WriteLine("No permission for role : " + role);
  }
} 

static void Main(string[] args) {
  // 1) Administrator group in my native language, with machine name
  // as prefix, no such role were being found.
  TestPrincipal(System.Environment.MachineName + @"\Administratorzy");  

  // This one works!
  TestPrincipal(@"BUILTIN\Administratorzy");

  // 2) After adding my account to following two groups, this code
  // kept throwing SecurityExceptions until I loged out and back in.

  TestPrincipal(System.Environment.MachineName + @"\VS Developers");
  TestPrincipal(System.Environment.MachineName + @"\Testers");
}

So, at the moment of writing this code, I was logged as Administrator, and was assigned only to groups: "Administratorzy" and "Debugger Users". I wanted to verify this membership, first problem I encountered was that I could not verify that my Administrator account belongs to DOMAIN\Administratorzy (that’s Administrators in my native language) group. After some investigation I found that I should be using BUILTIN\Administratorzy role name. BUILTIN works only for groups created at the moment of system installation, but there might be more groups of different origins that will require other prefixes, those might be the name of your domain controller or name of your machine. Use name of your machine when checking locally created groups. And don’t forget to log out and log in after changing groups memberships, this might save you some time.

Interesting reference is following article: http://www.codeguru.com/Cpp/W-P/system/security/article.php/c5735/.

If you are getting through with checking groups membership of your account, try listing them all and check if your role is one of the listed. Below code ( found here : http://www.grimes.demon.co.uk/workshops/secWSEight.htm ) will list all group memberships for current user:

WindowsIdentity identity = WindowsIdentity.GetCurrent();
Console.WriteLine("{0} is in: ", identity.Name);
foreach (SecurityIdentifier sid in identity.Groups) {
    NTAccount account = (NTAccount)sid.Translate(typeof(NTAccount));
    Console.WriteLine("\t" + account);
}

EDIT: After writing this I learnt that it is always better to use WindowsBuiltInRole enumeration, so insted of writing:

TestPrincipal(@"BUILTIN\Administratorzy");

use:

TestPrincipal(WindowsBuiltInRole.Administrator.ToString());

Posted on Tuesday, September 4, 2007 3:28 AM 70-536 preparation | Back to top


Comments on this post: Troubles with PrincipalPermission

No comments posted yet.
Your comment:
 (will show your gravatar)


Copyright © Martinez | Powered by: GeeksWithBlogs.net