Регистрация Войти
Рейтинг:0
Standard avatar Server

Отказано в доступе при подключении Kerberised NFS v4 Share

флаг de
Standard

Я хочу смонтировать общий ресурс NFS4, но с включенной защитой Kerberos. Это моя установка:

  • Сервер Debian (dns fqdn: nfsv4test.subnet.example.org)

  • Клиент Debian (dns fqdn: nfsv4client.subnet.example.org)

  • Windows ADC, действует также как KDC

  • Моя область REALM.EXAMPLE.ORG

  • Подсеть, в которой расположены обе машины Debian, называется subnet.example.org.

  • NAT не работает.

  • Обе машины современные.

Так как я все еще борюсь с Kerberos, вот как я пытался достичь своей цели:

Глава I: Настройка

1- Поместите обе машины в одну и ту же область/домен (это уже настроено другими и работает)

2- Создал двух пользователей (пользователей, а не компьютеров!) на машину: nfs-nfsv4client, host-nfsv4client, nfs-nfsv4test и host-nfsv4test После создания я включил шифрование AES256 Bit для всех учетных записей.

3- Установите субъект-службу для пользователей:

setspn -S nfs/[email protected] nfs-nfsv4test

Я сделал это для всех 4 пользователей/принципалов.

3- Создал keytabs на Windows KDC:

ktpass -princ host/[email protected] +rndPass -mapuser [email protected] -pType KRB5_NT_PRINCIPAL -out c:\temp\host-nfsv4test.keytab -crypto AES256- SHA1

Так что после этого у меня было 4 keytab.

4- Объединены таблицы ключей на сервере (и клиенте):

ктутил  
read_kt хост-nfsv4test.keytab   
read_kt nfs-nfsv4test.keytab    
write_kt /etc/krb5.keytab

Файл имеет 640 разрешений.

5- Экспорт каталогов на сервер; это уже работало без kerberos. При включенном Kerberos файл экспорта выглядит следующим образом:

/srv/kerbnfs4 gss/krb5(rw,sync,fsid=0,crossmnt,no_subtree_check,небезопасно)
/srv/kerbnfs4/homes gss/krb5(rw,sync,no_subtree_check,небезопасно)

Запуск exportfs -rav работает:

root@nfsv4test:~# exportfs -rav
экспорт gss/krb5:/srv/kerbnfs4/homes
экспорт gss/krb5:/srv/kerbnfs4

...и на клиенте я могу просматривать монтирования на сервере:

root@nfsv4client:~# showmount -e nfsv4test.subnet.example.org
Список экспорта для nfsv4test.subnet.example.org:
/srv/kerbnfs4/дома gss/krb5
/srv/kerbnfs4 gss/krb5

6a — krb5.conf имеет конфигурацию по умолчанию для среды, для которой он был настроен, и я ничего не менял:

[libdefaults]
    ticket_lifetime = 24000
    default_realm = ОБЛАСТЬ.ПРИМЕР.ORG
    default_tgs_entypes = rc4-hmac des-cbc-md5
    default_tkt__enctypes = rc4-hmac des-cbc-md5
    Allowed_enctypes = rc4-hmac des-cbc-md5
    dns_lookup_realm = истина
    dns_lookup_kdc = истина
    dns_fallback = да

# Следующие переменные krb5.conf предназначены только для MIT Kerberos.
    kdc_timesync = 1
    ccache_type = 4
    пересылаемый = правда
    прокси = правда

# Следующие параметры libdefaults предназначены только для Heimdal Kerberos.
    fcc-mit-ticketflags = true

[сферы]
    REALM.EXAMPLE.ORG = {
        kdc = kdc.realm.example.org
        default_domain = kds.realm.example.org
    }

[область_домена]
    .realm.example.org = KDC.REALM.EXAMPLE.ORG
    realm.example.org = KDC.REALM.EXAMPLE.ORG

[приложения по умолчанию]
пэм = {
   отладка = ложь
   ticket_lifetime = 36000
   renew_lifetime = 36000
   пересылаемый = правда
   krb4_convert = ложь
}

6- Затем я настроил свой sssd.conf следующим образом, но я действительно не понял, что здесь происходит:

[СССД]
домены = realm.example.org
услуги = nss, pam
config_file_version = 2

[нсс]
filter_groups = корень
filter_users = корень
default_shell = /bin/bash

[пэм]
reconnection_retries = 3

[домен/realm.example.org]
krb5_validate = Истина
krb5_realm = ОБЛАСТЬ.ПРИМЕР.ORG
subdomain_homedir = %o
default_shell = /bin/bash
cache_credentials = Истина
id_provider = объявление
access_provider = объявление
chpass_provider = объявление
auth_provide = объявление
ldap_schema = объявление
ad_server = kdc.realm.example.org
ad_hostname = nfsv4test.realm.example.org
ad_domain = realm.example.org
ad_gpo_access_control = разрешающий
use_full_qualified_names = Ложь
ad_enable_gc = Ложь

7- idmap.conf на обеих машинах:

[Общий]

Многословие = 0
Каталог Pipefs = /run/rpc_pipefs

Домен = realm.example.org

[Отображение]

Никто-Пользователь = никто
Никто-Группа = нет группы

8- И /etc/default/nfs-common на обеих машинах:

NEED_STATD=да
NEED_IDMAPD=да
NEED_GSSD=да

9- И последнее, но не менее важное: nfs-kernel-server на сервере:

RPCNFSDCOUNT=8
RPCNFSDPRIORITY=0
RPCMOUNTDOPTS="--manage-gids --no-nfs-версия 3"
НЕОБХОДИМО_SVCGSSD="да"
РПКСВГСССДОПТС=""

10- Затем, после перезагрузки сервера и клиента, я попытался смонтировать общий ресурс (как пользователь root):

mount -t nfs4 -o sec=krb5 nfsv4test.subnet.example.org:/srv/kerbnfs4/homes /media/kerbhomes -vvvv

Но, к сожалению, крепление не работает. Я не получаю доступ. С первой попытки это занимает довольно много времени, и вот результат:

root@nfsv4client:~# mount -t nfs4 -o sec=krb5 nfsv4test.subnet.example.org:/srv/kerbnfs4/homes /media/kerbhomes
mount.nfs4: тайм-аут установлен на среду, 15 декабря, 15:38:09 2021 г.
mount.nfs4: пробуем текстовые опции 'sec=krb5,vers=4.2,addr=********, clientaddr=*********'
mount.nfs4: mount(2): Отказано в доступе
mount.nfs4: доступ запрещен сервером при монтировании nfsv4test.subnet.example.org:/srv/kerbnfs4/homes

Глава II: Отладка

Для более подробного журнала я запустил

rpcdebug -m nfsd -s lockd
rpcdebug -m rpc -s вызов

на сервере, но я не получаю столько журналов.

Однако при попытке монтирования системный журнал сообщает мне, что:

6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.771800] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.771808] svc: svc_authenticate (0)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.771811] svc: вызов диспетчера
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.771840] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.773222] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000fc9bd395, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.774697] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000fc9bd395, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.774705] svc: svc_authenticate (6)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.774711] RPC: требуется обновление, refage = 120, age = 0
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.774712] svc: svc_process закрыть
[... 7x одно и то же сообщение]
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.791514] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.791519] svc: svc_authenticate (1)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.791521] svc: ошибка аутентификации (1)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.791538] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.791913] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.791918] svc: svc_authenticate (1)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.791920] svc: ошибка аутентификации (1)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.791940] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.792292] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2
6 декабря 11:20:02 ядро ​​​​тестового сервера: [ 2088.792296] svc: svc_authenticate (1)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.792298] svc: ошибка аутентификации (1)
6 декабря 11:20:02 ядро ​​​​тестового сервера: [2088.792316] svc: сервер 00000000c1c7fb25, пул 0, транспорт 00000000c5641df0, inuse=2

Поскольку это мне совсем не помогло, я записал трафик с помощью tcpdump, что дало мне следующее:

11:12:02.856200 IP ip-client.740 > ip-server.nfs: Flags [S], seq 763536441, win 65160, параметры [mss 1460,sackOK,TS val 2364952579 ecr 2826266858,nop,wscale 7], длина 0
11:12:02.856295 IP ip-server.nfs > ip-client.740: флаги [S.], seq 2444950221, ack 763536442, win 65160, параметры [mss 1460, sackOK, TS val 2826266858 ecr 2364952579, nop, wscale 7 ], длина 0
11:12:02.856304 IP ip-client.740 > ip-server.nfs: Flags [.], ack 1, win 510, options [nop,nop,TS val 2364952579 ecr 2826266858], длина 0
11:12:02.856324 IP ip-client.740 > ip-server.nfs: Flags [P.], seq 1:245, ack 1, win 510, options [nop,nop,TS val 2364952579 ecr 2826266858], длина 244 : запрос NFS xid 4035461122 240 getattr fh 0,2/42
11:12:02.856408 IP ip-server.nfs > ip-client.740: Флаги [.], ack 245, win 508, параметры [nop,nop,TS val 2826266858 ecr 2364952579], длина 0
11:12:02.856421 IP ip-server.nfs > ip-client.740: Flags [P.], seq 1:25, ack 245, win 508, options [nop,nop,TS val 2826266858 ecr 2364952579], длина 24 : Ответ NFS xid 4035461122 ответ ERR 20: Поддельные учетные данные аутентификации (пломба нарушена)
11:12:02.856425 IP ip-client.740 > ip-server.nfs: Flags [.], ack 25, win 510, options [nop,nop,TS val 2364952579 ecr 2826266858], длина 0
11:12:02.867582 IP ip-client.740 > ip-server.nfs: Flags [F.], seq 245, ack 25, win 510, options [nop,nop,TS val 2364952590 ecr 2826266858], длина 0
11:12:02.867751 IP ip-server.nfs > ip-client.740: Flags [F.], seq 25, ack 246, win 508, options [nop,nop,TS val 2826266869 ecr 2364952590], длина 0
11:12:02.867759 IP ip-client.740 > ip-server.nfs: Flags [.], ack 26, win 510, options [nop,nop,TS val 2364952590 ecr 2826266869], длина 0

(я отредактировал реальные IP-адреса)

Итак, самое интересное здесь — Auth Bogus (Печать сломана)? Действительно ли что-то не так или это просто ошибка, которая появляется, когда что-то не так? Я не мог найти ничего полезного об этой ошибке в Интернете.

Итак, чтобы вернуться к самому Kerberos, с keytab все в порядке:

root@nfsv4client:~# klist -k -e
Имя вкладки: ФАЙЛ:/etc/krb5.keytab
Директор КВНО
---- -------------------------------- ----------------------------
   7 host/[email protected]
   6 nfs/[email protected]

При попытке проверить файл keytab, похоже, он работает:

root@nfsv4client:~# kinit -k nfs/nfsv4client.realm.example.org
root@nfsv4client:~#

Но на эта страница указано, что keytab должен быть протестирован с

kinit -k `имя хоста -s`$

который решает

kinit -k nfsv4client

который не работает, так как ключ не найден для [email protected]. Так неверный keytab или метод тестирования?

Еще один лог, который я нашел на монтируемой клиентской машине (в сообщениях):

 Ядро nfsv4client: [4355.170940] svc: инициализация пула 0 для обратного вызова NFSv4
 Ядро nfsv4client: [4355.170940] nfs_callback_create_svc: служба создана
 Ядро nfsv4client: [4355.170941] NFS: создание данных обратного вызова для каждой сети; сеть=f0000098
 Ядро nfsv4client: [4355.170942] svc: создание транспорта tcp-bc[0]
 Ядро nfsv4client: [4355.171032] nfs_callback_up: служба запущена
 Ядро nfsv4client: [4355.171033] svc: svc_destroy (обратный вызов NFSv4, 2)
 Ядро nfsv4client: [4355.171034] NFS: nfs4_discover_server_trunking: тестирование 'nfsv4test.subnet.example.org'
 Ядро nfsv4client: [4355.171040] RPC: инициализирована новая задача, procpid 9204
 Ядро nfsv4client: [4355.171041] RPC: выделенная задача 000000006bdb9e01
 Ядро nfsv4client: [4355.171042] RPC: 110 __rpc_execute flags = 0x5280
 Ядро nfsv4client: [4355.171044] RPC: 110 call_start nfs4 proc EXCHANGE_ID (синхронизация)
 Ядро nfsv4client: [4355.171045] RPC: 110 call_reserve (статус 0)
 Ядро nfsv4client: [4355.171046] RPC: wake_up_first (000000005af696f3 "xprt_sending")
 Ядро nfsv4client: [4355.171047] RPC: 110 зарезервировано req 00000000d1a7d1a4 xid 04f914c3
 Ядро nfsv4client: [4355.171047] RPC: 110 call_reserveresult (статус 0)
 Ядро nfsv4client: [4355.171048] RPC: 110 call_refresh (статус 0)
 Ядро nfsv4client: [4355.171049] RPC: gss_create_cred для uid 0, вариант 390004
 Ядро nfsv4client: [4355.171050] RPC: gss_create_upcall для uid 0
 Ядро nfsv4client: [4355.171052] RPC: __gss_find_upcall ничего не нашел
 Ядро nfsv4client: [4355.201976] RPC: __gss_find_upcall найдено сообщение 000000000e5abcbc
 Ядро nfsv4client: [4355.201978] RPC: gss_fill_context возвращает ошибку 13
 Ядро nfsv4client: [4355.201982] RPC: gss_pipe_downcall возвращает 16
 Ядро nfsv4client: [4355.201986] RPC: gss_create_upcall для uid 0 результат -13
 Ядро nfsv4client: [4355.201987] RPC: 110 call_refreshresult (статус -13)
 Ядро nfsv4client: [4355.201988] RPC: 110 call_refreshresult: ошибка обновления кредитов с ошибкой -13
 Ядро nfsv4client: [4355.201989] RPC: 110 возвращает 0, статус -13
 Ядро nfsv4client: [4355.201990] RPC: задача выпуска 110

Много всего, но я не могу найти значение ошибки -13, кроме того, что это Отказано в доступе.

Глава III: Вопрос

Принципы есть в keytab. Поэтому, когда клиент спрашивает сервер об общем ресурсе NFS и пытается получить к нему доступ, оба должны иметь ключи для взаимодействия друг с другом. Но почему-то не работает. Может ли это быть из-за назначения принципалов учетным записям пользователей?

Как я могу заставить это работать? Как получить лучшую информацию при отладке? Извините за китайскую стену текста.

PS. Я в основном следовал этот учебник. Это казалось идеальным совпадением для моей среды ..

161
0 + 0
Semicolon avatar
флаг jo
Semicolon
Предположительно, ваши машины и пользователи находятся в REALM.EXAMPLE.ORG, но вы пытаетесь использовать SPN с SUBNET.EXAMPLE.ORG. Почему? Кроме того, что такое «имя подсети»? Я не уверен, но это не имеет отношения к SPN.
0
Ответить
Рейтинг:0
Semicolon avatar Server
флаг jo
Semicolon

Превратив мой комментарий в ответ...

SUBNET.EXAMPLE.ORG на самом деле не существует (вероятно). Ваше царство/домен/лес REALM.EXAMPLE.ORG, поэтому каждый объект в этом домене имеет эту область. Похоже, что subnet.example.org — это просто то, что вы придумали для удобства именования.

Итак, если вы хотите использовать SUBNET.EXAMPLE.ORG, вам потребуются соответствующие записи SRV для области subnet.example.org, они должны будут указывать на контроллеры домена AD, AD нужно будет настроить для использования этой области в качестве псевдонима (не уверен, что это строго возможно с реализация Microsoft). Кроме того, подключающийся клиент и контроллеры домена должны преобразовать полное доменное имя в IP-адрес, а IP-адрес — в полное доменное имя.

Я бы также удалил все «короткие имена» из ваших SPN. Придерживайтесь <service>\<FQDN>, хост\<полное доменное имя> или же UserPrincipalName

Эта строка в вашем sssd.conf недействительна. ad_hostname = nfsv4test.subnet.example.org

Все компьютеры в домене realm.example.com иметь полные доменные имена <имя_компьютера>@realm.example.com. Конец истории. Вы можете использовать DNS для разрешения машин с другими именами, но в AD/LDAP учетная запись компьютера всегда будет <имя_компьютера>@realm.example.com

Короче говоря, чтобы заставить это работать быстро, замените subnet.example.org с realm.example.org во всем, что вы пытались, и вы, вероятно, должны быть функциональными.

0 + 0
Standard avatar
флаг de
Standard
SUBNET.EXAMPLE.ORG существует, так как полное доменное имя машины на самом деле nfsv4test.subnet.example.org. По крайней мере, это то, что я получаю, когда запускаю `hostname --fqdn`. И, как я писал выше, KDC может быть достигнут, потому что, когда я вхожу в nfv4client с пользователем AD, я фактически получаю принципала по умолчанию (`[email protected]`) и принципала службы (`krbtgt/REALM. [email protected]`). И поскольку во всех учебниках/руководствах, которые я читал, говорится, что принципалы должны иметь полное доменное имя, я использовал `nfsv4test.subnet.example.org`.
0
Ответить
Semicolon avatar
флаг jo
Semicolon
Вы можете войти в систему, потому что правильно указали область в файле sssd.conf (krb5_realm = REALM.EXAMPLE.ORG). В этом сценарии я не думаю, что имеет значение, что ваша машина считает своим полным доменным именем. Если ваша машина NFSV4TEST находится в домене REALM.EXAMPLE.ORG, то ее полное доменное имя (по крайней мере, для Kerberos) де-факто nfsv4test.realm.example.org. Это не было догадкой или теорией, это факт.
0
Ответить
Standard avatar
флаг de
Standard
Итак, я наконец дошел до тестирования этого с заменой подсети на область. Я удалил и воссоздал SPN, сгенерировал новые таблицы ключей, импортировал их (по крайней мере, они вроде работают), обновил sssd.conf; но ошибка остается прежней (поддельные учетные данные аутентификации (пломба нарушена) в tcpdump, доступ запрещен для команды монтирования). Как проверить, что при монтировании запрашивается правильный ключ из keytab?
0
Ответить
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.