Назад | Перейти на главную страницу

В macOS High Sierra возникают проблемы с подключением керберизованных общих ресурсов NFSv4

Я использую 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).