Итак, сопоставление(маппинг) пользователей ESXi с доменными пользователями в Windows Server 2012.
Эта задача не давала мне покоя несколько дней. И проблема не в ее сложности а в отсутствии материалов на эту тему. Кроме этого, отличаются подходы к выполнению этой задачи в сервере 2008 и 2012. Обыскавшись информации по этому вопросу, собирая все по крупицам, могу с большой уверенностью сказать, что эта статья будет первой в рунете на эту тему.
Немного фундаментальных основ
Протокол NFS очень простой. Предоставил доступ к каталогу, разрешил чтение или запись определенным машинам в сети и все работает как барабан. Собственно, во многом по этой причине он приобрел такую популярность. Но, когда что то простое приходит в среду Windows, все становится сильно сложнее. Хотя, стоит отметить, что реализация NFS в Windows Server 20082012 выполнена отлично. Вся проблема тут в другом, в NTFS.
NTFS это такая низкоуровневая вещь, которая существует сама по себе не взирая не на что. Абсолютно все каталоги и объекты файловой система имеют владельца и список пользователей с некоторыми правами. Это в принципе понятно и давно известно. В случае с доменом Active Directory, в котором по умолчанию запрещен анонимный доступ к каким либо ресурсам, запись в любой каталог, обязательно должна происходить от чьего то имени. То есть от какого либо пользователя зарегистрированного в домене. Естественно, если у него есть на то права. Но, когда мы предоставляем доступ к каталогу по протоколу NFS, писать и читать в него будет не машина находящаяся в домене а ESXi-хост, который и понятия не имеет что такое NTFS. Запись в каталог он осуществляет от имени суперпользователя(root). Естественно в разрешениях NTFS указать учетную запись root с произвольной Linux-машины нельзя т.к. в домене ее не существует. Вот в этом и вся сложность. Далее поясню на примере конкретного каталога.
На этом рисунке мы предоставляем доступ к каталогу test по протоколу NFS. Выделен наиболее важный пункт. Он позволяет, писать в этот каталог, даже тем пользователям, которых нет в домене и соответственно нет в списке NTFS. Это своего рода обход NTFS. Но, как мы знаем, запись в каталог все равно должна осуществляться от чьего то имени. Поэтому предусмотренны варианты. Разрешить несопоставленный доступ пользователей Unix(по UID/GID) — это означает, что будет взят UID и GID пользователя от которого производитсься запись и на их основе сгенерируется аналог SIDа пользователя Windows. Этот SID будет указан владельцем записанных файлов с соответствующими правами.
В результате список прав NTFS на записанных ESXi-хостом файлах будет выглядить следующим образом.
Непонятный набор цифр со знаком вопроса и есть наш пользователь 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’а.
3. Указать где искать сопоставление пользователей и групп нужно в свойствах сервера NFS.
Диспетчер серверов -> Сервер для NFS -> Свойства -> вкладка Сетевые группы. Указываем полное имя домена.
Далее на сервере 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.
Вот уж не думал, что получится такая большая заметка. Но, в единственном более менее человечном оригинале, она значительно больше
Помогла ли вам статья?
