[EMAIL PROTECTED] (Alok Gore) wrote in message news:<[EMAIL PROTECTED]>... > >>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/[EMAIL PROTECTED]
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/[EMAIL PROTECTED] > Valid starting Expires > Service principal > Wed May 05 01:07:17 2004 Wed May 05 11:07:17 2004 > krbtgt/[EMAIL PROTECTED] > renew until Wed May 12 01:07:17 2004 > > client#klist -k > Keytab name: FILE:/etc/krb5/krb5.keytab > KVNO Principal > ---- -------------------------------------------------------------------------- > 4 nfs/[EMAIL PROTECTED] > 4 nfs/[EMAIL PROTECTED] 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/[EMAIL PROTECTED]: <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. ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
