Infrastructure at your Service

Morgan Patou

Configure a Kerberos Client and Alfresco as a Kerberized application

In the previous blog, I described How to install and manage a Kerberos Server but that’s useless if there are no clients and if no application have been kerberized! That’s why in this blog I will explain in the first part how to install a kerberos client in linux. The second part will be dedicated to the configuration of a browser to use Kerberos tickets and the last part will explain how to configure a popular application to use the newly created Kerberos MIT KDC. This application is Alfresco (leader in Open Source solutions for Electronic Content Management).

For this blog, let’s define the following properties/variables:

  • example.com = the DNS Domain
  • EXAMPLE.COM = the KDC REALM
  • kdc01oel.example.com = the FQDN of the KDC
  • mpatou@EXAMPLE.COM = the principal of a test user
  • alf01.example.com = the FQDN of the Alfresco host server

All configurations below have been tested on our infrastructure.

1. Install MIT Kerberos Client

On this part, I will only present how to install a Linux Client. I think the Mac release is available as part of the Mac OS X since version 10.3 (the current release is Mavericks: 10.9) and so there is nothing to do to install a Kerberos client but this installation isn’t configured. The Windows installation is quite easy if you use the installer but this isn’t a perfect solution. I think the best solution for windows would be to use the Windows implementation of Kerberos to configure the connection to a Linux KDC but this is a little bit more complex and I personally have troubles to configure that…

So, all steps to install a Linux client are quite the same as those to install a Kerberos Server. Indeed, there is no specific source code for the client and so the basic installation is the same but it’s not the case for the configuration.

Obviously, the first thing to do is to download the current release of the MIT Kerberos distribution for the target operating system. This could be done at the following URL: http://web.mit.edu/kerberos/dist/index.html. The current Linux release is krb5-1.12.1-signed.tar:

# wget  http://web.mit.edu/kerberos/dist/krb5/1.12/krb5-1.12.1-signed.tar
    --2014-04-01 14:00:28--  http://web.mit.edu/kerberos/dist/krb5/1.12/krb5-1.12.1-signed.tar
    Resolving web.mit.edu... 23.58.214.151
    Connecting to web.mit.edu|23.58.214.151|:80... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 11950080 (11M) [application/x-tar]
    Saving to: “krb5-1.12.1-signed.tar”
    100%[===============================================>] 11,950,080  1.52M/s   in 7.3s
    2014-04-01 14:00:38 (1.56 MB/s) - “krb5-1.12.1-signed.tar” saved [11950080/11950080]
# tar  -xvf krb5-1.12.1-signed.tar 
    krb5-1.12.1.tar.gz
    krb5-1.12.1.tar.gz.asc

As you can see, this file is signed and you could (should) verify the integrity and identity of the software. This can be done, for example, using GNU Privacy Guard:

# gpg  --verify  krb5-1.12.1.tar.gz.asc

After that, just extract the MIT Kerberos source code:

# tar  -zxf  krb5-1.12.1.tar.gz
# cd  krb5-1.12.1/src/
# ./configure
    ......
# yum  install  *yacc*
    ......
# make
    ......
# make  install

 

At this step, Kerberos should be installed properly and the binaries, libraries and the documentation should be under /usr/local. The default location is sufficient for a client installation:

# krb5-config  --all
    Version:     Kerberos 5 release 1.12.1
    Vendor:      Massachusetts Institute of Technology
    Prefix:      /usr/local
    Exec_prefix: /usr/local

To set up a linux client, there is only one step remaining: tell Kerberos where to find a KDC. This is done through a configuration file named krb5.conf. In the following configuration, I’ve included two lines (forwardable and proxiable) that are important for Alfresco SSO using Kerberos to work properly. These two lines aren’t mandatory for other kerberized applications:

# vi  /etc/krb5.conf
    [libdefaults]
        default_realm = EXAMPLE.COM
        forwardable = true                            {Line only important for Alfresco}
        proxiable = true                              {Line only important for Alfresco}
    [realms]
        EXAMPLE.COM = {
            kdc = kdc01oel.example.com:88
            admin_server = kdc01oel.example.com:749
            default_domain = example.com
      }
    [domain_realm]
        .example.com = EXAMPLE.COM
        example.com = EXAMPLE.COM

That should be enough to obtain a ticket for the test user (“kinit mpatou” OR “kinit mpatou@EXAMPLE.COM”) and delete this ticket:

# klist
    klist: Credentials cache file '/tmp/krb5cc_0' not found
# kinit  mpatou
    Password for mpatou@EXAMPLE.COM:
# klist
    Ticket cache: FILE:/tmp/krb5cc_0
    Default principal: mpatou@EXAMPLE.COM
    Valid starting               Expires               Service principal
    05/20/2014 10:54:48     05/20/2014 20:54:48     krbtgt/mpatou@EXAMPLE.COM
    renew until 05/21/2014 10:54:47
# kdestroy
# klist
    klist: Credentials cache file '/tmp/krb5cc_0' not found

2. Configure the Browser

Now the client should be able to acquire the first ticket (TGT) but that’s not enough! The next step is to configure the Browser to use tickets. Indeed, if the client tries to access to a kerberized application, the browser has to present a ticket for that application to be logged in automatically.

a. Mozilla Firefox (Window/Linux/Mac)

Open a new window/tab in Mozilla Firefox:

  • Enter in the URL field “about:config”
  • All properties of Firefox should be displayed
  • Search for “network.negotiate” and set: network.negotiate-auth.delegation-uris = .EXAMPLE.COM
  • Set: network.negotiate-auth.trusted-uris = .EXAMPLE.COM

b. Google Chrome

i. Mac

Modify the Google Chrome application with:

open 'Google Chrome.app' --args --auth-schemes="basic,digest,ntlm,negotiate" --auth-server-whitelist="*EXAMPLE.COM" --auth-negotiate-delegate-whitelist="*EXAMPLE.COM"

 

ii. Linux

Modify Google Chrome with:

google-chrome --enable-plugins --args --auth-server-whitelist="*EXAMPLE.COM" --auth-negotiate-delegate-whitelist="*EXAMPLE.COM" --auth-schemes="basic,digest,ntlm,negotiate"

iii. Windows

Modify the Google Chrome shortcut with:

chrome.exe --auth-schemes="basic,digest,ntlm,negotiate" --auth-server-whitelist="*EXAMPLE.COM" --auth-negotiate-delegate-whitelist="*EXAMPLE.COM"

c. Internet Explorer

Open a new window/tab in Internet Explorer and:

  • Open the “tools” (ALT+X)
  • Click on “internet options” (o)
  • Choose the “Advanced” tab
  • In the security section, select the “Enable Integrated Windows Authentication*”
  • Choose the “Security” tab
  • Select “Local intranet”
  • Click on “Sites”
  • Click on “Advanced”
  • Add “http://*.example.com” or/and “https://*.example.com”
  • Click on “Close”
  • Click on “OK”
  • Click on “OK”
  • Restart the computer

If everything works fine, then the client should be able to access to kerberized applications. If it’s not the case, a good start to debug the kerberos installation is to use a network analyzer like WireShark.

3. Configure Alfresco to use Kerberos SSO

Actual test configuration:

  • OS: Oracle Enterprise Linux 6
  • Alfresco: Alfresco Community Enterprise 4.2.c installed on /opt/alfresco
  • Application Server: Tomcat 7

So let’s begin the configuration of a Kerberized application with Alfresco. The first thing to know about Alfresco is that Alfresco uses two main Web Clients: Alfresco Explorer and Alfresco Share. The first one is the core of Alfresco and the second one is the new interface (mainly oriented on collaboration) that uses a proxy to ask Explorer to do the job. The configuration of Alfresco Explorer is quite easy but to get Alfresco Share working it’s not the same as Share add a new layer above Explorer.

If nothing is specified, all modifications below should be done on alf01.example.com, the Alfresco host server.

For Kerberos to work properly, the maxHttpHeaderSize must be increased:

# vi  /opt/alfresco/alfresco-4.2.c/tomcat/conf/server.xml
   Connector port="8080" URIEncoding="UTF-8" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxHttpHeaderSize="32768"

Then the authentication chain must allow Kerberos tickets to be used to authenticate a user:

# vi  /opt/alfresco/alfresco-4.2.c/tomcat/shared/classes/alfresco-global.properties:
    authentication.chain=kerberos1:kerberos,alfrescoNtlm1:alfrescoNtlm

After that, the Kerberos subsystem must be configured:

# cd  /opt/alfresco/alfresco-4.2.c/tomcat/shared/classes/alfresco/extension/subsystems
# vi  Authentication/kerberos/kerberos1/kerberos-authentication.properties
    kerberos.authentication.realm=EXAMPLE.COM
    kerberos.authentication.sso.enabled=true
    kerberos.authentication.authenticateCIFS=false
    kerberos.authentication.user.configEntryName=Alfresco
    kerberos.authentication.cifs.password=ChangeMe
    kerberos.authentication.cifs.configEntryName=AlfrescoCIFS
    kerberos.authentication.stripUsernameSuffix=true
    kerberos.authentication.http.password=ChangeMe
    kerberos.authentication.http.configEntryName=AlfrescoHTTP
    kerberos.authentication.defaultAdministratorUserNames=admin,xxx,yyy
    kerberos.authentication.browser.ticketLogons=true

 

Once this is done, the KDC must be configured to recognize Alfresco as a Kerberized application. For that purpose, enter in the KDC kadmin interface. Caution, this requires the installation of a Kerberos Server on kdc01oel.example.com as described in the previous blog (the important part is that kadmin must be available from a remote computer) and the installation of a Kerberos Client on alf01.example.com. If your kadmin doesn’t work from a remote location, you will have to use the kadmin.local interface on the KDC host server.

# /usr/local/bin/kadmin
    addprinc  cifs/alf01.example.com@EXAMPLE.COM
    addprinc  HTTP/alf01.example.com@EXAMPLE.COM
    ktadd  -k  /etc/krb5cifs.keytab  cifs/alf01.example.com@EXAMPLE.COM
    ktadd  -k  /etc/krb5http.keytab  HTTP/alf01.example.com@EXAMPLE.COM

This will create 2 files named ‘krb5cifs.keytab’ and ‘krb5http.keytab’ on the host where the kadmin was run. That means that if you used the kadmin from alf01.example.com, then there is nothing more to do but if you used the kadmin or kadmin.local from kdc01oel.example.com, then those 2 files must be moved to alf01.example.com:

# cd  /etc
# scp  krb5cifs.keytab  root@alf01.example.com:/etc
enter password:
# scp  krb5http.keytab  root@alf01.example.com:/etc
enter password:

Create or update the config file for the Java Security. Be careful that this is the Java used by Alfresco:

# vi  /opt/alfresco/alfresco-4.2.c/java/jre/lib/security/java.login.config:
    Alfresco {
        com.sun.security.auth.module.Krb5LoginModule sufficient;
    };
    AlfrescoCIFS {
        com.sun.security.auth.module.Krb5LoginModule required
        storeKey=true
        useKeyTab=true
        keyTab="/etc/krb5cifs.keytab"
        principal="cifs/alf01.example.com";
    };
    AlfrescoHTTP {
        com.sun.security.auth.module.Krb5LoginModule required
        storeKey=true
        useKeyTab=true
        keyTab="/etc/krb5http.keytab"
        principal="HTTP/alf01.example.com";
    };
    ShareHTTP {
        com.sun.security.auth.module.Krb5LoginModule required
        storeKey=true
        useKeyTab=true
        keyTab="/etc/krb5http.keytab"
        principal="HTTP/alf01.example.com";
    };
    com.sun.net.ssl.client {
        com.sun.security.auth.module.Krb5LoginModule sufficient;
    };
    other {
        com.sun.security.auth.module.Krb5LoginModule sufficient;
    };

Configure the default Java Security to use our custom configuration by adding a line at the end of the file:

# vi  /opt/alfresco/alfresco-4.2.c/java/jre/lib/security/java.security:
    login.config.url.1=file:${java.home}/lib/security/java.login.config

Finally, update the share-config-custom.xml file to contain the Kerberos configuration (the three images are in a unique file attached in this blog -> share-config-custom.zip):

# vi /opt/alfresco/alfresco-4.2.c/tomcat/shared/classes/alfresco/web-extension/share-config-custom.xml

ShareCustom1.pngShareCustom2.pngShareCustom3.png

That could be enough to get the Kerberos SSO working for Alfresco Explorer and Alfresco Share. I think there are some additional steps to get the Alfresco CIFS working too but I’m not sure. Moreover, it’s possible that you get some strange exceptions that prevent Alfresco to authenticate your Kerberos Ticket. That probably comes from the Java Cryptography Extension that is missing on your Alfresco server. For that purpose, download the JCE corresponding to the Java version used by Alfresco (JCE6 or JCE7) and deploy it (I assume below that the JCE7 is under /opt):

# unzip  /opt/UnlimitedJCEPolicyJDK7.zip
# cd  /opt/alfresco/alfresco-4.2.c/java/jre/lib/security
# cp  local_policy.jar  local_policy.jar.orig
# cp  US_export_policy.jar  US_export_policy.jar.orig
# cd  /opt/UnlimitedJCEPolicy
# cp  local_policy.jar  /opt/alfresco/alfresco-4.2.c/java/jre/lib/security/
# cp  US_export_policy.jar  /opt/alfresco/alfresco-4.2.c/java/jre/lib/security/

I hope I was clear enough in my explanations and I hope I was able to share (a little bit?) my passion for open source solutions!
Good luck with Kerberos and Alfresco!

 

Leave a Reply


+ 2 = six

Morgan Patou
Morgan Patou

Senior Consultant