Wednesday, September 14, 2011

Kerberos and LDAP, So Strong Together


Kerberos is one among several authentication protocols that are used as a part of security systems. Basically, it is a network authentication protocol designed to provide strong authentication and confidentiality for client/server and multi-tier applications. LDAP, on the other hand is a method of organizing the details and providing access to it. It is mostly used for user, service and machine details, and is incredibly useful.
Kerberos and LDAP are both popular, when considered separately. And when you put them together, it provides an even more powerful solution for secure authentication.
Through this article, I wish to demonstrate how to INTEGRATE Kerberos with LDAP to provide a strong means of user authentication and authorization. The implementation explained in this article has been tested on Ubuntu 9.04. Before getting into the details, let me take you through the common terms that are used here.
Authentication
Authentication is a process by which you verify the identity of a user. Is the user really the one who he/she claims to be? When a user signs into a workstation, the login and password he/she provides is used to establish user identity.
Authorization
Authorization establishes all the privileges that the user has. User privileges can be set by creating groups and then associating the users with the respective groups.
Kerberos
As mentioned previously, Kerberos is a network authentication protocol designed by MIT to securely establish user identity over an insecure network. It takes care of network security issues such as password sniffing. Unlike NIS, passwords are not sent over the network. Instead, authentication is achieved using Kerberos tickets.
LDAP
LDAP stands for Lightweight Directory Access Protocol. It is designed for accessing directory services. Directory servers can be used to store the user details such as user login name, home directory path, user ID and group ID and much more.
Usually, Kerberos is used for user authentication and LDAP for user authorization. Even though LDAP can also be used for authentication, Kerberos is prefered here since it is more secure. When a user logs in to a workstation, it contacts the Kerberos server to authenticate the user, and the LDAP server to get the user home and group details.

Implementation

 
  Server Setup
Install Ubuntu 9.04 Server Edition. Before installing Kerberos and OpenLDAP packages, set up the DNS for your domain and synchronize the server time with NTP. Kerberos is quite sensitive to time difference and it won’t allow authentication if the difference in time between the client and the server is more than FIVE minutes.
  Install Kerberos
Install the required packages. You will be asked to enter the "realm" name, KDC server hostname and the admin server details.
Let’s use "EXAMPLE.COM" as the realm name and set up the server hostname as srv.example.com. The same server will be used to run the KDC server and the admin server.
apt-get install krb5-kdc krb5-admin-server
Kerberos can be reconfigured after package installation using the following command:
dpkg-reconfigure krb5-config
Initialize the database for the realm, EXAMPLE.COM and start the KDC and Kerberos admin servers. You will now be prompted for the Database Master Password, and it is important to remember this password.
krb5_newrealm
Next, create an administrative user.
#kadmin.local
Authenticating as principal root/admin@EXAMPLE.COM with password.
kadmin.local: addprinc administrator
WARNING: no policy specified for administrator@EXAMPLE.COM; defaulting to no policy
Enter password for principal "administrator@EXAMPLE.COM":
Re-enter password for principal "administrator@EXAMPLE.COM":
Principal "administrator@EXAMPLE.COM" created.
kadmin.local: quit
Now, set ACL for the administrative user in /etc/krb5kdc/kadm5.acl
administrator *
Restart the server for the changes to take effect.
 /etc/init.d/krb5-admin-server restart
 
Kerberos and LDAP are both popular, when considered separately. And when you put them both together, it provides an even more powerful solution for secure authentication.
 
  Install OpenLDAP
Install the required packages. You will be prompted for LDAP directory admin password.
apt-get install slapd ldap-utils libsasl2-modules-gssapi-mit
In order to create organization units for users and groups, create a file “tree.ldif” with the following content and then use the ldapadd command.
dn: ou=users,dc=example,dc=com
objectClass: organizationalUnit
ou:users

dn: ou=groups,dc=example,dc=com
objectClass: organizationalUnit
ou: groups

ldapadd -x -D "cn=admin,dc=example,dc=com" -W -f tree.ldif
Enter the directory admin password, (the one given during package installation) when prompted.
  Kerberize LDAP with GSSAPI
We need to kerberize LDAP so that it can authenticate users through Kerberos. This is achieved via GSSAPI.
GSSAPI stands for Generic Security Services Application Program Interface. It is an API for programs to access security services, independent of the underlying security implementation. The application need not be rewritten even if the security implementation changes.
LDAP uses SASL calls to authenticate a user via GSSAPI. SASL (Simple Authentication and Security Layer) is a framework for authentication and data security in Internet protocols.
Add the LDAP principal in Kerberos and then export the key to the keytab file.

kadmin -p administrator
kadmin: addprinc -randkey ldap/srv.example.com
kadmin: ktadd -k /etc/ldap/ldap.keytab ldap/srv.example.com

List the keytab file in /etc/default/slapd by setting up the environment variable, KRB5_KTNAME.
export KRB5_KTNAME=/etc/ldap/ldap.keytab
Add the SASL regex to convert the SASL authenticated username to an LDAP username (Distinguished Name). The OpenLDAP server (slapd) configuration is stored as a special LDAP directory. The root of the configuration tree is named cn=config and will contain the global configuration settings. The SASL regex is also added to the tree using ldapmodify.

ldapmodify -x -D cn=admin,cn=config -W

dn: cn=config
add: olcAuthzRegexp
olcAuthzRegexp: uid=(.*),cn=example.com,cn=gssapi,cn=auth  uid=$1,ou=users,dc=example,dc=com

modifying entry “cn=config”

dn: cn=config
add: olcSaslHost
olcSaslHost: srv.example.com

modifying entry “cn=config”

dn: cn=config
add: olcSaslRealm
olcSaslRealm: EXAMPLE.COM

Now, change the client authentication method to GSSAPI in/etc/ldap/ldap.conf by adding the following lines:
BASE dc=example,dc=com
URI ldap://srv.example.com
SASL_MECH GSSAPI
All the users added to the Kerberos server will now be able to access the LDAP directory entries. To grant administrative privileges to a Kerberos user, modify the access control settings in the config tree.
"olcDatabase={1}hdb,cn=config".
  Adding a User
First, create the group to which the user should belong. To add a group “systems”, create group.ldif with the following content :
dn: cn=systems,ou=groups,dc=example,dc=com
objectClass: top
objectClass: posixGroup
cn: pivusers
gidNumber: 1100
Now add the group to the LDAP directory using ldapadd command.
ldapadd -x -D cn=admin,dc=example,dc=com -W -f group.ldif
To add a user “vishnu”, first create the user.ldif file with the following content :
dn: uid=vishnu,ou=users,dc=example,dc=com
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
cn: Vishnu Ram
sn: User
uid: vishnu
uidNumber: 1101
gidNumber: 1100
homeDirectory: /home/vishnu
loginShell: /bin/bash
Next, add the user to the LDAP directory using the ldapadd command.
ldapadd -x -D cn=admin,dc=example,dc=com -W -f user.ldif
Finally, add the user to Kerberos.

kadmin -p administrator
kadmin: addprinc vishnu

  Client Setup
Install the Ubuntu Desktop Edition, set DNS for the hostname and synchronize the time. Now, install the client packages for LDAP and Kerberos.
apt-get install ldap-auth-client libpam-krb5 krb5-user libsasl2-modules-gssapi-mit
The LDAP and Kerberos configuration details will be prompted during the installation of the packages. You may enter the details of the LDAP and Kerberos server during installation or manually edit the /etc/ldap.conf and/etc/krb5.conf files later.
The Kerberos configuration file entries - /etc/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {

kdc = srv.example.com
admin_server = srv.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
The LDAP configuration file entries - /etc/ldap.conf
base dc=example,dc=com
uri ldap://example.com
ldap_version 3
Now, configure PAM and nsswitch.conf to allow users to login using Kerberos and LDAP. Next, Create a file “/etc/auth-client-config/profile.d/krb-ldap-config” with the following content.
[krb_ldap]
nss_group=group:          files ldap
nss_passwd=passwd:         files ldap
nss_shadow=shadow:         files ldap
nss_netgroup=netgroup:       ldap
pam_account=account sufficient        pam_unix.so
        account sufficient        pam_krb5.so
        account required          pam_deny.so
pam_auth=auth sufficient pam_krb5.so
        auth sufficient pam_unix.so use_first_pass
        auth required   pam_deny.so
pam_password=password  sufficient   pam_unix.so nullok obscure md5
        password  sufficient   pam_krb5.so use_first_pass
        password  required     pam_deny.so
pam_session=session required        pam_unix.so
Update the pam and nsswitch.conf configuration files as per the above defined “krb_ldap” profile.
auth-client-config -a -p krb_ldap
The client machine is now ready to accept the users that were created in the Kerberos and LDAP servers. Now a user can sign into any of the workstations using the same login and password. To test the implementation, simply add a user and then use this to login to a client machine.

Conclusion

When it comes to security, the best option available to you is Kerberos. It is specifically modeled to handle authentication and will not do the information lookup that LDAP does. It avoids all the password security problems and enables the very useful single-sign-on feature.
Thus, the ideal situation would be to use both Kerberos and LDAP together. The first for authentication and the other for information co-ordination and access. To conclude I would say, Kerberos and LDAP do play quite well, when together.

References