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

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 #168.
• Documentation is non-existent, I based the setup on NC11 Administrator Manual and issue #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 #80.
• Using DAV from MS Office does not work, issue #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.

Start by reviewing the Apache / Location configuration and the user_saml settings shown in the issue, then reproduce the setup on EL7 with Apache 2.4 and PHP 7.1. Check each reported behavior, including public downloads, LDAP login fallback, and DAV access; done would require a clearly defined supported behavior or corresponding documentation.