ACS 7.3 + Kerberos. SSO Authentication for Share stops working every night

[s_palyukh]

Hello community,

we have encountered really odd behaviour from Alfresco Community 7.3 with Kerberos SSO configured and need your help!

Actually, Kerberos SSO works, so when a user logs into Windows he gets access to the Alfresco without a need to enter credentials.

BUT,  SSO stops working for the Alfresco Share interface every night... We still can access /alfresco/aos or /alfresco/webdav, however not Alfresco Share... SSO gets back to work after a simple restart of tomcat.

The log isn't really helpful, there are only a few records there:

2023-03-15 09:29:16,715  DEBUG [repo.webdav.WebDAVSessionListener] [http-nio-8080-exec-7] Session created FF5BC6CCD11CE7B798F41F76284BC6F6
2023-03-15 09:29:16,716  DEBUG [app.servlet.KerberosAuthenticationFilter] [http-nio-8080-exec-7] Non-WebDAV request, don't fallback
2023-03-15 09:29:16,739  WARN  [site.servlet.KerberosSessionSetupPrivilegedAction] [http-nio-8080-exec-5] credentials can not be delegated!

Has anyone faced such an issue before? Could you please share any ideas of what can be wrong?

Here are additional details about the server:

Installation method: from ZIP
Java version - openjdk 17.0.6
Tomcat - 9.0.73
ACS - 7.3

1. krb5.conf (real domain replaced with DOMAIN.COM)

[logging]
kdc = FILE:/var/log/kdc.log
kdc = SYSLOG:INFO:DAEMON
admin_server = FILE:/var/log/kadmin.log

[libdefaults]
default_realm = DOMAIN.COM
default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac

#forwardable = true
#proxiable = true
allow_weak_crypto = true

[realms]
DOMAIN.COM = {
kdc = 192.168.1.13
admin_server = 192.168.1.13
}
[domain_realm]
adsrv.domain.com = DOMAIN.COM
.adsrv.domain.com = DOMAIN.COM

2. java.login.config (real principal is replaced with alfresco.domain.com@DOMAIN.COM)

Alfresco {
    com.sun.security.auth.module.Krb5LoginModule sufficient;
};

AlfrescoHTTP {
    com.sun.security.auth.module.Krb5LoginModule required
    storeKey=true
    useKeyTab=true
    doNotPrompt=true
    keyTab="/etc/kerberos/alfresco/http_v2.keytab"
    principal="HTTP/alfresco.domain.com@DOMAIN.COM";
};

ShareHTTP {
    com.sun.security.auth.module.Krb5LoginModule required
    storeKey=true
    useKeyTab=true
    doNotPrompt=true
    keyTab="/etc/kerberos/alfresco/http_v2.keytab"
    principal="HTTP/alfresco.domain.com@DOMAIN.COM";
};

com.sun.net.ssl.client {
    com.sun.security.auth.module.Krb5LoginModule sufficient;
};

other {
    com.sun.security.auth.module.Krb5LoginModule sufficient;
};

3. share-config-custom.xml

 ...
   <config evaluator="string-compare" condition="Kerberos" replace="true">
      <kerberos>
      
         <password>RealPasswordHere!157</password>

         <realm>DOMAIN.COM</realm>
         <endpoint-spn>HTTP/alfresco.domain.com@DOMAIN.COM</endpoint-spn>
         <config-entry>ShareHTTP</config-entry>
         <stripUserNameSuffix>true</stripUserNameSuffix>
      </kerberos>
   </config>

<config evaluator="string-compare" condition="Remote">
        <remote>
            <endpoint>
                <id>alfresco-noauth</id>
                <name>Alfresco - unauthenticated access</name>
                <description>Access to Alfresco Repository WebScripts that do not require authentication</description>
                <connector-id>alfresco</connector-id>
                <endpoint-url>http://localhost:8080/alfresco/s</endpoint-url>
                <identity>none</identity>
            </endpoint>

            <endpoint>
                <id>alfresco</id>
                <name>Alfresco - user access</name>
                <description>Access to Alfresco Repository WebScripts that require user authentication</description>
                <connector-id>alfresco</connector-id>
                <endpoint-url>http://localhost:8080/alfresco/s</endpoint-url>
                <identity>user</identity>
            </endpoint>

            <endpoint>
                <id>alfresco-feed</id>
                <parent-id>alfresco</parent-id>
                <name>Alfresco Feed</name>
                <description>Alfresco Feed - supports basic HTTP authentication via the EndPointProxyServlet</description>
                <connector-id>alfrescoHeader</connector-id>
                <endpoint-url>http://localhost:8080/alfresco/wcs</endpoint-url>
                <identity>user</identity>
                <external-auth>true</external-auth>
            </endpoint>


            <endpoint>
                <id>activiti-admin</id>
                <name>Activiti Admin UI - user access</name>
                <description>Access to Activiti Admin UI, that requires user authentication</description>
                <connector-id>activiti-admin-connector</connector-id>
                <endpoint-url>http://localhost:8080/alfresco/activiti-admin</endpoint-url>
                <identity>user</identity>
            </endpoint>

            <endpoint>
                <id>alfresco-api</id>
                <parent-id>alfresco</parent-id>
                <name>Alfresco Public API - user access</name>
                <description>Access to Alfresco Repository Public API that require user authentication.
                    This makes use of the authentication that is provided by parent 'alfresco' endpoint.</description>
                <connector-id>alfresco</connector-id>
                <endpoint-url>http://localhost:8080/alfresco/api</endpoint-url>
                <identity>user</identity>
            </endpoint>

        </remote>
    </config>


  <config evaluator="string-compare" condition="Remote">
        <remote>
            <keystore>
                <path>alfresco/web-extension/alfresco-system.p12</path>
                <type>pkcs12</type>
                <password>alfresco-system</password>
            </keystore>

            <connector>
                <id>alfrescoCookie</id>
                <name>Alfresco Connector</name>
                <description>Connects to an Alfresco instance using cookie-based authentication</description>
                <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
            </connector>

            <connector>
                <id>alfrescoHeader</id>
                <name>Alfresco Connector</name>
                <description>Connects to an Alfresco instance using header and cookie-based authentication</description>
                <class>org.alfresco.web.site.servlet.SlingshotAlfrescoConnector</class>
                <userHeader>SsoUserHeader</userHeader>
            </connector>

            <endpoint>
                <id>alfresco</id>
                <name>Alfresco - user access</name>
                <description>Access to Alfresco Repository WebScripts that require user authentication</description>
                <connector-id>alfrescoCookie</connector-id>
                <endpoint-url>http://localhost:8080/alfresco/wcs</endpoint-url>
                <identity>user</identity>
                <external-auth>true</external-auth>
            </endpoint>
        </remote>
    </config>
...

Any ideas or help is really appreciated!

Thanks in advance

[s_palyukh · Accepted solution]

The reason for that weird behaviour was missing "ok_as_delegate" flag in the Kerberos ticket.

The missing "ok_as_delegate" flag in the Kerberos ticket can cause issues with Single Sign-On (SSO) in some scenarios, particularly when a service needs to delegate user authentication to another service.

To include the "ok_as_delegate" flag in the Kerberos ticket, you should ensure that the necessary configuration is in place on both the client and server sides:

On the Active Directory server  you need to configure the Service Principal Name (SPN) for the HTTP service to allow delegation. You can do this using the Active Directory Users and Computers management tool:

a. Locate the service account that has the SPN registered (e.g., HTTP/your domain).
b. Open the Properties dialog for the service account.
c. Go to the Delegation tab.
d. Choose "Trust this user for delegation to any service (Kerberos only)" or "Trust this user for delegation to specified services only" and add the appropriate services.
e. Save the changes.

On the client side, you may need to adjust the Group Policy settings to allow Kerberos delegation. The relevant setting can be found under Computer Configuration > Administrative Templates > System > Kerberos. Make sure that the "Allow delegating fresh credentials" and/or "Allow delegating fresh credentials with NTLM-only server authentication" settings include the appropriate Service Principal Names (SPNs) for the services involved.
After making these changes, we should test the SSO functionality again with Microsoft Office applications. If the issue persists, further investigation and troubleshooting might be needed to identify the root cause.

When I mentioned the "client side," I was referring to the user's computer or workstation where the Microsoft Office applications are being used to access the WebDAV server.

Hope it will help someone