Problemas na montagem do compartilhamento NFS autenticado por Kerberos no CentOS 6.4

Question

Estou tentando montar um compartilhamento NFS autenticado por Kerberos em uma máquina CentOS 6.4. Eu tentei exportar o compartilhamento protegido de outra máquina CentOS 6.4 e de nossa NetApp com os mesmos resultados.

As máquinas CentOS e a NetApp estão todas integradas ao nosso domínio do Active Directory (2012). Eu posso SSH para as máquinas CentOS usando credenciais do AD. Ferramentas como kinit, msktuil, etc funcionam. Eu usei o mskutil para gerar o arquivo keytab para o cliente. A conta da máquina no AD tem registros principais para a máquina, raiz, nfs, etc. Os relógios são todos sincronizados com os controladores de domínio.

Eu vejo na saída rpc.gssd (abaixo) que ela não está encontrando uma chave, mas depois ela encontra a chave raiz. A próxima linha parece mostrar que NÃO encontrou a chave que disse ter encontrado na linha anterior?

A mente da colméia pode me ajudar a entrar aqui? Eu sinto que sou isso perto de ter coisas funcionando ...

O bit relevante do arquivo /etc/krb5.keytab no cliente se parece com isto:

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]

A exportação no servidor NFS é assim:

/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)

Quando tento montar a exportação no cliente, vejo isso no comando 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

A saída de "rpc.gssd -fvvv" no cliente é assim:

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

    

Answer 1

Não tenho certeza se isso vai ajudar, mas parece tão familiar como um problema que eu tive que resolver ...

Meus usuários estavam experimentando mensagens negadas de acesso aleatório de um compartilhamento CIFS de um Netapp específico que possuímos. Demorou muito tempo para descobrir o problema porque era tão intermitente. Eu finalmente reduzi para os nossos 2 controladores de domínio de 2012. No Server 2012, há um novo recurso Kerberos introduzido chamado "SID Compression". Há muitos dispositivos NAS que têm problemas com isso porque não podem falar essa nova parte do Kerberos, a menos que o fornecedor atualize o código. Você receberá erros de acesso negado porque o Kerberos não poderá negociar ingressos de um KDC de 2012. Nossa questão era que só tínhamos 2 CDs funcionando em 2012 e o restante são 2008, que é a razão pela qual nosso problema era tão intermitente, já que era apenas para negar aos clientes que apenas recebessem seus ingressos desses 2 CDs de 2012.

Como você só tem 2012 em seu ambiente, gostaria de saber se o NetApp e o CentOS podem suportar a compactação SID. O OnTap 8.1.2P2 é o primeiro lançamento que adiciona esse recurso, qualquer coisa anterior não funcionará. A natureza de como o ticket do Kerberos é negado não permitirá que o Netapp volte ao NTLM porque acha que algo suspeito está acontecendo.

Aqui está o MS KB que lida diretamente com o problema e explica uma correção se você não puder atualizar seu código NetApp / CentOS: link . Você pode alterar o atributo msDS-SupportedEncryptionTypes do objeto de computador AD da sua caixa Netapp ou CentOS, que ignorará a Compactação SID para Kerberos somente para essas máquinas, permitindo que elas sejam autenticadas corretamente.

Mais uma vez, não tenho certeza se esse é exatamente o problema, mas é tão próximo que eu tive que mencionar isso.