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

от автора

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

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

Для организации тестовой сети мы будем использовать виртуальную среду VMware VSphere 5, реализованную на базе архитектуры гипервизора ESXi. Эта среда активно используется в информационно-вычислительной сети МЭИ для размещения серверов и исследовательских работ. Однако можно было бы воспользоваться и хорошо себя зарекомендовавшим Microsoft Hyper-V, а также любым другим аналогичным решением, в том числе и на основе свободного ПО, такого как гипервизор Xen или KVM.
Тестовая среда представляет собой доменную сеть на базе 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).

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

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, онлайн-версия), либо из встроенного руководства, набрав в командной строке 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.
Поскольку нашей задачей является авторизация в домене Windows, то в качестве User Account Database мы выбираем Winbind (рис. 9).


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

Необходимо указать основные параметры для authconfig. Windows Domain — это краткое наименование домена Windows 2008R2, то, которое используется в параметре workgroup файла конфигурации Samba (/etc/samba/smb.conf). О файле конфигурации Samba мы уже рассказывали в предыдущих статьях.
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.Заключение

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

ссылка на оригинал статьи http://habrahabr.ru/post/171249/


Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *