Трудно представить себе современную сеть, в которой не было бы рабочих станций и серверов на базе Microsoft Windows. Сосуществование UNIX и Windows в одной сетевой среде обуславливает гетерогенный её характер, выражающийся в том числе и в несовместимости методов доступа к сервисам, предоставляемым LAN. Наиболее типичной проблемой в таких сетях является наличие как минимум двух глобальных баз аутентификации пользователей для доступа к ресурсам. В современных ОС семейства Windows индустриальным стандартом является сервер каталогов Active Directory, для UNIX-систем, к сожалению, подобного единообразного подхода не существует, но на большинстве конфигураций также используются LDAP-сервера различных вендоров. Очевидно, что наличие двух (или более) независимых хранилищ аутентификационных данных становится препятствием при необходимости получения доступа к ресурсам UNIX-серверов с машин под управлением ОС Windows и наоборот.
Существует как минимум два эффективных подхода к решению данной проблемы
1. ПО Samba, акцентированное на проблемах взаимодействия UNIX и Windows-систем (сближение со стороны UNIX-систем). Данный метод позволяет пользователям Windows проходить аутентификацию в UNIX посредством отображения соотв. учётных записей Windows на заданный диапазон идентификаторов пользователей UNIX;
2. Microsoft Services For Unix (SFU), позволяющие добавить в Active Directory дополнительные атрибуты учётных записей, характерные для UNIX-систем и таким образом адаптирующие AD для использования в качестве базы аутентификации UNIX.
Второй метод на реальных конфигурациях используется относительно редко ввиду необходимости существенной модификации AD, требующей абсолютных администраторских привилегий, и относительной ненадёжности: корпорация Microsoft может изменять спецификации AD и SFU довольно часто, что в некоторых ситуациях способно создать затруднения не только при переходе к новой версии серверной ОС Windows, но даже и при элементарном её обновлении.
Здесь мы опишем только первый метод в контексте использования LDAP-каталога в качестве хранилища информации об учётных записях пользователей, получаемой из Active Directory.
Программный пакет Samba является открытой реализацией протокола SMB, используемого для доступа к разделяемым сетевым ресурсам в ОС семейства Windows, а также в OS/2 (что и немудрено, поскольку последняя является родоначальником упомянутого семейства). Он состоит из нескольких модулей, каждый из которых отвечает за свою часть функциональности пакета и конфигурируется в общем для всех компонентов Samba глобальном файле настройки smb.conf. Модуль, позволяющий авторизоваться и получать доступ к ресурсам Samba-сервера с использованием учётных записей из Windows, называется winbind. В том числе он отвечает за взаимодействие UNIX-систем с Active Directory (традиционно в качестве сокращённого названия используется аббревиатура AD), одним из наиболее известных сервисов каталогов, который начиная с Windows 2000 Server используется всеми серверными и версиями Windows как распределённое хранилище информации об объектах доменов сети Windows. Для связи с AD модуль Winbind использует следующие механизмы:
- Поиск в зоне DNS srv-записей контроллера домена и Kerberos Distribution Center для получения сведений о ролевой и функциональной структуре сети Windows;
- RPC-запросы контроллера домена;
- Непосредственное чтение из AD посредством LDAP-протокола.
Для заданного REALM’а (аналог домена) Winbind получает сведения об имеющихся учётных записях и при помощи вспомогательного модуля IDMap производит их отображение в UNIX. При этом используются стандартные для UNIX механизмы работы с объектами системного уровня: NSS (Name Switching Space) и PAM (Pluggable Authentication Modules), описанные в статье “Сервер каталогов LDAP как источник аутентификации – настройка NSS и PAM”. Для такого отображения необходимо определить способ установления соответствия между идентификаторами объектов (пользователей, групп) AD и уникальными идентификаторами UNIX (uidNumber, gidNumber соответственно). В случае связки Winbind+IDMap в зависимости от выбора метода соответствие может быть как достоверным (т.е. предиктивным, однозначным), так и произвольным (непредиктивным). Однозначные методы пытаются с использованием элементарной функции хеширования напрямую получить из поля RID (Relative ID) атрибута objectSID учётной записи пользователя в AD значение uidNumber/gidNumber соотв. эквивалентного ему объекта UNIX. Источником проблем здесь является принципиальное различие между способами структурного представления учётных записей в UNIX и Windows. Как известно, объекты в сетях Windows логически объединены в иерархическую структуру по признаку доменной принадлежности, в UNIX же общепринятой является так называемая плоская схема хранения сведений об объектах в плоских табличных структурах, на более высоком уровне объединяемых в некое подобие релятивной базы данных, в которой первичными ключами являются значения UID и GID объектов. Прямым следствием вышесказанного является то, что в совпадение имён пользователей в UNIX – аномалия, а в Windows – иерархии, состоящей из множества взаимно доверяющих друг другу доменов, эта ситуация совершенно нормальна. Таким образом, если в разных доменах встречаются пользователи с одинаковыми именами, в UNIX они должны отображаться как разные пользователи, для чего доменная часть добавляется к имени пользователя как необязательная составляющая и отделяется от него так называемым разделителем – «сепаратором».
Факультативность доменной части обусловлена тем, что во-первых домен в сети может быть всего один, когда фактически мы получаем ту же плоскую структуру, что в UNIX, а во-вторых – на уровне соглашений может быть принято, что имена пользователей уникальны по всему лесу. И в том, и в другом случае возможно непосредственное отображение имён без использования доменной части.
Итак, давайте рассмотрим пример конфигурации WinBind в связке с IDMap и OpenLDAP, взятый с реальной «боевой» системы, выполняющей функции файлового сервера в достаточно разветвлённом сильно перегруженном доменном лесе, зиждющемся на серверах Windows 2003.
auth methods = winbind #==/WINBIND/ winbind enum groups = no winbind enum users = no template shell = /bin/bash template homedir = /home/Samba/HomeDirs/%D/%U winbind uid = 3500-65000 winbind gid = 3500-65000 winbind nested groups = no winbind offline logon = true winbind cache time = 86400 allow trusted domains = no #==\WINBIND\ #==/IDMap/ idmap backend = ldap:ldap://127.0.0.1 #==\IDMap\ #==/LDAP/ ldap admin dn = uid=srvSamba,cn=Auxiliary Accounts,ou=Groups,dc=company,dc=com ldap suffix = dc=company,dc=com ldap idmap suffix = ou=IDMap #==\LDAP\
Постараюсь доходчиво объяснить назначение приведённых опций:
idmap backend – задаёт тип используемого бэкенда IDMap (в примере: ldap) и параметры, передаваемые бэкенду (URI-путь к серверу каталогов, например, ldap://127.0.0.1 или ldaps://ds.mydomain.com:1636)
ldap suffix – суффикс дерева LDAP, идентифицирующий базу данных;
ldap idmap suffix – смещение относительно суффикса до корня дерева отображений идентификаторов objectSID/uidNumber – Строго говоря, название опции вводит пользователя в заблуждение, потому что несмотря на семантическую схожесть с ldap suffix, фактически этот параметр задаёт относительную базу для поиска соответствий (отображений), но не имеет ни малейшего отношения к понятию суффикса (корня) дерева каталогов;
ldap admin dn– DN пользователя, от имени которого будет осуществляться доступ к СК. Этот пользователь должен иметь право на создание новых записей в целевой ветви, путь к которой совместно задаётся параметрами «ldap suffix» и «ldap idmap suffix»;
winbind enum groups, winbind enum users – указывают winbind на необходимость рекурсивного обхода всей доступной части доменного леса для формирования полного списка объектов, попадающих в «область интересов» winbind (пользователей, групп, рабочих станций сети). Необходимость в подобном перечислении возникает довольно редко – например, при использовании утилиты getent
winbind uid, winbind gid – диапазоны численных идентификаторов группы и пользователя, на которые через преобразование по таблице соответствия отображаются соответственно группы и пользователи из Active Directory.
Таким образом, для IDMap резервируется пул численных идентификаторов, в пределах которого порядок и последовательность отображения объектов контроля доступа зависят от настроек IDMap;
template shell, template homedir – оболочка пользователя из AD по умолчанию. После установки Microsoft Services For Unix становится возможным добавлять UNIX-специфичные атрибуты группам и пользователям Windows-доменов, поэтому данная опция не распространяется на всех доменных пользователей, но лишь на тех, у которых соотв. атрибуты не определены. Понятно, что если SFU ни на одном контроллере домена AD не используются или значения специфичных для UNIX атрибутов нигде не установлены, значения template shell и template homedir становятся глобальными;
Для того, чтобы Samba могла авторизоваться на LDAP-сервере, ей нужно передать пароль пользователя, указанного в параметре ldap admin dn. Этот пароль будет добавлен в локальное хранилище паролей Samba с расширением tdb, запись в которую осуществляет следующая команда:
smbpasswd -w «password»
Обратите внимание на то, что хотя имя пользователя и не передаётся команде smbpasswd, пароль в tdb-файл всё равно будет внесён вместе с отличительным именем администратора IDMap-ветви LDAP, поэтому при смене ldap admin dn, необходимо повторно выполнить данную команду, даже если пароль нового DN совпадает с паролем старого.. Также есть ещё два важных момента, которые следует учитывать при настройке отображения Windows -> UNIX в пространство некой ветви СК:
1. В виду отсутствия возможности точно указать базу, глубину и фильтры поиска пользователей в AD (на мой взгляд, это существенная недоработка winbind), количество записей, для которых будут созданы отображения в LDAP-каталоге, может быть очень значительным. В следствие этого для достаточно сложных доменных топологий рекомендуется создавать IDMap-базу на собственном самостоятельном суффиксе, иначе вы получите резкое снижение производительности СК на рекурсивных запросах со scope=sub
2. При назначении прав доступа учётной записи ldap admin dn, следует разрешать модификацию объекта-«корня» ветви отображения, поскольку он модифицируется Winbind’ом: добавляется objectClass=sambaUnixIdPool, атрибуты uidNumber и gidNumber. В означенных атрибутах IDMap хранит номера uidNumber и gidNumber, используемые при заведении новых пользователей/групп – берётся значение из этих атрибутов, присваивается вновь созданному объекту, затем инкрементированное новое значение записывается поверх считанного старого. Если таблица IDMap отделена от основной ветви каталога и хранится в отдельной базе, что предпочтительно с точки зрения производительности (см.выше), то проще всего использовать учётную запись администратора базы. Напомним, что для OpenLDAP это параметр задаётся как значение rootdn соответствующей секции конфигурационного файла slapd.conf, а для большинства СК, созданных на основе кода Netscape, по умолчанию это «cn=Directory Manager».
Помните о том, что после внесения необходимых изменений в файл smb.conf, необходимо применить их, перезапустив сервера smb и winbind.
После завершения настройки Samba, выполните команду testparm для синтаксической проверки корректности файла smb.conf. Убедившись в том, что всё в порядке, давайте попробуем ввести сервер в домен:
net ads join -U 'ADMIN'
где ADMIN – имя (идентификатор) пользователя в AD, имеющего право на создание учётных записей рабочих станций в целевом домене. В ответ на запрос введите пароль пользователя ADMIN, и через некоторое время при удачном стпечении обстоятельств Вы получите сообщение о том, что подключение к домену прошло успешно. В случае возникновения проблем (что более, чем вероятно), в первую очередь проверьте, может ли быть преобразовано имя компьютера из параметра «netbios name» файла smb.conf в IP-адрес и правильно ли осуществляется это преобразование. Проверьте свой файл /etc/hosts: во-первых в той строке, где указывается соответствие имени хоста адресу loopback-интерфейса НЕ должно содержаться имя компьютера из netbios name, во вторых, имени хоста должен быть сопоставлен адрес именно того реального сетевого интерфейса машины, через который она будет отправлять запросы к AD. Проиллюстрирую на примере выдержки из /etc/hosts:
127.0.0.1 localhost.localdomain localhost 3.163.186.141 SMBLINUX.My.Domain.Ru SMBLINUX
Здесь SMBLINUX – имя машины, а My.Domain.Ru – её realm, в данном случае совпадающий с именем DNS-домена.
Если с присоединением к домену всё прошло успешно (чего я очень вам желаю, не по наслышке зная, как это бывает непросто). Теперь укажем уже знакомой нам службе переключателя пространств имён (NSS) на необходимость обращения к WinBind за учётными записями пользователей и групп из Active Directory. Для этого отредактируйте файл /etc/nsswitch.conf, добавив модуль winbind в последовательность служб, запрашиваемых NSS при поиске системных обьектов в общесистемных базах (пространствах имён) passwd, group и shadow. Например, в случае, если запросы NSS уже обрабатываются с использованием баз files и ldap, то при настроенном winbind результирующие строки в nsswitch.conf должны выглядеть следующим образом:
passwd: files ldap [SUCCESS=return UNAVAIL=return] winbind shadow: files ldap [SUCCESS=return UNAVAIL=return] winbind group: files ldap [SUCCESS=return UNAVAIL=return] winbind
Далее для проверки работоспособности winbind и первоначальной инициализации базы соответствий в LDAP (которая для каждого «мигрированного» аккаунта из AD осуществляется только после первого обращения к соотв. записи) рекомендуется временно установить параметры winbind enum users/idmap enum users и winbind enum groups/idmap enum groups в значение yes и последовательно дать команды getent passwd и getent group. В результате после некоторой задержки, величина которой во многом зависит от сложности иерархии целевого домена AD, Вы должны получить перечень пользователей AD, «видимых» из UNIX, имена которых будут представлены в формате [{WORKGROUP}{WB_DELIMITER}]{USERNAME}, где
WORKGROUP – название рабочей группы AD из одноимённого параметра файла smb.conf;
WB_DELIMITER – разделитель между доменной частью и именем;
USERNAME – имя объекта-пользователя в AD.
Для настройки авторизации через PAM Вам необходимо отредактировать файл /etc/pam.d/system-auth и добавить модуль pam_winbind во все стэки после pam_unix, так что результирующий файл может выглядеть, например, следующим образом:
auth required pam_env.so auth sufficient pam_unix.so likeauth nullok auth sufficient pam_ldap.so use_first_pass auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_winbind.so account sufficient pam_ldap.so password required pam_cracklib.so retry=3 password sufficient pam_unix.so nullok use_authtok md5 shadow password sufficient pam_ldap.so use_authtok password sufficient pam_winbind.so use_authtok password required pam_deny.so session required pam_limits.so session required pam_unix.so session optional pam_mkhomedir.so skel=/etc/skel umask=0022