Original Post by Juliet Kemp...
Click here to see Profile:::
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 ssh to any system without having to re-authenticate.
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. kerberos.example.com.
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 [logging] section is optional, but simplifies debugging.
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 (/etc/init.d/krb5-admin-server start; /etc/init.d/krb5-kdc start). It's normal for it to take some time to start the admin server — so be patient.
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 kadmin.local for this — this only ever runs locally on the master server, and does not use Kerberos to authenticate to that server. So, before you have a Kerberos database, it's the only way to talk to the server! After you have your admin user set up, you should use kadmin instead.
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 krb5-kdc and krb5-admin-server for the changes to take effect. From now on, you use kadmin -p krbadm to make changes.
Check that all is working by typing kinit krbadm — you should be challenged for the password. Then type klist and you will see that you have an authorized principal krbadm.
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 sufficient line enables local login (e.g. by root) if necessary. At least one line in common-auth must be required, or you will be able to log in without a password, which probably isn't desirable.
The use_first_pass and try_first_pass options mean that you get asked for your password only once, whichever module is used. ignore_root means that the kerberos module is not used for root login — this is more secure.
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 GSSAPIAuthentication and GSSAPIDelegateCredentials to Yes.
You need to add the server host to the keytab in order to enable ssh to transfer the Kerberos credentials. From the client, run kadmin -p krbadm (authenticating you as the admin user) and execute these commands:
addprinc -randkey host/client.example.com
ktadd host/client.example.com
The -randkey option generates a random key rather than asking for a password — this is obviously preferable for a non-person entity.
Testing
Now it's time to ensure that everything is in working order. Create a test user via kadmin:
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:
Check the time on the KDC and the client machine — they must be the same. (There's a tolerance of 5 minutes by default).
Check that you can ping the KDC and that there aren't any other network problems.
Check that the host key has the correct number, by executing the following on the client:
sudo klist -k /etc/krb5.keytab
kinit krbadm
kvno host/client.example.comIf they are not the same, you need to start up
kadmin, remove the client principal from the keytab (ktrem), delete it (delprinc), then recreate and re-add it.
Now you should be able to use Kerberos for authentication. The next part of this article will tackle setting up your LDAP server.
Juliet Kemp has been playing with Linux systems for around 6 years now, after discovering that it was an excellent way to avoid Finals revision. She is currently sysadmin for the Astrophysics group at Imperial College, in London (UK), and is responsible for wrangling a Linux+Solaris network and its users.
No comments:
Post a Comment