On Tue, Sep 18, 2012 at 5:00 PM, Matt Garman <[email protected]> wrote: > On Tue, Sep 18, 2012 at 3:20 PM, Frank Cusack <[email protected]> wrote: >> Since you are initializing the ccache in the crontab itself, first of all >> make sure your kinit command is placing the ccache in the correct (for gssd) >> location. If that's fine (log the output of klist somewhere to be sure) >> then you are going to have to debug gssd. You can run it in the foreground >> in another window and see why it is failing. Sounds like this happens >> quickly so you'll be able to iterate quickly. You can set your ticket >> lifetime down to 1 minute to make it go faster. > > OK, I'm trying exactly that, but not coming up with anything obviously > wrong (to me anyway). Hoping some more some experienced eyes might > catch something that I'm not. Below, I have the output from three > different terminals: (1) the root terminal of the client machine > w/rpc.gssd running, (2) the user ("matt") terminal of the client > machine running kinit and trying to view his share, and (3) the root > terminal of the server w/rpc.svcgssd running. > > I inserted a few of my own comments, so you can follow what events > triggered what log messages. > > === CLIENT MACHINE, ROOT TERMINAL === > [root@lnxsvr95 ~]# rpc.gssd -f -vvv -rrr > --- startup --- > Using keytab file '/etc/krb5.keytab' > Processing keytab entry for principal 'nfs/[email protected]' > We will use this entry (nfs/[email protected]) > Processing keytab entry for principal > 'host/[email protected]' > We will NOT use this entry (host/[email protected]) > Using (machine) credentials cache: 'MEMORY:/tmp/krb5cc_machine_MYDOMAIN.COM' > > --- mounting the nfsv4 share --- > handling krb5 upcall > Using keytab file '/etc/krb5.keytab' > INFO: Credentials in CC 'MEMORY:/tmp/krb5cc_machine_MYDOMAIN.COM' are > good until 1348036914 > using MEMORY:/tmp/krb5cc_machine_MYDOMAIN.COM as credentials cache for > machine creds > using environment variable to select krb5 ccache > MEMORY:/tmp/krb5cc_machine_MYDOMAIN.COM > creating context using fsuid 0 (save_uid 0) > creating tcp client for server lnxutil6.mydomain.com > creating context with server [email protected] > DEBUG: serialize_krb5_ctx: lucid version! > prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 > doing downcall > > --- trying to ls a mode 700 directory on the nfsv4 share --- > handling krb5 upcall > getting credentials for client with uid 502 for server lnxutil6.mydomain.com > CC file 'krb5cc_529_iJEIV30226' being considered > '/tmp/krb5cc_529_iJEIV30226' owned by 529, not 502 > CC file 'krb5cc_507_zBnpJ16105' being considered > '/tmp/krb5cc_507_zBnpJ16105' owned by 507, not 502 > [ ... snip, repeats for many various users ... ] > CC file 'krb5cc_502' being considered > CC file 'krb5cc_502' matches owner check and has mtime of 1348000957 > CC file 'krb5cc_520_TpCqIK9958' being considered > using FILE:/tmp/krb5cc_502 as credentials cache for client with uid > 502 for server lnxutil6.mydomain.com > using environment variable to select krb5 ccache FILE:/tmp/krb5cc_502 > creating context using fsuid 502 (save_uid 0) > creating tcp client for server lnxutil6.mydomain.com > creating context with server [email protected] > DEBUG: serialize_krb5_ctx: lucid version! > prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 > doing downcall > > > === CLIENT MACHINE, USER TERMINAL === > $ kinit -V -k -t matt.keytab -l 2m matt/cron > Authenticated to Kerberos v5 > > $ klist > Ticket cache: FILE:/tmp/krb5cc_502 > Default principal: matt/[email protected] > > Valid starting Expires Service principal > 09/18/12 15:42:29 09/18/12 15:44:37 krbtgt/[email protected] > renew until 09/18/12 15:42:29 > 09/18/12 15:42:33 09/18/12 15:44:37 nfs/[email protected] > renew until 09/18/12 15:42:29 > > > Kerberos 4 ticket cache: /tmp/tkt502 > klist: You have no tickets cached > > > === SERVER MACHINE, ROOT TERMINAL === > [root@lnxutil6 log]# rpc.svcgssd -f -vvv -rrr > Warning: rpcsec_gss library does not support setting debug level > entering poll > > --- mounting the nfsv4 share --- > leaving poll > handling null request > sname = nfs/[email protected] > DEBUG: serialize_krb5_ctx: lucid version! > prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 > doing downcall > mech: krb5, hndl len: 4, ctx len 85, timeout: 1348036914 (35983 from > now), clnt: [email protected], uid: -1, gid: -1, num aux grps: > 0: > sending null reply > writing message: \x \x6082...[truncated] > finished handling null request > entering poll > > --- trying to ls a mode 700 directory on the nfsv4 share --- > leaving poll > handling null request > sname = matt/[email protected] > DEBUG: serialize_krb5_ctx: lucid version! > prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 > doing downcall > mech: krb5, hndl len: 4, ctx len 85, timeout: 1348001077 (116 from > now), clnt: matt@cron, uid: -1, gid: -1, num aux grps: 0: > sending null reply > writing message: \x \x6082...[truncated] > finished handling null request > entering poll > > === end of logs === > > If it's not obvious, the uid of user "matt" is 502. lnxutil6 is the > nfs server, and lnxsvr95 is the client. > > Thanks again! > Matt
The authentication appears to be working for both the mount and matt's access. > mech: krb5, hndl len: 4, ctx len 85, timeout: 1348036914 (35983 from > now), clnt: [email protected], uid: -1, gid: -1, num aux grps: 0: > mech: krb5, hndl len: 4, ctx len 85, timeout: 1348001077 (116 from > now), clnt: matt@cron, uid: -1, gid: -1, num aux grps: 0: However, name mapping (on the server) is failing for both (uid: -1, gid: -1), therefore "nobody" access is given to both users. If you "man idmapd.conf", does it show the option for Static mapping? Maybe you could attempt to map matt/[email protected] to matt on the server? i.e. [Static] matt/[email protected] = matt ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
