Active Directory and IsInRole

DougZ posted on Friday, December 15, 2006

This seems like a really easy problem, but for the life of me, I can't find the answer.  I want to use Active Directory to manage users and their role membership.  When authorizing who can do what with my BO's, I have a bunch of CanAddObject(), CanGetObject(), etc. methods.  In these methods, I have code like this:

return Csla.ApplicationContext.User.IsInRole("Administrator");

where "Administrator" could be the name of a security group in AD.  I have this in the app.config file of my test Windows Forms app:

  <appSettings>
    <add key="CslaAuthentication" value="Windows" />
  </appSettings>

I have this code, which runs when the Windows Forms app starts:

  if (Csla.ApplicationContext.AuthenticationType == "Windows")
    AppDomain.CurrentDomain.SetPrincipalPolicy(
      System.Security.Principal.PrincipalPolicy.WindowsPrincipal);

When I run the code, it doesn't recognize "Administrator" as a security group in AD.  I must be missing a step in connecting the name of a security group in AD to a role name that is used in IsInRole.  Any ideas?

Doug Z.

twistedstream replied on Friday, December 15, 2006

Administrator isn't typically a security group in an Active Directory domain, but rather a user.  You might be thinking of Domain Admins.  If you're not on a domain, then Administrators is a valid local security group.

~pete

twistedstream replied on Friday, December 15, 2006

I forgot to mention, but in an AD domain, you also need to include the domain name in the role name like this: "MYDOMAIN\Domain Admins".

~pete

DougZ replied on Friday, December 15, 2006

OK, now this might be it.  Let me try that out.

Thanks,
Doug Z.

DougZ replied on Saturday, December 16, 2006

It's still not recognizing group names.  In the immediate window, I checked

? ApplicationContext.User.Identity.Name

and it returns my domain and user name like this: "MYDOMAIN\\username".  I checked

? ApplicationContext.AuthenticationType

and it returns "Windows".  But when I check

? ApplicationContext.User.IsInRole("MYDOMAIN\\groupname")

it says false.  But I'm listed in that security group in AD.

Does the group scope have anything to do with it?  Group scope is "Universal", and group type is "Security".

Thanks,
DougZ

DougZ replied on Saturday, December 16, 2006

It must have to do with the group scope.  I tried a different group that I am a member of, that has a "Global" scope, and it worked.  So, which types of AD groups does IsInRole work for?

Thanks,
DougZ

RockfordLhotka replied on Saturday, December 16, 2006

You might need to cast the principal object to type WindowsPrincipal. That class has some extra overloads for IsInRole() to deal with the various types of roles available through Windows security.

DougZ replied on Monday, December 18, 2006

Rocky,

I tried your idea of casting the principal object, but I get the same results.  Right now, I'm just planning to make sure that the security groups I use for authorization are of the same type as the one that worked.

Thanks,
Doug

DougZ replied on Thursday, December 21, 2006

Well, I figured out how to get it working, but the reason this works still confuses me.  I don't know all the ins and outs of Active Directory, so bear with my descriptions. 

Some of our groups have two different names.  The first is the one you see in the Active Directory list (in the .mmc snap-in). The second is the one you see listed as "Group name (pre-Windows 2000)" when you look at the properties of an individual group.  When the two names are different, the IsInRole method recognizes the "Group name (pre-Windows 2000)", but not the other name.  That sounds a little backwards to me.  Does anyone have any insight on why this is so?

Thanks,
DougZ

ajj3085 replied on Thursday, December 21, 2006

Hmm, that is odd indeed.  I've always kept both names the same, so never encountered this.

DougZ replied on Thursday, December 21, 2006

Yes, I think it's very strange.  It appears that the pre-Windows 2000 field may have been used here more like a description field since some of the names have spaces, such as "Fire Department All" (even though AD provides a Description field), which hardly seems like a good name.  Still, I don't understand why IsInRole looks at this name.

Thanks,
DougZ

DougZ replied on Friday, December 15, 2006

OK, I just put that in there as a fake name.  The real group is a group called zz_CFD.  I'm using security groups that we have set up.  So, the name isn't the problem.  Any other ideas?