I had an interesting problem crop up trying to run my own application this week. We have a routine that uses an excel spreadsheet to import orders into Dynamics GP that includes some twists that aren't handled well by Integration Manager. Since the application runs from the network (using ClickOnce) and because these orders can be substantial and represent a commitment of corporate resources, we want some control over who can run them. Specifically, we use Active Directory group membership with hard-coded/defined groups.
One of the groups I want to allow is Domain Admins. And yes, this is a kludge. All three members of our small IT shop are Domain Admins—mainly so that we can act as backup when the others are unavailable. It's a handy kludge, though, so lump it. Unfortunately, when running from my machine (running Vista), the user token being used to check Identity.IsInRole() wasn't admitting that I am, in fact, in the Domain Admins domain group
This is, by the way, the first I've run into an inversion of Works on My Machine™.
The Problem
It wasn't terribly difficult to figure out what was wrong. The key to the problem is that Vista UAC (which I actually rather like because I want to know when programs undertake certain activities) creates a “split token” when you login using an account with admin privileges. The user actually runs using the filtered token that removes the dangerous things and only elevates (with user notification and approval) when those privileges are actually needed.
So when I asked WindowsIdentity.IsInRole("COMPANY\Domain Admins") it told me that it's never heard of that role and certainly I'm not a member of it. This was disconcerting.
Now the problem goes away if you start Visual Studio with “Run as Administrator” or start an application with a shortcut with that setting. Which works fine (not great) while developing (if you remember to start VS as administrator) but eventually I got tired of it and sometimes I want to run the deployed app from my box. There's just one small hitch. Remember that I mentioned that we deploy the app to the network using ClickOnce? It turns out that there's no good way to start a ClickOnce app with elevated privileges. Googling around (and even checking Stack Overflow) I found some people who wrote what were essentially batch files or ran services that could then be used to elevate processes either to run ClickOnce apps or to allow ClickOnce apps to do stuff that requires elevation. But really, that's a lot of hassle for something I just knew had to be simpler.
The Solution
After beating my head on the problem for a bit, I eventually took a step back and asked myself that crucial dev question: “What am I actually trying to accomplish here?” I need to remind myself to do that sooner when I find myself “brought to Point Non Plus” (as Georgette Heyer's characters might say). It turns out to be a good question and one that led to the “Duh” moment I share with you now.
Since I'm not actually doing anything that requires admin privileges, going for process elevation is a complete waste of time. All I really want to know is if the current user is part of a specific Active Directory group. Didn't I see something about .Net Framework 3.5 and managed domain objects? Why yes! Yes I did!
The nifty little buggers are in System.DirectoryServices.AccountManagement and if you do anything with Active Directory domains you owe it to yourself to give this namespace a once over. Here's what I ended up with:
bool isAllowed = false;
WindowsIdentity wi = WindowsIdentity.GetCurrent();
using (PrincipalContext pc = new PrincipalContext(ContextType.Domain, "COMPANY"))
{ UserPrincipal up = UserPrincipal.FindByIdentity(pc, wi.Name);
GroupPrincipal gp = GroupPrincipal.FindByIdentity(pc, "Domain Admins");
if (up.IsMemberOf(gp))
isAllowed = true;
}
This worked right out of the chute. Well, getting the right AD group membership didn't want to work when using the Principal.IsMemberOf(PrincipalContext, IdentityType, string) overload, but pulling down the actual GroupPrincipal looks cleaner anyway, I find.