State of Kerberos SSO on NC14 with EL7 (Apache 2.4, mod_auth_gssapi)

[bluikko]

Steps to reproduce

Install new NextCloud 14 on RHEL/CentOS 7 and try to make Kerberos SSO work. This is with PHP 7.1 from the IUS repository. gssproxy was also used which is why there is no keytab configuration in mod_auth_gssapi configuration.

I open this issue in the hope that it could help others trying to make Kerberos SSO work with NC14; and also to summarize the problems listed in different open issues.
Hopefully this can inform other system administrators for what to expect if planning to deploy NC with Kerberos SSO.

It is unfortunate that the Kerberos SSO support on NC is at this state - currently many/most enterprises still rely on Kerberos SSO and have not yet moved on to SAML/AD FS. Some of the issues listed here may also exist on SAML SSO.

Expected behaviour

There are several issues with the current status of Kerberos SSO on NC14 that makes it an unattractive/cumbersome solution. Ideally NC could still be used for public/password protected downloads and could still allow users to login by entering their LDAP credentials when necessary.

Actual behaviour

Several issues were encountered:

• PHP 7.2 has no mcrypt, issue mcrypt not available anymore for PHP 7.2  #168.
• Documentation is non-existent, I based the setup on NC11 Administrator Manual and issue Nextcloud 12 (11) + Active Directory + SSO (Kerberos) #118, which I could not make work 100% either.
• I could not find a way to allow public downloads, the whole site is protected with Kerberos SSO.
• If Kerberos SSO is enabled, users likely need VPN and could not use plain LDAP login when accessing NC from a computer not joined to the domain, issue Can't login "normally" with SSO enabled #80.
• Using DAV from MS Office does not work, issue Kerberos SSO, WebDAV, Windows and MS Office #181.

Server configuration

• user_ldap is configured and tested as working before adding user_saml. User UUID is set to userPrincipalName in LDAP Expert configuration. The default LDAP filters are not very good for enterprise usage; for example disabled users are still allowed login. Filters used were:
  Users
  (&(objectclass=person)(&(primaryGroupID=513)(!(userAccountControl:1.2.840.113556.1.4.803:=2))))
  Login Attributes
  (&(&(objectclass=person)(&(primaryGroupID=513)(!(userAccountControl:1.2.840.113556.1.4.803:=2))(userPrincipalName=%uid))))
• user_saml settings:

    "apps": {
        "user_saml": {
            "enabled": "yes",
            "general-allow_multiple_user_back_ends": "1",
            "general-require_provisioned_account": "0",
            "general-uid_mapping": "REMOTE_USER",
            "installed_version": "1.6.2",
            "type": "environment-variable",
            "types": "authentication"
        }
    }

The only way I could make it work was to enable mod_auth_gssapi on location / - both locations mentioned in #118 /index.php/login and /index.php/apps/user_saml/saml/login did not work.
This obviously makes it impossible to share files with the public with a totally open share or with password protection and is a show-stopper for me at least.

Relevant Apache configuration:

    <Directory /var/www/nextcloud/>
        Options +FollowSymlinks
        AllowOverride All
        SetEnv HOME /var/www/nextcloud
        SetEnv HTTP_HOME /var/www/nextcloud
    </Directory>
    <Location />
        AuthType                GSSAPI
        AuthName                "Login"
        GssapiAllowedMech       krb5
        GssapiNegotiateOnce     On
        GssapiSSLonly           On
        require                 valid-user
    </Location>

Operating system: EL7

Web server: Apache 2.4

Database: MySQL

PHP version: 7.1

Nextcloud version: 14.0.0.19

Where did you install Nextcloud from: .tar.bz2

Edit: several improvements on language used.

[lexeyka]

You do not need to protect the "global" location with Apache. Roughly speaking, the nextcloud has its own access control system. user_saml module extends it, allowing the use of additional tools for authentication.
Specify the protection of the location "/nextcloud/index.php/apps/user_saml/saml/login":

<Location "/nextcloud/index.php/apps/user_saml/saml/login">
    AuthType                GSSAPI
    AuthName                "Login"
    GssapiAllowedMech       krb5
    GssapiNegotiateOnce     On
    GssapiSSLonly           On
    require                 valid-user
</Location>

After receiving information about the authenticated user and creating a session, the nextcloud will perform further actions on access control (including public links and DAV) on its own.

[bluikko]

Sure, I understand that - but I did not get that Location to work on NC14. Only using root for Location worked, the suggested Location always complained about user not provisioned.

[lexeyka]

Very strange - I use a similar scheme and it works.
The only problem was the need to normalize login-name. I use the ldap backend to load the list of users and their attributes (just like you, I see). The problem is that the ActiveDirectory kerberos (and accordingly gssapi module) returns the user name in lowercase (in the form "user" after stripping REALM), and LDAP return uid attribute (sAMAccountName in my case) in the uppercase.
For nextcloud - these are different users and the problem "user not provisioned" got out of here.
I solved it using the lookup_identity apache module. The module gets the ldap attribute sAMAccountName, corresponding to user from gssapi, and assigns its value to the variable REMOTE_USER_SAMACCOUNTNAME:

    <IfModule mod_auth_gssapi.c>
        AuthType GSSAPI
        AuthName "GSSAPI Single Sign On Login"

        GssapiAllowedMech krb5
        GssapiLocalName On
        GssapiCredStore keytab:/etc/httpd/conf.d/HTTP.keytab
        GssapiUseSessions On
        GssapiNegotiateOnce On
        LookupUserAttr sAMAccountName REMOTE_USER_SAMACCOUNTNAME " "
        Require valid-user
    </IfModule>

Further in the module user_saml, it is used for authentication:

"user_saml": {
    "enabled": "yes",
    "general-require_provisioned_account": "1",
    "general-uid_mapping": "REMOTE_USER_SAMACCOUNTNAME",
    "installed_version": "2.1.0",
    "type": "environment-variable",
    "types": "authentication"
},

In short - regardless of the authentication module on the web server, do a normalization of the login-name of apache user, using the same attribute, as used in backend module on the nextcloud.

[lexeyka]

The only difficulty is that the module mod_lookup_identity works through sssd and additional configuration of sssd on the web server is needed.
Initially, look at the web-server and nextcloud logs to make sure that the problem is relevant to you.
Since the problem disappears when replacing a location with a global one - apparently this is not your case...
Sorry, did not think immediately ...

[bluikko]

I am familiar with mod_lookup_identity. The lookup cannot be the issue since NC recognizes the user with just a different Location in Apache configuration.

In any case this is just one of the issues - in the end we decided to drop NC due to the combination of multiple issues and may revisit the version 15 or wait until the SSO support is better.

[mumazin]

Hi
I am working with nextcloud for a while and I can't integrate it with SSO kerberos authentication using FreeIPA. I searched all the tutorials for this issue and all the blogs that tells its possible to make it works.
for me the ldap works fine but the kerberos not working although I can get a kerberos ticket but nextcloud unauthorized and it shows me
// Unauthorized
This server could not verify that you are authorized to access the document requested. Either you supplied the wrong credentials (e.g., bad password), or your browser doesn't understand how to supply the credentials required.
//
my config is Environment variable and REMOTE_USER as mentioned in all documents. and in the apache I used both the kerberos and the gssapi as below
krb method
I used the location for both "nextcloud/index.php/apps/user_saml/saml/login" and "/nextcloud/login" separately

##<Location "nextcloud/index.php/apps/user_saml/saml/login" >
#<Location /nextcloud/login >
#    AuthType Kerberos
#    AuthName "NAME"
#    KrbServiceName HTTP
#    KrbMethodNegotiate On
#    KrbMethodK5Passwd Off
#    KrbSaveCredentials Off
#    KrbVerifyKDC On
#    KrbAuthRealms REALM
#    Krb5KeyTab /etc/httpd/nextc.keytab 
#    Require valid-user
#</Location>

and for gssapi I used

<Location "/nextcloud/index.php/apps/user_saml/saml/login" >
 AuthType                GSSAPI
 AuthName                "Login"
 GssapiAllowedMech       krb5
 GssapiLocalName On
 GssapiCredStore keytab:/etc/httpd/conf.d/HTTP.keytab
 GssapiUseSessions On
 GssapiNegotiateOnce     On
 require                 valid-user
</Location>

[gno65]

Maybe a little late but I had the same problem.
If you have configured pretty url (no index.php in url) then it works only with

<Location "/">

That's not what you want. So you have to disable pretty url:
Remove 'htaccess.RewriteBase' => '/' from your /var/www/nextcloud/config/config.php

Then update .htaccess file with

occ maintenance:update:htaccess
systemctl restart apache2

change Location to

<Location "/index.php/apps/user_saml/saml/login" >

Now login should work

see also #415

[nikolaevan-rg]

Maybe a little late but I had the same problem. If you have configured pretty url (no index.php in url) then it works only with

<Location "/">

That's not what you want. So you have to disable pretty url: Remove 'htaccess.RewriteBase' => '/' from your /var/www/nextcloud/config/config.php

Then update .htaccess file with

occ maintenance:update:htaccess
systemctl restart apache2

change Location to

<Location "/index.php/apps/user_saml/saml/login" >

Now login should work

see also #415

Thanks a lot. It work's for me.
I had a problem with SSO in conjunction with Collabora
After I fixed the location to <Location /index.php/apps/user_saml/saml/login > (without quotes) in my site.conf file of webserver Apache2, everything worked fine.
Thanks again.