我正在尝试在 CentOS 6.4 机器上安装 Kerberos 身份验证的 NFS 共享。我尝试从另一台 CentOS 6.4 机器和我们的 NetApp 导出受保护的共享，结果相同。
CentOS 机器和 NetApp 都已加入我们的 Active Directory (2012) 域。我可以使用 AD 凭据通过 SSH 进入 CentOS 机器。kinit、msktuil 等工具都可以使用。我已使用 mskutil 为客户端生成密钥表文件。AD 中的机器帐户具有机器、根、nfs 等的主要记录。时钟都与域控制器同步。
我看到 rpc.gssd 输出（如下）中没有找到密钥，但随后它继续查找根密钥。下一行似乎表明它没有找到上一行中说找到的密钥？
蜂群思维能帮我找到线索吗？我觉得我这一切即将开始运转……
客户端上的 /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)
当我尝试在客户端上挂载导出时，我从挂载命令中看到以下内容：
[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
答案1
不完全确定这是否有帮助，但它看起来很熟悉，就像我刚刚必须解决的问题一样......
我的用户正在经历来自我们拥有的某个特定 Netapp 的 CIFS 共享的随机访问被拒绝消息。花了很长时间才找出问题所在，因为这个问题非常不连贯。我最终将问题缩小到我们的 2 个 2012 域控制器。在 Server 2012 中引入了一项名为“SID 压缩”的新 Kerberos 功能。许多 NAS 设备都存在此问题，因为除非供应商升级代码，否则它们无法使用这个新的 Kerberos 部分。您将收到访问被拒绝错误，因为 Kerberos 将被拒绝从 2012 KDC 协商票证。我们的问题是我们只有 2 个 DC 运行 2012，其余的是 2008，这就是我们的问题如此不连贯的原因，因为它只拒绝恰好从这 2 个 2012 DC 获取票证的客户端。
由于您的环境中只有 2012，我想知道您的 Netapp 和 CentOS 是否都支持 SID 压缩。OnTap 8.1.2P2 是第一个添加此功能的版本，以前的任何版本都不起作用。Kerberos 票证被拒绝的性质甚至不允许 Netapp 回退到 NTLM，因为它认为发生了一些可疑的事情。
以下是直接处理该问题的 MS KB，如果您无法升级 Netapp/CentOS 代码，则可以解释修复方法：http://support.microsoft.com/kb/2774190。您可以更改 Netapp 或 CentOS 框的 AD 计算机对象的 msDS-SupportedEncryptionTypes 属性，该属性将仅忽略这些机器的 Kerberos SID 压缩，从而允许它们正确进行身份验证。
再次，不确定这是否正是问题所在，但它太接近了，我想我必须提一下。