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?
