Introduction

Mandrake 9.1, an RPM-based distro, is fairly easy to setup as a DAS client. Kerberos and NIS RPMs are available on the Mandrake CDs, MandrakeSoft's MandrakeClub.Com website, and from other sources such as RPMfind.net. Since Mandrake uses PAM for authentication, it is not difficult to configure Kerberos as an additional authentication mechanism. Mandrake uses the MIT Kerberos software, not Heimdal. In general, the configuration is very similar to Red Hat. Mandrake needs the pam_krb5, NIS, nscd, and Kerberos 5 packages to become a DAS client.

Assumptions

These Mandrake DAS client instructions assume the following:

The last point is VERY important. If you are running telnet, ftp, rlogind, apache, etc. with those services configured to allow authentication of users with plaintext over the network, there is not much point in using Kerberos for secure authentication. The assumption is that you will only be logging in remotely via SSH2 or SSL/TLS encrypted sessions. This does NOT, however, preclude you from using Kerberized versions of TELNET or RLOGIN as long as they are configured to disallow plaintext authentication methods.

Step-by-step Instructions

Step 1: Software Installation

Although the krb5-libs-1.2.7-1mdk package is installed by default, we will need to add the following RPMs:

In order to install/upgrade these packages, use this command from a newly-created directory containing the packages:

[root@dhcp102 root]# rpm -Uvh krb5-workstation*rpm
Preparing...                ########################################### [100%]
   1:krb5-workstation       ########################################### [100%]
[root@dhcp102 root]# rpm -Uvh krbafs*rpm
Preparing...                ########################################### [100%]
   1:krbafs                 ########################################### [100%]
[root@dhcp102 root]# rpm -Uvh pam_krb5*rpm
Preparing...                ########################################### [100%]
   1:pam_krb5               ########################################### [100%]
[root@dhcp102 root]# rpm -Uvh yp*rpm
Preparing...                ########################################### [100%]
   1:ypbind                 ########################################### [ 50%]
   2:yp-tools               ########################################### [100%]
[root@dhcp102 root]# rpm -Uvh nscd*rpm
Preparing...                ########################################### [100%]
   1:nscd                   ########################################### [100%]  

Step 2: Modify Configuration Files

Here is a list of the config files that must be modified:

Before you do anything else, backup the orginal config files to another directory, or add the .org extension to them.

First, let's add entries in /etc/hosts for the DAS servers. These will be used by ypbind (the NIS client):

10.10.22.42 das-m
10.10.22.40 das-s

Now, let's configure /etc/yp.conf with information about our NIS servers. This file is used by the ypbind daemon.

# /etc/yp.conf - ypbind configuration file
# Valid entries are
#
#domain NISDOMAIN server HOSTNAME
#       Use server HOSTNAME for the domain NISDOMAIN.
#
#domain NISDOMAIN broadcast
#       Use  broadcast  on  the local net for domain NISDOMAIN
#
#ypserver HOSTNAME
#       Use server HOSTNAME for the  local  domain.  The
#       IP-address of server must be listed in /etc/hosts.
#
ypserver das-m
ypserver das-s

The next item is the /etc/nsswitch.conf file. Here is what it should look like:

#
# /etc/nsswitch.conf
#

passwd:     files nis
shadow:     files 
group:      files nis

hosts:      files dns nis

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files

netgroup:   nisplus

publickey:  nisplus

automount:  files 
aliases:    files

Note: Most of the remarks have been omitted for the sake of clarity and brevity.

We also need to setup the /etc/sysconfig/network file so that the NIS domain is assigned during system boot. Here is what the /etc/sysconfig/network file looked like on my Mandrake test system:

NETWORKING=yes
NISDOMAIN=kerb.org

Next, we need to edit or create the /etc/krb5.conf file. It should look like this:

[logging]
 default = FILE:/var/log/kerberos/krb5libs.log
 kdc = FILE:/var/log/kerberos/krb5kdc.log
 admin_server = FILE:/var/log/kerberos/kadmind.log

[libdefaults]
 ticket_lifetime = 24000
 default_realm = KERB.ORG
 default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc
 default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc
 permitted_enctypes = des3-hmac-sha1 des-cbc-crc
 dns_lookup_realm = false
 dns_lookup_kdc = false
 kdc_req_checksum_type = 2
 checksum_type = 2
 ccache_type = 1
 forwardable = true
 proxiable = true

[realms]
 KERB.ORG = {
  kdc = das-m.kerb.org:88
  kdc = das-s.kerb.org:88
  admin_server = das-m.kerb.org:749
  default_domain = kerb.org
 }

[domain_realm]
 .kerb.org = KERB.ORG
 kerb.org = KERB.ORG

[pam]
 debug = false
 ticket_lifetime = 36000
 renew_lifetime = 36000
 forwardable = true
 krb4_convert = false

[login]
 krb4_convert = false
 krb4_get_tickets = false

Now, all we have left is the PAM configuration. Here is what the config file needs to look like:

/etc/pam.d/system-auth

#%PAM-1.0
# password aging for Kerb5 users not supported in this config

auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth
auth        sufficient    /lib/security/pam_krb5.so use_first_pass minimum_uid=5000
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so

password    required      /lib/security/pam_cracklib.so retry=3 minlen=2  dcredit=0  ucredit=0 
password    sufficient    /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so
session     required      /lib/security/pam_mkhomedir.so skel=/etc/skel umask=007
session     optional      /lib/security/pam_krb5.so minimum_uid=5000

Depending on how you use your Mandrake system, you may also want to modify some of the other PAM config files in /etc/pam.d

Warning:  When you are altering the PAM config files, keep a root console open and test all your changes. Otherwise, you may be locked out of your own system.

Note: The "mkhomedir" PAM module is included so that every DAS user will automatically be given a home directory after their first login to the system. If you do not want this behavior, simply comment the line out.

Step 3: Start the DAS client services, and configure them to start automatically during boot

[root@dhcp102 root]# domainname kerb.org
[root@dhcp102 root]# domainname
kerb.org
[root@dhcp102 root]# /etc/init.d/portmap restart
Stopping portmap services:                                      [  OK  ]
Starting portmapper:                                            [  OK  ]
[root@dhcp102 root]# /etc/init.d/sshd restart
Stopping sshd:                                                  [  OK  ]
Starting sshd:                                                  [  OK  ]
[root@dhcp102 root]# /etc/init.d/ypbind start
Binding to the NIS domain...                                    [  OK  ]
Listening for an NIS domain server: .das-m
[root@dhcp102 root]# /etc/init.d/nscd start
Starting nscd:                                                  [  OK  ]
[root@dhcp102 root]# chkconfig portmap off
[root@dhcp102 root]# chkconfig ypbind off
[root@dhcp102 root]# chkconfig nscd off
[root@dhcp102 root]# chkconfig --level 345 portmap on
[root@dhcp102 root]# chkconfig --level 345 ypbind on
[root@dhcp102 root]# chkconfig --level 345 nscd on

Step 4: Make Sure System Clock is Synchronized

You can setup time synchronization by setting up ntpd, or by using ntpdate. Please refer to the Client Time Synchronization section for details.

Step 5: Test

First, make sure that the host is able to bind to the NIS domain. This can be done with the following command:

[root@dhcp102 root]# ypwhich
das-m

You should see "das-m" or "das-s". You can test NIS client functionality with the following additional commands:

If you are not having any luck with this, use the ps and netstat commands to check that the portmapper and ypbind are both running.

NIS testing example:

[root@dhcp102 root]# ypwhich -m
hosts.byaddr das-m.kerb.org
hosts.byname das-m.kerb.org
group.bygid das-m.kerb.org
group.byname das-m.kerb.org
passwd.byname das-m.kerb.org
ypservers das-m.kerb.org
passwd.byuid das-m.kerb.org

[root@dhcp102 root]# ypcat hosts
4.2.2.3       genuity
10.10.22.1    defgate
10.10.22.68   oscar
4.2.2.1       genuity-pri
10.10.22.90   printer
4.2.2.2       genuity-alt

[root@dhcp102 root]# yppoll hosts.byname
Domain kerb.org is supported.
Map hosts.byname has order number 1068430991. [Mon Nov 10 10:23:11 2003]
The master server is das-m.kerb.org.

[root@dhcp102 root]# id kitty
uid=6000(kitty) gid=50000(labuser) groups=50000(labuser)

[root@dhcp102 root]# getent hosts
127.0.0.1     mysql
10.10.22.42   das-m
10.10.22.40   das-s
4.2.2.3       genuity
10.10.22.1    defgate
10.10.22.68   oscar
4.2.2.1       genuity-pri
10.10.22.90   printer
4.2.2.2       genuity-alt

[root@dhcp102 root]# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100007    2   udp    628  ypbind
    100007    1   udp    628  ypbind
    100007    2   tcp    631  ypbind
    100007    1   tcp    631  ypbind

Getent is an excellent tool. It returns the information for nsswitch.conf entities and includes info from files, NIS, or any other configured name service. For example, "getent hosts" will show you the local hosts file with the NIS host file appended. Use the command "man getent" for more details.

Next, make sure than you can login as a DAS user to the Kerberos realm with kinit. You should do this as a local user, root or another one will work just as well. Here is an example:

[root@dhcp102 root]# kinit -p kitty
Password for kitty@KERB.ORG:
[root@dhcp102 root]# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: kitty@KERB.ORG
 
Valid starting     Expires            Service principal
11/11/03 15:36:33  11/12/03 01:36:33  krbtgt/KERB.ORG@KERB.ORG
        Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
 
 
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
[root@dhcp102 root]# kdestroy
[root@dhcp102 root]# klist
klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0)
 
 
Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Now you know that the Kerberos client programs are working correctly. Next, we will make sure that NIS, PAM, and Kerberos together can login a user from a console or SSH login. You will do this by obtaining a console login prompt. Enter the user "kitty" and then your Kerberos password. You should be logged on. Type klist and make sure that you have a Kerb ticket. Use the kpasswd command to change your Kerb password. Now logout, and try logging back in. You should have no problems.

You will also want to make sure that you can login as a local user or as root from the console. Now, from a remote machine, SSH to the Mandrake host and login as a local user. Then logout, and login as user "kitty". You should be able to login with your Kerb password.

Step 6: Security

First of all, you should probably consider using a packet-filter like iptables on your Mandrake machine to limit who can connect to which ports, as well as shutting off any unnecessary services. Whether you use a packet filter or not, the TCP Wrappers system can be used to add some security. In our case, the use of NIS and the Portmapper have added a potentially vulnerable service to our system. We can minimize the portmapper vulnerability by restricting who can connect to it with TCP wrappers. To do this, all you need to do is create (or edit) the /etc/hosts.allow file so that it looks like this:

#
# hosts.allow	This file describes the names of the hosts which are
#		allowed to use the local INET services, as decided
#		by the '/usr/sbin/tcpd' server.
#
portmap : 127. 10.10.22. : ALLOW
portmap : ALL : DENY

This limits who can connect to the portmapper to the loopback and the 10.10.22.0/24 network. Of course, you may have other restricted services listed in the file.

Packet Filtering:

The "shorewall" package that is included on the Mandrake 9.1 CD#1 is a high-level configuration tool for iptables. By default, running the shorewall config tool will configure a firewall that allows DAS client activity, such as NTP, NIS, and Kerberos traffic.

Step 7: Create Home Directories for DAS Users (optional)

Mandrake 9.1 includes the pam_mkhomedir PAM module. As long as you include it in your /etc/pam.d/system-auth config file, you will not manually have to create directories and skeleton entries for DAS users before they can use any given DAS Client host. However, you may want to control who can use the system by creating the home directories manually for those who need them. As root, here is how you would do that:

[root@dhcp102 home]# mkdir /home/kitty
[root@dhcp102 home]# cp -rv /etc/skel/.[a-z]* /home/kitty
[root@dhcp102 home]# id kitty
uid=6000(kitty) gid=50000(labuser) groups=50000(labuser)
[root@dhcp102 home]# chown -R kitty:labuser /home/kitty
[root@dhcp102 home]# chmod 0750 /home/kitty
[root@dhcp102 home]# ls -ald /home/kitty
drwxr-x---    2 kitty    labuser        90 Nov 11 15:44 /home/kitty/

Operational/Performance Notes

Note 1 - Client performance was very responsive when the DAS-M server was unavailable and the DAS-S server was available.

Note 2 - When both DAS servers are unavailable, boot, local user, and root logins are successful. Local user login is delayed about 5 seconds.

Note 3 - In any situtation where one or both DAS servers are unavailable, using nscd improves responsiveness, since it caches both postive and negative queries.

Note 4 - cron and at may not work for a DAS user when the DAS servers are unavailable. Mail delivery will fail if the output of a job is to be mailed to the local host with a "no such user" type of error. Also, crond may consider the cron job of a DAS user to be "orphaned" if it cannot find the name. If this happens, crond will continue processing other crontabs, but will stop processing the crontabs of DAS users. When the DAS is available again, the DAS user can fix this by deleting his cron job and re-submitting it. Another alternative is for the root user on the host to restart crond. In all cases, checking /var/log/cron should give you some clues.

Note 5 - If you must do administrative work on a DAS client host while it is disconnected from the network, it may cause some annoying delays with some tasks. If this is an issue, simply stop the ypbind daemon. You could also reconfigure the /etc/nsswitch.conf file so that NIS is not referenced.

Note 6 - Kerberized rlogin client sessions were tested for a DAS user. Both the encrypted and non-encrypted versions worked without any problems. I also tested encrypted, kerberized TELNET, which worked fine.


References

MandrakeSoft Home
Mandrake Secure