Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

SUSE Linux Enterprise Server (SLES 10) Installation and Administration
Previous Page Home Next Page

47.11 Using LDAP and Kerberos

When using Kerberos, one way to distribute the user information (such as user ID, groups,and home directory) in your local network is to use LDAP. This requires a strong authentication mechanism that prevents packet spoofing and other attacks. One solution is to use Kerberos for LDAP communication, too.

OpenLDAP implements most authentication flavors through SASL, the simple authentication session layer. SASL is basically a network protocol designed for authentication. The SASL implementation is cyrus-sasl, which supports a number of different authentication flavors. Kerberos authentication is performed through GSSAPI (General Security Services API). By default, the SASL plug-in for GSSAPI is not installed. Install it manually with rpm -ivh cyrus-sasl-gssapi-*.rpm.

To enable Kerberos to bind to the OpenLDAP server, create a principal ldap/earth.example.com and add that to the keytab.

By default, the LDAP server slapd runs as user and group ldap, while the keytab file is readable by root only. Therefore, either change the LDAP configuration so the server runs as root or make the keytab file readable by the group ldap. The latter is done automatically by the OpenLDAP start script (/etc/init.d/ldap) if the keytab file has been specified in the OPENLDAP_KRB5_KEYTAB variable in /etc/sysconfig/openldap and the OPENLDAP_CHOWN_DIRS variable is set to yes, which is the default setting. If OPENLDAP_KRB5_KEYTAB is left empty, the default keytab under /etc/krb5.keytab is used and you must adjust the privileges yourself as described below.

To run slapd as root, edit /etc/sysconfig/openldap. Disable the OPENLDAP_USER and OPENLDAP_GROUP variables by putting a comment character in front of them.

To make the keytab file readable by group LDAP, execute

chgrp ldap /etc/krb5.keytab

chmod 640 /etc/krb5.keytab
  

A third, and maybe the best solution, is to tell OpenLDAP to use a special keytab file. To do this, start kadmin, and enter the following command after you have added the principal ldap/earth.example.com:

ktadd -k /etc/openldap/ldap.keytab ldap/[email protected] 
  

Then, on the shell, run:

chown ldap.ldap /etc/openldap/ldap.keytab 
chmod 600 /etc/openldap/ldap.keytab
  

To tell OpenLDAP to use a different keytab file, change the following variable in /etc/sysconfig/openldap:

OPENLDAP_KRB5_KEYTAB="/etc/openldap/ldap.keytab"
  

Finally, restart the LDAP server using rcldap restart.

47.11.1 Using Kerberos Authentication with LDAP

You should now be able to use tools, such as ldapsearch, with Kerberos authentication automatically.

ldapsearch -b ou=people,dc=example,dc=com '(uid=newbie)'

SASL/GSSAPI authentication started
SASL SSF: 56
SASL installing layers
[...]

# newbie, people, example.com
dn: uid=newbie,ou=people,dc=example,dc=com
uid: newbie
cn: Olaf Kirch
[...]
   

As you can see, ldapsearch prints a message that it started GSSAPI authentication. The next message is very cryptic, but it shows that the security strength factor (SSF for short) is 56 (The value 56 is somewhat arbitrary. Most likely it was chosen because this is the number of bits in a DES encryption key). What this tells you is that GSSAPI authentication was successful and that encryption is being used to provide integrity protection and confidentiality for the LDAP connection.

In Kerberos, authentication is always mutual. This means that not only have you authenticated yourself to the LDAP server, but also the LDAP server authenticated itself to you. In particular, this means communication is with the desired LDAP server, rather than some bogus service set up by an attacker.

47.11.2 Kerberos Authentication and LDAP Access Control

Now, allow each user to modify the login shell attribute of their LDAP user record. Assuming you have a schema where the LDAP entry of user joe is located at uid=joe,ou=people,dc=example,dc=com, set up the following access controls in /etc/openldap/slapd.conf:

# This is required for things to work _at all_
access to dn.base="" by * read
# Let each user change their login shell
access to dn="*,ou=people,dc=example,dc=com" attrs=loginShell
       by self write
# Every user can read everything
access to *
       by users read
   

The second statement gives authenticated users write access to the loginShell attribute of their own LDAP entry. The third statement gives all authenticated users read access to the entire LDAP directory.

There is one minor piece of the puzzle missing—how the LDAP server can find out that the Kerberos user [email protected] corresponds to the LDAP distinguished name uid=joe,ou=people,dc=example,dc=com. This sort of mapping must be configured manually using the saslExpr directive. In this example, add the following to slapd.conf:

authz-regexp
   uid=(.*),cn=GSSAPI,cn=auth 
   uid=$1,ou=people,dc=example,dc=com

To understand how this works, you need to know that when SASL authenticates a user, OpenLDAP forms a distinguished name from the name given to it by SASL (such as joe) and the name of the SASL flavor (GSSAPI). The result would be uid=joe,cn=GSSAPI,cn=auth.

If a authz-regexp has been configured, it checks the DN formed from the SASL information using the first argument as a regular expression. If this regular expression matches, the name is replaced with the second argument of the authz-regexp statement. The placeholder $1 is replaced with the substring matched by the (.*) expression.

More complicated match expressions are possible. If you have a more complicated directory structure or a schema in which the username is not part of the DN, you can even use search expressions to map the SASL DN to the user DN.

SUSE Linux Enterprise Server (SLES 10) Installation and Administration
Previous Page Home Next Page

 
 
  Published Courtesy of Novell, Inc. Design by Interspire