Трудно представить себе современную сеть, в которой не было бы
рабочих станций и серверов на базе 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 использует следующие механизмы:
1)Поиск в зоне DNS srv-записей контроллера домена и Kerberos
Distribution Center для получения сведений о ролевой и функциональной
структуре сети Windows;
2)RPC-запросы контроллера домена;
3)Непосредственное чтение из 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
Источник: http://asplinux.net/node/3541 |