Meeting the InCommon Assurance profile criteria using Active Directory

[Brian Arkills <>]

I don’t think Microsoft likes to document this in  much detail.

 

Based on a really long PSS case (that we ended up not having to pay for!) back in ~2003-5 on how cross-realm Kerberos works, my understanding is that there is a point at which the password is no longer available to Windows. You can capture the password with a custom authentication provider. Why might cross-realm Kerberos be relevant here? With that, a user on a Windows computer gets an external Kerberos realm TGT (by entering a password to the local LSASS). That foreign TGT then allows a Windows domain (realm) TGT to be issued (via the altSecID mechanism). If the external realm password doesn’t match the Windows domain password, then that’s all the logon tokens that user ends up with. No NTLM logon token. If the user then connects to a service which only accepts NTLM, a challenge/response must be raised. However, if the external realm password matches the Windows domain password, then a NTLM token is issued at the same time as the Windows domain TGT. One way to verify for yourself that the password is no longer available, would be to setup cross-realm Kerberos with non-matching passwords. Logon. Then change the Windows domain password to match. Then try to access a resource that only allows NTLM. If you are challenged, then you know Windows doesn’t retain that password for use. If you aren’t challenged, then it does.

 

If the password is cached in the Credential Manager, I believe there are ways to retrieve it.

 

And of course, if you are on a computer running Windows prior to 8.1, there are ways to get the password from memory.

 

BTW, our efforts to kill off NTLMv1 continue here. Last week we discovered that Firefox and Chrome on non-Windows platforms don’t have support for NTLMv2. L I’ve got quite a bit of interesting findings coming out of this effort which should make it easier for others to follow in our footsteps.

 

From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, June 23, 2014 5:44 PM
To:
Subject: [AD-Assurance] RE: Dumb NTLM+IWA question

 

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: [] 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