Novell LINUX ENTERPRISE SERVER 10 SP2 - INSTALLATION AND ADMINISTRATION Installation Manual page 885

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 authen-
ticated 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.
46.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 at-
tribute 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 joe@EXAMPLE.COM 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 fol-
lowing to slapd.conf:
Installing and Administering Kerberos 867