2

short form: Should I use some well-known uid to authenticate a ldap client, and then other means within that client to validate the user-entered uid and pw?

long form: We have a commercial .net-based web product that is implemented in many customer sites, and currently uses internal user authentication.

I am investigating using LDAP for authentication against a directory. Since our product is implemented in various environments, I want this to be compatible across the broadest possible spectrum of LDAP-compliant directory services and configurations, including but not limited to Active Directory.

Besides authentication, I want to use a directory property of the user to determine whether they are authorized to use the application. I expect that this will indicated by the user's membership in a specific group. The name of the group will be a configuration point of the application.

The directory service is used only to confirm the userid, pw, and group membership. The application will NOT assume the identity of the user when processing subsequent requests from the user. So, no FormsAuthenticationTicket.

One of my first questions comes from the authentication examples I've reviewed, such as http://tldp.org/HOWTO/LDAP-HOWTO/authentication.html and http://msdn.microsoft.com/en-us/library/ff649227.aspx. These use the user-entered id and password to authenticate the LDAP client. That's reasonable, I suppose, but in my case the client will go on to do other LDAP searches to confirm group membership. Do I need to be concerned that the end-user might not have sufficient directory privileges to do a membership check? It seems to me that it would be better practice to use reserved credentials for the ldap client authentication, and then, via some other means, confirm the user-entered uid/pw. Or, perhaps, bind twice, once with the user credentials to authenticate those, and secondly with built-in credentials to do the search. Should I do this, or am I just making things harder than they need to be?

Elroy Flynn
  • 520
  • 1
  • 6
  • 8

2 Answers2

2

The principle of least privilege applies here. The account you use to bind to LDAP and enumerate users, groups and any other pertinent information should definitely be a "service account" and not an actual human's account.

There are different permissions required for this account compared to most human users. The VP's assistant doesn't need to be able to enumerate all groups and see if a given account exists, but the account you use to bind to LDAP does need this.

Joel E Salas
  • 5,562
  • 15
  • 25
0

If you use a system account to grant privileges that your regular user accounts don't have, you've got a privilege escalation. (In your example, users of your application can see group memberships that they can't see on their own.) That's ok, but be aware that any privilege escalation has the potential for abuse.

Personally, I'd prefer to write my ACLs such that user accounts have whatever privileges they need to have, and use my LDAP server (rather than my downstream application) to manage access. Why shouldn't your user accounts be able to see what groups they belong to?

As for "least privilege," here that means using the user's credentials, because he already has access to them. If you use a shared system account, that's--by design--additional privileges that regular users don't have.

anderbubble
  • 226
  • 3
  • 7
  • I accepted Joel's answer rather than yours, even though I would prefer your solution. However, I have no control and little influence over the directory policies of the enterprise that implements our application, so going with a special accounts is the more feasible solution. – Elroy Flynn Jul 10 '12 at 01:17