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

Мы продолжаем серию статей про взаимодействие Linux и Windows.
Теперь мы рассмотрим задачу введения в домен Windows 2008R2 сервера с операционной системой CentOS Linux (версия 6.3). Как и в последних статьях, будем пользоваться штатными средствами, поставляемыми в составе дистрибутива операционной системы. Но, в отличие от наших предыдущих статей, мы расширим задачу. Требуется организовать не только файловое хранилище на сервере под управлением CentOS Linux, но и обеспечить доступ доменных пользователей к командной и графической оболочке.
На сайте проекта CentOS можно найти информацию о настройке Samba, но эта информация касается, в основном, старых версий (CentOS 5) и охватывает небольшое количество примеров конфигурации.
Есть и другие материалы, посвященные настройке Samba для дистрибутива CentOS. В процессе написания статьи и тестирования очень пригодилось подборка статей, опубликованных на сайте ^[1]. Особенно полезными оказались следующие статьи (несмотря на то, что они опубликованы в марте–апреле 2007 года):

1. Active Directory Integration with Samba for RHEL/CentOS 5 ^[2]
2. Troubleshooting Active Directory and Winbind ^[3]
3. Active Directory Single Sign On ^[4]

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

1. Наименование домена — LAB.LOCAL
2. Сервер ForefrontThreat Management Gateway (TMG) 2010 — LAB-TMG.lab.local
3. Клиент — LAB-CL1.lab.local

На контроллере домена LAB-DC1 установлены роли:

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

Тестовая сеть и описания протоколов взаимодействия описаны в статье ^[7].

1.Требуемые пакеты

Мы устанавливаем минимально необходимый набор пакетов: рабочий стол Gnome (или другой оконный менеджер по выбору), базовый сервер и Samba. Нам потребуются:

1. пакет krb5-workstation (версия не ниже 1.9), содержащий необходимые клиентские приложения для аутентификации на основе Kerberos;
2. пакет oddjobmkhomedir (версия не ниже 0.30-5), предназначенный для автоматического создания каталогов пользователя при первом входе в систему;
3. сам пакет Samba (версия не ниже 3.5-10), содержащий основные программы и пакет samba-winbind, отвечающий за соединение нашего сервера с контроллером домена.

2.Настройка DNS

Сначала необходимо настроить службу DNS. Это весьма важно, поскольку от корректного разрешения имен в сети зависит надежная работа нашей сети и сервисов Samba. Наш контроллер домена одновременно является и сервером DNS. Поэтому выберем в разделе Administrative Tools программу управления DNS и вручную введем имя и адрес нового сервера. На рис. 1 уже представлен результат.

Рис. 1. Задание имени и адреса в DNS.

Наш сервер DNS интегрирован с Active Directory. Можно проверить корректность прямого и обратного разрешения имен с использованием утилиты nslookup или host. Уточним: это нужно сделать обязательно, даже несмотря на то, что необходимая запись уже появилась на сервере DNS. Нужно это сделать потому, что такая проверка — лишний тест работоспособности сети и корректности настроек. Проверка с помощью утилиты host выглядит так:
host 192.168.7.10 — определение имени по адресу, и
host test-centos.lab.local — определение адреса по имени.
В результате мы должны получить корректное разрешение имен в обоих случаях.

3.Настройка сетевого адаптера

Теперь этот IP-адрес (192.168.7.10) необходимо присвоить сетевому адаптеру вновь установленного сервера CentOS Linux. Воспользуемся пунктом меню System на рабочем столе и выберем пункт Network Connections (рис. 2).

Рис. 2. Настройка сетевого соединения.

В появившемся окне настроек зададим нужный IP-адрес. В результате мы должны получить следующее — см. рис. 3.

Рис. 3. Настройка сетевого соединения. Задание IP-адреса.

Наш сервер настроен с использованием менеджера соединений (Network Manager). Поэтому нужно обязательно отметить несколько опций:

1. Connect automatically, что позволяет автоматически подключать сетевой адаптер.
2. Available to all users, что разрешает пользоваться этим адаптером всем пользователям.

Можно настроить сетевое соединение вручную, отредактировав файл /etc/sysconfig/networking/devices/ifcfg-eth0, приведя его к виду, показанному на рис. 4.

Рис. 4. Настройка сетевого соединения. Файл настроек.

Ключевое слово NM_CONTROLLED разрешает или запрещает управлять соединением с использованием Network Manager.
При любом способе настроек, следует установить IP-адрес сервера DNS. Это наш контроллер домена с IP-адресом 192.168.7.2.
Для применения настроек сетевого адаптера следует выполнить команду перезапуска:

/etc/init.d/network restart

4.Настройка времени

Как уже говорилось в предыдущих статьях, корректная настройка времени очень важна для работы Active Directory. Настроить время можно с использованием штатных средств системы (см. рис. 5).

Рис. 5. Настройка времени.

Но для того, чтобы полностью избежать проблем с рассинхронизацией часов, следует настроить службу времени (демон ntpd) на синхронизацию времени с контроллером домена (см. рис. 6).

Рис. 6. Настройка службы времени.

Для этого нужно отредактировать файл /etc/ntp.conf, указав в качестве сервера времени контроллер домена. Не забудьте настроить запуск демона ntpd с помощью команды chkconfig ntpd on и перезапустить его командой /etc/init.d/ntpd restart.

5.Проверка настроек

Произведя указанные настройки, следует проверить их корректность. Нужно протестировать соединение с контроллером домена, настройку времени, правильность прямого и обратного разрешения имен (см. рис. 7).

Рис. 7. Проверка настроек.

6.Настройка авторизации в домене

Теперь настала пора настроить членство нашего сервера в домене Windows. В отличие от предыдущих примеров, не будем отдельно настраивать LDAP и Kerberos. Постараемся настроить все сразу, используя утилиту командной строки authconfig, поставляемую в составе дистрибутива CentOS.
Authconfig позволяет настроить сразу все требуемые службы. При этом настраивать можно не только авторизацию в домене Windows 2008, но и использование LDAP, NIS и других способов аутентификации.
Более подробную информацию об утилите authconfig можно получить из встроенного руководства (man authconfig, онлайн-версия ^[8]), либо из встроенного руководства, набрав в командной строке authconfig -help. Достаточно будет сказать, что authconfig имеет около 50 опций настройки — представляете его возможности и, одновременно, сложности в настройке? Проще воспользоваться графическим интерфейсом к authconfig — утилитой system-config-authentication (рис. 8). Эту утилиту можно вызвать из интерфейса администрирования системы, а можно и командной строкой. Причем второй вариант представляется предпочтительным, поскольку вывод диагностических сообщений будет происходить в окно терминала, что упростит поиск неисправностей.

Рис. 8. Вызов system-config-authentication.

В меню User Account Database можно выбрать место хранения списков пользователей и паролей. Возможными вариантами являются:

1. локальная база данных паролей (файлы /etc/passwd и /etc/shadow);
2. подключение к серверу LDAP;
3. подключение к серверу NIS;
4. использование Winbind — подключение к контроллеру домена Windows;
5. использование IPAv2 — интегрированное решение, объединяющее LDAP, Kerberos, NTP, DNS и службу сертификатов.

IPAv2 позволяет авторизовать пользователей, рабочие станции, группы и вести политику управления сетевым доступом. IPAv2 позиционируется как решение, заменяющее NSSWITCH и PAM. Более подробная информация представлена на http://www.freeipa.org/page/Main_Page ^[9].
Поскольку нашей задачей является авторизация в домене Windows, то в качестве User Account Database мы выбираем Winbind (рис. 9).

Рис. 9. Выбор User Account Database.

Необходимо указать основные параметры для authconfig. Windows Domain — это краткое наименование домена Windows 2008R2, то, которое используется в параметре workgroup файла конфигурации Samba (/etc/samba/smb.conf). О файле конфигурации Samba мы уже рассказывали в предыдущих статьях ^[10].
Security model устанавливается в ads, что соответствует значению параметра security в файле конфигурации Samba /etc/samba/smb.conf). Выбор security model = ads означает, что используются протоколы, совместимые со службами ADS Windows 2008R2. Другие возможные значения security model:

1. Domain — централизованная авторизация с использованием домена Windows 2000/2003;
2. Server — используется в тех случаях, когда Samba не является членом домена, но использует централизованное хранение пользовательских аккаунтов и паролей на сервере;
3. User — используется локальная база аккаунтов и паролей пользователей. При этом требуется не только пользовательский аккаунт, но и аккаунт рабочей станции.

Параметр Winbind ADS Realm аналогичен параметру REALM в файле конфигурации Samba и относится к настройкам безопасности Kerberos. Аналогичный параметр REALM указывается в файле настроек /etc/krb5.conf.
Поле Winbind Domain Controllers можно оставить пустым — имя контроллера домена определится из DNS. Заполнять это поле следует, если по каким-то причинам служба DNS не может определить имя и IP-адрес контроллера домена.
Весьма интересен параметр Template Shell, указывающий, какая командная оболочка будет использована при регистрации доменного пользователя на нашем сервере CentOS Linux. Возможные значения командных оболочек перечислены в файле /etc/shells. К этим значениям утилита system-config-authentication добавляет еще /bin/false, которое используется как значение по умолчанию. Если в качестве командной оболочки указать /bin/false, то доменным пользователям будет запрещен вход в систему. Параметр Template Shell аналогичен полю shell файла /etc/passwd в Linux. Чтобы разрешить пользователям интерактивную работу в системе с использованием командной строки, этот параметр нужно установить в /bin/sh или /bin/bash.
Параметр Allow Offline Login позволяет нашему серверу CentOS Linux кэшировать пароли и, соответственно, авторизовать пользователей в случае недоступности контроллера домена.
Перейдем на вкладку Advanced Options, поскольку там есть некоторые интересующие нас параметры (см. рис. 10).

Рис. 10. Вкладка Advanced Options system-config-authentication.

На этой вкладке нас интересуют два параметра: Create home directories on the first login и Enable local access control.
Enable local access control позволяет нам указать правила регистрации пользователей на нашем сервере. Можно разрешить или запретить определенным пользователям регистрироваться с использованием терминалов или удаленных рабочих столов. Это весьма удобно, если мы хотим, например, запретить пользователям подключаться через консольный терминал. Правила регистрации и их краткое описание содержатся в файле /etc/security/access.conf.
Параметр Create home directories on the first login позволяет снять с администратора обязанность создавать домашние каталоги для пользователей. При указании этого параметра домашний каталог создается автоматически при первом входе пользователя в систему. Но необходимо проверить корректность наличия этой опции. В CentOS Linux за это отвечает модуль pam_oddjob_mkhomedir.so, который должен быть упомянут в файле /etc/pam.d/system-auth в строке session required pam_oddjob_mkhomedir.so skel=/etc/skel/ umask=0022. Кроме того, домашний каталог для регистрации доменных пользователей на сервере Samba по умолчанию задается как /home/%D/%U. Это указывается параметром template homedir в файле настроек Samba. Если использовать значение по умолчанию, то администратору необходимо создать каталог /home/<DOMAIN>, где является кратким именем домена. В нашем случае необходим каталог /home/LAB, в котором будут автоматически создаваться домашние директории пользователей.
Теперь вернемся на вкладку Identity & Authentication утилиты system-config-authentication и включим наш сервер в домен Windows 2008 R2.
Для этого нужно выбрать действие Join Domain и ввести имя администратора домена и пароль (рис. 11). По нажатию кнопки OK, мы должны включить наш сервер в домен LAB.

Рис. 11. Указание имени и пароля администратора при вводе в домен.

Как видим, наш сервер Samba успешно включен в домен (рис. 12). Сообщение об этом появилось в окне терминала. Собственно, для этого сообщения мы и запускали system-config-authentication через командную строку в окне терминала. Если запускать через вкладку System, то сообщение о включении или невключении сервера в домен придется искать в файлах системных журналов.

Рис. 12. Включение в домен LAB.

После включения в домен в окне Authentication Configuration нажимаем кнопку Apply, и в окне терминала появляются сообщения о перезапуске Winbind и oddjobd.
Проверим включение нашего сервера в домен на контроллере (см. рис. 13).

Рис. 13. Проверка наличия в домене.

Мы видим, что наш сервер включен в домен под именем test-centos.
Теперь проверим возможность регистрации доменных пользователей на нашем сервере. Укажем доменного пользователя в ответ на приглашение о вводе имени на консоли сервера (рис. 14).

Рис. 14. Ввод имени доменного пользователя.

Как видно, имя пользователя указывается вместе с именем домена. По умолчанию разделителем является обратная косая «». Это значение можно изменить параметром winbind separator в файле настроек Samba. Выбрав кнопку Log In, получим приглашение ввести пароль. После ввода пароля получаем рабочий стол пользователя usertest (рис. 15).

Рис. 15. Рабочий стол доменного пользователя в CentOS Linux.

Таким образом, мы успешно решили задачу включения сервера CentOS Linux в домен Windows 2008 R2 и даже разрешили доменным пользователям обращаться к рабочему столу и командной строке Linux. Это дает пользователям домена дополнительные возможности использования различных операционных систем в сети предприятия.

7.Заключение

Данная работа выполнена на базе Информационно-вычислительного центра МЭИ.
Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть и отладить на ней различные варианты и конфигурации систем для обеспечения их взаимодействия.

Автор: SergeyKhorkov

Источник ^[11]