Dirty of Advanced Digest - Ouch!

A week or so ago, I got a mail that said: “Chris, do you know that much about Advanced Digest?”  I told this person, sure, what would you like to know...

Today I sit in judgement for speaking prior to “thinking”, which is a problem I often struggle with.  I knew how Advanced Digest was configured within IIS and what its requirements were, but I was far from saying I “know” much about Advanced Digest.

It turns out that Digest is covered in a RFC, and I had failed like I have on many of occasions to read that RFC.  I don't write code so I am not tasked with knowing the intrinisic nature of the protocol.  A customer, though, challenge us (MS) on it and I found I knew very, very little even about the protocol, the method for which it was transmitted to and from client to IIS.  I knew even less about how Digest communicated with the domain controller...Arghh!

The judgement you can take from today's message is this:  ChrisAd knows much more today than he did last week.  Let me explain to you how we implemented Advance Digest on Windows 2003, which by the way, is 100 percent compliant with the RFC located here -- Digest RFC

Advanced Digest is enabled when:

   a).  On a new install of Windows 2003 Server

Advanced Digest does not require the use of the IIS Sub-Authenticator (iissuba.dll).  Advance Digest is also implemented in the SSPI code (LSASS), which is to say, natively in the operating system. 

Advanced Digest DOES not require that the users password be stored in reversible encryption in Active Directory...

Oh, but tell me what we didn't know...

Ok -

a).  Windows 2003 with the creation of a new user, password reset, or password updated, the Adv. Digest pre-computed hashes are generated and stored in AD.

b).  This password is stored in the same area of the SAM (in this case, AD) that the password hashes for NTLM are stored

c).  The hash is always computed for every user on Windows 2003 without any admin intervention

d).  IIS receives the hash, of course, from the client and passes that hash to the DC.  It does so over a secure channel.  If you have a firewall between the IIS server and AD, punch a hole in port 138.

e).  All data is highly encrypted using the secure channel between the IIS Server and AD.

If this was coding an application, I would normally call this API:

Brain.Commit

Later

~Chris