NFS сервер на Windows 2012. Маппинг ESXi пользователей в домене

Итак, сопоставление(маппинг) пользователей ESXi с доменными пользователями в Windows Server 2012.

Эта задача не давала мне покоя несколько дней. И проблема не в ее сложности а в отсутствии материалов на эту тему. Кроме этого, отличаются подходы к выполнению этой задачи в сервере 2008 и 2012. Обыскавшись информации по этому вопросу, собирая все по крупицам, могу с большой уверенностью сказать, что эта статья будет первой в рунете на эту тему.

Немного фундаментальных основ

Протокол NFS очень простой. Предоставил доступ к каталогу, разрешил чтение или запись определенным машинам в сети и все работает как барабан. Собственно, во многом по этой причине он приобрел такую популярность. Но, когда что то простое приходит в среду Windows, все становится сильно сложнее. Хотя, стоит отметить, что реализация NFS в Windows Server 2008\2012 выполнена отлично. Вся проблема тут в другом, в NTFS.

NTFS это такая низкоуровневая вещь, которая существует сама по себе не взирая не на что. Абсолютно все каталоги и объекты файловой система имеют владельца и список пользователей с некоторыми правами. Это в принципе понятно и давно известно. В случае с доменом Active Directory, в котором по умолчанию запрещен анонимный доступ к каким либо ресурсам, запись в любой каталог, обязательно должна происходить от чьего то имени. То есть от какого либо пользователя зарегистрированного в домене. Естественно, если у него есть на то права.  Но, когда мы предоставляем доступ к каталогу по протоколу NFS, писать и читать в него будет не машина находящаяся в домене а ESXi-хост, который и понятия не имеет что такое NTFS. Запись в каталог он осуществляет от имени суперпользователя(root). Естественно в разрешениях NTFS указать учетную запись root с произвольной Linux-машины нельзя т.к. в домене ее не существует. Вот в этом и вся сложность. Далее поясню на примере конкретного каталога.

ESXi_user_map_srv_2012_nfs_shareНа этом рисунке мы предоставляем доступ к каталогу test по протоколу NFS. Выделен наиболее важный пункт. Он позволяет, писать в этот каталог, даже тем пользователям, которых нет в домене и соответственно нет в списке NTFS. Это своего рода обход NTFS. Но, как мы знаем, запись в каталог все равно должна осуществляться от чьего то имени. Поэтому предусмотренны варианты. Разрешить несопоставленный доступ пользователей Unix(по UID/GID) — это означает, что будет взят UID и GID пользователя от которого производитсься запись и на их основе сгенерируется аналог SIDа пользователя Windows. Этот SID будет указан владельцем записанных файлов с соответствующими правами.

В результате список прав NTFS на записанных ESXi-хостом файлах будет выглядить следующим образом.

ESXi_user_map_srv_2012_NTFS_UIDНепонятный набор цифр со знаком вопроса и есть наш пользователь ESXi. В таком случае, все что ESXi-хост запишет в наш каталог, то он и сможет прочесть или удалить. А вот то, что там положено администратором сервера, он не сможет не прочесть не удалить. Например, предоставив таким образом, доступ к каталогу с ISO-образами, подключить их к ВМ не позволит NTFS и vCenter будет сыпать ошибки о отказе в доступе.

Теперь про пиннинг пользователей

У учетных записей пользователей и групп в AD есть такие специальные атрибуты как «uidNumber» и «gidNumber» соответственно. Они призваны помочь нам следующим образом;
1. создать в домене простого пользователя и группу. Например nfs_user и nfs_group
2. далее нужно выяснить от какого пользователя работает NFS-клиент ESXi-хоста
3. указать сервису NFS на Windows Server 2012, что поиск сопоставленных пользователей нужно искать в нашем домене.
4. присвоить UID и GID этого пользователя учетным записям nfs_user и nfs_group соответственно.
5. дать все необходимые права nfs_user и nfs_group на каталог который подключается к ESXi-хосту по NFS.
6. изменить настройки NFS-шаринга.

Быстро по пунктам

1. Пропускаю т.к. понятно.
2. Для этого снифал NFS-сессию Wireshark-ом.

Выяснилось, что при наличии пользователя nfsnobody ESXi-хост все же подключается к NFS-серверу под учеткой root’а.

ESXi_user_map_srv_2012_Wireshark

3. Указать где искать сопоставление пользователей и групп нужно в свойствах сервера NFS.

Диспетчер серверов -> Сервер для NFS -> Свойства -> вкладка Сетевые группы. Указываем полное имя домена.

ESXi_user_map_srv_2012_AD_domain
Далее на сервере NFS выполняем команду PowerShell

# Set-NfsMappingStore -EnableADLookup $true

Это разрешает маппинг пользователей и групп в AD

4. Устанавливаем значения UID и GID для наших доменных учеток.

Вначале группе

Set-NfsMappedIdentity -GroupName nfs_group -GroupIdentifier 0

Затем пользователю. Тут же и указывается группа пользователя.

Set-NfsMappedIdentity -UserName nfs_user -UserIdentifier 0 -GroupIdentifier 0

Проверить маппинг

Get-NfsMappedIdentity -AccountName nfs_user -AccountType User

UserIdentifier      : 0
GroupIdentifier     : 0
UserName            : nfs_user
PrimaryGroup        :
SupplementaryGroups :

Теперь root на ESXi-хостах представлен в домене пользователем nfs_user. Предоставляя ему NTFS доступ мы фактически предоставляем его root’у.

5. тут понятно

6. Так как наш root стал практически пользователем домена, необходимо немного поменять настройки шаринга NFS.

ESXi_user_map_srv_2012_add_root

Вот уж не думал, что получится такая большая заметка. Но, в единственном более менее человечном оригинале, она значительно больше