Introduction

The Fedora Core 2 GNU/Linux distribution is easy to setup as a DAS client. It provides updated Kerberos, PAM, and NIS binary RPM packages. Configuration is fairly simple. FC-2 also supports the Name Service Cache Daemon, or NSCD, which is installed by default. This reduces the load on the NIS servers and the network by caching lookups for a period of time. It also helps with performance when the DAS-M (master) is unavailable.

Fedora Core 2 (FC-2) comes with the MIT version of Kerberos V. Of all the distributions I tested, Red Hat, Fedora Core, and Mandrake were the simplest to setup as DAS clients, with Red Hat/Fedora Core easily being the quickest.

Assumptions

These FC-2 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 some of the libraries and RPMs are already installed, we will get the latest RPM's from Red Hat and install ALL of the necessary RPM packages. At the time of this writing, these were the relevant packages:

Optional Packages:

Every package was installed by Anaconda except for krb5-workstation. This was found on FC-2 ISO disk #1, in the Fedora/RPMS directory. It can be installed with the following command:

rpm -Uvh krb5-workstation*rpm

The best way to upgrade/update these packages is by using yum or up2date.

If you need to install/upgrade these packages manually, then use this command from a newly-created directory containing the packages:

rpm -Uvh *rpm

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

Since we are setting up NIS client services for the first time, we must use the domainname command to set the NIS domain. Example:

[root@fc2 root]# domainname kerb.org
[root@fc2 root]# domainname
kerb.org

In order to set the NIS domain name correctly on system boot, we need to add the following line to the /etc/sysconfig/network config file:

NISDOMAIN=kerb.org

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: files
 
ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files
 
netgroup:   files
 
publickey:  nisplus
 
automount:  files
aliases:    files

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

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

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
 ticket_lifetime = 24000
 default_realm = KERB.ORG
 dns_lookup_realm = false
 dns_lookup_kdc = false
 
[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
 
[kdc]
 profile = /var/kerberos/krb5kdc/kdc.conf
 
[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = 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

auth        required      /lib/security/$ISA/pam_env.so
auth        sufficient    /lib/security/$ISA/pam_unix.so likeauth
auth        sufficient    /lib/security/$ISA/pam_krb5.so use_first_pass minimum_uid=5000
auth        required      /lib/security/$ISA/pam_deny.so
 
account     sufficient    /lib/security/$ISA/pam_succeed_if.so uid < 100
account     required      /lib/security/$ISA/pam_unix.so
 
password    requisite     /lib/security/$ISA/pam_cracklib.so retry=3
password    sufficient    /lib/security/$ISA/pam_unix.so use_authtok md5 shadow
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_mkhomedir.so skel=/etc/skel/ umask=007
session     optional      /lib/security/$ISA/pam_krb5.so minimum_uid=5000

Depending on how you use your FC-2 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. The user's first login has to be from the console, though. It does not function through SSH. 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@fc2 etc]# /etc/init.d/portmap start
Starting portmapper:                                       [  OK  ]
[root@fc2 etc]# /etc/init.d/ypbind start
Binding to the NIS domain:                                 [  OK  ]
Listening for an NIS domain server..
[root@fc2 etc]# /etc/init.d/nscd start
Starting nscd:                                             [  OK  ]
[root@fc2 etc]# chkconfig portmap off
[root@fc2 etc]# chkconfig ypbind off
[root@fc2 etc]# chkconfig nscd off
[root@fc2 etc]# chkconfig --level 345 portmap on
[root@fc2 etc]# chkconfig --level 345 ypbind on
[root@fc2 etc]# 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@fc2 etc]# 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@fc2 etc]# 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@fc2 etc]# ypcat hosts
4.2.2.3       genuity
10.10.22.1    defgate
10.10.22.68   oscar
10.10.230.60  rat
10.10.22.90   printer
4.2.2.2       genuity-alt

[root@fc2 etc]# yppoll hosts.byname
Domain kerb.org is supported.
Map hosts.byname has order number 1082010515. [Thu Apr 15 14:28:35 2004]
The master server is das-m.kerb.org.

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

[root@fc2 root]# getent hosts
10.10.22.68   fc2.kerb.org fc2
10.10.22.42   das-m
10.10.22.40   das-s
127.0.0.1     mysql.localdomain mysql
4.2.2.3       genuity
10.10.22.1    defgate
10.10.22.68   oscar
10.10.230.60  rat
10.10.22.90   printer
4.2.2.2       genuity-alt
[root@fc2 root]# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    391002    2   tcp  32768  sgi_fam
    100007    2   udp    647  ypbind
    100007    1   udp    647  ypbind
    100007    2   tcp    650  ypbind
    100007    1   tcp    650  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@fc2 root]# kinit kitty
Password for kitty@KERB.ORG:
[root@fc2 root]# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: kitty@KERB.ORG
 
Valid starting     Expires            Service principal
06/08/04 13:36:51  06/08/04 23:36:51  krbtgt/KERB.ORG@KERB.ORG
  renew until 06/08/04 13:36:51, 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@fc2 root]# kdestroy
[root@fc2 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 FC-2 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 Fedora Core 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.
#
 
# Secure the Portmapper to our LAN
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.

Using the iptables host-based packet filter/firewall is usually a good idea. UDP requests and replies must be handled correctly to support NIS, Kerberos, NTP, and DNS traffic. Fortunately, FC-2 comes with a simple tool for enabling iptables and the default config supports these types of UDP traffic. It supports the UDP traffic because stateful packet filtering is enabled by default. The only modification you may need to make is the addition of SSH or Kerberized RLOGIN inbound. For this example, I only enabled inbound SSH. The GUI tool can be invoked from the command line with:

[root@fc2 root]# system-config-securitylevel

Traffic that orginates elsewhere can connect to the host only if it is explicitly allowed in the firewall rules. Below are the relevant configuration statements from the /etc/sysconfig/iptables configuration file that is built with the system-config-securitylevel tool:

-A INPUT -j RH-Firewall-1-INPUT
-A FORWARD -j RH-Firewall-1-INPUT
-A RH-Firewall-1-INPUT -i lo -j ACCEPT
-A RH-Firewall-1-INPUT -p icmp --icmp-type any -j ACCEPT
-A RH-Firewall-1-INPUT -p 50 -j ACCEPT
-A RH-Firewall-1-INPUT -p 51 -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A RH-Firewall-1-INPUT -j REJECT --reject-with icmp-host-prohibited

Here is the what the running iptables config looks like:

[root@fc2 root]# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
18102 2304K RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 RH-Firewall-1-INPUT  all  --  *      *       0.0.0.0/0            0.0.0.0/0
 
Chain OUTPUT (policy ACCEPT 8147 packets, 695K bytes)
 pkts bytes target     prot opt in     out     source               destination
 
Chain RH-Firewall-1-INPUT (2 references)
 pkts bytes target     prot opt in     out     source               destination
   52  3952 ACCEPT     udp  --  *      *       10.10.22.42        0.0.0.0/0           udp spt:123 dpt:123
    0     0 ACCEPT     udp  --  *      *       10.10.22.42        0.0.0.0/0           udp spt:123 dpt:123
 3469  287K ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           icmp type 255
    0     0 ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 ACCEPT     ah   --  *      *       0.0.0.0/0            0.0.0.0/0
 4114  469K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
    2   120 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
10465 1544K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

To ensure that iptables starts automatically during system startup, use the chkconfig command:

[root@fc2 sysconfig]# chkconfig --list iptables
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off

If the command results in "off" for your desired runlevel, then do the following:

[root@fc2 sysconfig]# chkconfig iptables off
[root@fc2 sysconfig]# chkconfig --level 2345 iptables on
[root@fc2 sysconfig]# chkconfig --list iptables
iptables        0:off   1:off   2:on    3:on    4:on    5:on    6:off

Final Note:  If you write your own firewall script and then have problems with your DAS client, such as NIS or Kerberos errors, try removing the firewall before diving into any other troubleshooting.

The iptables -L -n -v command can also be a useful way of determining whether or not the packet filter is to blame.



Limiting the "su" command:

Once you setup an application server or client system to use DAS, it is possible for a DAS user to login to many different systems. By default, that user can try to use the su command to obtain a root shell. If the root password on that machine is poorly chosen, you could have a compromise. Therefore, you may want to keep DAS users from using the su command. This is very simple to configure on FC-2:

Make sure that any local users who need to be able to use the su command are added to the "wheel" group. Here is the command:

[root@fc2 root]# usermod -G wheel vano
[root@fc2 root]# id vano
uid=500(vano) gid=500(vano) groups=500(vano),10(wheel)

Now, modify the /etc/pam.d/su config file by un-commenting the pam_wheel.so entry so that the file looks like this:

#%PAM-1.0
auth       sufficient   /lib/security/$ISA/pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth       sufficient   /lib/security/$ISA/pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
auth       required     /lib/security/$ISA/pam_wheel.so use_uid
auth       required     /lib/security/$ISA/pam_stack.so service=system-auth
account    required     /lib/security/$ISA/pam_stack.so service=system-auth
password   required     /lib/security/$ISA/pam_stack.so service=system-auth
session    required     /lib/security/$ISA/pam_stack.so service=system-auth
session    optional     /lib/security/$ISA/pam_selinux.so multiple
session    optional     /lib/security/$ISA/pam_xauth.so

Now, on this system only user "vano" and "root" can use the su command, DAS users cannot.

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

FC-2 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@fc2 home]# mkdir /home/kitty
[root@fc2 home]# cp -rv /etc/skel/.[a-z]* /home/kitty
[root@fc2 home]# id kitty
uid=6000(kitty) gid=50000(labuser) groups=50000(labuser)
[root@fc2 home]# chown -R kitty:labuser /home/kitty
[root@fc2 home]# chmod 0750 /home/kitty
[root@fc2 home]# ls -ald /home/kitty
drwxr-x---    3 kitty    labuser      4096 May  3 17:10 /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 - If the FC-2 host boots while the DAS servers are unavailable, ypbind will not start. Once the DAS servers are available again over the network, you can restore DAS functionality to the client by executing the /etc/init.d/ypbind script as root.

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

Note 5 - Disk quotas for DAS users worked correctly, whether DAS servers were available or not. While the DAS servers are not available, root will not be able to edit a DAS user's quota. Quota, repquota, and edquota all use the Name Service Switch system that is configured by /etc/nsswitch.conf.

Note 6 - 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 7 - 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 queried.

Note 8 - Kerberized rlogin client sessions were tested for a DAS user. Both the encrypted and non-encrypted versions worked without any problems. telnet -x and ftp -x were also tested successfully.

Note 9 - You can setup public SSH keys for authentication, but you will not be granted any Kerberos tickets when you login. In order to use any Kerberized "SSO" clients, you will have to use kinit to get a ticket.

Note 10 - If the Kerberos password expires, you will still be able to login. You will see a warning. This works from the console and from an SSH session. However, you will not have a ticket!

Note 11 - FC-2 has a nice configuration tool called "authconfig" (or "authconfig-gtk") for setting up name services and authentication. Unfortunately, this tool does not configure PAM correctly for our particular application, so we will not use it. If you run "authconfig", it will overwrite (and hose up) your working config.


References

RH 9 Manual - PAM
RH 9 Manual - Kerb5
RH 9 Manual - Securing the Portmapper