NFSv4 + Kerberos: единое сетевое хранилище для Linux и Windows через AD-группы

У одного из наших клиентов сложилась типичная ситуация: build-сервер на Linux, разработчики сидят на Windows, общие исходники живут в трёх местах одновременно - Samba-шара, FTP-папка и ещё какая-то самодельная синхронизация через rsync по крону. Само собой, файлы расходились, права были у всех разные, а кто что менял - непонятно. Решили привести это в порядок через NFSv4 с Kerberos и правами через AD-группы.

Почему NFSv4, а не Samba

Samba работает нормально, но у неё есть неприятное свойство: когда Linux-процесс записывает файл, UID маппится через /etc/passwd или winbind, и права получаются непредсказуемыми, если конфигурация на нескольких хостах разошлась. NFSv4 с Kerberos решает это иначе: в сетевом трафике ходят настоящие Kerberos-принципалы, сервер видит, кто реально обращается, и сопоставляет с POSIX-правами через sssd/idmap.

Windows поддерживает NFS через компонент «Services for NFS», который входит в состав Windows Server 2008 R2 и в Windows 7 Enterprise/Ultimate как «Client for NFS». Это не что-то экзотическое - встроенный клиент, просто по умолчанию не установлен.

Что потребовалось

Серверная сторона (Linux, CentOS 6):

• nfs-utils, rpcbind
• krb5-workstation - хост введён в домен AD через Kerberos
• sssd с конфигурацией id_provider = ad
• keytab для NFS-принципала: nfs/nfs-server.corp.local@CORP.LOCAL

Keytab создаётся на контроллере домена через ktpass:

ktpass -princ nfs/nfs-server.corp.local@CORP.LOCAL
       -mapuser NFS-SERVER$ -ptype KRB5_NT_PRINCIPAL
       -crypto AES256-SHA1 -pass * -out nfs.keytab

Файл закидывается на сервер в /etc/krb5.keytab, права 600, владелец root.

В /etc/exports экспорт выглядит так:

/data/shared  *(rw,sec=krb5p,fsid=0,crossmnt)
/data/shared/build  *(rw,sec=krb5p,all_squash,anonuid=1500,anongid=1500)
/data/shared/src    *(rw,sec=krb5p,no_root_squash)

sec=krb5p - это полное шифрование трафика плюс Kerberos-аутентификация. Есть ещё krb5 (только аутентификация без шифрования) и krb5i (аутентификация плюс проверка целостности). Для внутренней сети взяли krb5p - производительность просела незначительно, зато трафик не читается сниффером.

Клиентская сторона (Windows 7 / Server 2008 R2):

Устанавливается «Client for NFS» через «Программы и компоненты - Компоненты Windows». После этого работает монтирование:

mount -o anon \\nfs-server\shared Z:

Но с Kerberos важно, чтобы Windows-клиент был в том же домене, и чтобы для пользователя был прописан UID/GID в атрибутах AD - иначе сервер не знает, кому что давать.

Маппинг UID через AD

Это самое занятное место. Linux использует UID/GID, Windows - SID. Чтобы они дружили, нужно прописать uidNumber и gidNumber в атрибутах пользователей AD. RFC 2307 определяет эти атрибуты, и Schema Extension для них есть в Server for NFS - устанавливается вместе с ролью.

После установки расширения схемы через snap-in или ldifde в свойствах пользователей AD появляются поля NFS. Заполнили для всех разработчиков вручную (около 20 человек), для новых - через PowerShell-скрипт при создании учётки.

На Linux-стороне sssd c ldap_user_uid_number = uidNumber забирает эти атрибуты напрямую из AD, без winbind. Это надёжнее и проще в отладке.

Права через группы AD

Создали в AD группы: nfs-build-rw, nfs-src-rw, nfs-src-ro. В /etc/group через sssd эти группы видны с нормальными GID (прописаны через gidNumber на группах AD). На сервере:

chown -R root:nfs-build-rw /data/shared/build
chmod -R 2770 /data/shared/build

chown -R root:nfs-src-rw /data/shared/src
chmod -R 2775 /data/shared/src

setgid-бит на директориях важен: новые файлы наследуют группу директории, а не первичную группу создателя. Без него разработчик создаёт файл с группой domain users, и коллеги его не могут редактировать.

Что не сработало сразу

Первое - время на хостах. Kerberos жёстко завязан на синхронизацию времени. Расхождение больше 5 минут - и аутентификация падает с невразумительной ошибкой. У нас один Windows-клиент жил с неправильным часовым поясом, и мы минут двадцать смотрели в логи krb5 прежде чем поняли в чём дело. NTP должен быть настроен на всех участниках - включая рабочие станции.

Второе - firewall между сегментами. NFSv4 использует один порт 2049, что хорошо. Но rpcbind (порт 111) тоже нужен для монтирования. Добавили в правила - заработало.

Третье - Client for NFS и буква диска. Монтирование через mount в Windows не сохраняется после перезагрузки. Сделали через скрипт в GPO при логоне - простой net use Z: \\nfs-server\shared. Работает надёжно, ярлык на рабочем столе пользователи перестали трогать.

Итог на сегодня

Build-сервер и разработчики работают с одним набором файлов. Прав через AD-группы хватает на нужное разграничение: разработчики пишут в /src, сборочный процесс пишет в /build, читать можно всем. Дублирования данных нет.

Открытый вопрос - производительность при одновременной работе десятков клиентов. Пока нагрузка умеренная, но нагрузочного тестирования не делали. Для клиентов на сопровождении инфраструктуры это будет следующий шаг перед тем, как масштабировать схему на другие команды.