Проблемы при монтировании общего ресурса NFS с проверкой подлинности Kerberos на CentOS 6.4

Я пытаюсь смонтировать раздел NFS с проверкой подлинности Kerberos на компьютере с CentOS 6.4. Я попытался экспортировать защищенный общий ресурс как с другой машины CentOS 6.4, так и с нашего NetApp с теми же результатами.

Машины CentOS и NetApp объединены в наш домен Active Directory (2012). Я могу использовать SSH на машинах CentOS, используя учетные данные AD. Инструменты, такие как kinit, msktuil и т. Д. Работают. Я использовал mskutil для создания файла keytab для клиента. Учетная запись компьютера в AD имеет основные записи для компьютера, root, nfs и т. Д. Все часы синхронизируются с контроллерами домена.

В выводе rpc.gssd (ниже) я вижу, что он не находит ключ, но затем он продолжает искать корневой ключ. Кажется, следующая строка показывает, что он НЕ нашел ключ, который, как он сказал, он нашел в предыдущей строке?

Может ли разум улья подсказать мне здесь? Я чувствую, что я так близок к тому, чтобы все работало...

Соответствующий бит файла /etc/krb5.keytab на клиенте выглядит следующим образом:

5 12/02/13 16:14:14 srred1kt01$@WORK.LOCAL
5 12/02/13 16:14:14 root/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:14 root/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 root/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 NFS/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 NFS/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 NFS/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 NFS/srred1kt01@WORK.LOCAL
5 12/02/13 16:14:15 NFS/srred1kt01@WORK.LOCAL
5 12/02/13 16:14:15 NFS/srred1kt01@WORK.LOCAL
5 12/02/13 16:14:15 HOST/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 HOST/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 HOST/srred1kt01.work.local@WORK.LOCAL
5 12/02/13 16:14:15 HOST/SRRED1KT01@WORK.LOCAL
5 12/02/13 16:14:15 HOST/SRRED1KT01@WORK.LOCAL
5 12/02/13 16:14:15 HOST/SRRED1KT01@WORK.LOCAL

Экспорт на сервере 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 SRRED1KT01.WORK.LOCAL$@WORK.LOCAL while getting keytab entry for 'SRRED1KT01.WORK.LOCAL$@WORK.LOCAL       '
Success getting keytab entry for 'root/srred1kt01.work.local@WORK.LOCAL'
WARNING: Client not found in Kerberos database while getting initial ticket for principal 'root/srred1kt01.work.local@WORK.LOCAL' 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 ответ

Не совсем уверен, поможет ли это, но это кажется настолько знакомым, как проблема, которую мне просто нужно было устранить...

Мои пользователи сталкивались с сообщениями об отказе в произвольном доступе из общего ресурса CIFS одного конкретного Netapp, который у нас есть. Потребовалось много времени, чтобы выяснить проблему, потому что это было так непостоянно. Я наконец сузил это до наших 2 контроллеров домена 2012 года. В Server 2012 появилась новая функция Kerberos под названием "Сжатие SID". Есть много устройств NAS, у которых есть проблемы с этим, потому что он не может говорить на этом новом фрагменте Kerberos, пока поставщик не обновит код. Вы получите ошибки об отказе в доступе, потому что Kerberos будет отказано в согласовании билетов от KDC 2012. Наша проблема заключалась в том, что у нас было только два DC, работающих в 2012 году, а остальные - в 2008 году, и это стало причиной того, что наша проблема была настолько неустойчивой, поскольку она только отрицала клиентов, которые случайно получили свои билеты от этих 2 DC 2012 года.

Поскольку в вашей среде только 2012, мне интересно, могут ли ваши Netapp и CentOS поддерживать сжатие SID. OnTap 8.1.2P2 является первым выпуском, который добавляет эту функцию, все предыдущие не будут работать. Характер отказа в билете Kerberos даже не позволит Netapp вернуться к NTLM, потому что он думает, что происходит что-то подозрительное.

Вот MS KB, которая непосредственно связана с проблемой и объясняет исправление, если вы не можете обновить код Netapp/CentOS: http://support.microsoft.com/kb/2774190. Вы можете изменить атрибут msDS-SupportedEncryptionTypes компьютерного объекта AD вашего блока Netapp или CentOS, который будет игнорировать сжатие SID для Kerberos только для этих машин, что позволит им правильно проходить аутентификацию.

Опять же, не уверен, что это именно проблема, но это так близко, что я решил упомянуть об этом.

Другие вопросы по тегам