Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Originally-posted on StackOverflow, cross-posted here as suggested in SO comments.


I need to password protect some actions in my application, such as loading/saving files, clicking check-boxes, etc. This is a standard C# .Net 4.0, WinForms application which will run on Windows 7 in a corporate network.

I was about to roll my own very basic system (read obfuscation with wide open backdoors) with a text file of users/passwords/permissions (hashed and salted) until after some searching I found what looks like a tantalizingly simple approach , but I'm having trouble finding a good tutorial on Roles that isn't about ASP.NET.


So does anyone know of one or more tutorials that show me how to:

  1. Create a Windows User/Group and give that User/Group a Role or Permission.
    • Note that I'm testing this from my company's networked laptop, but will deploy it on the customer's corporate network (Not sure if this is an issue, or how tricky this will get).
  2. Create winforms/console app sample with even just a single method that prints "Hello World" if I'm authenticated or throws an exception if I'm not?
  3. I've never done Network Admin or anything related and I keep reading about Active Directory and Local Users Vs Networked Users... I was hoping for an approach where I could build to an Interface and just ask Windows if the current user has permission ABC and not care too much about how Windows figured that out. Then I can make a concrete implementation for each Local/Network/ActiveDirectory/etc. use case as required (or if required... as I don't even know that right now).


- read if interested, but not required to answer question

Just to make sure I'm going in the right direction here, basically I need/want to test this on my development PC to make sure it's going to have a good end-user experience for my customer. The problem is that currently they run an Auto-login script for each computer that runs my application and there are several different operators that use my application throughout the day. The customer wants password protection on certain features of my app and only provide that to certain operators. I have no problem fitting this in, as I've expected the request for a while, I just haven't ever programmed authentication before.

I think it's worthwhile to convince my customer to give each operator their own network account and assign whatever permissions they want to that operator or group, in case they need to fire somebody, change permissions, etc. It also means I just open several options for them and they can group those permissions however they see fit based on internal corporate policies, which I really shouldn't have to be worried about (but will be if I have to roll my own, as they're IT department knows almost nothing of my application).

From what I can tell it also makes my life a lot easier by not having to deal with hashing passwords and encryption, etc. and just handle which Role is required to click this or that button.

share|improve this question
I wish more developers would care about authorization in their applications. I run into a ton of applications that authenticate against Active Directory but do their authorization in some hare-brained method instead of just relying on Active Directory group membership. It's refreshing to hear a developer actually caring about how authorization will be handled by the sysadmins who will be managing the product after deployment. Thanks for caring about this. – Evan Anderson Apr 4 '14 at 23:56
up vote 1 down vote accepted

I don't know what the current "best practice" method of doing authorization in a .NET-based application is. Here's something I did many years ago in a web-based application I wrote to offload all of the authorization functionality to the operating system itself. (This will probably come off as a dodgy hack written by someone who is a sysadmin first and a developer second.)

  • I enumerated all the permissions in the application and created files in a directory hierarchy to be made selectively available to users assigned to the appropriate role(s). (The files didn't contain anything-- as you'll see below, I just checked to see that the user could read the file.)

  • Created Active Directory groups that identified application user roles.

  • Assigned permission to read the files I created in the earlier step to the Active Directory groups.

When the user authenticated to the application (web-based) an attempt was made to access each of the "permission" files. Based on which succeeded/failed the application could ascertain the user's assigned "role".

For the Customer's IT department altering permission to the application was a matter of changing the ACLs on the "permission" files (if they needed to make radical changes), or more often, just changing user group memberships.

I liked this method because it handles all the "edge-cases" very well-- nested group memberships, security principals from foreign forests, etc. It's also nice because, if those permission files were relocated to a Windows Server 2012 machine, my application suddenly gains the new Dynamic Access Control functionality "for free".

share|improve this answer
I've been pondering your approach for a day, because... yes, it does sound a bit hacky... but at the same time it really does cleanly decouple the application from the implementation details of the security policy where it is installed and covers all the edge cases. I managed to write a demo app already that could can check if a user is in a group, but I see it getting very ugly very quickly. So until I need to make an app with permissions in a highly regulated industry (ie. medical) I'll use your suggested approach. – HodlDwon Apr 6 '14 at 20:20
Why would you not just create a permissions database? Opening and closing file handles all the time sounds like a recipe for disaster; databases were designed to be hit hard and hit often. This doesn't sound scalable to me. – Dan Apr 12 at 13:32
@Dan - The application I was writing about didn't use a database, so using the filesystem was a logical choice. I'm also talking about an application that had under 100 active users-- scalability wasn't an issue. Having said that, though, Windows Server does a pretty good job w/ large amounts of file traffic in my experience. I have file servers at Customer sites that regularly have 500+ active users and 10K+ files being interacted-with at any given time and performance is fine. – Evan Anderson Apr 13 at 3:11
@EvanAnderson While it may work with 100 users, in practice there are some potential problems. With any sort of concurrent design (as would be necessary in most client-server architectures), you might run into issues with file locks. Worse, you're likely thrashing the hell out of the disk, so I hope it's a dedicated server. If you must use this approach, I highly recommend enumerating the permissions once at startup and caching the result in memory (with a Reload() method if necessary). – Dan Apr 13 at 13:50

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.