Bug 975464

SSSD does not support NTLM authentication, you will have to keep using winbind if that's a requirement for you.

Proposing to close as NOTABUG

That would make me very sad. We have a bunch of services which require NTLM auth, not Kerberos/Negotiate.

Microsoft haven't even disabled automatic NTLM authentication yet, have they? We don't even need to tweak a registry key to turn on.

To claim that we have functional AD integration and single-sign-on, we *need* NTLM authentication to work.

Please reconsider.

From http://msdn.microsoft.com/en-us/library/cc236715.aspx

"Implementers should be aware that NTLM does not support any recent cryptographic methods, such as AES or SHA-256. It uses cyclic redundancy check (CRC) or message digest algorithms ([RFC1321]) for integrity, and it uses RC4 for encryption. Deriving a key from a password is as specified in [RFC1320] and [FIPS46-2]. Therefore, applications are generally advised not to use NTLM."

Yes, applications are advised to use Kerberos instead of NTLM. However, there are a large number of applications out there which predate that advice, and which still use NTLM only.

In some cases, upgrading to Kerberos would require a change of the underlying protocol between client and server. Or of the integration of the server into the domain, where said 'server' may be a black-box appliance.

So while new applications are advised *not* to use NTLM, that doesn't mean that a client can get away without supporting it. As I said, it's still enabled by default on Windows clients. The unfortunate reality is that NTLM auth is *so* far from dying, that we don't *even* need to tweak a registry setting to enable it on the client.

Note that we are handing the password off to gnome-keyring via the PAM hook, so perhaps gnome-keyring could be used to respond to NTLM challenges. We even had an implementation of this in the past; I wonder where we got with merging it...

http://git.infradead.org/users/dwmw2/gnome-keyring.git

Something based on this could potentially be used for keeping the Kerberos TGT up to date too, if you aren't already doing that in SSSD.

(In reply to David Woodhouse from comment #4)
> Yes, applications are advised to use Kerberos instead of NTLM. However,
> there are a large number of applications out there which predate that
> advice, and which still use NTLM only.
> 
> In some cases, upgrading to Kerberos would require a change of the
> underlying protocol between client and server. Or of the integration of the
> server into the domain, where said 'server' may be a black-box appliance.
> 
> So while new applications are advised *not* to use NTLM, that doesn't mean
> that a client can get away without supporting it. As I said, it's still
> enabled by default on Windows clients. The unfortunate reality is that NTLM
> auth is *so* far from dying, that we don't *even* need to tweak a registry
> setting to enable it on the client.

In most cases this is simply not true. Both NTLM and Kerberos authentication are performed through the same Security library in windows (SSPI).
NTLM is used as a fallback often when DNS is screwed up or IP addresses are used instead of hostnames. But it is a fallback.

THe problem with supporting NTLM is that is requires a ton of work, and our GSSAPI libraries do not have NTLMSSP support.

You are free to open a RFE in the upstream ticketing tool for sssd at https://fedorahosted.org/sssd and we can see what can be done to add support eventually if there is enough demand.

(In reply to David Woodhouse from comment #6)
> http://git.infradead.org/users/dwmw2/gnome-keyring.git
> 
> Something based on this could potentially be used for keeping the Kerberos
> TGT up to date too, if you aren't already doing that in SSSD.

man sssd-krb5 see krb5_renew_interval

That works for renewal but does it obtain a *new* one when the original one really expires? I believe Windows will, and users will expect that.

(In reply to David Woodhouse from comment #9)
> That works for renewal but does it obtain a *new* one when the original one
> really expires? I believe Windows will, and users will expect that.

You're not the first person to ask for this. It's inherently insecure (because it requires the storage of a plaintext password somewhere in the system), but there are ways we might be able to mitigate this (keeping it in the kernel keyring, not surviving an SSSD restart) so I've opened an RFE: https://fedorahosted.org/sssd/ticket/1990

We spent a lot of time and effort to solve the problem of applications running securely using Kerberos and not having to rely on cron jobs or other means to renew the tickets.
The current recommendation is to create an application account, issue it a keytab and use GSS proxy to establish connections to the external servers. One of the benefits of GSS proxy is that it would renew tickets automatically on behalf of application without any race conditions or problems.

Please see more information about GSS proxy here
https://fedoraproject.org/wiki/Features/gss-proxy
http://k5wiki.kerberos.org/wiki/Projects/ProxyGSSAPI
https://fedorahosted.org/gss-proxy

That's nice. The fact remains that I need to authenticate to services which are not within my control, and which only support NTLM authentication.

This is unfortunate but realistically it will take us more time to build NTLM support than those services to move to use Kerberos. We are talking years here and since it is the functionality of the last century there will be less and less demand to justify the investment on our way. 

I wonder may be there is some kind a Kerberos to NTLM gateway/proxy project that can be used for cases like this.

It will be User ---Kerberos--> Gateway ---NTLM--> Service

I wonder if something like this would work and available to handle legacy services. IMO that would be a cleaner solution than trying to introduce NTLM into SSSD.

(In reply to Dmitri Pal from comment #13)
> This is unfortunate but realistically it will take us more time to build
> NTLM support than those services to move to use Kerberos. We are talking
> years here

Seriously?

It's not exactly difficult to have something which receives the login password through PAM (like ecryptfs and gkr already do), and which then handles NTLM requests via the standard /usr/bin/ntlm_auth invocation that clients are already using.

It would also be relatively simple to make gkr do it; Stef had some patches to expose the login password as an object in its own right, and then it's just a couple of methods to generate the NTLM type1 and type3 packets. See the git repo in comment 6.

It doesn't have to be hard, and it doesn't have to live in SSSD itself. But it *does* need to work.

(And as discussed elsewhere, the same tool in the user's session could also handle the task of maintaining a Kerberos TGT. Not just renewing the one we obtained at login time, for the limited length of time that it can be renewed for.)

Why can't you use winbind for all this?

(In reply to David Woodhouse from comment #14)
> (In reply to Dmitri Pal from comment #13)
> > This is unfortunate but realistically it will take us more time to build
> > NTLM support than those services to move to use Kerberos. We are talking
> > years here
> 
> Seriously?
> 

Because you forget about domain trusts.

(In reply to David Woodhouse from comment #9)
> That works for renewal but does it obtain a *new* one when the original one
> really expires? I believe Windows will, and users will expect that.

No Windows usually do not automatically obtain a new ticket for a user, it just does what SSSd also does,m which is to get you new tickets when you unlock the screen. This is for interactiuve logins.
For non-interactive logins (like attaching to a network share) windows *may* indeed fallback to NTLM (if enabled) and use a cached NT Hash.

(In reply to David Woodhouse from comment #14)
> (In reply to Dmitri Pal from comment #13)
> > This is unfortunate but realistically it will take us more time to build
> > NTLM support than those services to move to use Kerberos. We are talking
> > years here
> 
> Seriously?

For client authentication (logins) supporting NTLM is not too difficult, but it does require adding annoying dependencies on Microsoft protocols. We do have code that does that in Samba but it is not yet all readily consumable in as a library. A concentrated effort could get that done in a resaonable time, but we do not have resources to do a concentrate effort on that at this moment (we have other priorities), that is why Dmitri says 'years'.

> It's not exactly difficult to have something which receives the login
> password through PAM (like ecryptfs and gkr already do), and which then
> handles NTLM requests via the standard /usr/bin/ntlm_auth invocation that
> clients are already using.

This is a second order problem.
Here the issue is not much about authentication on the client, but mostly about the fact you are going to store a password-equivalent hash in memory. It means live credentials that need to be carefully handled because if they are stolen they can be immediately reused as if they were a password.

We do have some plans about creating a GSSAPI NTLM provider, and that could be use in the browser directly without the need for ntlm_auth except for the fact we need to create some glue code to let this access secure storage.

This could be done using Gss-Proxy which is a trusted service and can be allowed access to the credentials w/o having them stolen by a compromised user application. however at this time we do not have this GSSAPI NTLM backend, nor APIs to allow sssd store an RC4 hash and then allow gssproxy to retrieve it.

> It would also be relatively simple to make gkr do it; Stef had some patches
> to expose the login password as an object in its own right, and then it's
> just a couple of methods to generate the NTLM type1 and type3 packets. See
> the git repo in comment 6.

Right, caching the user password in user accesible space. This mean any compromised user process can steal the user password.

This. is. bad. (TM).

> It doesn't have to be hard, and it doesn't have to live in SSSD itself. But
> it *does* need to work.

And it *needs* to be done properly and securely, with privilege separation. you cannot have a user process hang onto user credentials avbailable to be stolen by any compromised app.

> (And as discussed elsewhere, the same tool in the user's session could also
> handle the task of maintaining a Kerberos TGT.

As sai above this is a non-problem in 99% o the cases, especially for configuration that give you a ticket that is valid for a full week and the machine is regularly used by the user which is your case if I understand it correctly.

(In reply to Dmitri Pal from comment #15)
> Why can't you use winbind for all this?

I am entirely open-minded about how to do this. If the answer is "use winbind because sssd is not, and will never be, a fully-featured replacement for it" then I'll go file a g-i-s bug to have it set up winbind instead of sssd, and will restart my testing from scratch.

(In reply to Simo Sorce from comment #18)
> Right, caching the user password in user accesible space. This mean any
> compromised user process can steal the user password.

Well, caching the LM and NT hashes of the user password in user accessible space. Which means any compromised user process can steal them and... authenticate to a service which is violating the modern security recommendations and still allowing NTLM auth. We can live with that. It isn't a *new* concern, after all.

I'm a little hazy on the details of the Kerberos preauth, but don't we generate a key *from* the password and the principal, and thus what we have to cache is still not completely password-equivalent, but only usable to obtain a Kerberos TGT for that principal? (Which is admittedly more of a potential concern than the NTLM hashes, but still extremely useful from the usability POV.)

> As sai above this is a non-problem in 99% o the cases, especially for
> configuration that give you a ticket that is valid for a full week and the
> machine is regularly used by the user which is your case if I understand it
> correctly.

The machine may be regularly used, but the user isn't regularly entering their password — which is kind of the point :) 

And it may *not* be consistently connected to the VPN. Around here we seem to have a 10-day TGT lifetime, renewing every 10 hours. It's entirely feasible that machines will be off the VPN for 10 hours overnight, requiring a new TGT to be obtained every day.

I *suppose* if we require a password to unlock the screensaver we could use that to kick off a new TGT acquisition? So that part may well be OK for now. It's just NTLM that users are really going to miss, which is the subject of this RFE.

(In reply to David Woodhouse from comment #19)
> (In reply to Dmitri Pal from comment #15)
> > Why can't you use winbind for all this?
> 
> I am entirely open-minded about how to do this. If the answer is "use
> winbind because sssd is not, and will never be, a fully-featured replacement
> for it" then I'll go file a g-i-s bug to have it set up winbind instead of
> sssd, and will restart my testing from scratch.
> 
> (In reply to Simo Sorce from comment #18)
> > Right, caching the user password in user accesible space. This mean any
> > compromised user process can steal the user password.
> 
> Well, caching the LM and NT hashes of the user password in user accessible
> space. Which means any compromised user process can steal them and...
> authenticate to a service which is violating the modern security
> recommendations and still allowing NTLM auth. We can live with that. It
> isn't a *new* concern, after all.

Oh but it totally is. On windows machines a user account being compromised does not have access to the cached credentials. Cached credentials access is mediated byt their kernel/privileged APIs, so you can't take the NT hash and run away. Here you are setting yourself up to be able to do that.

> I'm a little hazy on the details of the Kerberos preauth, but don't we
> generate a key *from* the password and the principal, and thus what we have
> to cache is still not completely password-equivalent, but only usable to
> obtain a Kerberos TGT for that principal?

If you can obtain a TGT you have a password equivalent secret.

> (Which is admittedly more of a
> potential concern than the NTLM hashes, but still extremely useful from the
> usability POV.)

Extermely useful and risky, which is why we store password in the kernel keyring and delete them as soon as we can obtain a TGT. In every case the user processes do NOT have access to these credentials, access is only possible from privileged processes (sssd in this case).
 
> > As sai above this is a non-problem in 99% o the cases, especially for
> > configuration that give you a ticket that is valid for a full week and the
> > machine is regularly used by the user which is your case if I understand it
> > correctly.
> 
> The machine may be regularly used, but the user isn't regularly entering
> their password — which is kind of the point :) 

Your usesr do not lock their screens and then use a password to unlock ?

> And it may *not* be consistently connected to the VPN. Around here we seem
> to have a 10-day TGT lifetime, renewing every 10 hours. It's entirely
> feasible that machines will be off the VPN for 10 hours overnight, requiring
> a new TGT to be obtained every day.

This is not an issue, in SSSD we *do* cache the use rpassword in the keyring if you do not have a valid TGT and you are offline. As soon as you get online and a valid TGT can be fetched the password is deleted, but it is not needed anymore, you have the TGT.

> I *suppose* if we require a password to unlock the screensaver we could use
> that to kick off a new TGT acquisition?

You do not need to suppose, that is what we already do with SSSD by default.

> So that part may well be OK for now.
> It's just NTLM that users are really going to miss, which is the subject of
> this RFE.

Yes, but login using NTLM is more difficult to implement than negotiate using NTLM because of the protocols involved. Although I guess we could try to use NTLM against LDAP. That would be possible if we can implement an NTLM mechanism plugin for GSSAPI. The client part og a GSSAPI / NTLM mechanis is realtively simple.

Simo.

(In reply to Simo Sorce from comment #20)
> (In reply to David Woodhouse from comment #19)
> > And it may *not* be consistently connected to the VPN. Around here we seem
> > to have a 10-day TGT lifetime, renewing every 10 hours. It's entirely
> > feasible that machines will be off the VPN for 10 hours overnight, requiring
> > a new TGT to be obtained every day.
> 
> This is not an issue, in SSSD we *do* cache the use rpassword in the keyring
> if you do not have a valid TGT and you are offline. As soon as you get
> online and a valid TGT can be fetched the password is deleted, but it is not
> needed anymore, you have the TGT.
> 

FYI, this is not our default behavior. This requires the option "krb5_store_password_if_offline = True" to be set in the domain section of sssd.conf. I believe that ipa-client and authconfig both set this to True by default, but if you set up SSSD manually, this may not be the case.


> > I *suppose* if we require a password to unlock the screensaver we could use
> > that to kick off a new TGT acquisition?
> 
> You do not need to suppose, that is what we already do with SSSD by default.
> 

Yes, all screensavers (that I am aware of) call pam_authenticate() when you unlock them. This would go through pam_sss.so and as long as you are online, you will get a new TGT. If you are offline at this time, but you have the above-mentioned option set, SSSD will automatically acquire the TGT for you as soon as you go back online (e.g. reconnect to the dropped VPN) without re-prompting for auth.

Yeah, the TGT is probably fine. We can live with the situation as realmd sets it up by default, with krb5_store_password_if_offline = True.

We really do need NTLM though. See bug 976300 for "yet another" example where Kerberos doesn't quite work, and Windows presumably only works because it falls back to NTLM. These are not uncommon.

It doesn't need to be NTLM via GSSAPI; the /usr/bin/ntlm_auth option is perfectly sufficient for most purposes. Seriously, all I need is a way to, given an NTLM type2 challenge, produce the corresponding type3 response based on the password. The rest is just plumbing.

(In reply to David Woodhouse from comment #22)
> Yeah, the TGT is probably fine. We can live with the situation as realmd
> sets it up by default, with krb5_store_password_if_offline = True.
> 
> We really do need NTLM though. See bug 976300 for "yet another" example
> where Kerberos doesn't quite work, and Windows presumably only works because
> it falls back to NTLM. These are not uncommon.
> 
> It doesn't need to be NTLM via GSSAPI; the /usr/bin/ntlm_auth option is
> perfectly sufficient for most purposes. Seriously, all I need is a way to,
> given an NTLM type2 challenge, produce the corresponding type3 response
> based on the password. The rest is just plumbing.

I mention GSSAPI because then we can modify GSS-Proxy to perform this operation on behalf of the user and keep the credentials safely off the user processes reach, this way a compromised application cannot steal usable credentials.

(In reply to David Woodhouse from comment #19)
> (In reply to Dmitri Pal from comment #15)
> > Why can't you use winbind for all this?
> 
> I am entirely open-minded about how to do this. If the answer is "use
> winbind because sssd is not, and will never be, a fully-featured replacement
> for it" then I'll go file a g-i-s bug to have it set up winbind instead of
> sssd, and will restart my testing from scratch.

Already supported by g-i-s, because it uses realmd, and realmd supports configuring that as the default:

http://www.freedesktop.org/software/realmd/docs/guide-active-directory-client.html

(In reply to David Woodhouse from comment #22)
> We really do need NTLM though. See bug 976300 for "yet another" example
> where Kerberos doesn't quite work, and Windows presumably only works because
> it falls back to NTLM. These are not uncommon.

I'd just like to agree with Simo here that NTLMSSP in GSSAPI, really is the right way to do this.

> It doesn't need to be NTLM via GSSAPI; the /usr/bin/ntlm_auth option is
> perfectly sufficient for most purposes. Seriously, all I need is a way to,
> given an NTLM type2 challenge, produce the corresponding type3 response
> based on the password. The rest is just plumbing.

Yes, plumbing. That's what GSSAPI is: plumbing :D

Here's the bug tracking NTLM support in GSSAPI: bug #963341

Upstream ticket:
https://fedorahosted.org/sssd/ticket/2012

Tracked upstream now.