How to set up NFS client for Kerberized access in Solaris

[Mike Eisler]

alokgore at rediffmail.com (Alok Gore) wrote in message news:<a9877ca0.0405050255.403754ed at posting.google.com>...
> >>It might help if you use real names of clients and servers in your
> >>examples.
> 
> 
> server#klist
> Ticket cache: /tmp/krb5cc_0
> Default principal: root/nfs-alok.blr.novell.com at NFS-REALM

I don't like realms that aren't upper case fully qualified domain
names (fqdns). Your is upper case but not a fqdn. I can't say for sure
when I was leading the SEAM team at Sun that this was ever attempted. 
Wyllys might know if this works.

The other thing is that you are showing the klist output on the
NFS server. We need to klist output for the client.
(nfs-alok.blr.novell.com).
kinit'ing to root/<client name> on the NFS server is of no use.

> CLIENT::
> client#ps -eaf |grep gssd
>     root   527     1  0 06:46:45 ?        0:00 /usr/lib/gss/gssd
> client#klist
> Ticket cache: /tmp/krb5cc_0
> Default principal: root/dharma.blr.novell.com at NFS-REALM
> Valid starting                       Expires                      
> Service principal
> Wed May 05 01:07:17 2004  Wed May 05 11:07:17 2004 
> krbtgt/NFS-REALM at NFS-REALM
>         renew until Wed May 12 01:07:17 2004
> 
> client#klist -k
> Keytab name: FILE:/etc/krb5/krb5.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
>    4 nfs/nfs-alok.blr.novell.com at NFS-REALM
>    4 nfs/nfs-alok.blr.novell.com at NFS-REALM

There no record of you doing a kinit on the nfs client nor is
there a root/nfs-alog.blr.novell.com entry in the client's
keytab.

> >>Read the documentation on our web site.  You will find detailed, 
> >>step-by-step
> >>instructions for configuring Kerberized NFS.
> 
> Yes! In fact, that was the first source of my information.
> I have done everthing including the set-up of gsscred table
> only two things are not clear to me in the doc.

So it looks like to me that the SEAM docs for Solaris 8 are not quite
as detailed and task oriented as thos for Solaris 7. SEAM for Solaris
7
was packaged in the SEAS 3.0 product. Try following the instructions
for
SEAM 1.0 in SEAS 3.0. Specifically:

http://docs.sun.com/db/doc/805-5500/6j56o02or?q=Solaris+Easy+Access+Server+SEAM&a=view

Step 6 says:

Optional) If you want a user on the SEAM client to automatically mount
Kerberized NFS file systems using Kerberos authentication, you must
authenticate the root user.

This process is done most securely by using the kinit command;
however, users will need to use kinit as root every time they need to
mount a file system secured by Kerberos. You can choose to use a
keytab file instead. See "Setting Up Root Authentication to Mount NFS
File Systems" for detailed information about the keytab requirement.



client1 # /usr/krb5/bin/kinit root/client1.acme.com
Password for root/client1.acme.com at ACME.COM: <Enter password>
 

To use the keytab file option, add the root principal to the client's
keytab using kadmin:



client1 # /usr/krb5/sbin/kadmin -p kws/admin
Enter password: <Enter kws/admin password>
kadmin: ktadd root/client1.acme.com
kadmin: Entry for principal root/client.acme.com with
  kvno 3, encryption type DES-CBC-CRC added to keytab
  WRFILE:/etc/krb5/krb5.keytab
kadmin: quit
 
The at the bottom of the web page it says:

Setting Up Root Authentication to Mount NFS File Systems
If users want to access a non-Kerberized NFS file system, either the
NFS file system can be mounted as root, or the file system can be
accessed automatically through the automounter whenever they access it
(without requiring root permissions).

Mounting a Kerberized NFS file system is very much the same, but it
does incur an additional obstacle. To mount a Kerberized NFS file
system, users must use the kinit command as root to obtain credentials
for the client's root principal, because a client's root principal is
typically not in the client's keytab. This is true even when the
automounter is set up. Not only is this an extra step, but it forces
all users to know their system's root password and the root
principal's password.

To bypass this, you can add a client's root principal to the client's
keytab, which will automatically provide credentials for root.
Although this enables users to mount NFS file systems without running
the kinit command and enhances ease-of-use, it is a security risk. For
example, if someone gains access to a system with the root principal
in its keytab, the person has the capability of obtaining credentials
for root. So make sure you take the appropriate security precautions.
See "Administering Keytabs" for more information.

> 1) My KDC and the NFS Client server are not time-synchronized. But I
> have set the time manually on those machines which is almost matching.
>    But if that *can* create problems like this, I will do a set-up for
> running NTP  on those machines. Should I ?

You should run NTP, but to get things going it is not
needed. On the NFS client and server run rdate, specifying the
name of the KDC host.

> 2) Somewhere in the SEAM configuration Doc they say: Two KDCs are must
> for SEAM to work,
>     Even in my kerberos set-up (during installation) I was forced to
> enter two KDC host names (I have kept both same)
>         [realms]
>         NFS-REALM = {
>                 kdc = nfstest5.blr.novell.com
>                 kdc = nfstest5.blr.novell.com
>                 admin_server = nfstest5.blr.novell.com
>         }
>    Does it matter ?

No, this will work for the purpose of getting Kerberized NFS
going. You can list just one kdc = line and delete the
other one. But for production, it is bad, really bad. Lose the
KDC, and your client's won't be able to access Kerberos. Things
will fail, the sky will fall, and civilization will grind to a halt.