03-15-2023 06:02 AM
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
03-23-2023 03:48 PM
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
03-23-2023 03:48 PM
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
Explore our Alfresco products with the links below. Use labels to filter content by product module.