Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Hi all,

 

This is almost entirely unrelated to this group, except that it’s an AD question. Hope that’s not too presumptuous! :)

 

I have a simple question about NTLM-based “Integrated Windows Authentication”. Seems it would be simple to answer, but not being a Windows programmer, I’m not sure where to look for the info.

 

 

Windows caches a(n NTLM) hash (or encrypted plaintext copy) of the user’s AD password in memory when the user logs in. When the user later leverages Integrated Windows Authentication (IWA) for an NTLM (or NTLM over HTTP?) authenticated service, this cached password (or hash) is/must be used to generate the NTLM challenge response.

 

My question (presuming I haven’t gone horribly wrong already!) is:

 

·         When IE or another application leverages IWA, does the application gain direct access to the cached NTLM password hash? Or is there an API that IE/the app calls that generates the response?

 

I’m trying to understand whether the user’s cached password hash is exposed to applications using IWA, or if it’s more an abstraction layer that allows applications to authenticate the user without gaining access to the user’s password (or hashes of same).

 

 

It seems clear (though I guess I should call it out as well) that if the user is NOT authenticated and there is an HTTP-basic-like prompt from the browser/application for the user to authenticate, then in that case the browser/application has direct access to the credentials (as they would for any other forms based authentication). I’m really asking about the leveraging of the users local NTLM for IWA.

Thanks, and have a great weekend all,

 

--- Eric