Another Stranger Me

my comments, my projects, my resources…

Afresco integration with Active Directory using Kerberos

After the first article about Alfresco’s integration with Active Directory has spurred a lot of interest I’ve decided to write a follow up article that shows how to use Kerberos for authentication. I’ll divide the article in three main parts:

  1. Description of Kerberos authentication process
  2. Setting up requirements for Kerberos implementation
  3. Alfresco configuration parameters for Kerberos

Kerberos authentication process

In the simplest terms, the Kerberos authentication process works by checking and passing credentials between clients and servers. When a user logs on to a Windows domain, Windows locates an Active Directory server and Kerberos authentication service, and delivers the client’s credentials to the Kerberos service. The client is authenticated by means of a password that is used to derive a key that can be verified by the server. After checking the client’s authentication information, a Kerberos service, called the Key Distribution Service (KDC), issues a ticket-granting ticket (TGT) to the user, which is then used to identify the client as it requests subsequent Kerberos tickets for logging on to network resources. (Using a TGT reduces the number of times the KDC has to look up client information.)

kerberos authentication process alfresco

Client then presents the TGT ticket to KDC and requests session ticket for a particular network resource, in our case Alfresco application. Client then presents session ticket to application server at connection setup which in turns verifies received ticket and grants or denies access to application.

Setting up Kerberos

First step in enabling Alfresco to use Kerberos authentication is to set up accounts under Active Directory for use by Alfresco.
1. Create a user account for the Alfresco web application SSO using the Active Directory Users and Computers application and give it the full name like “Alfresco HTTP” and username “alfrescohttp”.

2. Do the same for the Alfresco CIFS server and create the user account with the full name like “Alfresco CIFS” and username “alfrescocifs”.

Make sure both accounts have the following attributes set:

  • Enabled Password never expires
  • Disabled User must change password at next logon
  • Use DES encryption types for this account
  • Do not require Kerberos preauthentication

3. Use the ktpass utility to generate key tables for the Alfresco CIFS and web server. The ktpass utility is a free download from the Microsoft site, and is also part of the Win2003 Resource Kit. The ktpass command can only be run from the domain controller.

ktpass -princ cifs/<cifs-server-name>.<domain>@<realm> -pass <password> -mapuser <domainnetbios>\alfrescocifs -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -out c:\temp\alfrescocifs.keytab

ktpass -princ HTTP/<web-server-name>.<domain>@<realm> -pass <password> -mapuser <domainnetbios>\alfrescohttp -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -out c:\temp\alfrescohttp.keytab


  • The principal should be specified using the server name and domain in lowercase with the realm in uppercase. The service types should match cifs and HTTP. For example, cifs/
  • The realm should be the domain upper cased; an example is if the domain is then the realm should be ALFRESCO.ORG.
  • <web-server-name> is the host name that is running the Alfresco server.
  • <cifs-server-name> is the NetBIOS name of the Alfresco CIFS server when running on an Active Directory client or the host name for a client that is not an Active Directory client, that is, not logged onto the domain.
  • <domain> is the DNS domain, for example
  • <domainnetbios> is the netbios name, for example alfresco.

4. create the Service Principal Names (SPN) for the Alfresco CIFS and web server using the setspn utility. The setspn utility is a free download from the Microsoft site, and is also part of the Win2003 Resource Kit.

setspn -a cifs/<cifs-server-name> alfrescocifs
setspn -a cifs/<cifs-server-name>.<domain> alfrescocifs
setspn -a HTTP/<web-server-name> alfrescohttp
setspn -a HTTP/<web-server-name>.<domain> alfrescohttp

Some versions of the ktpass command will add the SPN for the principal so you may only need to add the NetBIOS/short name versions of the SPNs. Use the setspn -l command to check if the ktpass command set the SPN. You can list the SPNs for a server using the following:

setspn -l <account-name>

For example:

setspn -l alfrescocifs
setspn -l alfrescohttp

5. Copy the key table files created in step 3 to the server where Alfresco will run. Copy the files to a protected area such as C:\etc\ or /etc.

6. Set up the Kerberos ini file. The default location (i.e. that Java looks for in Windows and Linux respectively) is C:\WINNT\krb5.ini or /etc/krb5.conf.

default_realm = ALFRESCO.ORG
kdc =
admin_server =
[domain_realm] = ALFRESCO.ORG = ALFRESCO.ORG

Note: The realm should be specified in uppercase.

7. Set up the Java login configuration file. This would usually be in the JRE\lib\security folder. Create a file named java.login.config with the following entries:

Alfresco { sufficient;
AlfrescoCIFS { required
AlfrescoHTTP { required
}; { sufficient;
other { sufficient;

8. Enable the login configuration file in the main Java security configuration file, usually at JRE\lib\security\ Add the following line:


Alfresco’s Kerberos related parameters

To enable full Kerberos support in Alfresco requires that the CIFS server and the SSO authentication filters each have a Kerberos service ticket.
The Kerberos subsystem supports the following properties:


The Kerberos realm with which to authenticate. The realm should be the domain upper cased; an example is that if the domain is then the realm should be ALFRESCO.ORG.


A Boolean that when true enables SPNEGO/Kerberos based Single Sign On (SSO) functionality in the web client. When false and no other members of the authentication chain support SSO, password-based login will be used.


A Boolean that when true enables Kerberos authentication in the CIFS server. When false and no other members of the authentication chain support CIFS authentication, the CIFS server will be disabled.


The name of the entry in the JAAS configuration file that should be used for password-based authentication. The default value Alfresco is recommended.


The name of the entry in the JAAS configuration file that should be used for CIFS authentication. The default value AlfrescoCIFS is recommended.


The name of the entry in the JAAS configuration file that should be used for web-based single-sign on (SSO). The default value AlfrescoHTTP is recommended.


The password for the CIFS Kerberos principal.


The password for the HTTP Kerberos principal.


A comma separated list of user names who should be considered administrators by default.

For further reading about Alfresco security and authentication you can refer to the chapter 6 of the Professional Alfresco: Practical Solutions for Enterprise Content Management (Wrox Programmer to Programmer) [] book or the chapter 4 of the Alfresco 3 Enterprise Content Management Implementation [] book.


  1. I see a lot of information telling how to set up passthru and ldap authentication against Active Directory, but it seems to me that Kerberos authentication is much better and easier to setup.

    So which is recommended for authentication against AD – kerberos or passthru/ldap? Is there any reason NOT to use kerberos authentication?

  2. Kerberos is definately more secure but there is a drawback that clients always must have access to the domain controller i.e. remote users must be in VPN. Apart from that I believe it’s less popular because support for it has been added to Alfresco later than for the NTLM/LDAP.

  3. The client must have access to the DC? Hmmm, that kinda sucks. I would prefer to be able to access the web and webdav interfaces over the internet, from my home computer which is not on the work domain and not connected via a vpn. A vpn is do-able, but I already have https set up and would prefer not require a vpn, for the convenience of our users. So I guess I may be going with passthru.

  4. Helo, thank you for your articles on Alfresco.
    With Kerberos will I be able to set the ACLs on Alfresco\Share using the accounts\groups on the AD directory? I would like to know before I put the guys on infrastructure to work on the Kerberos setup.

  5. Yes, you will be able to do that. However, I have not done extensive testing on CIFS and Sharepoint protocol when used with Kerberos so I’m not 100% sure everything works (there are some issues described on forum).

  6. Thanks again, Ivan – a great walkthrough.

    I managed to get this working after I got the NTLM working (your other article). So I already had the LDAP queries troubleshooted and working, and passthru configured; therefore half the work was already done.

    For anyone else working on setting this up, I was stumbling over two points before I got it working:

    1) I got the error “Pre-authentication information was invalid” until I made sure the “kerberos.authentication.cifs.configEntryName” and the “kerberos.authentication.http.configEntryName” were capitalised to match the java.config.login file – and not, e.g., the AD sAMAccountName: I started with “alfrescocifs”/”alfrescohttp” and got it working when I changed to “AlfrescoCIFS”/”AlfrescoHTTP”. I believe that is because in the java.login.config file that is how the names are specified (see above).

    2) Authentication chain that worked for me was: “passthru1:passthru,kerberos1:kerberos,ldap-ad1:ldap-ad”



  7. Tim,
    I’m glad you got it all working. Special thanks for the kerberos tip as I believe I have had the same problems couple of times and I was never aware that it could be caused by such a small detail especially in Windows where username case doesn’t matter…


  8. Just simple question: Will Kerberos allow SSO for Share application or it will only enable SSO for Alfresco Explorer???

  9. I think Kerberos SSO for Share is only available in latest nightly builds.

  10. Many Thanks. I used this article + some workaround to finally enable SSO for Web-Explorer using Kerberos. However when using NTLM, both Explorer + Share are SSO enabled but it does not work on IE8 or with Windows 7 cause of NTLVv2 enabled on it. The way around is to set registry value regedit –> Local Machice–>System –> Current Control –> LSA –>LMCompatibilityLevel and set it to 2. This setting needs to be applied on every client machine accessing the server.

    Do you know how can i get the latest build and setup environment for get it compiled and then deploy it on server???

  11. That setting is part of the client security policy therefore it can be easily setup through AD group policy on all computers.

    You can find latest builds here:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2022 Another Stranger Me

Theme by Anders NorenUp ↑