Centralized Authentication with Kerberos 5, Part I
New accounts still need to be added to your shadow file or password map. However, instead of putting the encrypted password into these places, you have to create a new Kerberos principal and store the password in the KDC.
Using the kadmin tool:
add a principal for a regular users with:
kadmin: addprinc john NOTICE: no policy specified for john@EXAMPLE.COM; assigning "default" Enter password for principal "john@EXAMPLE.COM": Re-enter password for principal "john@EXAMPLE.COM": Principal "john@EXAMPLE.COM" created.
The password you have entered during this principal creation process is the one john needs to enter in order to obtain a Kerberos TGT or to log in to a computer configured to use your Kerberos 5 realm.
You now either can create principals for all your accounts by hand or use the technique described in the migration section below.
If you plan to use Kerberos in production at your site, you should plan on using additional slave KDCs to make your installation more fault tolerant. For this, the master KDC needs to have an additional propagation service installed that sends updated versions of the KDC database to all slave servers. The slave servers need to have a receiving end for the propagation service installed. See the MIT documentation for how to set this up.
The easiest way to enable a computer for Kerberos authentication is to use a pluggable authentication module (PAM). Because it uses Kerberos API calls, it needs a working /etc/krb5.conf file. So, the first step is to copy the /etc/krb5.conf file from your KDC (see above) to each client machine.
Kerberos is used not only to authenticate users, it also is used to authenticate computers, to prevent you from logging in to a machine with a hijacked IP address. For this to work, each computer needs its own Kerberos principal with the key (the password) stored in a file (a keytab file). Principals for computers have the special form:
The first step is to create a new principal for each of your client machines. The following commands use the computer name client1 as an example. Replace the string client1 with the hostname of the client computer. Log in to every one of your client computers and execute:
% sudo /usr/local/sbin/kadmin kadmin: addprinc -randkey host/ ↪client1.example.com@EXAMPLE.COM
which assigns a random password to the new principal. Then, extract the key into a keytab file with:
kadmin: ktadd host/client1.example.com@EXAMPLE.COM
which creates the file /etc/krb5.keytab. To have write permissions to the /etc/ directory, you need to run the kadmin command with sudo. Simply creating a new principal would not have required these special privileges. Watch out for the ownership and file permissions of /etc/krb5.keytab, however; it has to be readable only by root. Otherwise, the security of this machine is compromised.
Several PAM modules for Kerberos 5 are available and all are called pam_krb5. Most of these do not work any more due to some API changes in MIT Kerberos 5 version 1.3. Your best choice right now is to use the PAM module that comes with your Linux distribution. See the section above on how to build a PAM module for Kerberos 5 from source.
Now, add the new PAM module to your system's authentication stack by editing the file /etc/pam.d/system-auth (on Red Hat systems). The entries should look similar to these Red Hat 9 entries:
auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_krb5.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore ↪service_err=ignore system_err=ignore] ↪/lib/security/$ISA/pam_krb5.so password required /lib/security/$ISA/pam_cracklib.so ↪retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so ↪nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_krb5.so ↪use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_krb5.so
These changes make every program with the system-auth PAM stack in its PAM configuration file (see the other files in /etc/pam.d/) use Kerberos for its authentication.
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
|Dart: a New Web Programming Experience||May 07, 2013|
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- New Products
- Developer Poll
- Trying to Tame the Tablet
- Tech Tip: Really Simple HTTP Server with Python
- Deceptive Advertising and
7 min 36 sec ago
- Let\'s declare that you have
8 min 33 sec ago
- Alterations in Contest Due
9 min 39 sec ago
- At a numbers mindset, your
10 min 50 sec ago
- Do not get Just Almost any
14 min 19 sec ago
- A fantastic rule-of-thumb to
15 min 42 sec ago
- Keren mastah..
1 hour 13 min ago
- mini tablet compare
2 hours 32 min ago
- Looking Good
6 hours 5 min ago
- Hey God - You may not be
10 hours 19 min ago