Аутентификация файловых серверов gnu linux в домене windows на базе ad часть 1

Время на прочтение10 мин

Количество просмотров21K

Аутентификация Samba в домене Windows

1. Введение. Обзор существующих публикаций

В последнее время системные администраторы сталкиваются с задачей объединения разнородных операционных систем в сети предприятия. В частности, одной из проблем является применение серверов GNU/Linux совместно с рабочими станциями и серверами под управлением Windows различных версий.
Обычно сеть небольшого предприятия включает в себя около 20-30 рабочих станций с операционной системой Windows 7, контроллер домена на базе Windows Server 2008 R2, маршрутизатор и нескольких специализированных серверов. Дальше мы будем рассматривать включение таких серверов на базе GNU/Linux в домен Windows Server 2008 R2 и порядок работы с такими серверами.
В качестве первой задачи рассмотрим организацию файлового сервера Samba в домене Windows Server 2008 R2. Проблеме создания файловых серверов на основе Samba посвящено множество статей и публикаций на различных форумах. В качестве примера можно привести документацию по Samba, опубликованную на официальном сайте проекта www.samba.org/samba/docs. Здесь приведены различные материалы, начиная со второго издания известной книги «Using Samba», написанной Джеем Ц (Jay Ts), Робертом Экштейном (Robert Eckstein) и Дэвидом Колльер-Брауном (David Collier-Brown) и выпущенной издательством O’Reilly & Associates. Третье издание этой книги, увидевшее свет в 2007 году, на сайте пока недоступно. Следует отметить и прекрасный набор руководств HOWTO и примеров конфигураций, представленный на сайте.
Немалое количество дополнительной информации о работе Samba можно получить и на сайтах производителей основных дистрибутивов Linux.
Стоит отметить и различные авторские материалы, опубликованные в в сетевых и печатных изданиях; например, статью Александра Фархутдинова в журнале Linux Format (http://wiki.linuxformat.ru/index.php/LXF123:Samba), Блог любителя экспериментов (http://www.k-max.name/) и целый ряд статей на таких известных ресурсах как www.opennet.ru и habrahabr.ru. Читатели могут сами убедиться в этом, задав поиск фразы «Включение samba в домен Windows» или «Включение Linux в домен Windows» и получив в итоге десятки и сотни тысяч ссылок.
Цель данной статьи – не только дать конкретные рекомендации по включению серверов GNU/Linux в доменную структуру Windows, но и рассмотреть работу тестовой сети, эмулирующую сеть небольшого предприятия. Мы постараемся рассмотреть большинство аспектов работы в такой сети и дать рекомендации по организации взаимодействия всех ее элементов.

2. Описание тестовой сети, домена Windows

Для организации тестовой сети мы будем использовать виртуальную среду VMware VSphere 5, реализованную на базе архитектуры гипервизора ESXi. Однако можно было бы воспользоваться и хорошо себя зарекомендовавшим Microsoft Hyper-V, а также любым другим аналогичным решением
Тестовая среда представляет собой, доменную сеть на базе Active Directory (Active Directory Domain Services – AD DS ), которая состоит из двух серверов инфраструктуры, работающих под управлением MS Windows Server 2008 R2 EE, и одной клиентской машины – MS Windows 7 Professional. Используются IP-адреса из подсети 192.168.7.0/24

Картинка с сайта: habr.com

Наименование домена – LAB.LOCAL Контроллер домена – LAB-DC1.lab.local Сервер Forefront Threat Management Gateway (TMG) 2010 – LAB-TMG.lab.local Клиент – LAB-CL1 .lab.local
На LAB-DC1 установлены роли

• Службы сертификации Active Directory (Active Directory Certificate Services — AD CS)
• Доменные службы Active Directory (Active Directory Domain Services — AD DS)
• DHCP – сервер (Scope name: LAB.LOCAL; Address pool: 192.168.7.20-192.168.7.70)
• DNS – сервер (Type: AD-Integrated; Dynamic updates: Secure only)
• Веб-службы (IIS)

Примечание
Установка доменной службы AD DS выполнена в соответствии с рекомендациями, изложенными в статье technet.microsoft.com/en-us/library/dd378801(v=ws.10).aspx

3. Механизмы авторизации в домене Windows

Картинка с сайта: habr.com

Крайне важной частью протокола SMB являются методы аутентификации. Несоответствие их на сторонах клиента и сервера является причиной значительного числа проблем сетевого доступа. Всего существует четыре основных метода аутентификации.
Источник — wiki.linuxformat.ru/index.php/LXF123:Samba

Открытым текстом
По понятным причинам, этот метод аутентификации является и самым простым и самым ненадежным. Такая аутентификация использовалась старыми версиями Samba. В текущих версия пароль шифруется по умолчанию. Для отключения шифрования необходимо изменить значение параметра encrypted password в файле smb.conf на false. Так же этот метод применялся в клиентах для MS DOS а так же в старых версиях Windows NT. Уже в Windows 95 (и более новых версиях) для его активации необходимо править реестр. Для Windows 2000 и выше возможно включить этот метод аутентификации через локальные политики безопасности. Для этого необходимо установить выставить значение «Да» переключателя «Посылать незашифрованный пароль сторонним SMB-серверам». Еще раз заметим: использование этого метода сегодня ничем не оправдано и крайне не рекомендуется.

Методом LM (LAN manager)
Используется в Windows 95/98. Samba по умолчанию допускает аутентификацию по протоколу LM. При возникновении проблем с доступом к ресурсам под управлением Windows NT 4.0 и выше необходимо откорректировать локальные политики безопасности на Windows-сервере — установить переключатель «Уровень проверки подлинности LAN Manager» в положение «Отправлять LM и NTLM ответы».

Методом NTLM
Появился в Windows NT 3.5. В настоящее время используется в несколько переработанном и усовершенствованном виде — NTLMv2. NTLMv2 работает по схеме «запрос-ответ». Интересная особенность этого метода заключается в том, что сервер не хранит пароль не только в открытом, но и в зашифрованом виде. Хранится лишь его хэш, но и он по сети не передается, что очень хорошо с точки зрения безопасности.
Windows 95/98 могут работать с NTLMv2 после установки клиента Directory Services. Samba также поддерживает этот метод аутентификации.

С помощью службы Kerberos

Kerberos — мощная система, выполняющая аутентификацию и авторизацию пользователей, которая используется в домене Active Directory (AD) в качестве основной. Она также обеспечивает шифрование внутрисетевого трафика. Протокол Kerberos предлагает механизм взаимной аутентификации клиента и сервера перед установлением связи между ними, причём в протоколе учтён тот факт, что начальный обмен информацией между клиентом и сервером происходит в незащищённой среде, а передаваемые пакеты могут быть перехвачены и модифицированы. Другими словами, протокол идеально подходит для применения в Интернете и аналогичных сетях. Начиная с третьей версии, Samba может являться полноценным клиентом домена Active Directory.
На этот метод мы обратим особое внимание, так как наша статья посвящена интеграции Samba-сервера на Linux в домен AD, а значит работать необходимо именно с Kerberos.
В операционной системе Windows Server 2008 R2 Центр распределения ключей (Key Distribution Center, KDC) реализован как служба домена. В качестве базы данных учетных записей он использует Active Directory. Кроме того, некоторые данные о пользователях поступают в него из глобального каталога (Global Catalog).
Центр KDC, как и служба каталогов Active Directory, имеется в каждом домене. Обе службы автоматически запускаются подсистемой LSA (Local Security Authority – распорядитель локальной безопасности), которая установлена на контроллере домена. Они работают в пространстве процессов этого распорядителя. Ни одну из этих служб остановить невозможно. Чтобы гарантировать постоянный доступ к KDC и Active Directory, в Windows предусмотрена возможность развертывания в каждом домене нескольких равноправных контроллеров домена. При этом запросы на аутентификацию и на выдачу билета, адресованные службе KDC данного домена, может принимать любой контроллер домена.
Центр KDC (Key Distribution Service) представляет собой единый процесс, объединяющий две службы: службу аутентификации Authentication Service (AS) и службу выдачи билетов Ticket-Granting Service (TGS). В общих чертах процесс выглядит следующим образом:
При входе в сеть, клиент обращается к службе аутентификации того домена, где находится учетная запись пользователя, предоставляя ей логин и пароль. В ответ та выдает клиенту билет TGT — Ticket-Granting Ticket, разумеется, если логин и пароль верны. После этого в игру вступает TGS. Эта служба выдает билеты на доступ к другим службам своего домена или к службе выдачи билетов доверяемого домена. Чтобы обратиться в службу TGS, клиенту нужно сначала войти в контакт со службой выдачи билетов того домена, где находится учетная запись службы, представить свой билет TGT и запросить нужный билет. Если у клиента нет билета TGT, который открывает доступ к данной службе выдачи билетов, он может воспользоваться процессом переадресации (referral process). Начальной точкой этого процесса является служба того домена, где находится учетная запись пользователя, а конечной – служба выдачи билетов домена, где находится учетная запись требуемой службы.
Во многих источниках билеты называют «тикетами», «квитанциями» и даже «мандатами». Но смысл от этого не меняется- это «документ» подтверждающий право воспользоваться сервисом.
В среде Windows политика Kerberos определяется на уровне домена и реализуется службой KDC домена. Она сохраняется в каталоге Active Directory как подмножество атрибутов политики безопасности домена. По умолчанию вносить изменения в политику Kerberos имеют право только члены группы администраторов домена.
В политике Kerberos предусматриваются:
Максимальный срок действия пользовательского билета (Maximum user ticket lifetime). Под «пользовательским билетом» здесь имеется в виду билет на выдачу билетов (билет TGT). Значение задается в часах и по умолчанию равно 10 часов.
Максимальное время, в течение которого допускается обновление пользовательского билета (Maximum lifetime that a user ticket can be renewed). Задается в сутках; по умолчанию составляет 7 суток.
Максимальный срок действия служебного билета (Maximum service ticket lifetime). Под «служебным билетом» здесь имеется в виду сеансовый билет. Значение этого параметра должно быть более 10 минут, но менее значения Maximum user ticket lifetime. По умолчанию оно равно 10 часов.
Максимально допустимое отклонение в синхронизации компьютерных часов (Maximum tolerance for synchronization of computer clocks). Указывается в минутах; по умолчанию равно 5 мин.

Проверка ограничений при входе пользователя в систему (Enforce user logon restrictions). Если этот пункт помечен флажком, служба KDC анализирует каждый запрос на сеансовый билет и проверяет, имеет ли данный пользователь право на локальный вход в систему (привилегия Log on Locally) или на доступ к запрашиваемому компьютеру через сеть (привилегия Access this computer from network). Такая проверка занимает дополнительное время и может замедлить предоставление сетевых услуг, поэтому администратору предоставляется право ее отключения. По умолчанию она включена.
Сразу стоит упомянуть несколько подводных камней, с которыми можно столкнуться. В первую очередь расхождение часов на стороне клиента и сервера должно составлять не более нескольких минут (по умолчанию, как уже было сказано выше, не более пяти), иначе сервер признает квитанцию клиента недействительной и откажет ему в доступе. В этом случае на клиентской Windows-машине или сразу будет выведено сообщение «Доступ запрещен», или Windows раз за разом будет спрашивать логин-пароль без всякого видимого результата. Во-вторых следует помнить, что основу Active Directory составляют четыре технологии: DNS, LDAP, SMB и Kerberos. Все они работают в составе домена, но к каждой из них можно обращаться как самостоятельной службе. Несмотря на такую независимость служб, неверная работа хотя бы одной из них сделает включение клиента в домен невозможным. Особое внимание следует обратить на то, что если на стороне клиента неверно указаны сервер DNS, имя клиента или имя домена, то он не будет включен в домен AD. Причиной этого является тот факт, что DNS-сервер в составе домена Active Directory хранит SRV-записи, указывающие на расположение серверов KDC и LDAP.

4. Требуемые пакеты для GNU/Linux

Все упомянутые ниже пакеты нужны для развертывания OpenLDAP, Kerberos и Samba на сервере, работающем под управлением Ubuntu Linux 10.04.4 LTS 64 с графической оболочкой Xfce. Также приводятся сведения о необходимых для установки предустановленных пакетах в соответствии с официальной документацией для OpenLDAP, Kerberos и Samba

Для сборки OpenLDAP необходимы следующие пакеты:

• Компилятор C, например gcc (обязательно)
• Reentrant POSIX REGEX software (обязательно)
• Cyrus SASL 2.1.21+ (рекомендуется)
• OpenSSL 0.9.7+ (рекомендуется)

Необходимые пакеты можно установить командой sudo apt-get install имя_пакета.
Так же потребуется Oracle Berkeley DB версий 4.4 – 4.8 или 5.0 – 5.1. О том, как собрать ее из исходников, мы расскажем чуть позже, когда будем говорить о сборке OpenLDAP.

Для сборки Kerberos нам понадобятся пакеты flex и bison(sudo apt-get install flex bison), иначе при сборке вы получите ошибку “yacc – command not found”. Затем нам понадобится g++ (sudo apt-get install g++), так как в противном случае Kerberos снова не соберется, сообщив, что “g++ — command not found.”

К моменту сборки Samba у нас уже должны быть установлены и OpenLDAP и Kerberos, в этом случае установка дополнительных пакетов не потребуется.
Для установки пакетов gcc, g++, flex, bison можно воспользоваться менеджерами пакетов, установленной на Вашем дистрибутиве GNU/Linux. Обычно нужно просто отметить эти пакеты при первоначальной установке системы.

5. Сборка пакетов из исходных текстов.

Итак, переходим к самой части — сборке пакетов из исходников. Конечно, сборка из исходников не является распространенной практикой для современных дистрибутивов Linux, и представляет скорее исследовательский интерес. Мы рассмотрим сборку из исходников, так как этот процесс является, в целом, универсальным для любого дистрибутива Linux. В дальнейшем мы будем работать с репозиториями, что несколько проще.
Сборка OpenLDAP
Сначала с сайта Oracle скачиваем source-файлы Berkeley DB(далее — BDB) с сайта Oracle. www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.html В нашем случае все получилось с BDB 4.8
Компилируем и устанавливаем BDB:

	tar xvzf db-4.8.30.tar.gz
	cd db-4.8.30/build_unix
	../dist/configure #Если необходимы специфические параметры - /configure 	--help
	make
	sudo make install

Скачиваем исходные тексты OpenLDAP www.openldap.org/software/download
В нашем случае это была версия 2.4.30.
Компилируем и устанавливаем OpenLDAP:

tar -xzvf openldap-2.4.30.tgz
cd openldap
export CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include 	-D_GNU_SOURCE"
export LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib"
export LD_LIBRARY_PATH="/db-4.8.30.NC/build_unix/.libs/"
./configure --with-tls=no #если необходимы некие особенные опции установки — ./configure --help
make depend
make
make test #на этом шаге проверяется OpenLDAP. Времени это занимает много, можно смело попить кофе.
make install

Вот и все с OpenLDAP. Напоследок хочется упомянуть несколько наиболее распространенных ошибок:
configure: error: Berkeley DB version mismatch
Solution: скорее всего вы не экспортировали переменные LDFLAGS и LD_LIBRARY_PATH, как было сказано выше.
getpeereid.c:52: error: storage size of ‘peercred’ isn’t known
Вы, скорее всего забыли о флаге -D_GNU_SOURCE, который необходим для обхода несовместимости с glibc.
И еще раз внимательно проверьте все, ли необходимые пакеты установлены на вашей системе.
Сборка Kerberos

Скачиваем Kerberos web.mit.edu/kerberos/dist/index.html Мы использовали current release.
После этого распаковываем, собираем и устанавливаем программу:

t

ar -xzvf  krb5-1.10.1.tar.gz
cd /krb5-1.10.1/src
./configure --with-ldap=yes #здесь, если необходимо, указываем опции. Какие — можно поинтересоваться командой ./configure —-help.
make
make install
make check #проверяем результат наших трудов.

Если вы получите ошибку «yacc — command not found», значит, вы забыли поставить пакеты flex и bison.
sudo apt-get install flex bison
Если «g++ – command not found», значит, забыли про компилятор g++.

sudo apt-get install g++

Сборка Samba
Скачиваем исходники Samba c www.samba.org/samba/download. Нам нужна последняя версия, поэтому качаем samba-latest.tar.gz.
Разархивируем, собираем и устанавливаем Samba:

tar -xzvf samba-latest.tar.gz
cd samba-3.6.3
cd source3
./configure --with-ldap=yes --with-ads=yes  
make
make install

Скорее всего, если все предыдущие шаги были выполнены правильно, сборка и установка Samba пройдет без проблем. Если нет — в первую очередь проверьте, все ли зависимости корректно установлены. Если Samba чего-то будет не хватать, она заявит об это весьма ясно.
Конечно, сборка всех пакетов из исходных текстов трудоемкая процедура с невысоким коэффициентом полезного действия. Поэтому лучше всего установить требуемые пакеты с использованием менеджера пакетов Вашего дистрибутива GNU/Linux.
Итак, все пакеты установлены и пора переходить к настройке.

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) имя пользователя и пароль передаются открытым текстом через сеть. Это небезопасно и недопустимо для большинства целей.

Картинка с сайта: www.cyberguru.ru

Рис 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 или, до недавнего времени, адекватного поиска членов групп.

Картинка с сайта: www.cyberguru.ru

Рис 2. Проверка подлинности в Active Directory с использованием LDAP и Kerberos

Использование Winbind Третьим способом использования Active Directory для проверки подлинности Linux является настройка PAM и NSS на выполнение вызовов к управляющей программе Winbind. Winbind переведет различные запросы PAM и NSS в соответствующие вызовы Active Directory, используя LDAP, Kerberos или RPC, в зависимости от того, что будет наиболее подходящим. На рис. 3 приведен наглядный пример данной стратегии.

Картинка с сайта: www.cyberguru.ru

Рис 3. Проверка подлинности в Active Directory с использованием Winbind

Наш план реализации

Усовершенствованная интеграция с Active Directory заставила меня выбрать Winbind на Red Hat Enterprise Linux 5 (RHEL5) для моего проекта интеграции Linux-Active Directory. RHEL5 – текущая версия коммерческого выпуска Red Hat Linux, и она довольно популярна в корпоративных центрах обработки данных.

Чтобы RHEL5 проверял подлинность через Active Directory, нужны, по сути, пять следующих отдельных действий:

1. Найти и загрузить подходящий пакет Samba и другие зависимые компоненты.
2. Собрать Samba.
3. Установить и настроить Samba.
4. Настроить Linux, конкретно PAM и NSS.
5. Настроить 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

Первый этап сборки Samba заключается в загрузке верного исходного пакета RPM. Я загрузил пакет RPM исходных кодов для Samba 3.0.31 с веб-узла PBONE. Далее поместите загруженный файл RPM исходных кодов в /usr/src/redhat/SRPMS; это стандартный каталог для пакетов RPM исходных кодов в ходе процесса сборки.

Откройте сеанс терминала («окно командной строки» в терминах Windows) и перейдите к папке SRPMS. После того, как это сделано, установите пакет исходных кодов, используя команду, как показано на рис. 5.

Картинка с сайта: www.cyberguru.ru

Рис. 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 приведен этот параметр.

Картинка с сайта: www.cyberguru.ru

Рис. 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 позже по ходу проекта.

Картинка с сайта: www.cyberguru.ru

Рис. 7. Создание двоичного файла RPM Samba

Настройка работы Linux с сетью

Чтобы проверять подлинность с помощью Active Directory, компьютер Linux должен иметь возможность связываться с контроллером домена. Чтобы это могло произойти, необходимо настроить три параметра сети.

Во-первых, важно убедиться, что сетевой интерфейс на компьютере Linux настроен должным образом либо путем использования протокола DHCP, либо путем назначения ему соответствующего IP-адреса и сетевой маски с помощью команды ifconfig. В случае RHEL5 можно настроить работу с сетью, выбрав ее (Network) из меню System | Administration (Система | Администрирование), как показано на рис. 8.

Картинка с сайта: www.cyberguru.ru

Рис 8. Настройка сети

Далее убедитесь, что служба разрешения имен DNS для компьютера Linux установлена на использование того же сервера имен DNS, который используют контроллеры домена; в большинстве случаев это контроллер домена в домене, к которому требуется присоединить компьютер Linux, предполагая, что используется DNS, интегрированная с Active Directory. Средство разрешения DNS настраивается на вкладке DNS той же служебной программы настройки сети, которая использовалась для настройки сети, как показано на рис. 9.

Картинка с сайта: www.cyberguru.ru

Рис 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.

Картинка с сайта: www.cyberguru.ru

Рис 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.

Картинка с сайта: www.cyberguru.ru

Рис. 11. Файл настройки РАМ для Gnome Desktop Manager

Каждая запись в файле настройки PAM имеет форму <группа управления> <элемент управления> <модуль> <параметры>, где <группа управления> соответствует средству, к которому относится запись настройки: проверки подлинности, учетных записей, паролей или сеансов. Управляющие ключевые слова, описанные на рис. 12, говорят PAM, как обработать запись настройки. Третий столбец файла содержит имя общей библиотеки PAM в каталоге безопасности /lib/. Общие библиотеки содержат динамически загружаемый исполняемый код, подобный DLL в Windows. Дополнительные термины после имени модуля – это параметры, передаваемые модулем PAM общей библиотеке.

Рис. 12. Управляющие ключевые слова PAM

Можно заметить, что у каждой группы управления есть несколько записей. PAM обрабатывает записи по порядку, вызывая названный модуль. Затем модуль возвращает успех либо сбой, и PAM действует в зависимости от управляющего ключевого слова.

Можно заметить, что в файле настройки PAM для GDM есть system-auth для всех групп управления. Это способ, которым PAM устанавливает поведение при проверке подлинности по умолчанию для GDM. Модифицируя system-auth, можно модифицировать это поведение для всех приложений, в которых есть файл system-auth в настройках PAM. Файл system-auth по умолчанию показан на рис. 13.

Картинка с сайта: www.cyberguru.ru

Рис. 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).

Картинка с сайта: www.cyberguru.ru

Рис. 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 (чтение и запись для владельца, чтение для основной группы и чтение для всех остальных) новой папке.

Картинка с сайта: www.cyberguru.ru

Рис. 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. Как следствие, пользователю необходимо подключаться к каждому компьютеру, доступ к которому ему нужен, что является нежелательной ситуацией.

Сетевые администраторы Linux обычно решают эту проблему, предоставляя сетевую проверку подлинности с помощью либо сетевой информационной системы (Network Information System – NIS), либо общего каталога LDAP. Сетевая система проверки подлинности предоставляет идентификатор UID для пользователя, и все компьютеры Linux, пользующиеся этой системой, будут пользоваться теми же идентификаторами пользователя и группы. В этой ситуации я использую Active Directory для предоставления уникальных идентификаторов пользователей и групп.

Для решения этой проблемы я использую две стратегии. Первая (а также наиболее очевидная) стратегия – создать идентификатор UID для каждого пользователя и группы и сохранить этот идентификатор с помощью соответствующего объекта в Active Directory. При ее применении, когда Winbind проверяет подлинность пользователя, я могу взглянуть на его идентификатор UID и предоставить его Linux в качестве внутреннего идентификатора данного пользователя. Winbind ссылается на эту схему как на сопоставление идентификаторов Active Directory (или idmap_ad). На рис. 17 показан процесс сопоставления идентификаторов Active Directory.

Картинка с сайта: www.cyberguru.ru

Рис 17. Процесс сопоставления идентификаторов Active Directory

Единственным недостатком сопоставления идентификаторов Active Directory является необходимость предоставления механизма наличия идентификаторов у каждого пользователя и группы, а также их уникальности в пределах леса. Более подробную информацию можно найти на боковой панели «Настройка Active Directory для сопоставления идентификаторов Active Directory».

К счастью, существует еще одна стратегия сопоставления идентификаторов, влекущая гораздо меньше административных издержек. Вспомним, что идентификатор SID Windows уникально идентифицирует пользователя внутри домена, а также сам домен. Часть идентификатора SID, уникально идентифицирующая пользователя внутри домена, именуется относительным идентификатором (RID) и является на самом деле 32-разрядным целым числом. Так что Winbind может просто извлечь RID из SID при входе пользователя в систему и затем использовать RID как уникальный внутренний идентификатор UID. Winbind ссылается на эту стратегию как на сопоставление идентификаторов RID или idmap_rid. На рис. 18 показано, как реально работает сопоставление RID.

Картинка с сайта: www.cyberguru.ru

Рис. 18. Сопоставление RID

Сопоставление RID имеет преимущество нулевых административных издержек, но его нельзя использовать в многодоменной среде в силу вероятности наличия одного значения RID у пользователей в нескольких доменах. Но при наличии одного домена Active Directory сопоставление RID – это верный выбор.

Чтобы настроить стратегию сопоставления ID в Winbind, откройте файл /etc/samba/smb.conf для правки снова и добавьте строку «idmap backend = ad» для использования стратегии сопоставления Active Directory, либо «idmap backend = rid» для использования стратегии сопоставления RID. Убедитесь в отсутствии других строк, указывающих стратегию сопоставления в файле.

Существует ряд других параметров настройки, которые нужно добавить к файлу smb.conf для Winbind. Даже если PAM установлен на создание домашнего каталога для каждого пользователя при его входе в систему, необходимо сказать Winbind, что это за имя. Мы делаем это путем добавления строки «template homedir = /home/%U» к smb.conf (см. рис. 19). Это говорит Winbind, что домашним каталогом для каждого пользователя, удостоверившего свою подлинность с помощью Active Directory, будет /home/<имя пользователя>. Не забудьте сначала создать каталог /home.

Картинка с сайта: www.cyberguru.ru

Рис. 19. Указание имени домашнего каталога

Присоединение к домену и вход в систему

Теперь, когда сеть, PAM, NSS и Samba Winbind настроены верно, пора присоединить компьютер Linux к домену. Это можно сделать с помощью команды net программы Samba. В запросе интерпретатора команд выполните «net ads join –U <имя администратора>». Замените <имя администратора> именем учетной записи, имеющей достаточно полномочий для присоединения компьютеров к домену.

Команда net запросит пароль пользователя. Если все сработает нормально, она присоединится к нужному компьютеру в домене. Для обнаружения созданной учетной записи компьютера можно использовать оснастку «Active Directory – пользователи и компьютеры».

Протестировать состояние присоединения можно с помощью тестового средства Winbind, именуемого wbinfo. Если выполнить wbinfo –t, будут протестированы отношения доверия между компьютером и доменом. В результате выполнения wbinfo –u будут перечислены все пользователи в домене, а wbinfo –g – все группы.

В случае успешного присоединения компьютера Linux к домену следующим этапом будет попытка входа в систему с помощью учетной записи пользователя и пароля Active Directory. Выйдите из системы на компьютере Linux и войдите в систему, используя имя пользователя Active Directory. Если всё сработает верно, то возможность входа в систему должна присутствовать.

Настройка Active Directory для процесса сопоставления идентификаторов Active Directory

Эта информация применима только к тем, кто использует сопоставление идентификаторов Active Directory. Те, то решил использовать сопоставление RID, могут спокойно не обращать внимания на эту панель.

Перед тем, как войти в систему на сервере Red Hat, используя учетную запись Active Directory, необходимо внести некоторые изменения в саму Active Directory. В-первых, в схему Active Directory придется внести атрибуты, используемые Winbind для хранения информации пользователя. При работе с Windows Server 2003 R2 схема готова к применению. В случае наличия более ранней версии схемы Active Directory ее придется расширить, используя пакет служб Microsoft Services for UNIX (SFU).

Дополнительную информацию можно найти по адресу Services for UNIX на TechNet. SFU также включает дополнительную страницу свойств для пользователей Active Directory Users и оснастку консоли управления компьютерами Майкрософт (Computers Microsoft Management Console – MMC), позволяющую управлять информацией об индивидуальном и групповом модификаторах, требуемой Linux.

После того, как схема установлена должным образом, необходимо предоставить идентификаторы Linux для всех пользователей (и групп, членами которых они являются), которые могут зайти на компьютер Linux. Это значит, что необходимо определить значения для атрибутов uidNumber и gidNumber для пользователей и групп, которые могут зайти на компьютер Linux. Но следует помнить о некоторых требованиях к этим атрибутам:

1. Linux требует идентификатор UID для каждого пользователя, удостоверяющего свою подлинность. Поскольку нам необходимо управлять информацией о пользователях в Active Directory, то каждая учетная запись пользователя, который будет входить в систему на компьютере Linux, должна иметь уникальный атрибут uidNumber. Конкретное значение, используемое для uidNumber, несущественно, но оно должно быть уникальным для всех пользователей, которые могут заходить на компьютер Linux.
2. Каждый пользователь Linux должен также иметь идентификатор группы по умолчанию, так что каждый пользователь Active Directory, входящий на компьютер Linux, требует значения также для атрибута gidNumber. Это значение не обязано быть уникальным среди пользователей, но оно должно уникально определять группу.
3. Каждая группа в Active Directory должна иметь уникальное значение для своего атрибута gidNumber. Строго говоря, для групп вполне нормально не иметь значения для атрибута gidNumber, но при проверке подлинности пользователя Winbind ожидает, что каждая группа, к которой тот принадлежит, будет иметь уникальное значение gidNumber. Вероятно, гораздо проще просто убедиться в наличии у каждой группы уникального значения gidNumber.
4. Winbind ожидает, что каждый пользователь, находимый им в Active Directory, будет членом группы пользователей домена, так что он также ожидает, что группа пользователей домена имеет значения для своего атрибута gidNumber.

А если это не заработает?

Установка компьютера Linux на проверку подлинности с помощью Active Directory и через Winbind – нетривиальный проект. Существует масса элементов, которые нужно настроить, и масса вещей, которые можно сделать неправильно. Тот факт, что каждая версия Linux или Samba несколько различаются по своим возможностям, не облегчает этой задачи. Но существует ряд источников, содержащих информацию о происходящем.

Во-первых, это файл журнала системы Linux, ведущийся в /var/log/messages. Samba будет помещать в этот файл сообщения о значительных событиях, таких как пропажа файлов или плохая настройка. В дополнение к файлу журнала системы, свои файлы журнала есть у Samba и Winbind. Их можно найти в /var/log/samba, и они предоставят пользователю некоторую дополнительную информацию.

Подробность (и объем) сообщений журналов, выдаваемых Winbind, можно увеличить, изменив его сценарий запуска для установки уровня отладки. Отредактируйте сценарий интерпретатора команд /etc/init.d/winbind и добавьте «-d 5» к команде winbind. Это увеличит уровень отладки до 5 (допустимые значения от 1 до 10), что заставит winbind создавать более детальные сообщения об ошибках.

Если Winbind доходит до связи с контроллером домена, можно провести запись сетевых пакетов с помощью служебной программы вроде Netmon 3.1. Это позволяет проанализировать, что именно Winbind пытается сделать. Можно также изучить журнал безопасности Windows на контроллере домена, в который будут занесены попытки проверки подлинности.

Теперь, когда это заработало, что у нас имеется?

Если все слаженно работает, то теперь имеется возможность входить в системы Linux, используя учетные данные, поддерживаемые в Active Directory. Это огромное улучшение по сравнению с локальным управлением идентификацией на компьютере Linux или использованием небезопасной системы вроде NIS. Это позволяет централизовать управление пользователями в одном хранилище удостоверений: Active Directory.

Но здесь не хватает некоторых вещей, которые могли бы сделать это решение действительно полезным. Во-первых, получение технической поддержки здесь – дело удачи. Многие организации Linux не очень-то разбираются в Active Directory, а поддержка, которую можно получить от сообщества Linux, целиком зависит от того, кто прочитал ваше сообщение и его настроения на сегодняшний день.

Кроме того, пакет Samba не снабжен средствами переноса или развертывания. В случае наличия существующих учетных записей Linux, с которыми связаны идентификаторы пользователей и полномочия, необходимо вручную убедиться, что они сохраняют свои идентификаторы UID при переносе их в Active Directory.

Наконец, одно из наиболее важных приложений Active Directory, групповая политика, не доступно с Samba, хотя над этим идет работа. Хотя систему Linux можно присоединить к Active Directory с помощью Samba, ей нельзя управлять, используя групповую политику.

Решения от сторонних производителей

Проверка подлинности для компьютеров Linux с помощью Active Directory – очевидно, хорошее дело, но создание собственного решения с помощью Samba Winbind утомительно, если не просто кошмарно. Читатели могут подумать, что кто-то из изобретательных поставщиков ПО должен выступить с более простым в использовании решением, и они будут правы.

Четыре поставщика коммерческого ПО разработали простые в установке и использовании версии того, что я продемонстрировал в этой статье. Они предоставляют код и средства переноса для почти всех популярных версий Linux, UNIX и Apple Macintosh, а также поддержку управления компьютерами Linux с помощью групповой политики.

Четыре компании это: Centrify , Likewise Software, Quest Software и Symark . Все четыре поставщика предоставляют похожие функции, включая управление групповой политикой в широком спектре выпусков Linux. Likewise Software недавно открыла код своей реализации, именуемой Likewise Open, хотя ее компонент групповой политики остается коммерческим продуктом. Likewise Open будет доступен для нескольких крупных выпусков Linux. (Раскрою секрет: пока я писал эту статью, моя компания, NetPro, была приобретена Quest Software.)

Имеет ли смысл строить собственную систему проверки подлинности, используя Samba и Winbind, когда доступны коммерческие варианты? Если бюджет не предусматривает денег на программы интеграции, то использование Samba с его открытым кодом имеет преимущество бесплатности. При этом также получаешь весь исходный код, что может быть заманчивым достоинством. Но перенос существующих компьютеров Linux и их существующих идентификаторов UID – весьма тернистая проблема.

С другой стороны, если требуется сэкономить время на реализацию и установку, либо имеются существующие компьютеры Linux, которые нужно перенести, либо предпочтителен ответ специалиста на возникший вопрос, то знакомство с коммерческими решениями имеет смысл. В случае же необходимости управления групповой политикой им нет альтернативы.

Но любое решение по интеграции проверки подлинности системами Linux с Active Directory сокращает усилия, уходящие на управление несколькими учетными записями пользователей, улучшает безопасность системы и предоставляет единое хранилище удостоверений для управления и аудита. И это достаточно основательные причины, чтобы попытаться применить его.

Автор: Джил Киркпатрик

В одной из прошлых заметок мы рассмотрели процедуру присоединения сервера на базе Ubuntu Server 14.04 LTS к домену Active Directory (AD) для обеспечения работы процедур аутентификации и авторизации на прокси-сервере Squid 3.3. Тем самым мы упростили доступ рядовых доменных пользователей к ресурсам Интернет. Однако не стоит забывать и об администраторах. Использование локальных учетных записей для аутентификации и авторизации администраторов на Linux-серверах может доставлять свои неудобства, когда количество таких серверов в организации увеличивается. В этой заметке мы рассмотрим процедуры настройки сервера Ubuntu направленные на упрощение процедур аутентификации и авторизации при входе в Linux-систему путём использования учетных записей пользователей и групп безопасности домена AD.

Как и в предыдущих заметках посвященных теме интеграции Linux в AD, в качестве хранилища доменных учетных записей пользователей и групп в нашем примере будут использоваться контроллеры домена под управлением ОС Microsoft Windows Server 2012 R2.

Прежде чем приступим, хочу сделать одно важное замечание. В этой заметке мы будем выполнять корректировку некоторых системных конфигурационных файлов, отвечающих за работу аутентификации и авторизации для локального и удалённого входа в Linux-систему. Поэтому, перед тем как начать подобные корректировки, настоятельно рекомендую сделать резервную копию системы, например снапшот виртуальной машины, ибо в случае некорректных настроек PAM мы сможем получить проблемы со входом в систему (например после перезагрузки сервера).

Устанавливаем плагин для Samba4 (nss_winbind) и поддержку Winbind для PAM:

sudo apt-get install libnss-winbind libpam-winbind

Проверяем работу Kerberos пытаясь получить билет для какого-нибудь доменного пользователя.

kinit artur-p@HOLDING.COM

Проверяем наличие билета Kerberos

klist

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: artur-p@HOLDING.COM

Valid starting       Expires              Service principal
07/01/2014 14:06:14  07/02/2014 00:06:14  krbtgt/HOLDING.COM@HOLDING.COM
        renew until 07/02/2014 14:06:09

Очищаем кэш билетов:

kdestroy

Конфигурация Samba4 по умолчанию для новых пользователей подразумевает создание домашнего каталога пользователя по шаблону (template homedir) /home/{Домен}/{Логин} с отсутствием оболочки (template shell). Немного изменим конфигурацию /etc/samba/smb.conf задав параметр описывающий оболочку

sudo nano -Y sh /etc/samba/smb.conf

Новое содержимое smb.conf:

[global]
   netbios name = KOM-AD01-GW10
   workgroup = KOM
   security = ADS
   realm = HOLDING.COM
   password server = KOM-DC01, KOM-DC02, *
   encrypt passwords = yes

   interfaces = 10.0.0.0/8
   bind interfaces only = yes

   allow trusted domains = No
   winbind use default domain = yes
   winbind enum users  = yes
   winbind enum groups = yes

#   log level = 9

   idmap config *:backend = tdb
   idmap config *:range = 1000000-1999999
   idmap config KOM:backend = rid
   idmap config KOM:range = 10000-999999

   template homedir = /home/%D/%U
   template shell = /bin/bash
   winbind refresh tickets = yes

   preferred master = No
   local master = No
   domain master = No

   load printers = No
   show add printer wizard = No
   printcap name = /dev/null
   disable spoolss = Yes

Обратите внимание на то, что по сравнению с конфигурационным файлом приведённым для примера ранее, добавился также ряд других параметров, нацеленных не конкретно под нашу задачу, а для оптимизации работы процессов Samba.

После изменения диапазона idmap в smb.conf не плохо бы сбросить кэш Winbind:

sudo net cache flush

Для вступления новой конфигурации smb.conf перезапускаем службы Samba:

sudo service smbd restart
sudo service nmbd restart
sudo service samba restart
sudo service winbind restart

Добавляем возможность использования Winbind в системный конфигурационный файл nsswitch.conf

sudo nano -Y sh /etc/nsswitch.conf

Дописываем winbind в строки passwd и group. Результирующий файл будет выглядеть так:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

Убеждаемся в том, что ниже указанные команды возвращают список как локальных пользователей и групп так и доменных:

sudo getent passwd
sudo getent group

Обратите внимание на то, что при большом количестве пользователей и групп в домене вывод getent может работать некорректно в том случае, если в конфигурации smb.conf диапазон idmap недостаточно велик. Хотя на самом деле у нас нет необходимости получать полный список всех групп и пользователей домена, а достаточно выполнить проверку для какой-то одной конкретной группы, например для доменной группы безопасности, которую мы специально создали для объединения администраторов серверов Linux…

sudo getent group 'KOM-SRV-Linux-Administrators'

kom-srv-linux-administrators:x:206484:artur-p,senya-l,petya-r

…и для доменной учетной записи любого пользователя, которую мы планируем использовать для входа на наш Ubuntu Server…

sudo getent passwd 'artur-p'

artur-p:*:98981:10513:Артур Пирожков:/home/KOM/artur-p:/bin/bash

Создадим в каталоге домашних папок пользователей подкаталог для доменных пользователей в соответствии с настройками нашего smb.conf (в качестве имени каталога используем NetBIOS-имя домена):

sudo mkdir /home/KOM

Проверим, что после установки библиотеки libpam-winbind соответствующие PAM-модули для Winbind активирован.

sudo pam-auth-update

Картинка с сайта: blog.it-kb.ru

Правим файл /etc/pam.d/common-session. В конец файла добавим строку определяющую директиву создания домашнего каталога в случае его отсутствия: 

sudo nano -Y sh /etc/pam.d/common-session

Результирующий файл (без вывода комментариев) получится следующий:

session [default=1]     pam_permit.so
session requisite       pam_deny.so
session required        pam_permit.so
session optional        pam_umask.so
session required        pam_unix.so
session optional        pam_winbind.so
session optional        pam_systemd.so
session required        pam_mkhomedir.so umask=0022 skel=/etc/skel

Правим файл /etc/pam.d/common-auth. В строку описывающую вызов pam_winbind.so добавляем дополнительный параметр require_membership_of, в котором указываем имя доменной группы безопасности. В эту группу будут входить пользователи, которым мы хотим разрешить вход на наш Linux-сервер. Имя группы желательно указывать с учётом регистра, то есть так, как она создана в домене AD. Указанная группа должна быть группой глобального типа (область действия в домене AD).

sudo nano -Y sh /etc/pam.d/common-auth

Результирующий файл (без вывода комментариев) получится следующий:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass require_membership_of=KOM-SRV-Linux-Administrators
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

Обратите внимание также на то, что в указанные файлы не стоит вносить никаких других изменений кроме указанных, даже таких простых, как например, изменение отступов в существующих параметрах. В противном случае мы потеряем возможность управлять включением/выключением PAM-модулей через конфигуратор pam-auth-update. Проверить то, как после ручной правки pam-auth-update воспринимает common-файлы, можно просто запустив его и если что-то ему не понравится, он сообщит нам об этом:

Картинка с сайта: blog.it-kb.ru

Если же всё таки где-то напортачили, то можно заставить pam-auth-update исправить параметры common-файлов в их исходные значения выбрав в указанном сообщении Yes, либо отдельной командой:

sudo pam-auth-update --force

Остальные common-файлы привожу информативно. В них мы редактировать вручную ничего не будем, так как конфигуратор pam-auth-update уже внёс все необходимые правки со ссылкой на winbind.

Результирующий файл /etc/pam.d/common-account (без вывода комментариев):

account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_winbind.so
account requisite                       pam_deny.so
account required                        pam_permit.so

Результирующий файл /etc/pam.d/common-password (без вывода комментариев):

password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 default=ignore]      pam_winbind.so use_authtok try_first_pass
password        requisite                       pam_deny.so
password        required                        pam_permit.so

Результирующий файл /etc/pam.d/common-session-noninteractive (без вывода комментариев):

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session optional                        pam_umask.so
session required        pam_unix.so
session optional                        pam_winbind.so

После указанных настроек проверяем вход в систему используя учетные данные пользователя домена AD. В качестве логина указываем доменный логин пользователя (без доменной части). При этом проверяем, то что в систему удаётся войти только тем пользователям, которые включены в доменную группу безопасности KOM-SRV-Linux-Administrators. В случае возникновения проблем при входе следим за системным логом аутентификации:

sudo tail -f /var/log/auth.log

Замечено, что в случае, если в домене AD в свойствах групп безопасности, членом которых является аутентифицируемый пользователь, присутствует непустой атрибут sIDHistory (группа ранее была мигрирована в текущий домен из другого домена), то в процессе входа в Linux может появляться ряд сообщений типа:

...
groups: cannot find name for group ID 11224
groups: cannot find name for group ID 11231
groups: cannot find name for group ID 11277
groups: cannot find name for group ID 12569
groups: cannot find name for group ID 12737
groups: cannot find name for group ID 12753
...

Это связано с тем, что после аутентификации и авторизации для пользователя запускается shell-оболочка, которая была назначена пользователю согласно параметра template shell конфигурационного файла smb.conf. То есть в нашем случае выполняется оболочка /bin/bash. В текущей своей версии оболочка bash при запуске выполняет скрипт /etc/bash.bashrc. Если мы откроем этот скрипт, то увидим, что в нём присутствует такой фрагмент кода:

# sudo hint
if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; then
    case " $(groups) " in *\ admin\ *)
    if [ -x /usr/bin/sudo ]; then
        cat <<-EOF
        To run a command as administrator (user "root"), use "sudo ".
        See "man sudo_root" for details.

        EOF
    fi
    esac
fi

Этот участок скрипта используется для банального вывода подсказки о том, что для выполнения административных действий требуется использовать sudo. При этом здесь выполняется проверка членства залогинившегося пользователя в группах вызовом утилиты groups, которая в свою очередь при вызове в контексте доменного пользователя будет пытаться вернуть список доменных групп в которые он входит. При этой операции используется Winbind, у которого есть проблемы с чтением из домена AD групп имеющих непустой атрибут sIDHistory.

Чтобы избавиться от вывода подобного рода сообщений при входе в систему есть два простых решения. Либо закомментировать представленный выше участок кода в файле /etc/bash.bashrc, либо для доменных пользователей использовать альтернативную shell-оболочку, например zsh (при этом надо поменять параметр template shell конфигурационного файла smb.conf на /bin/zsh и перезапустить службы Samba). Я предпочёл первый способ.

Итак, мы уже имеем возможность локального и удалённого (по SSH) входа на наш Linux-сервер используя учётную запись пользователя домена AD с ограничением по членству в доменной группе безопасности. Однако для выполнения таким пользователем административных действий в Linux-системе, нам потребуется включить для этого пользователя возможность выполнения sudo. Проще всего будет выдать данное разрешение не для конкретного пользователя, а сразу для указанной доменной группы. Для этого нам потребуется внести изменения в системный конфигурационный файл /etc/sudoers. Прямая правка этого файла не рекомендуется, поэтому воспользуемся специальным инструментом visudo, который при сохранении файла sudoers выполняет его проверку:

sudo visudo

Приведу фрагмент файла, в котором описываются группы доступа имеющие возможность выполнять sudo (здесь была добавлена последняя строчка фрагмента):

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
%KOM-SRV-Linux-Administrators ALL=(ALL) ALL

После сохранения файла снова входим в систему доменным пользователем и пробуем выполнить любую команду с sudo.

На этом всё. В следующей заметке мы рассмотрим процедуру настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows

Дополнительные источники информации:

• Ubuntu.ru WIKI — Ввод компьютера в домен Windows
• Ubuntu Community Help Wiki — Active Directory Winbind How-to
• Samba manpages — smb.conf.5
• Habrahabr — Linux в домене Active Directory
• UNIX/LINUX TECH NOTES  — Authenticate Linux users by Windows AD: LDAP+Kerberos or Winbind method

Для текущего проекта понадобилось ввести рабочие станции на базе Ubuntu linux в Windows домен. Этот вопрос я уже подробно рассматривал в различных интерпретациях, поэтому теоретическую часть рассматривать не будем, а перейдем сразу к практике.

1. Устанавливаем необходимые пакеты (smbd и winbind):

# aptitude install samba winbind

2. Так как современные версии SAMBA получают сведения о домене из DNS-записей необходимо удостовериться, что в качестве DNS-сервера указан DNS-сервер домена Active Directory.

3. Настраиваем конфигурационный файл (приведу действующий пример с комментариями)

[global]
    # Рабочая группа (Короткое имя домена)
    workgroup = SINTEZ
    # Полное наименование домена
    realm = sintez.sintez.com
   # Описание рабочей станции в проводнике Windows
    server string = %h workstation (Samba, Ubuntu)
    # Разрешаем nmbd делать запросы к DNS
    dns proxy = yes
    # Параметры логирования
    log file = /var/log/samba/log.%m
    max log size = 1000
    syslog = 0
    # Режим работы рабочей станции (член домена)
    server role = member server
    # Хранилище локальных пользователей и групп
    passdb backend = tdbsam
    # Использовать ли Linux pam (не используем)
    obey pam restrictions = no
    unix password sync = no
    # Запросы с неправильным паролем будут отклонены, если такое имя пользователя существует.
    map to guest = bad user
    # Не позволяет не аутентифицированным пользователям получить доступ к общим ресурсам пользователей.
    usershare allow guests = yes
    # Смещение преобразования SID -> UID
    idmap config *:backend = tdb
    idmap config *:range = 10000-40000
    # Использовать домен по умолчанию (для интеграции с учетными данными домена без указания имени домена)
    winbind use default domain = yes
    # Shell по умолчанию для доменных пользователей
    template shell = /bin/bash

# Общие ресурсы принтеров
[printers]
    comment = All Printers
    browseable = no
    path = /var/spool/samba
    printable = yes
    guest ok = no
    read only = yes
    create mask = 0700

[print$]
    comment = Printer Drivers
    path = /var/lib/samba/printers
    browseable = yes
    read only = yes
    guest ok = no

4. Вводим компьютер в домен командой

# net ads join -U «chernousov@sintez.sintez.com»

5. Перезапускаем службы

# /etc/init.d/smbd restart
# /etc/init.d/nmbd restart
# /etc/init.d/winbind restart

6. Удостоверяемся, что разрешение имен и групп работает.

а. Пользователи домена:

# wbinfo -u
SINTEZ\guest
SINTEZ\administrator
SINTEZ\tsinternetuser
SINTEZ\iusr_dc
SINTEZ\iwam_dc
SINTEZ\iusr_dc2
…

б. Группы пользователей домена:

# wbinfo -g
SINTEZ\domain users
SINTEZ\domain computers
SINTEZ\domain guests
SINTEZ\group policy creator owners
SINTEZ\domain admins
…

В случае если вы указали параметр winbind use default domain = yes, то имена выводимые указанными выше командами будут без указания домена SINTEZ\, например:

# wbinfo -u
guest
administrator
tsinternetuser
iusr_dc
iwam_dc
iusr_dc2
…

в. Проверяем преобразование SID в UID

# wbinfo  —name-to-sid=chernousov
S-1-5-21-1177238915-436374069-1343024091-5713 SID_USER (1)

# wbinfo —sid-to-uid=S-1-5-21-1177238915-436374069-1343024091-5713
10002

Обратите внимание, что если вы не активировали в домене Службы Active Directory for UNIX, идентификаторы UID для одного доменного пользователя будут разными и выданными случайным образом в процессе выделения из пула idmap uid и idmap gid.

В случае использования интеграции AD и UNIX (RFC 2307) вам необходимо задать атрибуты UID и GID для всех пользователей и групп Active Directory, в противном случае следующий этап вызовет ошибку.

7. Настраиваем интеграцию локальных идентификаторов пользователей и групп пользователей  с данными Active Directory.

Для этого обязательно установите пакет libnss-winbind конандой:

# apt-get install libnss-winbind

И в файл /etc/nsswitch.conf внесите следующие изменения:

passwd:         compat winbind
group:          compat winbind

Проверьте получение и преобразование о доменных пользователях в локальных пользователей Ubuntu командой id:

# id administrator
uid=10003(administrator) gid=10005(domain users) группы=10005(domain users),10007(группа с запрещением репликации паролей rodc),10009(schema admins),10010(enterprise admins),10008(domain admins),10011(group policy creator owners),10002(BUILTIN\users),10001(BUILTIN\administrators)

8. Настраиваем возможность авторизации доменных пользователей на рабочей станции. Для этого необходимо внести следующие изменения в конфигурационные PAM-файлы. Обратите внимание, что в процессе редактирования PAM-файлов лучше держать одну консоль root открытой, так как в случае ошибки вы не сможете больше авторизоваться и вам придется загружаться с Live ISO, так как вход в recovery-режим так же будет недоступен.

Установите пакет libpam-winbind:

# aptitude install libpam-winbind

Создайте символическую ссылку (в противном случае в pam-файлах придется указывать полный путь до библиотеки авторизации):

# mkdir /lib/security
# ln -s /lib/x86_64-linux-gnu/security/pam_winbind.so /lib/security/pam_winbind.so

И последовательно выполняем следующие действия:

а. Настраиваем автоматическое создание домашних каталогов пользователей при входе в систему. Для запуска графического конфигуратора выполните команду:

# pam-auth-update

В гафичиском конфигураторе активируйте пункт «Создавать домашний каталог при входе в систему»

б. Вносим изменения в конфигурационные файлы (в ряде версий изменения производятся автоматически при установке пакета libpam-winbind):

/etc/pam.d/common-account

добавить:

account    [success=1 new_authtok_reqd=done default=ignore]    pam_winbind.so
(после pam_unix.so)

/etc/pam.d/common-password

password    [success=1 default=ignore]    pam_winbind.so use_authtok try_first_pass
(после pam_unix.so)

в. Проведите тестовую авторизацию выполнив команду

~$ su admin

Где admin это доменный пользователь. Обратите внимание, что возможны конфликты между локальными и доменными пользователями и приоритетными будут пароли доменных пользователей!

Выполните id для текущего пользователя и проверьте интеграцию доменных учетных данных и локальных (при условии, что существует одноименный локальный пользователь)

9. Настройка ограничений безопасности. В текущем режиме на рабочих станциях и серверах может авторизоваться любой доменный пользователь. Настроим ряд ограничений, а именно создадим доменную группу Unix users, члены данных группы смогут авторизоваться на рабочих станциях и серверах и административную группу Unix admins, которые смогут выполнять sudo.

Для реализации данной модели безопасности отредактируйте следующие файлы:

Файл /etc/security/pam_winbind.conf

В случае отсутствия данного файла скопируйте его из каталога с примерами конфигурационных файлов:

# cp /usr/share/doc/libpam-winbind/examples/pam_winbind/pam_winbind.conf /etc/security/pam_winbind.conf

Определаем sid группы Unix users командой:

# wbinfo —name-to-sid=»Unix users»
S-1-5-21-1177238915-436374069-1343024091-5725  SID_DOM_GROUP (2)

Изменяем параметр конфигурации разрешая авторизоваться только членам данной группы:

require_membership_of = S-1-5-21-1177238915-436374069-1343024091-5725

Файл /etc/sudoers

Добавьте указанную ниже строку чтобы разрешить выполнять sudo пользователям членам группы Unix admins:

%unix\ admins    ALL=(ALL:ALL) ALL

Обратите внимание на \, указывая\-пробел мы описываем доменную группу содержащую пробел в названии.

На этом модуль авторизации завершен, а в следующей статье мы рассмотрим автономную авторизацию, клиширование учетных данных, создание и подключение к общим ресурсам с учетом расширенных прав доступа, авторизацию на ресурсах с использованием kerberos и многое другое.