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.