Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
Some situations exhibit limitations of the Alfresco 'kerberos' authentication subsystem.
The most frequent problems are caused by the need of Share to use kerberos delegation. Kerberos delegation is a known issue when clients are Mac Mavericks machines, see MNT-12087.
This wiki page provides a solution that will work each time an Alfresco kerberos setup works when accessing the platform or Explorer, but fails when accessing Share (assuming the Share configuration itself is correct).
This solution relies on the 'external' authentication subsystem: the kerberos negotiation is left to an extra piece of software: an apache proxy with mod_auth_kerb. What is nice with this solution, is that it removes any asymmetry between Share and Explorer: both paths are seen by the client as two kerberos protected application, where no delegation is needed.
CIFS will not work: authentication will not be possible as apache is an HTTP proxy, and cannot be a CIFS proxy.
FTP will work if you put as second element in the authentication.chain an 'ldap-ad' authentication subsystem that point to the same AD.
When the 'kerberos' authentication subsystem is used, kerberos tickets hitting Share need to be forwarded to the Alfresco backend. kerberos tickets thus need to have the kerberos forwardable flag to true, and the service users for the HTTP spn (Service Principal Name) need to allow delegation, see picture below.
On the other hand, when using the 'external' subsystem and relying on an apache proxy with mod_auth_kerb to negociate kerberos, we remove the asymmetry between Alfresco and Share: there is no difference from the point of view of kerberos between an HTTP call to Explorer and an HTTP call to Share: the Active Directory server (noted AD in the diagram below) always recives direct decryption requests from the proxy: no delegation is needed.
Decide what protocol will be used for the communication between the proxy and the backend layers:
you mainly have two possibilities: AJP or HTTP.
If you use AJP, the authenticated user username will be transmitted from the proxy to the back ends in the REMOTE_USER CGI variable.
If you use HTTP, the authenticated user username will be transmitted from the proxy to the back ends in a custom HTTP header.
From now on, we assume you use AJP.
Configure the proxy to redirect requests to Tomcat AJP port 8009.
Sample config would be:
<VirtualHost proxyajp.foo:80>
ServerName proxyajp.foo
ProxyRequests Off
ProxyPreserveHost On
ProxyPass /alfresco ajp://localhost:8009/alfresco
ProxyPassReverse /alfresco ajp://localhost:8009/alfresco
ProxyPassReverseCookiePath /alfresco /alfresco
ProxyPass /share ajp://localhost:8009/share
ProxyPassReverse /share ajp://localhost:8009/share
ProxyPassReverseCookiePath /share /share
</VirtualHost>
Modify the Virtualhost section above to require kerberos authentication, e.g
<Location />
AuthType Kerberos
AuthName 'Acme Corporation'
KrbMethodNegotiate on
KrbMethodK5Passwd off
Krb5Keytab /etc/apache2/http.keytab
</Location>
see http://modauthkerb.sourceforge.net/ for more information.
The keytabs are generated in a way similar to the one used when using the alfresco 'kerberos' module.
Set the option
tomcatAuthentication='false'
on the 8009 ajp connection in your tomcat server.xml
creating a file in webapps/alfresco/test.jsp that contains:
getRemoteUser() is set to:
and go to:
http://proxyajp.foo/alfresco/test.jsp
If you get SSO to that URL and you see your username displayed, then that means your proxy is configured correctly.
If you see Null, then you ned to check your proxy configuration before going to the next stepos.
set your authentication.chain to use the 'external' authentication subsystem:
authentication.chain=external1:external
`Note:` If you want to also import users from AD and/or make FTP authentication work, you could also append the ldap-ad subsystem, e.g:
authentication.chain=external1:external,ldap-ad1:ldap-ad
Leave the proxyUserName parameter black ascommunications from the proxies to the Alfresco backend do not use SSL client certificates (whihc requires HTTPS):
external.authentication.proxyUserName=
Follow the SSO instructions in share-config-custom.xml.
You can use alfrescoCookie or alfrescoHeader for the communication between Share and Alfresco.
Before 5.0, VTI sharepoint is provided by an embedded Jetty server. By default jetty does not support AJP.
You will need to add AJP support to Jetty and configure it, see
MNT-12476 and MNT-7135 in particular:
To be able to handle AJP protocol we need to configure vtiServerConnector in vti-context.xml to use org.mortbay.jetty.ajp.Ajp13SocketConnector
<bean id='vtiServerConnector' class='org.mortbay.jetty.ajp.Ajp13SocketConnector'>
<property name='port'>
<value>${vti.server.port}</value>
</property>
<property name='headerBufferSize'>
<value>8192</value>
</property>
</bean>
and also install
jetty-ajp-6.1.26.jar in your Alfresco JAR directory, see MNT-12476
The kerberos protocol itself is secure. You need to make sure however, that access to alfresco cannot be made bypassing the proxy. Enforcing connections through the proxy ca be achieved using firewall rules, i.e using iptables for instance when Alfresco runs on Linux.
Pseudo code for the firewall rules could be (assuming the proxy, the share and alfresco platform all run on the same linux box):
allow inbound HTTP connections to port 80 of the firewall
block inbound connections to port 8009 (AJP) and 8080 (HTTP) if they do not come from the loopback interface.
With this setup it becomes very easy to add SSL encryption the the whole system. Using mod_ssl, you can easily protect using SSL both Alfresco and Share.
The change is much less intrusive than relying on tomcat to do SSL encryption.