Meeting the InCommon Assurance profile criteria using Active Directory

[Eric Goodman <>]

Thanks Jeff,

 

Yeah, I’d seen much of this.

 

Is it just me, or is that reference itself contradictory? :) My understanding of the process is that credentials are not sent, rather challenges and responses are (which is consistent with how NTLM and Kerberos authentication protocols operate).

In any case, I’m trying to understand if desktop clients have an API to get the user’s password hash (stored in the LSASS?), or if they can only get responses to NTLM challenges by sending those challenges to a system service that itself handles the hash. I certainly hope it’s the latter, but it’s really vaguely defined in the references I’ve looked at.

 

Thanks for the attempt!

 

--- Eric

 

From: [mailto:] On Behalf Of Capehart,Jeffrey D
Sent: Monday, June 23, 2014 6:48 AM
To:
Subject: [AD-Assurance] RE: Dumb NTLM+IWA question

 

Not sure if this will help, or clear it up, but I found some information on ASP.net about IWA.

Seems to be integrated into IIS but it also seems like it is a replacement name for NTLM challenge response.  Maybe the author of this article knows more about it than we might.

-Jeff

http://www.asp.net/web-api/overview/security/integrated-windows-authentication

Integrated Windows authentication enables users to log in with their Windows credentials, using Kerberos or NTLM. The client sends credentials in the Authorization header. Windows authentication is best suited for an intranet environment. For more information, see Windows Authentication.

Advantages	Disadvantages
Built into IIS. Does not send the user credentials in the request. If the client computer belongs to the domain (for example, intranet application), the user does not need to enter credentials.	Not recommended for Internet applications. Requires Kerberos or NTLM support in the client. Client must be in the Active Directory domain.

 

 

From: [] On Behalf Of Eric Goodman
Sent: Friday, June 20, 2014 7:35 PM
To:
Subject: [AD-Assurance] Dumb NTLM+IWA question

 

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