HOWTO Active Directory 2008 R2 как Kerberos KDC для NFSv4

Ноябрь 19th, 2011 Рубрики: Active Directory, HOWTO, Linux, NFS, Windows, Настройка сервера Linux

настройка NFS для авторизации в windows 2008 R2Доброго времени, уважаемые читатели и гости блога! В продолжении прошлой темы о NFS, хочу опубликовать небольшой мануал как настроить экспортированные каталоги NFSv4 на проверку подлинности через Active Directory на Windows 2008 R2. Данный пост я реализовывал на дистрибутиве Debian. Удачно заставить работать NFSv4 и AD на Windows 2008 мне удалось только на тестовой версии - wheezy с ядром 3.0.0. На версии squeeze до сих пор идут дебаты по поводу ошибки

Nov 17 11:20:49 archiv rpc.svcgssd[13849]: ERROR: GSS-API: error in handle_nullreq: gss_accept_sec_context(): \
GSS_S_FAILURE (Unspecified GSS failure.  Minor code may provide more information) - \
No supported encryption types (config file error?)

Если появится какое-либо решение этой проблемы, то я обновлю пост...

План интеграции Active Directory на Windows 2008 R2 и NFSv4 на Linux (Debian wheezy)

В целом, организацию проверки подлинности ресурсов NFS посредством Kerberos можно представить в виде следующей последовательности шагов:

1. Настроить NFS и проверить работоспособность без Kerberos по протоколу NFSv4

  1. Настройка NFSv4 на сервере
  2. Настройка NFSv4 на клиенте.

2. Настроить Kerberos

  1. Предварительная настройка DNS и контроллера домена.
  2. Настройка синхронизации времени (на основе демона ntpd)
  3. Настроить и проверить Kerberos на идентификацию пользователя без ключевого файла krb5.keytab.
  4. Создать ключевой файл krb5.keytab на KDC (контроллер домена Windows 2008 R2)
  5. Настроить и проверить работу Kerberos для авторизации через krb5.keytab

3. Настроить NFSv4 на проверку подлинности через Kerberos.

  1. Настроить и проверить работу сервера NFSv4 на Debian
  2. Настроить и проверить работу клиента NFSv4 на Debian

4. Траблешуттинг Troubleshooting

Давайте подробней разберем каждый шаг.

Исходные данные для организации NFS

  • домен - DOMAIN.LOCAL
  • DNS-имя контроллера домена - DC.DOMAIN.LOCAL
  • IP-адрес контроллера домена - 10.0.0.4
  • NFS-server
    • DNS-имя NFS сервера - NFSD.DOMAIN.LOCAL
    • IP-адрес NFS сервера - 10.0.0.50
  • NFS-client
    • DNS-имя NFS сервера - NFSC.DOMAIN.LOCAL
    • IP-адрес NFS сервера - 10.0.0.51

1. Настройка NFSv4 без Kerberos

1.1., 1.2. Настройка NFSv4 сервера и клиента

Я решил объединить эти 2 пункта, т.к. они содержат очень похожие шаги. Поэтому начнем настройку с общих этапов для клиента и сервера. Итак, и на клиенте и на сервере необходимо настроить сеть в Debian. (Так же можно почитать статью основные понятия сетей). На сервере и клиенте необходим установленный пакет nfs-common с необходимыми зависимостями (portmap). Для того чтобы протокол Kerberos работал корректно, необходимо обязательно правильно настроить файлы /etc/hosts, /etc/hostname, /etc/resolv.conf, ну и конечно /etc/network/interfaces. Для того чтобы избавиться от возможных ошибок при работе к Kerberos, необходимо учесть некоторые нюансы (хотя и без этих нюансов скорей всего заработает), которые я отмечу комментариями:

root@nfsc:~# cat /etc/hosts
10.0.0.51       nfsc.DOMAIN.local  nfsc
127.0.0.1       localhost
# для Kerberos советуют указывать именно такой порядок
# то есть первой строкой именно 10.0.0.51 (внешний IP, не loopback)
root@nfsc:~# cat /etc/hostname
nfsc
root@nfsc:~# cat /etc/resolv.conf
domain DOMAIN.local
search DOMAIN.local
nameserver 10.0.0.4
root@nfsc:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 10.0.0.51
        netmask 255.255.0.0
        gateway 10.0.0.254
==================================
root@nfsd:~# cat /etc/hosts
10.0.0.50       nfsd.DOMAIN.local  nfsd
127.0.0.1       localhost

root@nfsd:~# cat /etc/hostname
nfsd
root@nfsd:~# cat /etc/resolv.conf
domain DOMAIN.local
search DOMAIN.local
nameserver 10.0.0.4
root@nfsd:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
        address 10.0.0.50
        netmask 255.255.0.0
        gateway 10.0.0.254

Думаю видно, где тут сервер, где тут клиент? Если все же - нет, то как я уже говорил выше nfsd - это сервер и имеет строку root@nfsd:~#, а nfsс - это клиент и имеет строку root@nfsc:~#. На клиенте и на сервере необходимо иметь установленный пакет nfs-common, как он устанавливается и из чего он состоит я писал в прошлой статье. В конфигурационном файле NFS клиента (/etc/default/nfs-common) необходимо добавить "yes" в параметр NEED_IDMAPD=yes и NEED_GSSD=yes. Это разрешить запуск демонов rpc.idmapd и rpc.gssd, которые необходимы для работы интерфейса GSS-API для взаимодействия с Kerberos. После этого, необходимо перезапустить nfs-common на обеих машинах.

root@nfsс:~# service nfs-common restart
Stopping NFS common utilities: gssd idmapd statd.
Starting NFS common utilities: statd idmapd gssd.

Далее, настройка производится на cервере. На сервере NFS необходимо установить пакет nfs-kernel-server. И задать экспортируемые каталоги в файле /etc/exports, перезапустить сервер и проверить сделанное командой showmount:

root@nfsd:~# mkdir /nfs
root@nfsd:~# vim /etc/exports
root@nfsd:~# cat /etc/exports
/nfs    10.0.0.51(rw,sync,no_subtree_check) 10.0.0.50(rw,sync,no_subtree_check)
root@nfsd:~# service nfs-kernel-server restart
Stopping NFS kernel daemon: mountd nfsd.
Unexporting directories for NFS kernel daemon....
Exporting directories for NFS kernel daemon....
Starting NFS kernel daemon: nfsd mountd.
root@nfsd:~# showmount -e
Export list for nfsd:
/nfs 10.0.0.50,10.0.0.51

На этом настройка сервера и клиента завершена. Давайте проверим наши настройки. Сначал необходимо попробовать смонтировать экспортированный каталог локально на сервере по протоколу NFSv4:

root@nfsd:~# mount -v -t nfs4 10.0.0.50:/nfs /mnt
mount.nfs4: timeout set for Fri Nov 18 12:20:52 2011
mount.nfs4: trying text-based options 'addr=10.0.0.50,clientaddr=10.0.0.50'
10.0.0.50:/nfs on /mnt type nfs4 (rw)
root@nfsd:~# mount | grep nfs4
10.0.0.50:/nfs on /mnt type nfs4 (rw,addr=10.0.0.50,clientaddr=10.0.0.50)

Как видно, монтирование произошло удачно. Более подробно о команде mount тут, а еще подробней - в man mount. Теперь проверим возможность удаленного монтирования с клиентской машины:

root@nfsc:~# mount -v -t nfs4 10.0.0.50:/nfs /mnt
mount.nfs4: timeout set for Fri Nov 18 11:01:16 2011
mount.nfs4: trying text-based options 'addr=10.0.0.50,clientaddr=10.0.0.51'
10.0.0.50:/nfs on /mnt type nfs4 (rw)
root@nfsc:~# mount | grep nfs4
10.0.0.50:/nfs on /mnt type nfs4 (rw,addr=10.0.0.50,clientaddr=10.0.0.51)

Как видно, опять все удачно. На этом можно считать, что NFS корректно работает по протоколу NFSv4. Теперь можно приступить к настройке протокола Kerberos на Debian.

2. Настройка протокола Kerberos на Debian

2.1. Предварительная настройка DNS и Active DirectoryСоздание A и PTR записей для Debian

Для корректной работы Kerberos в Linux необходима правильная настройка DNS. "Настройка DNS" тут громко сказано, просто нужно иметь корректные записи в прямой и обратной зоне для клиента NFS и сервера NFS. Создаем эти записи в оснастке DNS (изображение) и проверим работу на Debian:

root@nfsc:~# nslookup -type=A nfsc
Server:         10.0.0.4
Address:        10.0.0.4#53

Name:   nfsc.DOMAIN.local
Address: 10.0.0.51

root@nfsc:~# nslookup -type=A nfsd
Server:         10.0.0.4
Address:        10.0.0.4#53

Name:   nfsd.DOMAIN.local
Address: 10.0.0.50

root@nfsc:~# nslookup 10.0.0.50
Server:         10.0.0.4
Address:        10.0.0.4#53

50.0.0.10.in-addr.arpa  name = nfsd.domain.local.

root@nfsc:~# nslookup 10.0.0.51
Server:         10.0.0.4
Address:        10.0.0.4#53

51.0.0.10.in-addr.arpa  name = nfsc.domain.local.

DNS корректно отдает наши IP по именам и имена DNS по IP. Это меговажный момент, ибо Kerberos активно взаимодействует с DNS и без данных записей просто не будет работать!

2.2. Настройка синхронизации времени для протокола Kerberos

Для работы среды Kerberos v5 необходимо, чтобы расхождение времени KDC и хостов, запрашивающих доступ к каким-либо ресурсам и времени на хостах, предоставляющих сами ресурсы не составляло более 5 минут. Для синхронизации будем использовать возможности пакета ntp. О том, как настроить сервер и клиента NTP я уже рассказывал в прошлых статьях, поэтому отправлю вас читать NTP server на Linux. Здесь же ограничусь основными параметрами. Итак, на клиенте и сервере NFS необходимо установить пакет ntp, отредактировать файл конфигурации /etc/ntp.conf до следующего вида (после этого перезапустить службу ntp):

root@nfsd:~# cat /etc/ntp.conf
server dc.domain.local
restrict default ignore
restrict dc.domain.local
restrict 127.0.0.1 nomodify notrap
root@nfsd:~# service ntp restart
Stopping NTP server: ntpd.
Starting NTP server: ntpd.

2.3. Настройка клиента Kerberos на Debian Wheezy для доменной аутентификации

Данный этап необходимо сделать как на клиенте, так и на сервере - он одинаков как для сервера, так и для клиента NFS. Поэтому покажу, как настроить на примере сервера. Для Kerberos необходимо установить пакет krb5-user с зависимостями (он должен подтянуть krb5-config), далее его необходимо настроить. Настройка заключается в редактировании файла /etc/krb5.conf. Данный файл содержит настройки, необходимые библиотекам, взаимодействующим со средой Kerberos V, такие как область (ее еще называют realm) по умолчанию, расположение серверов KDC (key distribution centers) для известных областей и др. По синтаксису файл очень похож на файл конфигурации SAMBA (smb.conf) и так же состоит из разделов, выделенных квадратными скобками и параметров в формате параметр=значение (более подробно о настройках этого файла в man krb5.conf). Для работы в сети с одной областью вполне достаточно следующего конфигурационного файла:

root@nfsd:~# cat /etc/krb5.conf
[libdefaults]
        default_realm = DOMAIN.LOCAL
[realms]
        DOMAIN.LOCAL = {
                kdc = dc.domain.local
        }

Раздел [libdefaults] содержит значения по-умолчанию для Kerberos V библиотек, а параметр default_realm задает область по умолчанию, которая будет задействована при взаимодействии с Kerberos. Раздел  [realms] содержит подразделы с параметрами, отписывающими область Kerberos, например расположение KDC контроллера. Остальные параметры, которые часто советуют указывать в этом файле вполне работоспособны и по-умолчанию.  После данной настройки давайте проверим работоспособность Kerberos, для этого используется утилита kinit. Kinit запрашивает, получает и кэширует TGT (ticket-granting ticket)-билеты от KDC.

root@nfsc:~# # получаем билет для любого доменного пользователя
root@nfsc:~# kinit domainuser
Password for domainuser@DOMAIN.LOCAL:
root@nfsc:~# # после ввода пароля ошибок не было
root@nfsc:~# # значит билет получен корректно
root@nfsc:~# # просмотрим содержимое кэша:
root@nfsc:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: domainuser@DOMAIN.LOCAL

Valid starting     Expires            Service principal
11/18/11 16:12:00  11/19/11 02:12:08  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 11/19/11 16:12:00
root@nfsc:~# ls -la /tmp/krb5*
-rw------- 1 root root 1101 Ноя 18 16:12 /tmp/krb5cc_0
root@nfsc:~# # очистим содержимое кэша:
root@nfsc:~# kdestroy
root@nfsc:~# ls -la /tmp/krb5*
ls: невозможно получить доступ к /tmp/krb5*: Нет такого файла или каталог

Как видно, билет корректно получен. Не забудьте те же действия проделать на сервере.

Тут я сделаю небольшое отступление в виде абзаца, взятого не помню откуда и не с первого прочтения подающегося пониманию, но тем не менее, хорошо описывающего работу Kerberos ):

Сервер Kerberos свободно распространяет TGT (Ticket Granting Ticket) на каждый неавторизованный запрос; однако, каждый TGT зашифрован ключом, полученным из пароля пользователя. Следовательно, когда пользователь вводит свой пароль, он не отправляется на KDC, а используется для расшифровки TGT, который уже получен kinit. Если в процессе расшифровки получается правильный билет с правильным значением времени, у пользователя есть действующее удостоверение. Это удостоверение содержит ключ сессии для установления безопасного соединения с сервером Kerberos, как и действующий TGT, зашифрованный ключом сервера Kerberos. Второй уровень шифрования недоступен пользователю, но позволяет серверу Kerberos проверять правильность каждого TGT.

Идем дальше...

2.4. Создание keytab-файла на контроллере домена Windows 2008 R2

Перед созданием ключевого файла необходимо создать учетные записи для хостов (сервера и клиента) NFS, соответствующие именами хостов:keytab account

Наступает самый интересный этап. Не углубляясь в Kerberos, keytab-файл это "связка ключей", файл содержащий в себе одну или несколько запсей - ключей, которые используются вместо логина/пароля при запросе доступа у сервера KDC к какому-либо ресурсу. Другими словами, машина предоставляет данный файл серверу KDC как подтверждение своей достоверности, когда запрашивает у контроллера домена (KDC) доступ к какому-либо ресурсу (например доступ к службе или сетевому каталогу). В большинстве случаев, при настройке какой-либо службы в связке с Kerberos проблемы возникают именно на данном этапе, т.к. именно этот файл является связующим звеном между Windows 2008 и Linux (в нашем случае - Debian). Проблемы обычно связаны с различными типами шифрования, которые поддерживает Windows, но не поддерживает Linux и наоборот...

Итак, согласно документации жадных, Windows 7 и Windows Server 2008 R2 более не поддерживают типы шифрования, основанные на DES (DES-CBC-MD5 & DES-CBC-CRC), но в них включены следующие типы шифрования (по убиванию стойкости):

  • AES256-CTS-HMAC-SHA1-96
  • AES128-CTS-HMAC-SHA1-96
  • RC4-HMAC

При этом, необходимо учитывать, что если при использовании Kerberos будут использоваться клиенты на основе WinXP и младше, то они из всего приведенного поддерживают только RC4-HMAC.

keytab создается с помощью утилиты ktpass (документация по ней), которая с Windows 2003 SP1 входит в состав дистрибутива, а в дистрибутивах младше - необходимо установить отдельно Microsoft Server SupportTools, имеющегося на диске с дистрибутива Windows Server . Формат создания keytab утилитой ktpass следующий:

ktpass.exe /princ имя_службы/fqdn.имя.хоста@ИСПОЛЬЗУЕМАЯ.ОБЛАСТЬ
/mapuser учетная_запись_хоста$@ИСПОЛЬЗУЕМАЯ.ОБЛАСТЬ
/crypto тип_шифрования
/ptype ТИП_ПРИНЦИПАЛА
/pass пароль_или_+rndpass
/out C:\каталог\создаваемый_файл

В примере параметры команды для удобства выстроены в столбик, реально же они пишутся все в одну строку. Давайте поймем,  что делает команда ktpass и ее параметры и все их рассмотрим. Вообще, говоря о функциях и назначении данной программы, то создание keytab файла - это одна из двух ее функций, другая функция - это создание принципала (/princ), "привязанного" (примапленного - /mapuser) к учетной записи компьютера или пользователя.  Принципал представляет собой SPN-запись (server principal name, дословно - имя основного сервера), думаю, что из дословного перевода SPN, понятно что назначение этой записи - указать на компьютер, предоставляющий тот или иной сервис (службу, в нашем случае - служба NFS). О том, что есть принципал (SPN) - более подробно - можно почитать тут. Давайте пойдем по прядку по параметрам...

Параметр /princ

Задает имя службы и хост, на котором она (служба) расположена и в какой области домене. В нашем случае указывается nfs/nfsd.domain.local@DOMAIN.LOCAL (для сервера NFS) и nfs/nfsс.domain.local@DOMAIN.LOCAL (для клиента NFS). Для примера, для службы Apache указывается принципал HTTP/fqdn.имя.хоста@ИСПОЛЬЗУЕМАЯ.ОБЛАСТЬ, причем HTTP обязательно В ВЕРХНЕМ РЕГИСТРЕ, многие службы требуют указания имени службы в SPN именно в верхнем регистре. Узнать, в каком регистре и какое значение имя_службы указывать можно из документации к службе, например в man rpc.gssd есть такая информация. Очень часто указывается общее имя принципала host/fqdn@REALM. Стоит отметить такой нюанс...почему-то во всех источниках указывают, что должно стоять имя FQDN. Но на сколько я знаю, FQDN-имя предполагает наличие точки в конце имени, но тем не менее - точку не ставят в данном случае.

Параметр /mapuser

Задает имя доменной учетной записи, к которой "цепляется" указанный выше SPN. Для нас это будет созданные в предыдущем разделе учетные записи компьютеров nfsc$@DOMAIN.LOCAL - для клиента и nfsd$@DOMAIN.LOCAL - для сервера.

Параметр /crypto

Задает тип шифрования Kerberos, который будет использоваться при шифрации/дешифрации билетов, передаваемых между контроллером домена KDC и хостами. На Windows 2008 R2 мне удалось запустить корректную аутентификацию при указании параметра /crypto ALL (то есть keytab создавался с несколькими принципалами со всеми поддерживаемыми типами шифрования). Тем не менее, желательно придерживаться следующих правил, чтобы избежать проблем с шифрованием: для win 2k и 2k3 желательно указывать /crypto DES-CBC-MD5, для Win 2k3 SP1 - /crypto rc4-hmac-nt, для Windows 2008 R2 - /crypto AES256-SHA1 или /crypto rc4-hmac-nt.

Параметр /ptype

Задает тип принципала. В значении этого параметра рекомендуется указывать KRB5_NT_PRINCIPAL, т.к. подходит практически для всех служб.

Параметр /pass

Задает пароль, который может быть указан вручную, или устанавливает произвольный пароль, если задано значение +rndpass.

Параметр /out

Задает имя выходного файла keytab.

Итак, рассмотрев параметры, можно составить команды, которые создадут нам необходимые keytab файлы на контроллере домена:

C:\Windows\system32>ktpass.exe /princ nfs/nfsc.domain.local@DOMAIN.LOCAL /mapuser \
nfsc$@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass +rndpass \
/out C:\tmp\nfsckeytab
Targeting domain controller: DC.domain.local
Using legacy password setting method
Successfully mapped nfs/nfsc.domain.local to NFSC$.
WARNING: Account NFSC$ is not a user account (uacflags=0x1021).
WARNING: Resetting NFSC$'s password may cause authentication problems if NFSC$
is being used as a server.

Reset NFSC$'s password [y/n]?  y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to C:\tmp\nfsckeytab:
Keytab version: 0x502
keysize 55 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x1 (DES-CBC-CRC) keylength 8 (0x206e7fbaa738ec1c)
keysize 55 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x3 (DES-CBC-MD5) keylength 8 (0x206e7fbaa738ec1c)
keysize 63 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 79 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x12 (AES256-SHA1) keylength 32 (0x624fe15973fb5bda6c88a289260789cd16b135451f296
a83679424c27c04507a)
keysize 63 nfs/nfsc.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x11 (AES128-SHA1) keylength 16 (0x5ea804c4527c2467f7c710d845c09821)

Это был клиент. Как видно, вывалилось несколько "варнингов". Первый нам говорит, о том, что это аккуант не пользователя, а компьютера, второй - что могут возникнуть проблемы, если мы сбросим пароль (но мы то знаем, что делаем, поэтому подтверждаем и жмахаем Ентер), третий говорит нам, что ptype не соответствует аккуанту. Это произошло потому что мы указали "общий" тип, а привязали принципал к учетной записи хоста. Теоретически, это не должно привести к проблемам при настройке, но если сообщение мозолит глаза, то можно указать тип KRB5_NT_SRV_HST. Давайте теперь создадим кейтаб для сервера NFSv4:

C:\Windows\system32>ktpass.exe /princ nfs/nfsd.domain.local@DOMAIN.LOCAL /mapuser \
nfsd$@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass +rndpass \
/out C:\tmp\nfsdkeytab
Targeting domain controller: DC.domain.local
Using legacy password setting method
Successfully mapped nfs/nfsd.domain.local to NFSD$.
WARNING: Account NFSD$ is not a user account (uacflags=0x1021).
WARNING: Resetting NFSD$'s password may cause authentication problems if NFSD$
is being used as a server.

Reset NFSD$'s password [y/n]?  y
WARNING: pType and account type do not match. This might cause problems.
Key created.
Key created.
Key created.
Key created.
Key created.
Output keytab to C:\tmp\nfsdkeytab:
Keytab version: 0x502
keysize 55 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x1 (DES-CBC-CRC) keylength 8 (0xb36dd6ef3b518f73)
keysize 55 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x3 (DES-CBC-MD5) keylength 8 (0xb36dd6ef3b518f73)
keysize 63 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115fc)
keysize 79 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x12 (AES256-SHA1) keylength 32 (0x760287626e74dea671b3c90cfae8d2b2f5b69f596ff9e
f73c8c3da476ee64925)
keysize 63 nfs/nfsd.domain.local@DOMAIN.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype
0x11 (AES128-SHA1) keylength 16 (0x8fa396ecd3d4a69c329437b08da883e9)

Итого, мы получили 2 keytab в каталоге C:\tmp\ для клиента - nfsсkeytab и для сервера - nfsdkeytabKerberos keytab файлы для NFSv4

Примечание. Подразделение (Organization Unit) в котором размещены учетные записи сервера (nfsd) и клиента (nfsc) не должны иметь в своем имени кириллических символов. Иначе при создании keytab будет ошибка Password set failed! 0×00000020. Aborted. (Спасибо за замечание комментатору Михаилу)

Теперь эти ключи Kerberos необходимо БЕЗОПАСНО скопировать на соответствующие машины, например чрез WinSCP и приступить к следующему шагу.

2.5. Настройка клиента Kerberos для аутентификации через keytab

Допустим, мы скопировали наши keytab файлы в папку пользователя root. Теперь рассмотрим настройку keytab на сервере NFS:

root@nfsd:~# ktutil
ktutil:  rkt /root/nfsdkeytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   2    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   3    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   4    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
   5    3             nfs/nfsd.domain.local@DOMAIN.LOCAL
ktutil:  wkt /etc/krb5.keytab
ktutil:  q
root@nfsd:~# kinit -k  nfs/nfsd.domain.local
root@nfsd:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nfs/nfsd.domain.local@DOMAIN.LOCAL

Valid starting     Expires            Service principal
11/19/11 01:17:30  11/19/11 11:17:31  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 11/20/11 01:17:30
root@nfsd:~# kdestroy
root@nfsd:~# chmod -v u=rw,go-rwx /etc/krb5.keytab
права доступа «/etc/krb5.keytab» изменены с 0644 (rw-r--r--) на 0600 (rw-------)

Давайте разберем сделанное: сначала, с помощью утилиты ktutil прочитали исходный скопированный файл, просмотрели его содержимое, чтобы убедится, что это нужный нам файл и записали прочитанное содержимое в файл /etc/krb5.keytab, который читается библиотеками Kerberos, затем вышли из утилиты командой q. Командой kinit с параметром -k и указанным именем службы мы попробовали проверить подлинность без пароля с помощью keytab. Данное действие корректно завершилось, т.к. ошибок выдано не было и klist нам отобразил полученный билет из кэша. Далее мы удалили полученный билет и задали права на доступ к krb5.keytab только пользователю root. Дополнительно могу отметить, что иногда приходится к kinit добавить ключ -t с путем к кейтаб-файлу. Это может понадобиться, если по какой-то причине, kinit не смог найти и обратиться к keytab файлу по умолчательному пути... (спасибо комментатору angel2s2АХТУНГ!!! Если на данном этапе kinit выдал ошибки, то далее настраивать смысла нет, ибо Kerberos клиент работает не корректно. Необходимо избавиться от ошибок.

Далее, давайте то же самое проделаем с клиентом:

root@nfsc:~# ktutil
ktutil:  rkt /root/nfsckeytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   2    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   3    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   4    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
   5    3             nfs/nfsc.domain.local@DOMAIN.LOCAL
ktutil:  wkt /etc/krb5.keytab
ktutil:  q
root@nfsc:~# kinit -k nfs/nfsc.domain.local
root@nfsc:~# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: nfs/nfsc.domain.local@DOMAIN.LOCAL

Valid starting     Expires            Service principal
11/19/11 01:31:28  11/19/11 11:31:29  krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
        renew until 11/20/11 01:31:28
root@nfsc:~# kdestroy
root@nfsc:~# chmod -v -u=rw,go- /etc/krb5.keytab
права доступа «/etc/krb5.keytab» изменены с 0600 (rw-------) на 0644 (rw-r--r--)

Все у нас хорошо. Можно пробовать настроить NFS через Kerberos.

3. Настройка NFSv4 на проверку подлинности через Kerberos V (Win 2k8 R2 как KDC)

Настройку начнем с сервера NFS. В конфигурационном файле сервера (/etc/default/nfs-kernel-server)  необходимо разрешить запуск демона, отвечающего за взаимодействие с Kerberos (демон rpc.svcgssd), для этого необходимо вставить yes в параметре NEED_SVCGSSD=yes, задать экспортируемому ресурсу соответствующую настройку для авторизации через KDC и перезапустить службу:

root@nfsd:~# cat /etc/exports
/nfs    gss/krb5(rw,sync,no_subtree_check)
root@nfsd:~# service nfs-kernel-server restart
Stopping NFS kernel daemon: mountd svcgssd nfsd.
Unexporting directories for NFS kernel daemon....
Exporting directories for NFS kernel daemon....
Starting NFS kernel daemon: nfsd svcgssd mountd.
root@nfsd:~# showmount -e
Export list for nfsd:
/nfs gss/krb5

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

root@nfsd:~# umount -v /mnt
NFSv4 mount point detected
10.0.0.50:/nfs umounted
root@nfsd:~# mount -v -t nfs4 -o sec=krb5 nfsd:/nfs /mnt
mount.nfs4: timeout set for Sat Nov 19 01:50:11 2011
mount.nfs4: trying text-based options 'sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.50'
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5)
root@nfsd:~# mount | grep nfs4
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.50)

Как видно, все получилось отлично. Давайте то же самое попробуем проделать на клиенте:

root@nfsc:~# mount -v -t nfs4 -o sec=krb5 nfsd:/nfs /mnt
mount.nfs4: timeout set for Sat Nov 19 02:24:21 2011
mount.nfs4: trying text-based options 'sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.51'
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5)
root@nfsc:~# mount | grep nfs4
nfsd:/nfs on /mnt type nfs4 (rw,sec=krb5,addr=10.0.0.50,clientaddr=10.0.0.51)

Так же - все удачно.

4. Траблешуттинг Kerberos и NFS

Диагностику стоит начать с проверки - запущены ли необходимые процессы:

root@nfsd:~# ps aux | grep rpc
root       667  0.0  0.2   2236   940 ?        Ss   Nov17   0:01 /sbin/rpcbind -w
root       690  0.0  0.0      0     0 ?        S<   Nov17   0:00 [rpciod]
statd     1666  0.0  0.3   2548  1248 ?        Ss   Nov18   0:00 /sbin/rpc.statd
root      1679  0.0  0.1   2552   736 ?        Ss   Nov18   0:00 /usr/sbin/rpc.idmapd
root      1684  0.0  0.5   3948  2240 ?        Ss   Nov18   0:28 /usr/sbin/rpc.gssd
root      3859  0.0  0.4   3880  1808 ?        Ss   01:44   0:00 /usr/sbin/rpc.svcgssd
root      3862  0.0  0.3   3076  1504 ?        Ss   01:44   0:00 /usr/sbin/rpc.mountd --manage-gids
root      4017  0.0  0.1   3424   768 pts/0    S+   02:29   0:00 grep rpc

Это вывод с сервера. На клиенте, соответственно, не будет процесса rpc.svcgssd. Далее стоит просмотреть лог /var/log/daemons.log и /var/log/syslog на наличие ошибок.

Для диагностики клиента, необходимо добавить в /etc/defaults/nfs-common строку RPCGSSDOPTS=-vvv и перезапустить nfs-common. Это запустит демон rpc.gssd в очень verbose-режиме )). Для диагностики сервера можно добавить такую же опцию в RPCSVCGSSDOPTS=-vvv и перезапустить nfs-kernel-server. После этого - наблюдать за логом /var/log/daemons.log и /var/log/syslog.

БОлше понимания о шифровании в Kerberos дает команда klist с параметром -e, что заставляет отображать типы шифрования в файле keytab и кэше.

Можно так же "поиграться" с заданием разрешенного типа шифрования Kerberos. Это делается добавлением строк в файл krb5.conf:

[libdefaults]
 …
      # явно задает тип шифрования RC4, можно
      # задать des-cbc-cbr, des-cbc-md5, aes256-cts или aes128-cts
      default_tkt_enctypes = rc4-hmac
      default_tgs_enctypes = rc4-hmac
      permitted_enctypes = rc4-hmac

Если используется Kerberos клиент старше 1.6, то скорее всего DES там как и в Windows 2008 - не поддерживается и для его включения необходимо добавить в раздел [libdefaults] строку allow_weak_crypto = true.

Хочется отметить еще вот такой нюанс: на контроллере домена возможно привязать несколько SPN к однойучетной записи, но это может привести к некоторым проблемам, поэтому я бы не советовал этого делать. Пример такой проблемы хорошо раборали товарсчи с форума ixbt. Кроме того, в сети идет много дебатов о том, привязывать SPN к учетной записи компьютера или к учетной записи пользователя, некоторую полезную информацию об этом можно найти тут.

Многие ресурсы советуют добавить в krb5.conf вот такой раздел:

[logging]
FILE=/var/krb5/kdc.log

Что теоретически должно заставить библиотеки клиента kerberos писать о своей работе в лог, но заставить работать этот механизм мне не удалось, поэтому я пропустил данную настройку в статье.

Резюме.

Итак, статью можно считать завершенной. Чтобы до конца разобраться в этом вопросе мне пришлось убить более 2х недель и перечитать кучу материалов. Очень надеюсь, что  материал, который я постарался как можно понятней донести до Вас будет Вам полезен. Буду рад комментариям и замечаниям. До новых встреч!

Что почитать еще

http://blog.scottlowe.org/2007/01/15/active-directory-integration-index/ - очень много информации по интеграции UNIX и AD
http://technet.microsoft.com/en-us/library/cc734104(WS.10).aspx - Kerberos Key Distribution Center на Windows 2008
http://social.technet.microsoft.com/wiki/contents/articles/717.aspx - SPN от мелкософт
http://technet.microsoft.com/en-us/library/cc753771(WS.10).aspx - ktpass от Microsoft
http://msdn.microsoft.com/en-us/library/ms995329.aspx - очень интересная статья с теоретической точки зрения о настройке Linux, Kerberos и HTTP
http://technet.microsoft.com/ru-ru/library/dd546914.aspx - управление доступом в гетерогенных сетях
http://www.grolmsnet.de/kerbtut/ - тоже о Linux, Kerberos и HTTP
http://osdude.wordpress.com/2011/08/12/authenticating-unixlinux-to-windows-2008r2-part-3-rhel-5-6/ - неплохая теоретическая информация о шифровании в KDC на Windows 2008
http://osdude.wordpress.com/2011/08/12/authenticating-unixlinux-to-windows-2008r2-part-5-kerberos-encryption-types/ - вторая неплохая теоретическая информация о шифровании в KDC на Windows 2008
http://www.securitylab.ru/analytics/265153.php - работа Kerberos в Linux
http://nfsworld.blogspot.com/2005/06/using-active-directory-as-your-kdc-for.html - NFS и Windows 2003
http://sammoffatt.com.au/jauthtools/Kerberos - хорошая wiki по Kerberos
http://techpubs.spinlocksolutions.com/info/kerberos.html - MIT Kerberos в Debian

C Уважением, Mc.Sim!




Теги: , , , , ,

19 комментариев к “HOWTO Active Directory 2008 R2 как Kerberos KDC для NFSv4”

  1. Dao
    Апрель 23rd, 2012 at 20:37
    1

    Сэр…

    если бы все писали пояснительные статьи таки образом, то общий прогресс развития сетевых технологий шёл бы, как минимум мене мучительно и более правильно.

    Большое спасибо.

    • Апрель 23rd, 2012 at 22:53
      2

      Пожалуйста. Приходите еще!

  2. Антон Фурс
    Апрель 25th, 2012 at 07:24
    3

    Святой человек… ).
    А не напишете статью как на линукс системах наклепать из кучи конфиг файлов и служб неплохую биллинговую систему для учета всех возможных видов траффика с всеми возможными видами авторизации, квотирования, шейпинга… так, чего-то там еще)).
    вообще есть такая задача… а я тут совсем зашился… много не понимаю, то одна программа что-то умеет, но другое не может, то другая… и т.д… а уж все эти путаницы с тем, где можно при прозрачном проксировании авторизацию проводить где незя… запутали меня. а еще волнует вопрос прозрачного сокс-прокси с какой-нибудь не ip авторизацией. такое существует в природе в бесплатном варианте? ))).

    • Апрель 25th, 2012 at 21:58
      4

      вполне неплохой биллинг можно реализовать на iptables. Шейпинг тоже на нем, но довольно трудоемко.
      Прокси-сервер на squid, но при прозрачном проксировании авторизация не будет работать. Без прозрачного проксирования — необходимо настраивать браузеры клиентов.
      В целом, если сеть небольшая, то всех пустить через squid — он и биллинг и шейпер и авторизация.
      И не допускать натирования трафика на шлюзе. Или вообще не выдавать адрес шлюза в локальную сеть.

  3. Михаил
    Май 18th, 2012 at 07:30
    5

    Добрый день.
    Есть маленькое замечание, касающееся создания хостов nfsc и nfsd в Active Directory.
    Organization Unit, где хранятся nfsc и nfsd, и верхние OU должны называться латиницей. В противном случае при создании keytab-а, вываливается следующая ошибка:

    Password set failed! 0x00000020
    Aborted.

    • Май 22nd, 2012 at 23:17
      6

      Отличное замечание. Спасибо.

  4. Сентябрь 25th, 2013 at 15:47
    7

    Привет, коллега.

    Спасибо за полезные материалы. Сейчас как раз сдруживаю кальмара с АДом :-D

    Кстати, через «kinit -k nfs/nfsc.domain.local» подключается не получится, даже если через указание юзера подключается.
    А если добавить еще один ключик сюда — «-t /root/nfsckeytab», то все заводится.

    • Октябрь 3rd, 2013 at 15:30
      8

      Приветствую.
      Да, тоже иногда с таким сталкивался, никак не было возможности допилить статью. Теперь сделал.
      Спасибо.

  5. Алмас
    Январь 27th, 2014 at 09:22
    9

    здравствуйте. Подскажите пожалуйста, надо изначально создать учетную запись компьютера или юзера???

    • Январь 28th, 2014 at 10:19
      10

      Я думаю, что не имеет значения последовательность создания учетных записей.

  6. Andrey
    Июнь 2nd, 2014 at 16:23
    11

    Привет! Отличные статьи, но не получается авторизоваться кейтабом на сквиде((( Выдаёт ошибку:
    kinit: Client not found in Kerberos database while getting initial credentials

    keytab создавал командой:
    ktpass.exe /princ HTTP/ssmrsqd01.elsystems.local@ELSYSTEMS.LOCAL /mapuser ssmrsqd01$@ELSYSTEMS.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass +rndpass /out C:\tmp\squid.keytab

    Вывод консоли:
    Targeting domain controller: SSMRDC001.elsystems.local
    Successfully mapped HTTP/ssmrsqd01.elsystems.local to SSMRSQD01$.
    WARNING: Account SSMRSQD01$ is not a user account (uacflags=0x1021).
    WARNING: Resetting SSMRSQD01$’s password may cause authentication problems if SS
    MRSQD01$ is being used as a server.

    Reset SSMRSQD01$’s password [y/n]? y
    Password succesfully set!
    WARNING: pType and account type do not match. This might cause problems.
    Key created.
    Key created.
    Key created.
    Key created.
    Key created.
    Output keytab to C:\ssmrsqd01.keytab:
    Keytab version: 0x502
    keysize 73 HTTP/ssmrsqd01.elsystems.local@ELSYSTEMS.LOCAL ptype 1 (KRB5_NT_PRINC
    IPAL) vno 4 etype 0x1 (DES-CBC-CRC) keylength 8 (0x01576eb97c7ad94c)
    keysize 73 HTTP/ssmrsqd01.elsystems.local@ELSYSTEMS.LOCAL ptype 1 (KRB5_NT_PRINC
    IPAL) vno 4 etype 0x3 (DES-CBC-MD5) keylength 8 (0x01576eb97c7ad94c)
    keysize 81 HTTP/ssmrsqd01.elsystems.local@ELSYSTEMS.LOCAL ptype 1 (KRB5_NT_PRINC
    IPAL) vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x85a6dea042798a45a547f8450e1115
    fc)
    keysize 97 HTTP/ssmrsqd01.elsystems.local@ELSYSTEMS.LOCAL ptype 1 (KRB5_NT_PRINC
    IPAL) vno 4 etype 0x12 (AES256-SHA1) keylength 32 (0xfaec8c62c578afc38e241051605
    9a11830b4d3475e7142fd1b1bd1679aa6be54)
    keysize 81 HTTP/ssmrsqd01.elsystems.local@ELSYSTEMS.LOCAL ptype 1 (KRB5_NT_PRINC
    IPAL) vno 4 etype 0x11 (AES128-SHA1) keylength 16 (0x19cb6cb315610d1128078eb1044
    4183d)

    В чем может быть причина? Какую ещё информацию предоставить? Голый kinit при этом работает и с паролем тикет получает.

    • Июнь 24th, 2014 at 21:10
      12

      Выводы команд вставляйте на pastebin.com.
      Покажите, последовательно выводы:
      1. создание keytab
      2. перенос кейтаба на linux (как переносите)
      3. конфигурацию /etc/krb5.conf
      4. доказательства идентичности времени на клиенте и сервере (словам я верить перестал ))) )
      5. вывод настройки сетевой части linux

  7. rlagutin
    Август 16th, 2015 at 06:19
    13

    1. Keytab нужно мапить только на уч. запись пользователя, кот. Domain User (и как-либо доп. настраивать ее не нужно). В Win 2012R2 утилита ktpass разрешает в /mapuser использовать только уч. запись пользователя (не компьютера).
    2. Верся kvno для всех записей в ketrab файле должна быть одинаковая.
    3. Для всех записей keytab рекомендуется указывть KRB5_NT_PRINCIPAL
    4. Траблшутинг: На клиенте в отдельной сессии выполните rpc.gssd -fvvv а в другой выполните mount -t nfs4 -o rw,sec=krb5p server1:/nfs/secure/ /mnt/secure/

    ПС. Связка Windows 2012R2 AD + NFS сервер Rhel 7.1 + NFS клиент 7.1 = работает. (все конфиги по умолчанию)

    • Октябрь 10th, 2015 at 14:01
      14

      Спасибо за дополнения.
      1. Но почему только на пользователя?
      3. Откуда такая рекомендация?
      Буду признателен за предоставление пруф линков.

  8. Free4ert
    Декабрь 4th, 2015 at 17:15
    15

    Да это я понял.
    Но эти операции не помогли.

    Если выполнить kinit Admin
    Авторизоваться по паролю.
    Дальше Kerberos авторизация будет работать в сквиде.

    Единственный камень предкновения этот keytab файл.

    Напишу что я делал для его получения.
    Мб что не так:

    Создал DNS записи на linux сервер и обратные DNS записи
    Синхронизировал время на linux с AD
    Создал учетную запись в домене Windows 2008
    squid3
    Поставил её не истекаемый пароль

    Получил keytab файл следующей компандой:

    ktpass -princ HTTP/sq.mydomain.name@MYDOMAIN.NAME -mapuser squid3@MYDOMAIN.NAME -pass Pa$$word -ptype KRB_NT_PRINCIPAL -crypto ALL -out c:123squid3.keytab

    (Пытался сделать через учетную запись ПК sq$@MYDOMAIN.NAME)
    (Пытался сделать через msktutils)
    (Пытался сделать через samba , net ads )

    Получаю два типа ошибок.
    1. Client Not Found in Kerberos database.. (не найден пользователь)
    2. Keytab contains no suitable keys (не найдена пара ключей в файле)

    Вот еще мой конфиг файл krb5.conf

    Время сихнронизирую через ntpd, работает ntlm авторизация.
    keytab копирую через WinSCP

    У меня проблема один в один как у Андрея выше в 2014 году. Не знаю решилась она или нет…

  9. Декабрь 6th, 2015 at 09:26
    16

    Вообщем разобрался я в итоге утром ))
    Дело было в том что я двумя дорогами шел к одной цели.
    А как известно за двумя зайцами гонятся бесполезное занятие.

    В итоге.
    Я удалил всех пользователей на которых делал мапинг keytab через ktpass.
    Проверил командой на AD: stspn -Q HTTP/sq.mydomain.name , что данный принципиал никуда не привязан.

    Переввел samba в домен еще раз.
    Создал keytab файл через samba, предварительно я авторизовался в домене через kinit admin, получив билет, это избавило от ввода пароля позднее, если этого не сделать надо везде писать -U admin
    [code]
    net ads keytab flush - очистить кейтаб
    net ads keytab create - создать кейтаб
    net ads keytab add HTTP - добавим принципал HTTP для прокси или веб сервера
    net ads keytab list - посмотрим что получилось
    [/code]

    kdestroy — очистим все прошлые попытки логона.
    kinit -V -k -t /etc/krb5.keytab HTTP/sq.mydomain.name@MYDOMAIN.NAME
    Проверим что возможно войти по kytab файлу.

    Дальше уже можно возвращаться в манулалы по сквиду.

    Т.е. мой путь был через samba, т.е. Линкус машина уже была в домене АД.

    • Август 3rd, 2016 at 21:56
      17

      Спасибо за интересный рассказ.
      Да, иногда выспаться очень хорошо помогает )

  10. DAZ
    Март 23rd, 2016 at 13:00
    18

    «NFS посредствам Kerberos» — должно быть «NFS посредством Kerberos». ;)

    • Август 3rd, 2016 at 23:17
      19

      Да, действительно )
      Спасибо

Написать комментарий