Due to some technical issues (i’ll show you below) it is impossible to authenticate using Digest Authentication for authenticating the user against an Database/LDAP and the webserver itself. I did this before with Basic authentication, which works fine.

It is possible to authenticate with basic authentication against a Database, simply write a 401 header to the client, wait until the client responses, decode the response with a Base64Decode function and query a database table with that username and password. When you decode the client response with a Base64Decode function, you get the ‘username:pasword’ (separated by a colon).
The great advantage is that you can authenticate the user against a database AND the webserver/Active Directory now.
I.E.: You have a Microsoft Access or MySQL database with over 2000 usernames in it (when a user registers, he gets an account). Some ‘special’ users are also created on the webserver as a local user account or Active Directory account. You can redirect these ‘special’ users to a ‘/test/admin/’ directory which is normally protected by the webserver but these ‘special’ users are already authenticated so they have permission to go there.

To achieve this, configure IIS to use Anonymous AND Basic Authentication to the ‘/test/’ directory (this is where all the users get a login page we’ve written with a 401-header so they’re asked for an username/password. The ‘/test/’ directory also has a modify-profile and some other standard-user pages).
Configure the ‘/test/admin/’ directory in IIS to only accept Basic authentication. This is the webserver protected directory. You can put fancy stuff in here and even let the ‘special’ user execute things because he is not authenticated as the default IUSR but as the local user/Active Directory account.

The disadvantage of the above example is that is works with Basic authentication, so everybody who is able to sniff the network can capture your password, it’s almost sended in clear text over the line.
So i wanted to do the same with Digest authentication, this uses a MD5 algorithm to encrypt the password which is much more difficult to decode, nearly impossible.

I also created a ‘/test/’ and a ‘/test/admin/’ directory on the webserver, in the ‘/test/’ directory i’ve written a login page which serves a 401-header (and some other special digest headers) to the client. The client gives a response (only the password is encrypted by MD5), i will not decode the MD5 response this time but look in my Microsoft Access or MySQL database for the client’s username and see if the MD5 password response from the client is the same as the MD5 encrypted password in my database. If it is the same, this user is given a session/authenticated, otherwise i serve the 401-header again.
However i cannot redirect ‘special’ users to a ‘/test/admin/’ directory this time (i’ve configured IIS to accept only Digest authentication on that directory).

I went in depth to find out;

By writing the Digest authentication login page, you write a 401 header to the client AND another header with a unique number (any number we want). The client now responses with a his username, the MD5 hash of the password and the unique number.
(Also see Greg Reinacker’s Weblog for an interesting item).
As soon as we redirect the user to the ‘/test/admin/’ folder it can not be authenticated by the webserver because the unique number (which is sent by the client) is not what the webserver expects. So the webserver will send a 401 header and a unique number. The client needs to type his username and password (again) and send it to the server. This time he gets authenticated because the unique number matches the one that the webserver has just sent.

Conclusion: We CAN use Digest authentication but then the user always has to login twice, this is not what we want. The reason to do all this stuff is because we want a single signon (normal users from the database AND ‘special’ users who also have a local user/Active Directory account can login at once).
I did not find a solution yet and think it”s actually impossible on the current Windows/IIS/ASP platform.