NTLM or Kerberos support

[smidt]

It would be nice to get NTLM or Kerberos support for the client.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/4073049-ntlm-or-kerberos-support?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F216457&utm_medium=issues&utm_source=github).

[MTRichards]

I thought NTLM was already there. @danimo Didn't this get a fix a while ago?

[danimo]

No, only in Qt for the IL branch. @guruz knows more.

[MTRichards]

Ok. Good to know. Thanks.

[danimo]

Note: Kerberos via Negotiate is a different topic alltogether:

https://bugreports.qt-project.org/browse/QTBUG-1538

[MTRichards]

roger that. Note: Made NTLM feature request.

[guruz]

Is this issue about proxy support? if yes please change the topic.

Negotiate doesn't matter since all proxies seem to support NTLM too. The NTLM proxy fix will be Qt 5.3.2 or Qt 5.3.3 https://codereview.qt-project.org/#/c/91285/ or earlier if we decide to pick anything into "our" Qt for the owncloud client.

[smidt]

No it is not about proxy support. It is a feature request for the client. But what do you mean by "if we decide to pick anything into "our" Qt for the owncloud client"?

[danimo]

No it is not about proxy support. It is a feature request for the client.

This is not primarily a client bug. It's the server that only offers basic auth. Once it offers more, that's easy to support for us. Please file a respective bug in the core component.

But what do you mean by "if we decide to pick anything into "our" Qt for the owncloud client"?

For Windows, we keep patches on top of Qt and build it ourselves, so we can be flexible.

[smidt]

Ok, i opened an issue at owncloud/core#10682

[dragotin]

pushed out to at least 2.4.0

[Zombie-Ryushu]

Another up vote for GSSAPI based Kerberos Authentication. It should be coded such that both the Desktop Sync Client, and FireFox with support, can use GSSAPI Kerberos.

[butonic]

Some terminology: ADFS 2.0 (and 3.0) supports multiple authentication types:

1. Integrated Windows authentication (IWA) - can utilize Kerberos or NTLM authentication. You should always prefer Kerberos authentication over NTLM and configure the appropriate service principal name (SPN) for the AD FS 2.0 service account so that Kerberos can be used. Credential collection can happen in two ways depending on how your browser is configured:
   1. automatic logon with current user name and password - used when AD FS 2.0 URL is in IE Intranet Zone or another IE Zone which is configured to automatically logon with current user name and password
   2. Browser-based HTTP 401 authentication prompt - used when credentials cannot be automatically supplied to the 401 challenge for credentials
2. Forms-based authentication (FBA) - A forms-based .aspx page is presented to the user containing username and password fields. This page is fully customizable so that you can add new sign-in logic or page customizations (logos, style sheet, etc.)
3. Transport layer security client authentication - a.k.a. Client certificate authentication or Smart Card authentication. The credential is supplied by selecting an appropriate client authentication certificate.
4. Basic authentication - The web browser displays a credential prompt and the credentials supplied are sent across the network. The advantage of Basic authentication is that it is part of the Hypertext Transfer Protocol (HTTP) specification, and is supported by most browsers. [...]

Currently, the desktop client only supports FBA and Basic authentication (correct me if I am wrong). In ADFS scenarios this requires adding "Gecko" to the list of WIA supported user agents.

With 9.1 the server supports 2FA and AFAIK the plan is to always use a browser based login for all clients (desktop and mobile) to aquire a device specific token.

Since the client will always open a browser window additional authentication types remain an important feature. Actuall, looking at the above list of authentication types there are two tasks:

• [ ] support WIA in the form of
  1. Kerberos (Requested by Default in ADFS scenarios), requires upstream support by qt or
  2. NTLM (less secure)
• [ ] client certificates, tracked in https://github.com/owncloud/client/issues/69

@guruz what type exists in the branch mentioned in https://github.com/owncloud/client/issues/2111#issuecomment-53543982 @danimo what is the status of NTLM? I only found http://doc.qt.io/qt-5/qauthenticator.html#ntlm-version-2 Doesn't that mean we can support IWA via NTLMv2? Debugging ADFS and mod_shib reveals that ADFS will request Kerberos auth by sending the WWW-Authenticate: Negotiate header. I never saw WWW-Authenticate: NTLM :( Answering myself ... we kind of need kerberos: https://community.dynamics.com/crm/f/117/t/165603 Also https://codereview.qt-project.org/#/c/91285/ has been merged.

[guruz]

About NTLM Qt side: https://codereview.qt-project.org/#/c/91285/ was a fix for proxy authorization. Web server auth (Your WWW-Authenticate) should already work?

NTLM server side: Just googled https://gist.github.com/JosefJezek/5748211 by @JosefJezek

Kerberos Qt side: Yeah I guess we'd need https://bugreports.qt.io/browse/QTBUG-1538 .. (@peter-ha and @richmoore might know more

About Kerberos server side: This might be an interesting comment for the server side: https://github.com/owncloud/core/issues/10682#issuecomment-226495676 (not sure if this can integrate with Windows, maybe via Samba?).

FYI @ChristophWurst about 2factor comments.

[Zombie-Ryushu]

Kerberos is a tiny bit complicated with Apache, FireFox, Samba, and Linux. In the past, Kerberos has been a stand in for Negotiate Authentication for Apache and FireFox. As long as DNS was working right, you could use MIT or Heimdal Kerberos to use Negotiate Authentication in place of Basic Authentication. It was actually Apache and FireFox doing the Authentication, and passing the results on to whatever Nagios/eGroupware/OwnCloud wanted. In FireFox, the server had to be listed as a Trusted URI.

This broke the typical Forms based Login page these applications normally used. If the Kerberos Authentication failed, the server could deny Authentication completely, or fall back to Basic Authentication, it couldn't route back to Forms based Auth.

with Samba 4.x, Samba 4.x is just a Heimdal Kerberos KDC to Apache and FireFox. Treat it accordingly.

[ogoffart]

We have upgraded version of Qt now, maybe this should work. Please re-open if this still does not work with recent version of the client and and this is still something we need.

[michaelstingl]

With OAuth 2.0, only the default web browser needs to support Kerberos. Clients are authorised using OAuth 2.0.