Я использую FreeIPA для LDAP / Kerberos и создал принципала для устройства хранения (виртуальная машина Dell / EMC UnityVSA). Я установил VSA с помощью keytab из IPA, я также настроил в VSA конфигурацию LDAP и создал NAS с поддержкой Kerberized NFS share. И IPA, и VSA не сообщают о каких-либо проблемах, и там все выглядит нормально.
С клиента macOS (High Sierra) я могу смонтировать общий ресурс NFSv4, когда Kerberos на сервере отключен (так что основы работают). Однако, когда я указываю Kerberos для безопасности этого общего ресурса, я не могу подключиться («Permission denied»).
Команда, которую я использую для монтирования:
sudo mount_nfs -vv -o sec=krb5,vers=4 <storage-server>:/test ~/test
Результат:
mount <storage-server>:/test on /Users/<user>/test
mount flags: 0x0
socket: type:any,nomntudp
file system locations:
/test
<storage-server>
inet <ip of storage server>
NFS options: fg,retrycnt=1,vers=4,hard,nointr,noresvport,conn,callback,negnamecache,nonamedattr,acl,noaclonly,nocallumnt,locks,quota,rsize=32768,wsize=32768,readahead=16,dsize=32768,nordirplus,nodumbtimr,timeo=10,retrans=10,maxgroups=16,acregmin=5,acregmax=60,acdirmin=5,acdirmax=60,deadtimeout=0,nomutejukebox,noephemeral,nonfc,sec=krb5
mount_nfs: can't mount /test from <storage-server> onto <mount-point>: Permission denied
Я могу получить билет от KDC на стороне клиента. В klist
Команда показывает следующий вывод после того, как я попытаюсь подключиться к общему ресурсу NFS, где вторая запись - это принципал IPA для VSA (сервер хранения).
Credentials cache: API:A2FC2CF2-BA23-CE06-BC50-D5CA1180C946
Principal: admin@<REALM>
Issued Expires Principal
Feb 20 21:13:07 2019 Feb 21 21:12:46 2019 krbtgt/<REALM>@<REALM>
Feb 20 21:18:12 2019 Feb 21 21:12:46 2019 nfs/<storage-server>.<domain>@<REALM>
Файл /etc/krb5.conf на моем клиенте выглядит так:
[libdefaults]
default_realm = <REALM>
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
<REALM> = {
kdc = tcp/<FQDN of IPA>
admin_server = tcp/<FQDN of IPA>
}
[domain_realm]
.<domain> = <REALM>
<domain> = <REALM>
<FQDN of IPA> = <REALM>
<FQDN of storage-server> = <REALM>
Кроме того, я не могу получить kadmin
работать. Например, команда
kadmin admin@REALM.COM
возвращает следующий вывод:
kadmin: kadm5_init_with_password: Cannot contact any KDC for requested realm
Есть мысли, что мне здесь не хватает? Нужен ли мне файл krb5.conf или IPA должен иметь возможность обрабатывать все, что связано с служебными записями в DNS?
Обновить
Когда я указываю AUTH_SYS
на стороне сервера, который, похоже, также отлично работает с точки зрения подключения к NFS.
Обновление 2: дамп WireShark
Приведенный ниже дамп показывает трафик NFS между клиентом и сервером NFS во время выполнения указанной выше команды монтирования. Первый - это клиент, второй - ответ сервера (далее попарно):
Оказывается, проблема связана со спецификацией схемы на UnityVSA, поэтому он не может правильно выполнять поиск LDAP; Керберизованная NFS теперь работает.
Все еще не знаю почему kadmin
возвращает то, что делает в macOS.
Для записи, /etc/krb5.conf
(или эквивалентный файл в /Library/Preferences/...
) вообще не требуется, а всю тяжелую работу берет на себя DNS. Для macOS с IPA не требуется специальной конфигурации шифрования, она работает из коробки.
Для справки в будущем, с точки зрения поведения, даже если идентификатор Kerberos указан в средстве просмотра билетов macOS (с паролем, хранящимся в цепочке для ключей), необходимо явно запросить билет (если билет не активен, но идентификатор указан, билет не запрашивается неявно при доступе к общему ресурсу NFS, например, в Finder).