|
|
Integrating LDAP and Kerberos: Part One (Kerberos)LDAP and Kerberos are widely used, separately, yet integrating them seems less popular. This is a shame, as they fit together very well — in particular, you should avoid using LDAP for authentication, for which it is not well designed. Security is increasingly important for all sites, and Kerberos is a massive security increase over LDAP authentication. What is LDAP? LDAP stands for Lightweight Directory Access Protocol — it is not itself either hardware or software, but a protocol to define how a client and server interact with each other. An LDAP directory is used to describe a directory whose server corresponds to this protocol. LDAP works by the client asking the server for particular information, the server runs the appropriate search (e.g. to find the entry for a given uid), and returns that information to the client. An entry is a structure which holds information about an object, and entries are arranged in a tree structure. Schemas are used to prescribe the syntax and structure for particular types of object and particular object attributes. Plenty of standard schemas are available, and you can also create your own schemas or add to existing ones, in order to meet the needs of your site. LDAP can run either (using SSL, on port 636 as ldaps:///) or over a unsecured connection (on port 389 as ldap:///). The next part of this piece will explain how to set up a secure LDAP server, using OpenLDAP. What is Kerberos? Kerberos only handles authentication, of machines or of users. When a user logs in to their machine, they request a Ticket-Granting Ticket (TGT) from the Key Distribution Center (your main Kerberos server, or a slave server). The KDC finds the user in its database, then sends back a TGT encrypted using their key. That TGT is decrypted at the other end with the user's password. Therefore the password isn't sent over the network, increasing security. After that, any kerberized service uses this TGT to ask for a service-specific ticket: the user doesn't need to enter their password again until the TGT expires (usually 10 hours), or is deleted. So, for example, if your entire system is Kerberos authenticated, you can log on once and then The process works similarly for services or machines — except that a locally stored key is used instead of a password. If you want more information, there's an excellent and very readable explanation of how Kerberos works on the MIT Web site. The rest of this article will deal with setting up Kerberos (the MIT version) — it's easier (in my experience) to set up Kerberos first, then LDAP, than the other way around. Kerberos server setup Let's start with installation and configuration. Kerberos should be available from any distribution — or, of course, you can compile from source. The Debian/Ubuntu packages needed are krb5-kdc, krb5-admin-server, libkrb5-dev, krb5-config, krb5-user, krb5-clients, and libkadm55. During the installation of the packages you'll be asked for the hostname of your server. This should be the fully qualified domain name (FQDN) of your server — e.g. Most of the configuration is done in /etc/krb5.conf. Edit this to look as follows: [libdefaults] default_realm EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kerberos.example.com admin_server = kerberos.example.com default_domain = example.com } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM [login] krb4_convert = false [logging] kdc = FILE:/var/log/kerberos/krb5kdc.log admin_server = FILE:/var/log/kerberos/kadmin.log default = FILE:/var/log/kerberos/krb5lib.log Your realm should match your local domain, as illustrated above. The If you want to set up a slave kerberos server as well as the master, you can have multiple KDC lines. The KDC, as mentioned above, does the giving out of TGTs, and you can have as many as you like. However, you only have a single admin server, which acts as the master KDC. Start the kerberos admin server and the KDC ( Setting up the database Now you'll need to create the initial database and populate it with your inital admin user(s). Initially, you use The commands to issue from the command line are: kdb5_util create -s kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/admin" kadmin.local -q "ktadd -k /etc/krb5kdc/kadm5.keytab kadmin/changepw" kadmin.local -q "addprinc krbadm@EXAMPLE.COM" kadmin.local -q "addprinc ldapadm@EXAMPLE.COM" The first command creates your database, and the next two are needed to enable admin changes to happen. The final two commands create a Kerberos admin principle (krbadm) and an LDAP admin principal (ldapadm) — you'll be asked to provide a password. Obviously, your choice of usernames in the last two lines is up to you! Or you can have a single admin user. Some sites prefer to create admin users that look like krbadm/admin@EXAMPLE.COM to make it clear which users have admin privileges. You also need to edit the ACL (access control), in the file /etc/krb5kdc/kadm5.acl. A very basic example corresponding to the above setup is as follows: krbadm@EXAMPLE.COM * */admin@EXAMPLE.COM * */*@EXAMPLE.COM i *@EXAMPLE.COM i This gives all access to the Kerberos admin user, and to any /admin user, and read-only access to all principals in the domain (note that */* and * are both required — just as user/admin@EXAMPLE.COM and user@EXAMPLE.COM are both different). Edit /etc/krb5kdc/kdc.conf to set EXAMPLE.COM as the realm, and ensure that the database, keytab, and ACL locations match what you set in the database creation above. Note that the admin_keytab location must be specified as FILE:/etc/krb5kc/kadm5.keytab, not just as the bare filename. Restart Check that all is working by typing Kerberos client setup The Debian packages needed are: krb5-user (for klist and kinit), ntpdate (the time on server and client must match), and libsasl2-gssapi-mit. Edit /etc/krb5.conf to make sure that the following entries are correctly set: [libdefaults] default_realm = EXAMPLE.COM [realms] EXAMPLE.COM = { kdc = kerberos.example.com admin_server = kerberos.example.com } [domain_realm] example.com = EXAMPLE.COM .example.com = EXAMPLE.COM This may already have been done by the Debian package configuration, if you answered the questions correctly. SSH and logon You next need to set up both server and clients to use Kerberos for logon and for SSH logon. Debian users will need to install libpam-krb5, openssh-server, libsasl2-dev, libsasl2-gssapi-mit, and libsasl2-modules. The same packages should be available for Ubuntu and other distros, but (in some cases) with different names. Edit /etc/pam.d/common-auth and /etc/pam.d/common-session to use pam_krb5.so.1, as follows: # /etc/pam.d/common-auth auth sufficient pam_krb5.so use_first_pass ignore_root forwardable auth required pam_unix.so nullok_secure try_first_pass # /etc/pam.d/common-session session sufficient pam_unix.so session sufficient pam_krb5.so ignore_root The The For ssh, edit /etc/ssh/sshd_config to set the various Kerberos options as follows: KerberosAuthentication yes KerberosOrLocalPasswd yes KerberosTicketCleanup yes UsePAM yes AllowTcpForwarding yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes GssapiKeyExchange yes Then edit /etc/ssh/ssh_config to set both You need to add the server host to the keytab in order to enable ssh to transfer the Kerberos credentials. From the client, run addprinc -randkey host/client.example.com ktadd host/client.example.com The Testing Now it's time to ensure that everything is in working order. Create a test user via addprinc test@EXAMPLE.COM Test the setup by first logging on with console, then with graphical logon, and then via ssh. Once logged on to one kerberized machine, you should be able to ssh to another kerberized machine without typing your password again. Troubleshooting Things to check if it doesn't work smoothly:
Now you should be able to use Kerberos for authentication. The next part of this article will tackle setting up your LDAP server.
|