Я пытаюсь смонтировать общий ресурс NFS с аутентификацией Kerberos на машине CentOS 6.4. Я попытался экспортировать защищенный общий ресурс как с другой машины CentOS 6.4, так и с нашего NetApp с теми же результатами.
Все машины CentOS и NetApp присоединены к нашему домену Active Directory (2012). Я могу подключиться к машинам CentOS по SSH, используя учетные данные AD. Такие инструменты, как кинит, мсктуил и др. Работают. Я использовал 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
Не совсем уверен, поможет ли это, но это кажется таким знакомым, как проблема, которую мне просто нужно было устранить ...
Мои пользователи получали сообщения об отказе в произвольном доступе из общего ресурса CIFS от одного конкретного NetApp, который у нас есть. На то, чтобы разобраться в проблеме, потребовалось много времени, потому что она возникала периодически. Я, наконец, сузил его до наших 2 контроллеров домена 2012 года. В Server 2012 появилась новая функция Kerberos, которая называется «Сжатие SID». Есть много устройств NAS, у которых есть проблемы с этим, потому что они не могут использовать эту новую часть Kerberos, если поставщик не обновит код. Вы получите ошибки отказа в доступе, потому что Kerberos будет отказано в согласовании билетов от KDC 2012. Наша проблема заключалась в том, что у нас было только 2 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 только для этих компьютеров, что позволит им правильно аутентифицироваться.
Опять же, не уверен, что это именно проблема, но это так близко, что я решил, что должен упомянуть об этом.