Integrating FreeIPA and Alfresco...

After describing how to install CentOS, DNS and reverse DNS, FreeIPA and Alfresco, in this post I'm going to describe how to integrate Alfresco with FreeIPA. I want to achieve the following goals with the integration:

• Users and groups are kept within FreeIPA and authentication is done by FreeIPA.
• Alfresco Web interface honors Kerberos tickets. Upon opening Web interface users are immediately presented with their pages withoug necessity for authentication (if, of course, they have valid Kerberos tickets).
• Authentication when mounting DAV share is also done via Kerberos tickets.

In short, I want to achieve SSO (Single Sign-On) as much as possible. Users sign in when they start to use their workstations once, that's the only time they have to enter password.

Another internal error trying to access IPA Web UI

I just tried to access IPA's Web UI and I got 'Internal Server Error' dialog box:

Looking into log file (/var/log/httpd/error_log) I found the following entry that obviously was the reason dialog box appeared:

[Thu Jun 28 21:10:28 2012] [error] [client 192.168.178.1] gss_acquire_cred() failed: Unspecified GSS failure.  Minor code may provide more information (, No key table entry found for HTTP/ipa.example-domain.local.localdomain@EXAMPLE-DOMAIN.HR), referer: https://ipa.example-domain.local/ipa/ui/

It's immediately obvious that something is wrong with the name of IPA server and that somehow .localdomain was appended!? At first, I thought that the problem is in the Firefox and that the value of keys network.negotiate-auth.trusted-uris and network.negotiate-auth.delegation-uris have to end with a dot so that no domain is appended. But quick test showed that I was wrong, when I added dots there nothing worked any more. :)

So, I thought that there must be something on a server that causes that behavior. And then, I looked into /etc/resolv.conf and there it was:

search localdomain example-domain.local

So, this search statement cause localdomain to be appended to the IPA's FQDN. So, I removed that statement and tried again, but the error was still there. Then, it occured to me that Apache probably memorized the statement so I restarted it. And, lo and behold, everyting worked.

You might wonder from where came this search statement. Well, I play tricks with my network setup, and in this case DHCP was used to obtain list of DNS servers which later I manually changed into 127.0.0.1. But, I forgot to remove search statement and so the error occurred. Playing games with network setup obviously bites sometimes... ;)

Installing FreeIPA on minimal CentOS installation..

This post is a continuation on a minimal CentOS6 installation. The goal is to install FreeIPA that will be used as authentication and authorization server for Zimbra and Alfresco.

Environment and parameters

Referring to a figure given in a post about minimal CentOS6 installation, IPA server will be placed within a local network. Actually, it should be placed within separate network along with other servers not accessible from the Internet. But because I have only DMZ and one LAN segment for workstations and to keep things simple, obviously the local network is the place to go. So, based on that, the following parameters will be used:

• The IP address of FreeIPA server will be 172.16.1.2/24.
• FQDN name will be ipa.example-domain.local. Note the domain name of the local network!
• Kerberos REALM will be EXAMPLE-DOMAIN.COM.

I'm also assuming that you already have working DNS server, with both forward and reverse queries working! If you don't, you should first configure DNS (and then configure reverse DNS, too) and then proceed with FreeIPA. Of course, the two can be hosted on the same host, but for my scenario, DNS is with mail server in DMZ as it is accessible from the Internet, while FreeIPA is on a separate host in local network.

Software installation

The first step is to install base OS as specified in the post about minimal CentOS6 installation. Note that some things, like IP address, host name and DNS server should be appropriately changed!

After the base OS installation is finished next step is to install necessary software. So, install ipa-server package using yum:

yum -y install ipa-server 

This will result in installation of hefty set of dependencies, somewhere around 190M to download which will take aproximatelly 572M after installation. Anyway, disk usage after IPA server installation looks something like this:

# df
Filesystem  1K-blocks      Used Available Use% Mounted on
/dev/sda1     7739864   1600788   5745912  22% /

Sever configuration

Now, start server configuration program. Here is the transcript of installation I did:

# ipa-server-install

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will set up the IPA Server.

This includes:
  * Configure a stand-alone CA (dogtag) for certificate management
  * Configure the Network Time Daemon (ntpd)
  * Create and configure an instance of Directory Server
  * Create and configure a Kerberos Key Distribution Center (KDC)
  * Configure Apache (httpd)

To accept the default shown in brackets, press the Enter key.

Enter the fully qualified domain name of the computer
on which you're setting up server software. Using the form
<hostname>.<domainname>
Example: master.example.com.


Server host name [ipa.example-domain.local]:

The domain name has been calculated based on the host name.

Please confirm the domain name [example-domain.local]:

The IPA Master Server will be configured with
Hostname:    ipa.example-domain.local
IP address:  192.0.2.2
Domain name: example-domain.local

The kerberos protocol requires a Realm name to be defined.
This is typically the domain name converted to uppercase.

Please provide a realm name [EXAMPLE-DOMAIN.LOCAL]: EXAMPLE-DOMAIN.COM
Certain directory server operations require an administrative user.
This user is referred to as the Directory Manager and has full access
to the Directory for system management tasks and will be added to the
instance of directory server created for IPA.
The password must be at least 8 characters long.

Directory Manager password: <enter password>
Password (confirm): <enter password>

The IPA server requires an administrative user, named 'admin'.
This user is a regular system account used for IPA server administration.

IPA admin password: <enter password>
Password (confirm): <enter password>


The following operations may take some minutes to complete.
Please wait until the prompt is returned.

Configuring ntpd
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
done configuring ntpd.
Configuring directory server for the CA: Estimated time 30 seconds
  [1/3]: creating directory server user
  [2/3]: creating directory server instance
  [3/3]: restarting directory server
done configuring pkids.
Configuring certificate server: Estimated time 3 minutes 30 seconds
  [1/17]: creating certificate server user
  [2/17]: creating pki-ca instance
  [3/17]: configuring certificate server instance
  [4/17]: disabling nonces
  [5/17]: creating CA agent PKCS#12 file in /root
  [6/17]: creating RA agent certificate database
  [7/17]: importing CA chain to RA certificate database
  [8/17]: fixing RA database permissions
  [9/17]: setting up signing cert profile
  [10/17]: set up CRL publishing
  [11/17]: set certificate subject base
  [12/17]: configuring certificate server to start on boot
  [13/17]: restarting certificate server
  [14/17]: requesting RA certificate from CA
  [15/17]: issuing RA agent certificate
  [16/17]: adding RA agent as a trusted user
  [17/17]: Configure HTTP to proxy connections
done configuring pki-cad.
Configuring directory server: Estimated time 1 minute
  [1/35]: creating directory server user
  [2/35]: creating directory server instance
  [3/35]: adding default schema
  [4/35]: enabling memberof plugin
  [5/35]: enabling referential integrity plugin
  [6/35]: enabling winsync plugin
  [7/35]: configuring replication version plugin
  [8/35]: enabling IPA enrollment plugin
  [9/35]: enabling ldapi
  [10/35]: configuring uniqueness plugin
  [11/35]: configuring uuid plugin
  [12/35]: configuring modrdn plugin
  [13/35]: enabling entryUSN plugin
  [14/35]: configuring lockout plugin
  [15/35]: creating indices
  [16/35]: configuring ssl for ds instance
  [17/35]: configuring certmap.conf
  [18/35]: configure autobind for root
  [19/35]: configure new location for managed entries
  [20/35]: restarting directory server
  [21/35]: adding default layout
  [22/35]: adding delegation layout
  [23/35]: adding replication acis
  [24/35]: creating container for managed entries
  [25/35]: configuring user private groups
  [26/35]: configuring netgroups from hostgroups
  [27/35]: creating default Sudo bind user
  [28/35]: creating default Auto Member layout
  [29/35]: creating default HBAC rule allow_all
  [30/35]: initializing group membership
  [31/35]: adding master entry
  [32/35]: configuring Posix uid/gid generation
  [33/35]: enabling compatibility plugin
Restarting IPA to initialize updates before performing deletes:
  [1/2]: stopping directory server
  [2/2]: starting directory server
done configuring dirsrv.
  [34/35]: tuning directory server
  [35/35]: configuring directory to start on boot
done configuring dirsrv.
Configuring Kerberos KDC: Estimated time 30 seconds
  [1/14]: setting KDC account password
  [2/14]: adding sasl mappings to the directory
  [3/14]: adding kerberos entries to the DS
  [4/14]: adding default ACIs
  [5/14]: configuring KDC
  [6/14]: adding default keytypes
  [7/14]: adding default password policy
  [8/14]: creating a keytab for the directory
  [9/14]: creating a keytab for the machine
  [10/14]: exporting the kadmin keytab
  [11/14]: adding the password extension to the directory
  [12/14]: adding the kerberos master key to the directory
  [13/14]: starting the KDC
  [14/14]: configuring KDC to start on boot
done configuring krb5kdc.
Configuring ipa_kpasswd
  [1/2]: starting ipa_kpasswd
  [2/2]: configuring ipa_kpasswd to start on boot
done configuring ipa_kpasswd.
Configuring the web interface: Estimated time 1 minute
  [1/13]: disabling mod_ssl in httpd
  [2/13]: setting mod_nss port to 443
  [3/13]: setting mod_nss password file
  [4/13]: enabling mod_nss renegotiate
  [5/13]: adding URL rewriting rules
  [6/13]: configuring httpd
  [7/13]: setting up ssl
  [8/13]: setting up browser autoconfig
  [9/13]: publish CA cert
  [10/13]: creating a keytab for httpd
  [11/13]: configuring SELinux for httpd
  [12/13]: restarting httpd
  [13/13]: configuring httpd to start on boot
done configuring httpd.
Applying LDAP updates
Restarting IPA to initialize updates before performing deletes:
  [1/2]: stopping directory server
  [2/2]: starting directory server
done configuring dirsrv.
Restarting the directory server
Restarting the KDC
Restarting the web server
Sample zone file for bind has been created in /tmp/sample.zone.OHH8V_.db
==============================================================================
Setup complete

Next steps:
    1. You must make sure these network ports are open:
        TCP Ports:
          * 80, 443: HTTP/HTTPS
          * 389, 636: LDAP/LDAPS
          * 88, 464: kerberos
        UDP Ports:
          * 88, 464: kerberos
          * 123: ntp

    2. You can now obtain a kerberos ticket using the command: 'kinit admin'
       This ticket will allow you to use the IPA tools (e.g., ipa user-add)
       and the web user interface.

Be sure to back up the CA certificate stored in /root/cacert.p12
This file is required to create replicas. The password for this
file is the Directory Manager password

As you can see the process is quite automated.

Postinstallation steps

There are few more things that have to be done before clients can be configured. Note the italic text almost at the end of the transcript? It says that there is a file with data you should place in your DNS server. The file is only example, and basically it defines the whole zone. But since we already have working zone, we only need the IPA related part, i.e. without SOA, NS and A records. That would be the following fragment:

; ldap servers
_ldap._tcp              IN SRV 0 100 389        ipa

;kerberos realm
_kerberos               IN TXT EXAMPLE-DOMAIN.TXT

; kerberos servers
_kerberos._tcp          IN SRV 0 100 88         ipa
_kerberos._udp          IN SRV 0 100 88         ipa
_kerberos-master._tcp   IN SRV 0 100 88         ipa
_kerberos-master._udp   IN SRV 0 100 88         ipa
_kpasswd._tcp           IN SRV 0 100 464        ipa
_kpasswd._udp           IN SRV 0 100 464        ipa

;ntp server
_ntp._udp               IN SRV 0 100 123        ipa

Basically, these records define services provided by IPA so that they are discoverable by DNS. All the services (or server - SRV - records) consist of two parts, the first one defines service name with prepended underscore while the second part defines transport protocol, also with prepended underscore. So, for example, there is LDAP over TCP protocol (_ldap._tcp) which listens on port 389 (standard LDAP port) on IPA host. Anyway, place those lines in example-domain.local, and in internal view of example-domain.com zone files. Don't forget to change serial number of zone file and to restart BIND after the change.

It's time to test that IPA is working correctly. First, request ticket for user admin:

# kinit admin
Password for admin@EXAMPLE-DOMAIN.COM:

You are asked password that you entered during installation process! Anyway, you shouldn't receive any message and that means you were issued ticket. To check ticket, use klist command:

# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin@EXAMPLE-DOMAIN.COM

Valid starting     Expires            Service principal
06/26/12 17:43:05  06/27/12 17:43:01  krbtgt/EXAMPLE-DOMAIN.COM@EXAMPLE-DOMAIN.COM

If you got output as shown (or similar) then IPA is working correctly. Note that when you have to do something with IPA (using command line tool ipa) you are authorized (and authenticated) with the ticket. So, for example, when you are adding new user, you need to have valid admin ticket.

Client installation

Finally, we'll describe setup of a client, more specifically, Firefox browser. This is necessary so that you can use Web interface to administer IPA server. Two things have to be done. First, you have to edit /etc/krb5.conf file. The content of that file should look like this:

[logging]
        default = FILE:/var/log/krb5libs.log
        kdc = FILE:/var/log/krb5kdc.log
        admin_server = FILE:/var/log/kadmind.log
[libdefaults]
        default_realm = EXAMPLE-DOMAIN.COM
        dns_lookup_realm = false
        dns_lookup_kdc = false
        ticket_lifetime = 24h
        renew_lifetime = 7d
        forwardable = true
[realms]
        EXAMPLE-DOMAIN.COM = {
                kdc = ipa.example-domain.local
                admin_server = ipa.example-domain.local
        }
[domain_realm]
        .example-domain.hr = EXAMPLE-DOMAIN.COM
        example-domain.hr = EXAMPLE-DOMAIN.COM
        .example-domain.local = EXAMPLE-DOMAIN.COM
        example-domain.local = EXAMPLE-DOMAIN.COM

Basically, in this file you define default realm (so that you can write kinit admin, instead of full kinit admin@EXAMPLE-DOMAIN.COM), and you also define KDC server for this real (under realm section). Finally, you define mapping from domain names to realm. In our case, we have a single realm that is valid in all domains. Note that it is possible to use DNS to resolve much of the information we gave in the configuration file but I'm not using that feature currently (dns_lookup_* = false). There is one more reason I'm not using DNS resolution. Namely, while my IPA and DNS servers are virtual machines, I'm using my physical laptop as a client and I don't want to change DNS server for laptop or otherwise half of the things would stop working. :) Oh, yeah, if you are doing the same, don't forget to put name ipa.example-domain.local into /etc/hosts on a laptop. Otherwise, you'll get the following error message:

$ kinit admin
kinit: Cannot contact any KDC for realm 'EXAMPLE-DOMAIN.COM' while getting initial credentials

This actually means that the KDC host name isn't resolvable. If you get the following error message:

$ kinit admin
Password for admin@EXAMPLE-DOMAIN.COM:
kinit: Clock skew too great while getting initial credentials

That means that the clock on one of the machines (KDC or your laptop, or both) is wrong and the difference is too large. So, check and fix clocks. Finally, when everything is OK, you should get no error messages:

$ kinit admin
Password for admin@EXAMPLE-DOMAIN.COM: 

And you can use klist to very that you really got ticket. This ticket is important because without it Web application won't let you access it. Ok, now Firefox configuration. This is done via Firefox browsing, so it's easy. :)

Open Firefox and type IPA server's IP address (or name) into URL location. The first thing you are asked is to import untrasted certificate because you are switched to HTTPS connection. When you've done that you'll receive dialog box that informs you that you have to import CA from IPA server. During the import process it is very important to select all check boxes! Otherwise, the next step won't work! Ok, the next step is automatic configuration of Firefox configuration to allow kerberos ticket forwarding to remote host. When it's done reload page and you should have access to adminstration interface.

I had a problem with some internal error by Web application. It turned out that my laptop used IP address that Web application couldn't resolve to name (via reverse DNS), and then to realm. I had to enter laptop name and IP address into DNS server. Also, be careful that you use the correct DNS server on IPA server.

So, that's it for this post. :)