3

I am trying to achieve the following:

  1. Authenticate users against Active directory.
  2. If the user belongs to group "A" i want to limit user rights
  3. If the user belongs to group "B" i want to have some other logic in my code.

I am able to achieve the first one in the above list.

I am using forms authentication in my web application(Intranet).I did some research and there are various suggestions to use Microsoft Active Directory Application Mode (ADAM) which i m completely unaware of.Is there a way i can achieve the above with out using ADAM? Say suppose get the group list into the code and based on that can i make a call if user belongs to some group and so on..

Is is that i am thinking only on group level which limits my options? Or is there a way other than giving user access rights from group level or am i completely not understanding the concept of Active directory authentication ?

Macnique
  • 1,028
  • 2
  • 19
  • 44
  • Take a look at How To: Use Windows Authentication in ASP.NET 2.0 - http://msdn.microsoft.com/en-us/library/ff647405.aspx – jrummell Nov 08 '11 at 14:09

2 Answers2

3

Check this question, it is the same problem though differently described: Validate a username and password against Active Directory?

Either way ActiveDirectory is fully supported within C#, no need for additional systems (I am not aware what ADAM is either).

To check the groups of a username, use this code:

UserPrincipal p = UserPrincipal.FindByIdentity(
domainContext, IdentityType.SamAccountName, userName);
var groups = p.GetGroups();
foreach (GroupPrincipal g in groups) { /* do something */ }
Community
  • 1
  • 1
zmilojko
  • 2,125
  • 17
  • 27
  • I am able to authenticate User in AD but i am working on roles ,the link you suggested have replies for authentication of user and password. – Macnique Nov 08 '11 at 14:18
  • @Macnique Pls check my update, I copied the code that might give you groups of a user from AD. – zmilojko Nov 08 '11 at 14:26
  • What is domainContext and UserName in this code you mentioned above? – Macnique Nov 08 '11 at 14:36
  • @Macnique domainContext yo ucan get as `PrincipalContext domainContext = new PrincipalContext(ContextType.Domain, "domain_name");`, where domain_name is a flat name of your domain, whatever it is - it should find LDAP server from the domain server. Username is, obviously, a username of the user for which you are checking the groups membership - I guess the user that your process is running after. – zmilojko Nov 08 '11 at 19:27
  • i did try that but it throws an exception logon failure :unkown username or bad password" – Macnique Nov 09 '11 at 14:54
  • I am trying to help here, but you need to provide more information, for instance post your code and say exactly which line fails... Also, play a bit with parameters (see other options but the `SamAccountName` and check that domain name and username are correct!), but `UserPrincipal` is the class to provide you with the user's groups. – zmilojko Nov 09 '11 at 15:01
2

If you are asking about a general architectural or best practices question, I would suggest looking at Claims Based Authentication. In particular Active Directory Federation Services (ADFS).

Basically, it seems that you need to control what a user can do at a more granular level than based only groups. Group membership can sometimes be very broad. For example, not every one in the "Users" might have the same right, not everyone in the "Sales" would have the same access. But then you don't want to create groups such as "Sales - Managers", "Sales - Employees", "Sales - Executives" etc. etc. This quickly becomes unwieldy. And no matter how much time you put into designing the perfect distribution of groups, in a few years it will all change because some subset of the sales managers will be allowed to do something, which other sales managers cannot.

To get around this problem, Claims based authentication is used. Rather than specifying rights at the group membership level you just check in your code whether a user has a certain "Claim". You can go nuts and create as many claims as makes sense for your application. You can have claims like "Can Change Birth Date", "Can Authorize Payment More Than $1000" etc. etc.

The claims are just attached to your user's identity, which is available via the thread's current principle.

Now, how does the user get assigned these "Claims" you ask? Well, if you are using ADFS, anyway you want. You can obviously do it based on AD group memberships. You can do it based on database look ups. You can do it on the time of the day or the month of the year if you so wish.

The point is, now your claim issuing and claim enforcement are completely independent and can change independently without affecting each other. Your code just says "Hey, this guy has a claim that lets him make more than $1000 payments, so I will let him do that. Why he has that claim, I don't know or care". Then your ADFS can issue claims based on any criteria that it sees fit. For example "If user is member of Managers group or has an entry in SuperUsers table in the security Database or is named 'Tim Timsky', he is allowed to spend more than $1000"

So to answer your question about "thinking only on group level which limits my options", it most certainly doesn't have to. If you are starting a new, green fields project, new tools like ADFS would give you a lot of options more easily.

But of course it comes with a caveat, which is that all abstraction has a cost of increased complexity. It is another part you are introducing into your system. You can decouple your application and introduce higher layers of abstraction and functionality. But whether or not that layer is worth introducing depends on how you plan to use the application. If you think that the application will never ever ever have to distinguish between a "Manager" and a "User" then, claims based authentication is an over kill. But if you feel that as time goes on, you will have different bits and pieces of functionality in your application that will need to be assigned to different users based on vague and ever changing rules, then claims based authentication will make your solution much neater.

As always, the net advantage of decoupling two parts depends on how often one changes independent of the other.

Chaitanya
  • 5,203
  • 8
  • 36
  • 61
  • :I am looking for a solution where i can have two containers admins and users in AD .I want to give permissions based on whether the current user belongs to admins or users in AD. – Macnique Nov 08 '11 at 15:57
  • 1
    Then what you need is User.IsInRole("Administrators") explained here http://weblogs.asp.net/scottgu/archive/2006/07/12/Recipe_3A00_-Enabling-Windows-Authentication-within-an-Intranet-ASP.NET-Web-application.aspx and here http://weblogs.asp.net/scottgu/pages/Recipe_3A00_-Implementing-Role_2D00_Based-Security-with-ASP.NET-2.0-using-Windows-Authentication-and-SQL-Server.aspx – Chaitanya Nov 08 '11 at 21:40
  • I did look at the link you mentioned above,but it details about windows authentication,i am trying in the line of forms authentication. – Macnique Nov 09 '11 at 14:55