Meeting the InCommon Assurance profile criteria using Active Directory

[Brian Arkills <>]

Interesting information. I think I even follow most of it. :)

 

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

 

Right, but that’s the password locker, right? I.e., the user intentionally stores it there a la lastpass or 1password.

[BA] Right.

 

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

 

This may be what I was asking. Are there “supported” ways to do this, or are you just saying it could be done by a determined enough attacker?

[BA] Supported? Not really. Although there seem to be some sketchy exceptions. For example, Microsoft’s Password Export Server somehow allows you to migrate a password stored on a DC in a “one-way” hash to somewhere else. Microsoft has always declined to explain how. The more recent DirSync password sync capability ships the hash, so it’s not an example. The really recent Azure AD self-service password reset allows a password to flow between the cloud and on-premise. How is a little bit mysterious, and I think that’s what the recent tweet from Alex Simons was about.

 

There are quite a few “canned” hacks that allow you to get at passwords in memory. I’ve seen several demonstrated. They generally involve some device driver with enough smarts to find the juicy bits. In some cases, the password is stored in a memory location that is easy to find.

 

Clearly if the user enters a username/password directly into an application, then said application will have direct access to the NTLM hash (by directly creating it from the plaintext). When IWA is in use it would seem to be a security risk if an arbitrary app could just grab it and start authenticating itself as the user, but I’m just not knowledgeable enough to speak to whether that’s really what happens.

 

This is all of interest to me because of a vendor that has all sorts of “interesting” SSO support options that rely on NTLM and IWA (one of which is SAML ECP support authenticated by NTLM of all things). Some clients are web clients and some are “fat” applications, so whether the app vs. the OS generate the challenges with IWA is actually relevant to whether the vendor’s applications (where “the vendor” != Microsoft) will have access to the user’s password in some of these cases.

[BA] Generally, this kind of configuration means the client sends the password in clear text to a proxy (over a secure channel). The proxy then handles the authentication protocols that the clients can’t support. I know that’s how Microsoft implemented Shib support for Live@EDU many years ago. In some cases the “proxy” is part of the application server itself.

 

I’m sure I’m overthinking given that we’re talking about NTLM in the first place, but I’m prone to such obsessions! :)

 

Thanks for humoring me, and let me know if there’s a better place to ask this kind of question.

 

--- Eric

 

From: [] On Behalf Of Brian Arkills
Sent: Tuesday, June 24, 2014 8:46 AM
To:
Subject: [AD-Assurance] RE: Dumb NTLM+IWA question

 

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