Kerberosで認証されたNFS共有をCentOS6.4マシンにマウントしようとしています。保護された共有を別のCentOS6.4マシンとNetAppの両方からエクスポートしようとしましたが、同じ結果になりました。
CentOSマシンとNetAppはすべて、Active Directory(2012)ドメインに参加しています。 AD資格情報を使用してCentOSマシンにSSHで接続できます。 kinit、msktuilなどのツールが機能します。 mskutilを使用して、クライアントのkeytabファイルを生成しました。 ADのマシンアカウントには、マシン、ルート、nfsなどの主要なレコードがあります。クロックはすべてドメインコントローラーに同期されます。
Rpc.gssdの出力(下記)で、キーが見つからないことがわかりますが、その後、ルートキーが見つかります。次の行は、前の行で見つかったと言ったキーが見つからなかったことを示しているようです。
集合精神はここで私を手がかりにするのを助けることができますか?私はthis物事が機能することに近いと感じています...
クライアント上の/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
これが役立つかどうかは完全にはわかりませんが、トラブルシューティングしなければならなかった問題のようによく知られているようです...
私のユーザーは、私たちが持っている特定のNetappからのCIFS共有からのランダムアクセス拒否メッセージを経験していました。それはとても断続的だったので、問題を理解するのに長い時間がかかりました。私はついにそれを2つの2012ドメインコントローラーに絞り込みました。 Server 2012には、「SID圧縮」と呼ばれる新しいKerberos機能が導入されています。ベンダーがコードをアップグレードしない限り、この新しいKerberosを話すことができないため、これに問題があるNASデバイスがたくさんあります。Kerberosはチケットのネゴシエーションを拒否されるため、アクセス拒否エラーが発生します。私たちの問題は、2012年に実行されているDCが2つだけで、残りは2008年であるということでした。これが、2つの2012 DCからチケットを取得するクライアントを拒否するだけだったため、問題が断続的に発生した理由です。
ご使用の環境には2012しかありませんので、NetappとCentOSの両方でSID圧縮をサポートできるかどうか疑問に思います。 OnTap 8.1.2P2は、この機能を追加した最初のリリースであり、以前のリリースでは機能しません。 Kerberosチケットが拒否される方法の性質上、疑わしいことが起こっていると見なされるため、NetappはNTLMにフォールバックすることさえできません。
これは、問題を直接処理し、Netapp/CentOSコードをアップグレードできない場合の修正について説明しているMSKBです: http://support.Microsoft.com/kb/277419 。 NetappまたはCentOSボックスのADコンピューターオブジェクトのmsDS-SupportedEncryptionTypes属性を変更できます。これにより、これらのマシンのKerberosのSID圧縮が無視されるため、正しく認証されます。
繰り返しますが、これが正確に問題であるかどうかはわかりませんが、非常に近いので、言及する必要があると思いました。