Настройка Samba с интеграцией в AD

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

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

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

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

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

Samba и winbind

Samba – это проект с открытым исходным кодом, целью которого является интеграция между средами Windows и Linux. Samba содержит компоненты, дающие компьютерам Linux доступ к службам файлов и печати Windows, а также предоставляющие службы на основе Linux, которые имитируют контроллеры доменов Windows NT 4.0.

Для нас особо интересна часть 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 Майкрософт.

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

Установка компьютера 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 на контроллере домена, в который будут занесены попытки проверки подлинности.

Добавляем сервер к домену через realm

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

Итак, отключаем firewall и SELinux, если не сделали это раньше. Если не хотите отключать, то настройте сами. Данная настройка выходит за рамки статьи.

# mcedit /etc/sysconfig/selinux

меняем значение

SELINUX=disabled

Выполняем команду, чтобы не ждать перезагрузки для применения изменений.

setenforce 0

Выключаем firewalld.

# systemctl stop firewalld
# systemctl disable firewalld

Перед дальнейшей настройкой, убедитесь, что с вашего сервера centos вы без проблем пингуете и резолвите контроллер домена по полному имени. Если есть какие-то проблемы, исправьте это либо указанием нужного dns сервера, либо правкой файла hosts.

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

Устанавливаем утилиту для синхронизации времени chrony:

# yum install chrony

Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.

server xs-winsrv.xs.local iburst

Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.

# systemctl start chronyd && systemctl enable chronyd

Проверим, что с синхронизацией.

Устанавливаем софт, который понадобится для дальнейшей работы.

# yum install realmd sssd sssd-libwbclient oddjob oddjob-mkhomedir adcli samba-common samba-common-tools

Делаем проверку перед вводом в домен.

# realm discover XS.LOCAL
xs.local
 type: kerberos
 realm-name: XS.LOCAL
 domain-name: xs.local
 configured: no
 server-software: active-directory
 client-software: sssd
 required-package: oddjob
 required-package: oddjob-mkhomedir
 required-package: sssd
 required-package: adcli
 required-package: samba-common-tools

Заводим в домен.

Используемые параметры команды net

-U username%password: Обязательный параметр, вместо username необходимо подставить имя пользователя с правами администратора домена, и указать пароль.

-D DOMAIN: DOMAIN – собственно сам домен, домен можно и не указывать, но лучше всё же это всегда делать – хуже не будет.

-S win_domain_controller: win_domain_controller, можно не указывать, но бывают случаи когда автоматически сервер не находит контроллер домена.

createcomputer=«OU/OU/…» : В AD часто используется OU (Organizational Unit), есть в корне домена OU = Office, в нем OU = Cabinet, чтобы сразу добавить в нужный можно указать так: sudo net ads join -U username createcomputer=«Office/Cabinet».

Если больше никаких сообщений нет – значит всё хорошо. Попробуйте попинговать свой компьютер по имени с другого члена домена, чтобы убедиться, что в домене всё прописалось так, как надо.

Так же можно набрать команду:

net ads testjoin

Если все хорошо, можно увидеть:

#net ads testjoin
Join is OK

Но иногда после сообщения о присоединении к домену выдаётся ошибка наподобие<![CDATA[]]>:

DNS update failed!

Это не очень хорошо, и в этом случае рекомендуется ещё раз прочитать раздел про настройку <![CDATA[]]>DNS чуть выше и понять, что же вы сделали не так. После этого нужно удалить компьютер из домена и попытаться ввести его заново. Если вы твердо уверены, что всё настроили верно, а DNS всё равно не обновляется, то можно внести вручную запись для вашего компьютера на ваш DNS сервер и всё будет работать. Конечно, если нет никаких других ошибок, и вы успешно вошли в домен. Однако лучше всё же разберитесь, почему DNS не обновляется автоматически. Это может быть связано не только с вашим компьютером, но и с некорректной настройкой AD.

Если всё прошло без ошибок, то поздравляем, вы успешно вошли в домен! Можете заглянуть в AD и убедиться в этом. Кроме того хорошо бы проверить, что вы можете видеть ресурсы в домене. Для этого установите smbclient:

sudo aptitude install smbclient

Теперь можно просматривать ресурсы компьютеров домена. Но для этого нужно иметь билет kerberos, т.е. если мы их удалили, то получаем опять через kinit (см. выше). Посмотрим какие ресурсы предоставлены в сеть компьютером workstation:

smbclient -k -L workstation

Вы должны увидеть список общих ресурсов на этом компьютере.

Настройка dns

Для начала необходимо изменить настройки DNS на вашей машине, прописав в качестве DNS сервера доменконтроллер<![CDATA[]]> и в качестве домена поиска – нужный домен.

Если у вас статический IP-адрес, то в Ubuntu Desktop это можно сделать через Network Manager, в Ubuntu Server необходимо изменить содержимое файла /etc/resolv.conf на примерно такое:

domain domain.com
search domain.com
nameserver 192.168.0.1
nameserver 192.168.0.2

В современных дистрибутивах файл resolv.conf создается автоматически и править вручную его не нужно. Для получение нужного результата нужно добавить необходимые изменения в файл: /etc/resolvconf/resolv.conf.d/head Данные которые будут добавлены в него, будут автоматически вставлены в файл /etc/resolv.conf

Если IP-адрес динамический и присваивается <![CDATA[]]>DHCP сервером то после перезагрузки resolv.conf может формироваться «неправильный» resolv.conf’ , например присутствует только один nameserver 192.168.0.1 и не указаны domain и search. Нужно отредактировать /etc/dhcp/dhclient.conf. Чтобы появились записи domain и search нужно убрать комментарий перед строкой supersede domain-name, и вписать свой домен:

supersede domain-name "domain.com";

Чтобы добавить еще один nameserver нужно убрать комментарий перед prepend domain-name-servers и указать ip сервера:

prepend domain-name-servers 192.168.0.2;

Для применения изменений остается перезапустить службу:

/etc/init.d/networking restart

Теперь убедитесь, что вы задали нужное имя компьютера в файле /etc/hostname:

smbsrv01

Кроме того необходимо отредактировать файл /etc/hosts так, чтобы в нём была запись с полным доменным именем компьютера и обязательно коротким именем хоста, ссылающаяся на один из внутренних IP:

# Имена этого компьютера
127.0.0.1	localhost
127.0.1.1	smbsrv01.domain.com	smbsrv01

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

ping dc
ping dc.domain.com

Не обязательно, но если вы что-то поменяете – перезагрузите компьютер для применения изменений.

Похожее:  api - PHP: how to make a GET request with HTTP-Basic authentication - Stack Overflow

Настройка 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.

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

Каждая запись в файле настройки PAM имеет форму <группа управления> <элемент управления> <модуль> <параметры>, где <группа управления> соответствует средству, к которому относится запись настройки: проверки подлинности, учетных записей, паролей или сеансов.

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

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

Ключевое слово

Описание

Required («Обязательно»)Если модуль срабатывает успешно, то PAM продолжает вычислять остающиеся записи для группы управления, и результаты будут определены результатами остающихся модулей. Если нет, то PAM продолжит вычисление, но возвратит сбой вызывавшему приложению.
Requisite («Необходимо»)Если модуль срабатывает успешно, PAM продолжает вычислять записи группы управления. Если нет, то PAM произведет возврат вызывавшему приложению без дальнейшей обработки.
Sufficient («Достаточно»)Если модуль сработает успешно, то PAM возвратит успешный результат вызывавшему приложению. Если нет, то PAM продолжит вычисление, но результаты будут определены последующими модулями.
Optional («Необязательно»)PAM игнорирует результаты модуля, если это не единственный модуль, указанный для группы управления.
Include («Включить»)PAM включает в себя содержимое файла настройки PAM, на который дается ссылка, а также содержащиеся в нем процессы и записи.

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

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

Рис. 13. Файл system-auth модуля PAM

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

В частности, администратор может указать, как хранится информация об имени пользователя и пароле. Поскольку нам нужно, чтобы приложения искали информацию о пользователях в Active Directory при помощи Winbind, нам нужно изменить настройку NSS, чтобы показать это.

Red Hat включает небольшую графическую программку для настройки PAM и NSS, называемую system-config-authentication. Она заботится о большинстве изменений (но не о всех), которые необходимо ввести в файлы system-auth и nss.conf.

Настройка samba и вход в домен

Для того, чтобы войти в домен, необходимо прописать правильные настройки в файле /etc/samba/smb.conf. На данном этапе вас должны интересовать только некоторые опции из секции [global]. Ниже – пример части файла конфигурации Samba с комментариями по поводу значения важных параметров:

[global]
   # Эти две опции нужно писать именно в заглавном регистре, причём workgroup без
   # последней секции после точки, а realm - полное имя домена 
   workgroup = DOMAIN
   realm = DOMAIN.COM

   # Эти две опции отвечают как раз за авторизацию через AD
   security = ADS
   encrypt passwords = true
   # Просто важные 
   dns proxy = no 
   socket options = TCP_NODELAY

   # Если вы не хотите, чтобы самба пыталась при случае вылезти в лидеры в домене или рабочей группе,
   # или даже стать доменконтроллером, то всегда прописывайте эти пять опций именно в таком виде
   domain master = no
   local master = no
   preferred master = no
   os level = 0
   domain logons = no

   # Отключить поддержку принтеров
   load printers = no
   show add printer wizard = no
   printcap name = /dev/null
   disable spoolss = yes

После того, как вы отредактируете smb.conf выполните команду

testparm

Она проверит вашу конфигурацию на ошибки и выдаст суммарную сводку о нём:

# testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions

Как видно мы задали правильные параметры для того, чтобы наш компьютер стал членом домена. Теперь пора попытаться непосредственно войти в домен. Для этого введите команду:

net ads join -U username -D DOMAIN

И в случае успеха вы увидите что-то похожее на:

# net ads join -U username -D DOMAIN
Enter username's password:
Using short domain name -- DOMAIN
Joined 'SMBSRV01' to realm 'domain.com'

Настройка авторизации через kerberos

Начнём с настройки авторизации в домене через протокол Kerberos. Вам потребуется изменить файл /etc/krb5.conf. В общем случае он выглядит так:

[libdefaults]
	default_realm = DOMAIN.COM
	kdc_timesync = 1
	ccache_type = 4
	forwardable = true
	proxiable = true
	v4_instance_resolve = false
	v4_name_convert = {
		host = {
			rcmd = host
			ftp = ftp
		}
		plain = {
			something = something-else
		}
	}
	fcc-mit-ticketflags = true

[realms]
	DOMAIN.COM = {
		kdc = dc
		kdc = dc2
		admin_server = dc
		default_domain = DOMAIN.COM
	}

[domain_realm]
	.domain.com = DOMAIN.COM
	domain.com = DOMAIN.COM
[login]
	krb4_convert = false
	krb4_get_tickets = false

Вам, конечно, нужно изменить domain.com на ваш домен и dc и dc2 на ваши доменконтроллеры. Кстати, возможно вам понадобится написать полные имена доменконтроллеров dc.domain.com и dc2.domain.com. Поскольку у меня прописан домен поиска в DNS, то мне это делать не нужно.

Обратите особое внимание на регистр написания имени домена – везде, где домен написан в верхнем регистре, его обязательно нужно писать именно в верхнем регистре. Иначе волшебным образом ничего может не заработать.

Это не все возможные опции настройки Kerberos, только основные. Однако их обычно достаточно.

Теперь настало время проверить, что мы можем авторизоваться в домене. Для этого выполните команду

kinit [email protected]

Вместо username естественно стоит вписать имя существующего пользователя домена.

Имя домена необходимо писать заглавными буквами!

Если вы не получили никаких ошибок – значит вы настроили всё верно и домен отдаёт вам билет Kerberos. Кстати, некоторые распространённые ошибки перечислены чуть ниже.

Убедиться в том, что билет получен, можно выполнив команду

klist

Удалить все билеты (они вам вообще говоря не нужны) можно командой

kdestroy

Итак, будем считать, что авторизацию вы настроили, пора настроить непосредственно вход в домен, об этом после списка распространённых ошибок kinit.

Он-лайн авторизация

Для Ubuntu 10.04 и выше добавьте всего одну строку в файле /etc/pam.d/common-session, т.к. PAM и так неплохо справляется с авторизацией:

session  optional  pam_mkhomedir.so skel=/etc/skel/ umask=0077

Для Ubuntu 13.10 чтобы появилось поле ручного ввода логина необходимо в любой файл из папки /etc/lightdm/lightdm.conf/ снизу добавить строку:

greeter-show-manual-login=true

Для Ubuntu 9.10 и ниже придется редактировать несколько файлов (но никто не запрещает использовать этот способ и в 10.04 – он тоже работает):

Последовательность строк в файлах имеет значение!

/etc/pam.d/common-auth

auth        required      pam_env.so
auth        sufficient    pam_unix.so likeauth nullok try_first_pass
auth        sufficient    pam_winbind.so use_first_pass krb5_auth krb5_ccache_type=FILE
auth        required      pam_deny.so

/etc/pam.d/common-account

account     sufficient    pam_winbind.so
account     required      pam_unix.so

/etc/pam.d/common-session

session     optional      pam_mkhomedir.so skel=/etc/skel/ umask=0077
session     optional      pam_ck_connector.so nox11
session     required      pam_limits.so
session     required      pam_env.so
session     required      pam_unix.so

/etc/pam.d/common-password

password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
password    sufficient    pam_winbind.so
password    required      pam_deny.so

И, наконец, необходимо перенести запуск Winbind при загрузке системы после всех остальных служб (по умолчанию он запускается с индексом 20). Для этого в терминале выполните следующую команду:

sudo bash -c "for i in 2 3 4 5; do mv /etc/rc$i.d/S20winbind /etc/rc$i.d/S99winbind; done"

Что эквивалентно запуску для каждого уровня (в примере – 4) команды:

mv /etc/rc4.d/S20winbind /etc/rc4.d/S99winbind

В некоторых случаях winbind может иметь иной уровень запуска (например, S02winbind). Поэтому сначала проверьте имена файлов, вполнив команду «ls /etc/rc{2,3,4,5}.d/ | grep winbind» (без кавычек).

Готово, все настройки завершены. Перезагружайтесь и пытайтесь войти с учетной записью пользователя домена.

Офф-лайн авторизация

Часто возникает ситуация, когда домен-контроллер недоступен по различным причинам — профилактика, отключение света или вы принесли ноутбук домой и хотите поработать. В этом случае для Winbind можно настроить кэширование учетных записей пользователей домена. Для этого необходимо сделать следующее. Добавьте в секцию [global] файла /etc/samba/smb.conf следующие строки:

[global]
   # Возможность оффлайн-авторизации при недоступности доменконтроллера
   winbind offline logon = yes
   # Период кэширования учетных записей, по умолчанию равен 300 секунд
   winbind cache time = 300
   # Необязательная настройка, но избавляет от нудных пауз, указываем контроллер домена dc, 
   # можно указать и ip, но это является плохим тоном
   password server = dc

Обычно этого достаточно. Если же возникают ошибки, то необходимо создать файл /etc/security/pam_winbind.conf со следующим содержанием<![CDATA[]]>5)<![CDATA[]]>:

Похожее:  Личный кабинет твинго баланс вход

Внимание! При использовании советов ниже может возникать совершенно случайная ошибка «Сбой аутентификации»! Поэтому все что Вы делаете, Вы делаете на свой страх и риск!

#
# pam_winbind configuration file
#
# /etc/security/pam_winbind.conf
#
[global]
  # turn on debugging
  debug = no
  # request a cached login if possible
  # (needs "winbind offline logon = yes" in smb.conf)
  cached_login = yes
  # authenticate using kerberos
  krb5_auth = yes
  # when using kerberos, request a "FILE" krb5 credential cache type
  # (leave empty to just do krb5 authentication but not have a ticket
  # afterwards)
  krb5_ccache_type = FILE
  # make successful authentication dependend on membership of one SID
  # (can also take a name)
  ;require_membership_of =
  silent = yes

Файл /etc/pam.d/gnome-screensaver в таком случае принимает вид:

auth    sufficient      pam_unix.so nullok_secure
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

А также изменяется файл /etc/pam.d/common-auth:

auth    optional        pam_group.so
auth    sufficient      pam_unix.so nullok_secure  use_first_pass
auth    sufficient      pam_winbind.so use_first_pass
auth    required        pam_deny.so

Взято с сайта – <![CDATA[]]>http://help.ubuntu.ru/wiki/ввод_в_до%…<![CDATA[]]>

Что бы ограничить вход пользователей домена на машинку нужно довбавить в

/etc/pam.d/login

account required pam_access.so

и в /etc/security/access.conf

– : group : ALL

Поиск нужных программ

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

Компоненты Linux для Red Hat имеют две формы. Файлы RPM содержат двоичные файлы, которые были заранее скомпилированы и собраны для определенного сочетания версии компонента, выпуска Linux и архитектуры ЦП. Так что можно загрузить и установить, для примера, версию 1.3.

8-5 стандартной системы печати UNIX (Common UNIX Printing System – CUPS), собранную для Fedora версии 10, работающей на ЦП архитектуры Intel x86. Учитывая наличие дюжины различных архитектур ЦП, более чем 100 выпусков Linux и тысяч пакетов и версий, можно увидеть, что выбирать приходится из невероятного количества двоичных пакетов RPM.

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

Группа Samba выпускает обновления и исправления безопасности бешеными темпами; лишь за июль и август 2008 вышло четыре выпуска Samba 3.2, всего содержавших свыше 100 устраненных ошибок и исправлений безопасности. Для этого проекта я загрузил файлы исходного кода для последней стабильной версии Samba, версии 3.0.31.

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

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

Даже хотя Linux, сам по себе, является маленьким ядром, в выпуске Red Hat Enterprise заранее установлено множество пакетов. Обычно это серьезно упрощает жизнь, позволяя начать с полной и работающей операционной системы, но заранее установленные пакеты порой конфликтуют с программами, которые предполагается установить позже.

Я не включил Samba в свою установку Red Hat (обычно Samba устанавливается по умолчанию), поскольку мне нужно было использовать более новую версию. Однако более новая версия Samba требует новых версий нескольких других библиотек и служебных программ, которые уже были установлены. Проблемы, связанные с подобной зависимостью, действуют на нервы, но их можно легко решить, используя RPM.

Существует множество веб-узлов, на которых размещаются двоичные пакеты RPM. Тот, что использовал я (просто потому, что он нашелся первым), именуется PBONE и расположен на rpm.pbone.net. У него имеется удобный способ поиска пакетов, и на нем есть все двоичные файлы, которые были необходимы для моей архитектуры ЦП (i386) и выпусков операционной системы (Red Hat Enterprise Linux 5/Fedora 7 и 8).

Мне пришлось загрузить и обновить пакеты, перечисленные на рис. 4, чтобы собрать и установить последнюю версию Samba 3.0 (существует еще более новое дерево версий 3.2, работать с которым я не пробовал). Отметьте, что все эти пакеты предназначены для выпуска Fedora Core (fc).

Дистрибутив Red Hat основан на тех же исходных кодах, что используются в Fedora, и полностью совместим с ней. Пакеты, собранные для Fedora Core 7 и более поздних версий, будут работать в RHEL5 без изменений. Поместите загруженные файлы RPM в каталог /usr/src/redhat/RPMS.

Рис. 4. Пакеты, необходимые для сборки и установки Samba 3.0.31

samba-3.031-0.fc8.src.rpmПакет RPM исходного кода Samba 3.0.31
gnutls1.6.3-3.fc7.i386Библиотеки проекта GNU для протокола TLS (Transport Layer Security)
gnutils-devel-1.6.3-3.fc7.i386Файлы разработки проекта GNU для протокола TLS
popt-1.12-3.fc8.i386Библиотеки анализа аргументов командной строки
popt-devel-1.12-3.fc8.i386Файлы разработки для анализа аргументов командной строки
cups-libs-1.2.12-11.fc7.i386Библиотеки стандартной системы печати UNIX
cups-devel-1.2.12-11.fc7.i386Файлы разработки стандартной системы печати UNIX
cups-1.2.12.11.fc7.i386Двоичные файлы стандартной системы печати UNIX

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

Теперь, когда сеть, 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. Если всё сработает верно, то возможность входа в систему должна присутствовать.

Проблема сопоставления идентификаторов

У проверки подлинности пользователей 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 в качестве внутреннего идентификатора данного пользователя.

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

Похожее:  Вход в личный кабинет Сбербанк Партнер риэлтора – авторизация в ДомКлик PRO Партнер Онлайн

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

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

Проверка подлинности linux

Первоначально Linux (а также средства и библиотеки GNU, работавшие на нем) не рассчитывался на единый механизм проверки подлинности. Как следствие этого, разработчики приложений Linux обычно брались за разработки собственных схем проверки подлинности.

Получившийся ассортимент механизмов проверки подлинности был неуправляемым. В 1995 г. компания Sun предложила механизм, именуемый подключаемыми модулями проверки подлинности (Pluggable Authentication Modules – PAM). PAM предоставляли общий набор интерфейсов API проверки подлинности, который мог использоваться всеми разработчиками приложений, а также настраиваемый администратором серверный элемент, позволяющий использовать различные «подключаемые» схемы проверки подлинности.

Использование интерфейсов API PAM для проверки подлинности и интерфейсов API переключателя сервера имен (Name Server Switch – NSS) для поиска сведений о пользователе позволило разработчикам приложений Linux писать меньше кода, а администраторам Linux управлять процессом проверки подлинности и настраивать его из одного места.

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

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

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

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

Три стратегии проверки подлинности

Учитывая доступность LDAP, Kerberos и Winbind на компьютерах Linux, существуют три различные стратегии реализации, которые можно применить, чтобы дать компьютеру Linux возможность использовать Active Directory для проверки подлинности.

Использование проверки подлинности LDAP Простейший, но наименее удовлетворительный способ использования Active Directory для проверки подлинности – настроить PAM на использование проверки подлинности LDAP, как показано на рис. 1.

При проверке подлинности LDAP (именуемой привязкой LDAP) имя пользователя и пароль передаются открытым текстом через сеть. Это небезопасно и недопустимо для большинства целей.

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

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

Использование LDAP и Kerberos Другой стратегией использования Active Directory для проверки подлинности Linux является настройка PAM на использование проверки подлинности Kerberos и NSS на использование LDAP для поиска информации о пользователях и группах, как показано на рис. 2.

Эта схема имеет преимущество относительной защищенности, и в ней используются «встроенные» возможности Linux. Но она не использует записи расположения службы (SRV) DNS, публикуемые контроллерами доменов Active Directory, что заставляет проверить определенный набор контроллеров домена, чтобы проверить подлинность по ним.

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

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

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

Установка и настройка 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.

После установки двоичных файлов клиента Samba необходимо модифицировать настройку Samba по умолчанию, чтобы убедиться, что Winbind обрабатывает проверку подлинности должным образом с помощью Active Directory. Всю информацию о настройке Samba (и клиента, и сервера) можно найти в текстовом файле smb.conf, который по умолчанию находится в каталоге /etc/samba. Smb.conf может содержать огромное количество параметров настройки, и полный рассказ о его содержимом выходит за рамки данной статьи. На веб-узле vhod-v-lichnyj-kabinet.ru и в справочной системе Linux о smb.conf рассказано подробнее.

Первым этапом настройки Winbind является использование Active Directory для проверки подлинности. Модель безопасности в smb.conf необходимо установить на «объявления». Служебная программа system-config-authentication уже должна была установить это сама, но проверка никогда не помешает.

Откройте для правки файл smb.conf и найдите раздел, помеченный Domain Member Options («Параметры члена домена»). Найдите строку, начинающуюся с “security” и убедитесь, что она читается как “security = ads”. На следующем этапе настройки определяется, как Winbind сопоставит участников безопасности Windows, таких как пользователи и группы, с идентификаторами Linux, и это требует несколько более подробного объяснения.

Заключение

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

Если у вас есть возможность настроить файловый сервер на windows, либо обойтись линуксом без домена, то сделайте так. Существенно упростите настройку и дальнейшую эксплуатацию. Данную статью еще можно дополнить некоторыми моментами, которые я рассказал ранее, а что не рассказал, постараюсь раскрыть позже и добавить сюда ссылки на статьи:

  1. Подробное логирование всех действий с файлами на сервере.
  2. Настройка корзины для сетевых дисков samba.
  3. Бэкап файлового сервера.
  4. Мониторинг за размером файловой шары.

Буду рад любым полезным замечаниям, исправлениям, советам по настройке файлового сервера samba. Я потратил значительное время, чтобы поделиться своими знаниями и опытом с остальными. Надеюсь, кто-то поделится чем-то полезным со мной. В том числе ради этого я и пишу статьи. Они расширяют мой кругозор и закрепляют полученные знания.

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

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

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

Adblock
detector