我试图在CentOS 6.4机器上安装Kerberosauthentication的NFS共享。 我试图从另一个CentOS 6.4机器和我们的NetApp导出受保护的共享，结果相同。
CentOS机器和NetApp都join到我们的Active Directory（2012）域。 我可以使用AD凭证SSH进入CentOS机器。 诸如kinit，msktuil等工具的工作。 我已经使用mskutil来生成客户端的keytab文件。 AD中的计算机帐户具有计算机，根，nfs等的主要logging。时钟全部同步到域控制器。
我在下面的rpc.gssd输出中看到它没有find一个键，但是它继续find根键。 下一行似乎表明它没有find它在前面的行中find的键？
蜂房的头脑可以帮我在这里find我吗？ 我觉得我已经接近有事情了
客户端上的/etc/krb5.keytab文件的相关位如下所示：
5 12/02/13 16:14:14 [email protected] 5 12/02/13 16:14:14 root/[email protected] 5 12/02/13 16:14:14 root/[email protected] 5 12/02/13 16:14:15 root/[email protected] 5 12/02/13 16:14:15 NFS/[email protected] 5 12/02/13 16:14:15 NFS/[email protected] 5 12/02/13 16:14:15 NFS/[email protected] 5 12/02/13 16:14:15 NFS/[email protected] 5 12/02/13 16:14:15 NFS/[email protected] 5 12/02/13 16:14:15 NFS/[email protected] 5 12/02/13 16:14:15 HOST/[email protected] 5 12/02/13 16:14:15 HOST/[email protected] 5 12/02/13 16:14:15 HOST/[email protected] 5 12/02/13 16:14:15 HOST/[email protected] 5 12/02/13 16:14:15 HOST/[email protected] 5 12/02/13 16:14:15 HOST/[email protected] NFS服务器上的导出如下所示：
/foo gss/krb5(ro,fsid=0,sync,insecure,no_root_squash,no_subtree_check,squash_uids=0-99) /foo/bar gss/krb5(rw,insecure,no_subtree_check,nohide,sync,no_root_squash,squash_uids=0-99)
当我尝试在客户端上安装导出时，我从mount命令中看到了这一点：
[root@srred1kt01 ~]# mount -t nfs4 -o sec=krb5 srred1nfs01:/foo /backups -vvv mount: fstab path: "/etc/fstab" mount: mtab path: "/etc/mtab" mount: lock path: "/etc/mtab~" mount: temp path: "/etc/mtab.tmp" mount: UID: 0 mount: eUID: 0 mount: spec: "srred1nfs01:/foo" mount: node: "/backups" mount: types: "nfs4" mount: opts: "sec=krb5" final mount options: 'sec=krb5' mount: external mount: argv[0] = "/sbin/mount.nfs4" mount: external mount: argv[1] = "srred1nfs01:/foo" mount: external mount: argv[2] = "/backups" mount: external mount: argv[3] = "-v" mount: external mount: argv[4] = "-o" mount: external mount: argv[5] = "rw,sec=krb5" mount.nfs4: timeout set for Mon Dec 2 16:26:44 2013 mount.nfs4: trying text-based options 'sec=krb5,addr=10.10.10.63,clientaddr=10.10.10.62' mount.nfs4: mount(2): Permission denied mount.nfs4: access denied by server while mounting srred1nfs01:/foo
客户端上的“rpc.gssd -fvvv”的输出如下所示：
dir_notify_handler: sig 37 si 0x7fffaa8850b0 data 0x7fffaa884f80 dir_notify_handler: sig 37 si 0x7fffaa8850b0 data 0x7fffaa884f80 dir_notify_handler: sig 37 si 0x7fffaa8850b0 data 0x7fffaa884f80 handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt14) handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt14) process_krb5_upcall: service is '<null>' Full hostname for 'srred1nfs01.work.local' is 'srred1nfs01.work.local' Full hostname for 'srred1kt01.work.local' is 'srred1kt01.work.local' No key table entry found for [email protected] while getting keytab entry for '[email protected] ' Success getting keytab entry for 'root/[email protected]' WARNING: Client not found in Kerberos database while getting initial ticket for principal 'root/[email protected]' using keytab 'FILE:/etc/krb5.keytab' ERROR: No credentials found for connection to server srred1nfs01.work.local doing error downcall dir_notify_handler: sig 37 si 0x7fffaa884b70 data 0x7fffaa884a40 dir_notify_handler: sig 37 si 0x7fffaa884b70 data 0x7fffaa884a40 dir_notify_handler: sig 37 si 0x7fffaa884b70 data 0x7fffaa884a40 dir_notify_handler: sig 37 si 0x7fffaa884b70 data 0x7fffaa884a40 dir_notify_handler: sig 37 si 0x7fffaa884b70 data 0x7fffaa884a40 dir_notify_handler: sig 37 si 0x7fffaa884b70 data 0x7fffaa884a40 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt14
不完全确定，如果这会帮助，但似乎很熟悉，就像我只需要解决问题…
我的用户遇到了来自CIFS分享的随机访问被拒绝的消息，我们有一个特定的Netapp。 由于间歇性的原因，我们花了很长时间才弄清楚这个问题。 我最后把它缩小到了我们的2012年2个域控制器。 在Server 2012中，引入了一个名为“SID压缩”的新Kerberosfunction。 有许多NAS设备都有这个问题，因为除非供应商升级代码，否则不能说这个新的Kerberos。 您将收到访问被拒绝的错误，因为Kerberos将被拒绝与2012年KDC的票据进行谈判。 我们的问题是，我们只有2个区议会运行了2012年，其余的是2008年，这是我们的问题是如此间歇的原因，因为它只是拒绝客户，才刚刚从那些2 2012年区议会获得门票。
既然你在你的环境中只有2012，我不知道你的Netapp和CentOS是否都支持SID压缩。 OnTap 8.1.2P2是第一个增加了这个function的版本，以前的任何东西都不行。 Kerberos票据被拒绝的性质甚至不允许Netapp退回到NTLM，因为它认为有可疑的事情正在发生。
这里是直接处理这个问题的MS KB，并解释如果你不能升级你的Netapp / CentOS代码的解决方法： http : //support.microsoft.com/kb/2774190 。 您可以更改Netapp或CentOS盒子的AD计算机对象的msDS-SupportedEncryptionTypes属性，该属性将忽略仅适用于这些机器的Kerberos的SID压缩，从而允许它们正确进行身份validation。
再次，不知道这是否是问题，但它是如此接近我想我不得不提到它。