Республиканцы и демократы.
Зубная паста и апельсиновый сок. Linux и Windows. Некоторые вещи просто
не сочетаются друг с другом, верно? Каждый центр ИТ, с которым я имел
дело, был разбит на два лагеря: команды Windows и команды Linux. Они не
особенно конкурируют друг с другом, но определенно и не сотрудничают. В
некоторых местах дело даже доходит до проведения желтой полосы по полу,
чтобы точно исключить неприлично тесные отношения между двумя группами.
Я принадлежу к стану
Windows, и мне определенно приходилось подтрунивать над моими
ориентированными на Linux коллегами, но всех нас объединяет цель
предоставления организации качественных и рентабельных услуг ИТ. Один
из способов сделать это – совместное использование базовой программной
инфраструктуры, такой как Active Directory. Почти что все организации
ИТ остановились на Active Directory для предоставления служб проверки
подлинности своим настольным компьютерам и серверам под управлением
Windows. Не было бы лучше, если б вместо предоставления отдельной
инфраструктуры проверки подлинности среде Linux (вместе с отдельным
набором имен пользователей и паролей) компьютеры Linux тоже
использовали бы Active Directory? Я думаю, что было бы, и в данной
статье я покажу, как этого добиться.
Проверка подлинности Windows
Windows уже довольно давно поставляется в комплекте с интегрированной системой сетевой проверки подлинности и
единого входа. До Windows
2000 контроллеры доменов Windows NT предоставляли клиентам Windows
службы проверки подлинности, используя протокол NTLM. Хотя NTLM не был
так защищен, как казалось первоначально, он был очень полезен,
поскольку давал удобное решение проблеме необходимости поддерживать
дубликаты учетных записей пользователя на различных серверах сети.
Начиная с Windows 2000,
корпорация Майкрософт перешла с NTLM на Active Directory и ее
интегрированные службы проверки подлинности Kerberos. Kerberos был
значительно защищеннее NTLM, а также лучше масштабировался. К тому же,
Kerberos был стандартом отрасли, уже используемым системами Linux и
UNIX, что открыло врата интеграции этих платформ с Windows.
Проверка подлинности Linux
Первоначально Linux (а
также средства и библиотеки GNU, работавшие на нем) не рассчитывался на
единый механизм проверки подлинности. Как следствие этого, разработчики
приложений Linux обычно брались за разработки собственных схем проверки
подлинности. Им удавалось добиться этого либо за счет поиска хэш-кодов
имен и паролей в /etc/passwd (текстовом файле, традиционно содержащем
учетные данные пользователей Linux) или предоставления совершенно иного
(и отдельного механизма).
Получившийся ассортимент
механизмов проверки подлинности был неуправляемым. В 1995 г. компания
Sun предложила механизм, именуемый подключаемыми модулями проверки
подлинности (Pluggable Authentication Modules – PAM). PAM предоставляли
общий набор интерфейсов API проверки подлинности, который мог
использоваться всеми разработчиками приложений, а также настраиваемый
администратором серверный элемент, позволяющий использовать различные
«подключаемые» схемы проверки подлинности. Использование интерфейсов
API PAM для проверки подлинности и интерфейсов API переключателя
сервера имен (Name Server Switch – NSS) для поиска сведений о
пользователе позволило разработчикам приложений Linux писать меньше
кода, а администраторам Linux управлять процессом проверки подлинности
и настраивать его из одного места.
Большинство выпусков Linux
снабжались несколькими модулями проверки подлинности PAM, включая
модули, поддерживающие проверку подлинности в каталоге LDAP и проверку
подлинности с использованием Kerberos. Эти модули можно использовать
для проверки подлинности в Active Directory, но на это существуют
значительные ограничения, о которых я расскажу ниже в данной статье.
Samba и Winbind
Samba – это проект с
открытым исходным кодом, целью которого является интеграция между
средами Windows и Linux. Samba содержит компоненты, дающие компьютерам
Linux доступ к службам файлов и печати Windows, а также предоставляющие
службы на основе Linux, которые имитируют контроллеры доменов Windows
NT 4.0. Используя клиентские компоненты Samba, компьютеры Linux могут
пользоваться службами проверки подлинности Windows, предоставляемыми
контроллерами доменов Windows NT и Active Directory.
Для нас особо интересна
часть Samba, именуемая Winbind. Winbind – это демон («служба» в
терминах Windows), работающий на клиентах Samba и действующий как
прокси для связи между PAM и NSS, работающими на компьютере Linux, с
одной стороны, и Active Directory, работающей на контроллере домена, с
другой. В частности, Winbind использует Kerberos для проверки
подлинности с помощью Active Directory и LDAP для получения информации
о пользователях и группах. Winbind также предоставляет дополнительные
услуги, такие, как возможность обнаруживать контролер домена, используя
алгоритм, подобный DCLOCATOR в Active Directory, и возможность
сбрасывать пароли Active Directory, связываясь с контроллером домена
при помощи RPC.
Winbind решает ряд проблем,
сохраняющихся при простом использовании Kerberos с помощью PAM. В
частности, вместо жесткого кодирования контроллера домена для проверки
подлинности PAM Winbind выбирает контроллер домена путем поиска по
записям локатора DNS подобно тому, как это делает модуль DC LOCATOR
Майкрософт.
Три стратегии проверки подлинности
Учитывая доступность LDAP,
Kerberos и Winbind на компьютерах Linux, существуют три различные
стратегии реализации, которые можно применить, чтобы дать компьютеру
Linux возможность использовать Active Directory для проверки
подлинности.
Использование проверки подлинности LDAP Простейший,
но наименее удовлетворительный способ использования Active Directory
для проверки подлинности – настроить PAM на использование проверки
подлинности LDAP, как показано на рис. 1. Хотя Active
Directory и является службой LDAPv3, клиенты Windows используют для
проверки подлинности Kerberos (с NTLM в качестве резервного варианта),
а не LDAP.
При проверке подлинности
LDAP (именуемой привязкой LDAP) имя пользователя и пароль передаются
открытым текстом через сеть. Это небезопасно и недопустимо для
большинства целей.
Рис 1. Проверка подлинности в Active Directory с использованием LDAP
Единственным способом
смягчения этого риска открытой передачи учетных данных является
шифрование канала связи клиент-Active Directory с использованием
чего-нибудь вроде SSL. Это определенно возможно, но возлагает
дополнительную нагрузку управления сертификатами SSL как на компьютер
контроллера домена, так и на компьютер Linux. Вдобавок, использование
модуля LDAP PAM не поддерживает изменения сброшенных или истекших
паролей.
Использование LDAP и Kerberos
Другой стратегией использования Active Directory для проверки
подлинности Linux является настройка PAM на использование проверки
подлинности Kerberos и NSS на использование LDAP для поиска информации
о пользователях и группах, как показано на рис. 2.
Эта схема имеет преимущество относительной защищенности, и в ней
используются «встроенные» возможности Linux. Но она не использует
записи расположения службы (SRV) DNS, публикуемые контроллерами доменов
Active Directory, что заставляет проверить определенный набор
контроллеров домена, чтобы проверить подлинность по ним. Это также не
дает особенно интуитивного способа управления истекающими паролями
Active Directory или, до недавнего времени, адекватного поиска членов
групп.
Рис 2. Проверка подлинности в Active Directory с использованием LDAP и Kerberos
Использование Winbind
Третьим способом использования Active Directory для проверки
подлинности Linux является настройка PAM и NSS на выполнение вызовов к
управляющей программе Winbind. Winbind переведет различные запросы PAM
и NSS в соответствующие вызовы Active Directory, используя LDAP,
Kerberos или RPC, в зависимости от того, что будет наиболее подходящим.
На рис. 3 приведен наглядный пример данной стратегии.
Рис 3. Проверка подлинности в Active Directory с использованием Winbind
Наш план реализации
Усовершенствованная
интеграция с Active Directory заставила меня выбрать Winbind на Red Hat
Enterprise Linux 5 (RHEL5) для моего проекта интеграции Linux-Active
Directory. RHEL5 – текущая версия коммерческого выпуска Red Hat Linux,
и она довольно популярна в корпоративных центрах обработки данных.
Чтобы RHEL5 проверял подлинность через Active Directory, нужны, по сути, пять следующих отдельных действий:
- Найти и загрузить подходящий пакет Samba и другие зависимые компоненты.
- Собрать Samba.
- Установить и настроить Samba.
- Настроить Linux, конкретно PAM и NSS.
- Настроить Active Directory.
В нескольких следующих разделах этой статьи данные действия описаны более подробно.
Поиск нужных программ
Одним из крупнейших
различий между Linux и Windows является то, что Linux состоит из
маленького ядра операционной системы и огромной коллекции отдельно
загружаемых и устанавливаемых компонентов. Это делает возможным
создание очень тщательно подобранных комплектов Linux, оптимальных для
определенных задач, но также делает очень сложными настройку сервера и
управление им. Различные дистрибутивы справляются с этим различными
способами. Red Hat (и его некоммерческая родственница Fedora)
используют для установки этих компонентом и управления ими диспетчер
пакетов Red Hat Package Manager (RPM).
Компоненты Linux для Red
Hat имеют две формы. Файлы RPM содержат двоичные файлы, которые были
заранее скомпилированы и собраны для определенного сочетания версии
компонента, выпуска Linux и архитектуры ЦП. Так что можно загрузить и
установить, для примера, версию 1.3.8-5 стандартной системы печати UNIX
(Common UNIX Printing System – CUPS), собранную для Fedora версии 10,
работающей на ЦП архитектуры Intel x86. Учитывая наличие дюжины
различных архитектур ЦП, более чем 100 выпусков Linux и тысяч пакетов и
версий, можно увидеть, что выбирать приходится из невероятного
количества двоичных пакетов RPM.
Исходные файлы RPM, с
другой стороны, содержат реальный исходный код для данного пакета. От
пользователя ожидается, что он загрузит и установит исходные файлы,
настроит параметры сборки, после чего сам скомпилирует и скомпонует
двоичные файлы. Идея сборки собственной операционной системы является
устрашающей для специалиста по Windows, привыкшего устанавливать то,
что Майкрософт предоставляет на компакт-диске установки Windows, но
диспетчер пакетов делает процесс относительно безболезненным и на
удивление надежным. Группа Samba выпускает обновления и исправления
безопасности бешеными темпами; лишь за июль и август 2008 вышло четыре
выпуска Samba 3.2, всего содержавших свыше 100 устраненных ошибок и
исправлений безопасности. Для этого проекта я загрузил файлы исходного
кода для последней стабильной версии Samba, версии 3.0.31.
Почему я загрузил исходный
код Samba вместо заранее скомпилированного набора двоичных файлов?
Поначалу я, конечно, попытался сделать первое. Но после многих часов с
отладчиком я обнаружил, что загруженные мною двоичные файлы не были
собраны нужным для поддержки проверки подлинности Active Directory
образом. В частности, код, поддерживающий сопоставление идентификаторов
Linux в Active Directory, был отключен в сборках по умолчанию, так что
мне пришлось перестраивать Samba с должными параметрами сборки. Я
подробно рассмотрю вопрос сопоставления идентификаторов ниже.
Даже хотя Linux, сам по
себе, является маленьким ядром, в выпуске Red Hat Enterprise заранее
установлено множество пакетов. Обычно это серьезно упрощает жизнь,
позволяя начать с полной и работающей операционной системы, но заранее
установленные пакеты порой конфликтуют с программами, которые
предполагается установить позже.
Я не включил Samba в свою
установку Red Hat (обычно Samba устанавливается по умолчанию),
поскольку мне нужно было использовать более новую версию. Однако более
новая версия Samba требует новых версий нескольких других библиотек и
служебных программ, которые уже были установлены. Проблемы, связанные с
подобной зависимостью, действуют на нервы, но их можно легко решить,
используя RPM.
Существует множество
веб-узлов, на которых размещаются двоичные пакеты RPM. Тот, что
использовал я (просто потому, что он нашелся первым), именуется PBONE и
расположен на rpm.pbone.net. У него имеется удобный способ поиска
пакетов, и на нем есть все двоичные файлы, которые были необходимы для
моей архитектуры ЦП (i386) и выпусков операционной системы (Red Hat
Enterprise Linux 5/Fedora 7 и 8).
Мне пришлось загрузить и обновить пакеты, перечисленные на рис. 4,
чтобы собрать и установить последнюю версию Samba 3.0 (существует еще
более новое дерево версий 3.2, работать с которым я не пробовал).
Отметьте, что все эти пакеты предназначены для выпуска Fedora Core
(fc). Дистрибутив Red Hat основан на тех же исходных кодах, что
используются в Fedora, и полностью совместим с ней. Пакеты, собранные
для Fedora Core 7 и более поздних версий, будут работать в RHEL5 без
изменений. Поместите загруженные файлы RPM в каталог
/usr/src/redhat/RPMS.
Рис. 4. Пакеты, необходимые для сборки и установки Samba 3.0.31
samba-3.031-0.fc8.src.rpm |
Пакет RPM исходного кода Samba 3.0.31 |
gnutls1.6.3-3.fc7.i386 |
Библиотеки проекта GNU для протокола TLS (Transport Layer Security) |
gnutils-devel-1.6.3-3.fc7.i386 |
Файлы разработки проекта GNU для протокола TLS |
popt-1.12-3.fc8.i386 |
Библиотеки анализа аргументов командной строки |
popt-devel-1.12-3.fc8.i386 |
Файлы разработки для анализа аргументов командной строки |
cups-libs-1.2.12-11.fc7.i386 |
Библиотеки стандартной системы печати UNIX |
cups-devel-1.2.12-11.fc7.i386 |
Файлы разработки стандартной системы печати UNIX |
cups-1.2.12.11.fc7.i386 |
Двоичные файлы стандартной системы печати UNIX |
samba-3.031-0.fc8.src.rpm |
Пакет RPM исходного кода Samba 3.0.31 |
gnutls1.6.3-3.fc7.i386 |
Библиотеки проекта GNU для протокола TLS (Transport Layer Security) |
gnutils-devel-1.6.3-3.fc7.i386 |
Файлы разработки проекта GNU для протокола TLS |
popt-1.12-3.fc8.i386 |
Библиотеки анализа аргументов командной строки |
popt-devel-1.12-3.fc8.i386 |
Файлы разработки для анализа аргументов командной строки |
cups-libs-1.2.12-11.fc7.i386 |
Библиотеки стандартной системы печати UNIX |
cups-devel-1.2.12-11.fc7.i386 |
Файлы разработки стандартной системы печати UNIX |
cups-1.2.12.11.fc7.i386 |
Двоичные файлы стандартной системы печати UNIX |
Сборка Samba
Первый этап сборки Samba
заключается в загрузке верного исходного пакета RPM. Я загрузил пакет
RPM исходных кодов для Samba 3.0.31 с веб-узла PBONE. Далее поместите
загруженный файл RPM исходных кодов в /usr/src/redhat/SRPMS; это
стандартный каталог для пакетов RPM исходных кодов в ходе процесса
сборки.
Откройте сеанс терминала
(«окно командной строки» в терминах Windows) и перейдите к папке SRPMS.
После того, как это сделано, установите пакет исходных кодов, используя
команду, как показано на рис. 5.
Рис. 5. Установка пакета RPM исходных кодов Samba
Если появится
предупреждение об ошибке "user mockbuild does not exist—using root"
(«макетной сборки пользователя не существует – используется корень»),
не волнуйтесь. Эта ошибка указывает, что служебные программы макетной
сборки не установлены. Процесс сборки будет работать и без них.
Далее перейдите к каталогу
/usr/src/redhat/SPECS и исправьте файл samba.spec, содержащий параметры
сборки Samba. Найдите строку, начинающуюся с "CFLAGS=", и убедитесь,
что параметр "--with-shared-modules=idmap_ad,idmap_rid" существует.
Этот параметр гарантирует, что в процессе сборки будет включен код,
правильно преобразующий уникальные идентификаторы (unique identifiers –
UID) Linux для Active Directory. На рис. 6 приведен этот параметр.
Рис. 6. Параметр сборки with-shared-modules («с совместно используемыми модулями»)
Далее может понадобиться
обновить некоторые из библиотек на компьютере, чтобы должным образом
собрать и установить Samba; это зависит от того, какие версии библиотек
уже установлены. В моем случае мне пришлось установить пакеты,
перечисленные на рис. 4, используя команду rpm
–install; в некоторых случаях мне пришлось, впрочем, использовать
вариант --force, чтобы преодолеть некоторые из проблем зависимости.
Чтобы собрать Samba, перейдите к каталогу /usr/src/redhat и выполните команду rpmbuild –bb SPECS/samba.spec, как показано на рис. 7.
В результате этой процедуры новый файл RPM samba-3.0.31-0.i386
останется в каталоге /usr/src/redhat/RPMS. Мы установим этот файл RPM
позже по ходу проекта.
Рис. 7. Создание двоичного файла RPM Samba
Настройка работы Linux с сетью
Чтобы проверять подлинность
с помощью Active Directory, компьютер Linux должен иметь возможность
связываться с контроллером домена. Чтобы это могло произойти,
необходимо настроить три параметра сети.
Во-первых, важно убедиться,
что сетевой интерфейс на компьютере Linux настроен должным образом либо
путем использования протокола DHCP, либо путем назначения ему
соответствующего IP-адреса и сетевой маски с помощью команды ifconfig.
В случае RHEL5 можно настроить работу с сетью, выбрав ее (Network) из
меню System | Administration (Система | Администрирование), как
показано на рис. 8.
Рис 8. Настройка сети
Далее убедитесь, что служба
разрешения имен DNS для компьютера Linux установлена на использование
того же сервера имен DNS, который используют контроллеры домена; в
большинстве случаев это контроллер домена в домене, к которому
требуется присоединить компьютер Linux, предполагая, что используется
DNS, интегрированная с Active Directory. Средство разрешения DNS
настраивается на вкладке DNS той же служебной программы настройки сети,
которая использовалась для настройки сети, как показано на рис. 9.
Рис 9. Установка основного средства разрешения DNS
Наконец, по завершении этих
действий, нужно установить имя компьютера Linux для отражения его имени
в домене. Хотя это имя можно установить, используя приложение настройки
сети, это, похоже, не всегда работает должным образом.
Вместо этого измените файл
/etc/hosts и добавьте запись под записью localhost.localdomain в форме
<ip адрес> <полное доменное имя> <имя компьютера>.
(Пример: "10.7.5.2 rhel5.linuxauth.local linuxauth".) Мне следует
отметить, что если этого не сделать, то после присоединения компьютера
Linux к домену в каталоге будет создан неверный объект компьютера.
Настройка синхронизации времени в Linux
Протокол Kerberos
полагается на наличие у систем проверки подлинности часов с достаточно
высокой точностью синхронизации. По умолчанию, Active Directory
допускает максимальное отклонение по времени в пять минут. Чтобы
гарантировать пребывание систем Linux и часов систем контроллеров
домена в пределах этого значения, необходимо настроить системы Linux на
использование службы протокола NTP контроллера домена.
Далее на сервере Linux
запустите служебную программу Date & Time («Дата и время») из меню
System | Administration и выберите вкладку протокола NTP. Установите
флажок Enable Network Time Protocol («Включить протокол NTP») и
добавьте IP-адрес контроллера домена, который нужно использовать как
сетевой источник времени. Обратите внимание, что обычно это должен быть
контроллер домена в домене, содержащим роль FSMO имитатора основного
контроллера домена (primary domain controller – PDC). На рис. 10 приведен пример установки сетевого источника времени для Linux.
Рис 10. Настройка протокола NTP
Настройка PAM и NSS
PAM и NSS предоставляют
средство соединения приложения Linux, такого как рабочая среда, и
Winbind. Подобно многим службам Linux, PAM и NSS настраиваются через
текстовые файлы. Сначала мы рассмотрим настройку PAM.
PAM предоставляет четыре относящихся к проверке подлинности средства использующих им приложениям.
Средство проверки
подлинности позволяет приложению определить, кто использует его.
Средство учетных записей предоставляет функции управления учетными
записями, которые не относятся прямо к проверке подлинности, такими как
ограничение времени входа. Средство паролей предоставляет механизмы для
запроса паролей и управления ими. Средство сеансов выполняет
относящиеся к пользователю задачи установки и удаления для приложения,
такие как ведение журнала или создание файлов в категории конкретного
пользователя.
Файлы настройки PAM в Red
Hat хранятся в каталоге /etc/pam.d, в котором будет находиться
текстовый файл для каждого приложения, использующего PAM для проверки
подлинности. Например, файл /etc/pam.d/gdm содержит информацию о
настройке PAM для Gnome Desktop Manager (GDM), оконной среды по
умолчанию в Red Hat. В каждом файла настройки PAM содержатся несколько
строк, каждая из которых определяет какой-либо аспект процесса проверки
подлинности PAM. На рис. 11 показано содержимое файла настройки PAM для GDM.
Рис. 11. Файл настройки РАМ для Gnome Desktop Manager
Каждая запись в файле
настройки PAM имеет форму <группа управления> <элемент
управления> <модуль> <параметры>, где <группа
управления> соответствует средству, к которому относится запись
настройки: проверки подлинности, учетных записей, паролей или сеансов.
Управляющие ключевые слова, описанные на рис. 12,
говорят PAM, как обработать запись настройки. Третий столбец файла
содержит имя общей библиотеки PAM в каталоге безопасности /lib/. Общие
библиотеки содержат динамически загружаемый исполняемый код, подобный
DLL в Windows. Дополнительные термины после имени модуля – это
параметры, передаваемые модулем PAM общей библиотеке.
Рис. 12. Управляющие ключевые слова PAM
Ключевое слово |
Описание |
Required («Обязательно») |
Если модуль срабатывает успешно, то PAM продолжает вычислять
остающиеся записи для группы управления, и результаты будут определены
результатами остающихся модулей. Если нет, то PAM продолжит вычисление,
но возвратит сбой вызывавшему приложению. |
Requisite («Необходимо») |
Если модуль срабатывает успешно, PAM продолжает вычислять записи
группы управления. Если нет, то PAM произведет возврат вызывавшему
приложению без дальнейшей обработки. |
Sufficient («Достаточно») |
Если модуль сработает успешно, то PAM возвратит успешный результат
вызывавшему приложению. Если нет, то PAM продолжит вычисление, но
результаты будут определены последующими модулями. |
Optional («Необязательно») |
PAM игнорирует результаты модуля, если это не единственный модуль, указанный для группы управления. |
Include («Включить») |
PAM включает в себя содержимое файла настройки PAM, на который дается ссылка, а также содержащиеся в нем процессы и записи. |
Ключевое слово |
Описание |
Required («Обязательно») |
Если модуль срабатывает успешно, то PAM продолжает вычислять
остающиеся записи для группы управления, и результаты будут определены
результатами остающихся модулей. Если нет, то PAM продолжит вычисление,
но возвратит сбой вызывавшему приложению. |
Requisite («Необходимо») |
Если модуль срабатывает успешно, PAM продолжает вычислять записи
группы управления. Если нет, то PAM произведет возврат вызывавшему
приложению без дальнейшей обработки. |
Sufficient («Достаточно») |
Если модуль сработает успешно, то PAM возвратит успешный результат
вызывавшему приложению. Если нет, то PAM продолжит вычисление, но
результаты будут определены последующими модулями. |
Optional («Необязательно») |
PAM игнорирует результаты модуля, если это не единственный модуль, указанный для группы управления. |
Include («Включить») |
PAM включает в себя содержимое файла настройки PAM, на который дается ссылка, а также содержащиеся в нем процессы и записи. |
Можно заметить, что у
каждой группы управления есть несколько записей. PAM обрабатывает
записи по порядку, вызывая названный модуль. Затем модуль возвращает
успех либо сбой, и PAM действует в зависимости от управляющего
ключевого слова.
Можно заметить, что в файле
настройки PAM для GDM есть system-auth для всех групп управления. Это
способ, которым PAM устанавливает поведение при проверке подлинности по
умолчанию для GDM. Модифицируя system-auth, можно модифицировать это
поведение для всех приложений, в которых есть файл system-auth в
настройках PAM. Файл system-auth по умолчанию показан на рис. 13.
Рис. 13. Файл system-auth модуля PAM
Модуль переключателя блока
преобразования имен (NSS) скрывает конкретные сведения о хранилище
данных систем от разработчика приложения, примерно так же, как PAM
скрывает подробности проверки подлинности. NSS позволяет администратору
указать способ, которым хранятся базы данных системы. В частности,
администратор может указать, как хранится информация об имени
пользователя и пароле. Поскольку нам нужно, чтобы приложения искали
информацию о пользователях в Active Directory при помощи Winbind, нам
нужно изменить настройку NSS, чтобы показать это.
Red Hat включает небольшую
графическую программку для настройки PAM и NSS, называемую
system-config-authentication. Она заботится о большинстве изменений (но
не о всех), которые необходимо ввести в файлы system-auth и nss.conf.
Запустите приложение system-config-authentication, и можно будет увидеть диалог, подобный показанному на рис. 14.
Установите флажок Winbind как на вкладке User Information («Информация
о пользователе», она настраивает файл nss.conf), так и на вкладке
Authentication («Проверка подлинности», она модифицирует файл
system-auth).
Рис. 14. Диалог systemconfig-authentication
Нажмите кнопку Configure Winbind, и будет отображен диалог, приведенный на рис. 15.
Введите имя домена, в котором должна проверяться подлинность
пользователей, в поле Winbind Domain и выберите «объявления» как модель
безопасности. Введите доменное имя DNS домена Active Directory в поле
Winbind ADS Realm. В поле Winbind Domain Controllers введите либо имя
контроллера домена, с помощью которого нужно проверять подлинность для
этой системы Linux, или звездочку, указывающую, чтоWinbind следует
выбрать контроллер домена, запрашивая записи SRV в DNS.
Рис. 15. Настройка диалога Winbind
Выберите подходящий
интерпретатор команд по умолчанию, который должны иметь пользователи
Active Directory; в данном случае я выбрал bash (Bourne-again Shell).
Не пытайтесь воспользоваться кнопкой "Join Domain" («Присоединиться к
домену») на этом этапе. Компьютер будет присоединен к домену позже.
В файл
/etc/pam.d/system-auth необходимо внести еще одно дополнительное
изменение после того, как он был модифицирован для поддержки Winbind.
Когда пользователь Linux входит в систему, система требует от
пользователя наличия домашнего каталога. Домашний каталог содержит
многие параметры и элементы настройки конкретного пользователя во
многом подобно реестру Windows. Проблема здесь состоит в том, что
поскольку пользователи создаются в Active Directory, Linux не будет
автоматически создавать домашний каталог пользователя. К счастью, PAM
можно настроить на выполнение этого в качестве части настройки сеанса.
Откройте файл the
/etc/pam.d/system-auth, затем прокрутите экран вниз и вставьте строку
"session optional map_mkhomedir.so skel=/etc/skel umask=0644" перед
последней строкой в разделе сеанса (см. рис. 16). Эта
строка настраивает PAM на создание домашнего каталога для пользователя,
если такового еще не существует. Она будет использовать /etc/skel в
качестве «скелета» шаблона и назначит маску прав 0644 (чтение и запись
для владельца, чтение для основной группы и чтение для всех остальных)
новой папке.
Рис. 16. Создание домашнего каталога для пользователей
Установка и настройка Samba.
Чтобы установить только что
созданные двоичные файлы Samba, перейдите в каталог
/usr/src/redhat/RPMS. Все файлы RPM, созданные командой rpmbuild,
появятся в этом каталоге. Помните, что Samba включает двоичные файлы,
позволяющие клиенту Linux получить доступ к общему хранилищу файлов
Windows (или Samba), а также к коду, позволяющему системе Linux
действовать как файловый сервер Windows, сервер печати Windows и
контроллер домена в стиле Windows NT 4.0.
Чтобы позволить Linux
производить проверку подлинности в Active Directory, всего этого не
нужно; достаточно общих файлов Samba и двоичных файлов клиента Samba.
Эти файлы для нашего удобства разбиты на два файла RPM:
samba-client-3.0.31-0.i386.rpm и samba-common-3.0.31-0.i386.rpm.
Установите файлы RPM, используя команду rpm --install. Приведу пример:
rpm --install samba-common-3.0.31-0.i386.rpm. (Отметьте, что перед этим
нужно установить файл RPM –common.)
После установки двоичных
файлов клиента Samba необходимо модифицировать настройку Samba по
умолчанию, чтобы убедиться, что Winbind обрабатывает проверку
подлинности должным образом с помощью Active Directory. Всю информацию
о настройке Samba (и клиента, и сервера) можно найти в текстовом файле
smb.conf, который по умолчанию находится в каталоге /etc/samba.
Smb.conf может содержать огромное количество параметров настройки, и
полный рассказ о его содержимом выходит за рамки данной статьи. На
веб-узле samba.org и в справочной системе Linux о smb.conf рассказано
подробнее.
Первым этапом настройки
Winbind является использование Active Directory для проверки
подлинности. Модель безопасности в smb.conf необходимо установить на
«объявления». Служебная программа system-config-authentication уже
должна была установить это сама, но проверка никогда не помешает.
Откройте для правки файл smb.conf и найдите раздел, помеченный Domain
Member Options («Параметры члена домена»). Найдите строку, начинающуюся
с "security" и убедитесь, что она читается как "security = ads". На
следующем этапе настройки определяется, как Winbind сопоставит
участников безопасности Windows, таких как пользователи и группы, с
идентификаторами Linux, и это требует несколько более подробного
объяснения.
Проблема сопоставления идентификаторов
У проверки подлинности
пользователей Linux с помощью Active Directory существует одна большая
и пока что не упомянутая мной проблема – проблема уникальных
идентификаторов (UID) для пользователей и групп. Внутренне ни Linux, ни
Windows не называют пользователей их реальными именами, используя
вместо этого уникальный внутренний идентификатор. В Windows
используются идентификаторы безопасности (Security Identifier – SID),
являющиеся структурой переменной длины и дающие уникальное средство
опознания каждого пользователя в домене Windows. SID также содержит
уникальный идентификатор домена, чтобы Windows могла различать
пользователей в различных доменах.
Схема Linux гораздо проще.
Каждый пользователь на компьютере Linux имеет идентификатор UID,
представляющий из себя просто 32-разрядное целое число. Но область
действия идентификатора UID ограничена самим компьютером. Нет никакой
гарантии, что пользователь с идентификатором UID 436 на одном
компьютере Linux идентичен пользователю с идентификатором UID 436 на
другом компьютере Linux. Как следствие, пользователю необходи
|