In a previous post, I shared some tips to configure the Kerberos SSO with Documentum D2 3.1 SP1. Since that day, I worked on different projects to also setup the Kerberos SSO on some other components of Documentum. In this post I will try to explain in detail what need to be done to configure the Kerberos SSO for the Content Server. Actually it’s not that hard to do it but you may face some issues if you try to follow the official documentation of EMC.
So what are the pre-requisites to setup the Kerberos SSO for the Content Server? Well in fact you just need a Content Server of course and an Active Directory to generate the keytab(s). Just to let you know, I used a Content Server 6.7 SP1 and an Active Directory on a Windows Server 2008 R2. Let’s define the following properties:

  • Active Directory – user = cskrb
  • Active Directory – password = ##cskrb_pwd##
  • Active Directory – domain = DOMAIN.COM
  • Active Directory – hostname1 = adsrv1.domain.com
  • Active Directory – hostname2 = adsrv2.domain.com
  • Documentum – repository (docbase) = REPO

I. Active Directory prerequisites

As always when working with Kerberos on an Active Directory, the first thing to do is to create a user. So let’s create this user with the following properties:

  • User name: cskrb
  • Support AES 128 bits encryption
  • WARNING: This account MUST NOT support AES 256 bits encryption
  • Trust for Delegation to any service (Kerberos Only)
  • Password never expires
  • Account never expires
  • Account not locked

Once the user has been created, you can proceed with the keytab creation using the comment prompt on the Active Directory host:

cs_keytab.png
According to the documentation of EMC, you can create one keytab with several keys inside for the Documentum repositories. Actually, that’s wrong! It’s not possible in the Microsoft world to generate a keytab with more than one Service Principal Name (SPN) in it, only the Linux implementations of Kerberos allow that. If you try to do so, your Active Directory may loop forever trying to add a second SPN to the keytab. That will considerably slow down your Active Directory and it may even crash…
If you want to setup the Kerberos SSO for more than one repository, you will have to create one user per repository and generate one keytab per user. So just repeat these two steps above for each repository, replacing the user name, user password and repository name… What is possible with an Active Directory is to map more than one SPN to a user. That can be useful for a Load Balancer setting for example but the keytab will always contain one SPN and therefore it seems that this solution isn’t suitable for the Content Server.
The second remark here is that the documentation of EMC often uses the DES encryption only for the keytab but as shown above, you can of course specify the encryption to use or simply specify “ALL” to add all possible encryptions in this keytab. By default Kerberos will always use the stronger encryption. In our case as the Content Server doesn’t support AES 256 bits encryption, the AES 128 bits encryption will be used instead.

II. Configuration of the Content Server side

So let’s start the configuration of the Kerberos SSO for the Content Server. The first thing to do is of course to transfer the keytab created previously (REPO.keytab) from the Active Directory to the Content Server’s host. This CS’s host can be a Windows Server or a Linux Server, it doesn’t matter as long as the Linux Server is part of your enterprise network (well if it’s properly configured). In this post, I will use a Linux server because we usually install Documentum on Linux.
During the installation of the Content Server, the installer creates some default authentication folders, some security elements, aso… Therefore, you have to put the newly created keytab in this specific location for the Content Server to automatically recognize it. Please make sure that the keytab belongs to the Documentum installation owner (user and group) on the file system with the appropriate permissions (640). The correct location is:

$DOCUMENTUM/dba/auth/kerberos/

Then create the file “/etc/krb5.conf” with the following content:

[libdefaults]
noaddresses = true
udp_preference_limit = 1
default_realm = DOMAIN.COM
default_tgs_enctypes = aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc rc4-hmac
default_tkt_enctypes = aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc rc4-hmac
permitted_enctypes = aes128-cts arcfour-hmac-md5 des-cbc-md5 des-cbc-crc rc4-hmac
dns_lookup_realm = true
dns_lookup_kdc = true
passwd_check_s_address = false
ccache_type = 3
kdc_timesync = 0
forwardable = true
ticket_lifetime = 24h
clockskew = 72000

[domain_realm]
.domain.com = DOMAIN.COM
domain.com = DOMAIN.COM
adsrv1.domain.com = DOMAIN.COM
adsrv2.domain.com = DOMAIN.COM

[realms]
DOMAIN.COM = {
master_kdc = adsrv1.domain.com:88
kdc = adsrv1.domain.com:88
kpasswd = adsrv1.domain.com:464
kpasswd_server = adsrv1.domain.com:464
kdc = adsrv2.domain.com:88
kpasswd = adsrv2.domain.com:464
kpasswd_server = adsrv2.domain.com:464
}

[logging]
default = /var/log/kerberos/kdc.log
kdc = /var/log/kerberos/kdc.log

[appdefaults]
autologin = true
forward = true
forwardable = true
encrypt = true

You can of course customize this content with what is suitable for you depending on your environment. Moreover, if the file “/etc/krb5.conf” already exist and you don’t want to modify it or if you can’t modify it, then you can still create this file wherever you want. For example, create the folder “$DOCUMENTUM/kerberos/” and put this file inside. Then edit the file “~/.bash_profile” and add the following line into it to reference this new location:

export KRB5_CONFIG=$DOCUMENTUM/kerberos/krb5.conf

Once done, simply restart your ssh session or source the file “~/.bash_profile” for the new environment variable to be available.
The last thing to do is to refresh the Kerberos configuration for the Content Server to know that a keytab is available on the File System (and therefore enable the dm_krb authentication plugin). This process is known as the re-initialization of the Content Server. There are two main ways to do it: with or without Documentum Administrator (DA). When using DA, you can simply click on a button while the Content Server is running and that’s the main advantage of this method. If you don’t have a DA installed, then I guess you will have to reboot the Content Server for the changes to take effect.
To re-initialize the Content Server using DA, here is what need to be done:

  • Open DA in Internet Explorer
  • Log in to the repository “REPO” with the account of the Documentum installation owner or any account with sufficient permissions
  • Expand the “Basic Configuration item”
  • Click on “Content Servers”
  • Right-click on the repository you are connected to
  • Click on “Properties”
  • Check “Re-Initialize Server”
  • Click on “Ok”

Once done, you should be able to confirm that the reload of the dm_krb plugin was successful by checking the log file of the repository:

$DOCUMENTUM/dba/log/REPO.log

If everything goes well, you will see some lines showing that the Content Server was able to parse the keytab successfully. On a next blog, I will certainly explain how to configure the Kerberos SSO for the DFS part. Stay tuned!