FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 11-16-2010, 12:31 PM
Hans Persson
 
Default Still have problems with secure NFS and Kerberos

Both pc13267 and pc14113 run CentOS 5.5. On pc14113, my test user gets a
home directory when logging in, but not on pc13267. But why?

All logs below are from /var/log/messages. I have removed dates and
stuff from the beginning of lines to make them more readable, and then
grouped lines about the same thing from both machines.

> pc13267 Using keytab file '/etc/krb5.keytab'
> pc13267 INFO: Credentials in CC
> 'MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE' are good until
> 1288959329

> pc14113 getting credentials for client with uid 2038 for server
> triangulum.ifm.liu.se
> pc14113 CC file 'krb5cc_2038_R3Gzcw' being considered
> pc14113 CC file 'krb5cc_2038_R3Gzcw' matches owner check and has
> mtime of 1288949932

For some reason, only the broken machine appears to look
in /etc/krb5.keytab (or at least it's the only one admitting to doing
it).

/etc/krb5.conf looks the same on both machines.

/etc/krb5.keytab has the same rights (root.root, 600) and size on both
machines, and as far as I can tell no differences in content:

> [root@pc13267 ~]# klist -k -e
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- -----------------------------------------------------------------
> 20 host/pc13267.ad.ifm.liu.se@IFM.LIU.SE (DES cbc mode with
RSA-MD5)
> 6 nfs/pc13267.ad.ifm.liu.se@IFM.LIU.SE (DES cbc mode with CRC-32)

> [root@pc14113 ~]# klist -k -e
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- -----------------------------------------------------------------
> 3 nfs/pc14113.ad.ifm.liu.se@IFM.LIU.SE (DES cbc mode with CRC-32)
> 3 host/pc14113.ad.ifm.liu.se@IFM.LIU.SE (DES cbc mode with
RSA-MD5)


There are no differences in /etc/pam.d/ between the machines (except
that the working machine apart from the files it should have also has a
system-auth-ac~, but I have a hard time imagining that to be
significant).


> pc13267 using MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE as credentials
> cache for machine creds
> pc13267 using environment variable to select krb5 ccache
> MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE

> pc14113 using FILE:/tmp/krb5cc_2038_R3Gzcw as credentials cache for
> client with uid 2038 for server triangulum.ifm.liu.se
> pc14113 using environment variable to select krb5 ccache
> FILE:/tmp/krb5cc_2038_R3Gzcw

The machine having problems save to memory, the working one to disk, and
they use file names with a different structure. I suspect this to be
relevant somehow, but I have no clue why they behave differently.


> pc13267 creating context using fsuid 0 (save_uid 0)
> pc13267 creating tcp client for server triangulum.ifm.liu.se
> pc13267 creating context with server nfs@triangulum.ifm.liu.se

> pc14113 creating context using fsuid 2038 (save_uid 0)
> pc14113 creating tcp client for server triangulum.ifm.liu.se
> pc14113 creating context with server nfs@triangulum.ifm.liu.se

The machine that works gets the uid right while the other one for some
reason gets it to 0. Definitely wrong, but why?


> pc13267 rpcsec_gss: gss_init_sec_context: (major) Unspecified GSS
> failure. Minor code may provide more information - (minor)
> Unknown code krb5 60
> pc13267 WARNING: Failed to create krb5 context for user with uid 0
> for server triangulum.ifm.liu.se
> pc13267 WARNING: Failed to create krb5 context for user with uid 0
> with credentials cache MEMORY:/tmp/krb5cc_machine_IFM.LIU.SE for
> server triangulum.ifm.liu.se
> pc13267 WARNING: Failed to create krb5 context for user with uid 0
> with any credentials cache for server triangulum.ifm.liu.se

> pc14113 DEBUG: serialize_krb5_ctx: lucid version!
> pc14113 prepare_krb5_rfc1964_buffer: serializing keys with enctype 4
> and length 8

After this, things break down (which doesn't really surprise me). The
question is, I guess, why the broken machine starts using uid 0 to begin
with.


There is also a difference in what tickets the user gets on the
different machines.

> [testson2@pc13267 /]$ klist
> Ticket cache: FILE:/tmp/krb5cc_2038_ch9xY3
> Default principal: testson2@IFM.LIU.SE
>
> Valid starting Expires Service principal
> 11/05/10 10:34:46 11/06/10 10:34:46 krbtgt/IFM.LIU.SE@IFM.LIU.SE
>
>
> Kerberos 4 ticket cache: /tmp/tkt2038
> klist: You have no tickets cached

(non-working)

> pc14113:/home/testson2> klist
> Ticket cache: FILE:/tmp/krb5cc_2038_R3Gzcw
> Default principal: testson2@IFM.LIU.SE
>
> Valid starting Expires Service principal
> 11/05/10 10:38:52 11/06/10 10:38:52 krbtgt/IFM.LIU.SE@IFM.LIU.SE
> 11/05/10 10:38:52 11/06/10 10:38:52
nfs/triangulum.ifm.liu.se@IFM.LIU.SE
>
>
> Kerberos 4 ticket cache: /tmp/tkt2038
> klist: You have no tickets cached

(working)

Ideas? I'm all out of 'em.

Hans


_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 01:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org