 |
|
|
|
Танцуем Самбу
Танцуем Самбу Любая операционная система имеет сильные и слабые стороны. В чем-то она получается удачнее других, в чем-то – нет, поэтому никогда нельзя однозначно расставить разные ОС по рангам. На таком «пьедестале почета» участники могут казаться идеальным решением для одной сферы применения, но в других областях на них вряд ли можно смотреть серьезно. Среди людей, вращающихся в IT-сфере, уже много лет идет религиозная война между сторонниками UNIX-подобных и Windows-систем. Это является неотъемлемой чертой человеческой натуры, которая выражается в бесконечном поиске идеала. Если же этот идеал вдруг находится, то закрываются глаза на все его отрицательные качества – ведь совершенству не положено их иметь. Несомненно, рациональнее всего беспристрастно смотреть на вещи и не бросаться в гущу сражений на вечную тему. Ведь если есть возможность использовать преимущества разных операционных систем в рамках одной сети, к чему нужны все эти религиозные предрассудки? Главным и основным качеством любого системного администратора по всеобщему признанию является чувство лени – стоит один раз правильно настроить систему, а дальше останется только пить чай, наблюдая за тем, как все работает без постороннего вмешательства. Шутка шуткой, но удобство работы очень часто влияет на результат в лучшую сторону. Как показывает практика, в первую очередь оно зависит от размера подконтрольной сети, причем чем больше компьютерная сеть, тем грамотнее следует продумывать ее внутреннее устройство в плане удобства последующего администрирования. В случае маленькой комнаты с дюжиной компьютеров при возникновении какой-нибудь проблемы вполне реально подойти и лично с ней разобраться или поменять требуемую настройку вручную на каждой машине, если есть такая необходимость. Но если компьютеров в сети далеко за сотню, а пользователей и того больше, то всех четырех рук системного администратора не хватит, с какой бы скоростью он не размахивал ими. В этом случае необходима мощная централизованная система управления и контроля за работой сети. Стандартным решением в случае большого количества пользователей и рабочих станций является объединение всех их в единый домен. Для этого, если верить статистике, чаще всего используются программные решения компании Microsoft. Понятие «домен» в последнее время стало неразрывно связано с сетями под управлением Windows. Но не окнами едиными жив этот мир. Существует большое количество задач, работу которых по тем или иным причинам не доверяют этим операционным системам. Порой просто нет необходимости или возможности заводить какой-нибудь www- или ftp-сервер на мощном в плане железа компьютере, так как последние версии Windows весьма требовательно относятся к аппаратной конфигурации своего места жительства. Появление сервера на базе любой UNIX-подобной операционной системы в сети с доменом может пошатнуть всю идею самой централизации, ведь UNIX – это другой мир, в котором все работает иначе, и к любой проблеме уже неприменимы те решения, которые существовали раньше. В случае, если с появившейся в сети «белой вороной» общается только системный администратор и информация, с которой работают сервисы на этой машине, не требует синхронизации с данными, находящимися в домене, то особенно изощренная настройка серверу не нужна. Здесь работает правило, гласящее, что чем проще система, тем меньше вероятность выхода ее из строя. Но если вдруг неожиданно потребуется открыть доступ на данный сервер доменным пользователям, то сразу же возникнет масса проблем, которые быстро решить не удается:
Выход из сложившейся ситуации один – необходимо интегрировать UNIX-сервер в Windows-домен, чтобы он был способен проводить аутентификацию пользователей на контроллере домена. При должной настройке сразу исчезнут все проблемы, возникавшие раньше с синхронизацией информации о пользователях, – теперь данные о них будут едины и для Windows-систем, и для UNIX. В данной статье я старался не привязываться к какой-то конкретной реализации UNIX и попытался дать достаточно обобщенные советы в плане настроек. Дело в том, что все перечисленные программные пакеты не являются большой редкостью, официально поддерживаются на большом количестве *nix-систем и конфигурируются одинаково на разных платформах. Однако, как бы я ни старался сделать статью универсальной, хочу сразу заметить, что существовала базовая платформа, на которой проводилось все тестирование перед пересадкой на боевую конфигурацию: Gentoo Linux 2004.2, и вся статья основана именно на ней. Чтобы убедиться в том, что на вашей системе предложенное решение будет работать, требуется удостовериться, что она поддерживает работу со следующими пакетами:
Если эти программные пакеты работают, то с большой вероятностью можно сказать, что и предложенная связка заработает, все зависит только от вас. Алгоритм Kerberos Информация, которую UNIX-машина получает от контроллера домена, не должна ходить по сети в открытом виде, так как она представляет большую ценность как для получателя, так и для возможных злоумышленников, поэтому для поддержания должного уровня безопасности системы в любом случае нужно использовать какую-либо криптографическую схему. В среде Windows ею является Kerberos5. В реальной жизни два человека могут быть уверены в личности друг друга при наличии паспортов у обоих. В данной ситуации человек доверяет не собеседнику, а паспортному столу, выдавшему документ. Это позволяет ему удостовериться в том, что он говорит именно с тем, кем является собеседник на самом деле. В Kerberos используется такая же схема: между сервером и клиентом есть посредник под названием Центр распределения ключей (KDC, Key Distribution Center), которому доверяют оба компьютера. KDC также известны их секретные ключи. Криптографический алгоритм, в котором они используются, является симметричным, т.е. один и тот же ключ может быть использован как для кодирования, так и для декодирования сообщения. Для начала KDC и клиент должны удостовериться в личности друг друга:
Далее, если клиент хочет обратиться к серверу:
Для того чтобы клиент постоянно не использовал свой секретный ключ для связи с Центром распределения ключей, KDC выдает ему мандат на выдачу мандатов (ticket granting ticket, TGT):
Теперь система связи между клиентом и сервером выглядит так:
Как видите, для нормальной работы этой системы аутентификации обязательно требуется синхронизация времени на всех ее элементах. В журнале «Системный администратор» №4 за 2004 год была подробная статья Михаила Платова о настройке сервера времени «NTP – атомные часы на каждом столе». Настройка Kerberos Для UNIX-систем существует две реализации kerberos5, совместимых со стандартом: Heimdal и MIT. В настройке они отличаются не очень сильно, но второй гораздо более популярен, поэтому будем рассматривать именно его. Учтите, что на старых версиях MIT Kerberos (меньших или равных 1.3.1) возникали проблемы с Windows Kerberos Service на Win2003, поэтому рекомендую использовать последнюю доступную на данный момент версию. В качестве открыто указанного имени клиента в описываемой связке Kerberos+Samba+AD используется доменное имя машины. Но зачастую бывает так, что ее реальное DNS-имя не соответствует тому, кем она себя считает. Предположим, что nslookup говорит нам следующее: C:>nslookup 192.168.1.14
Тогда в переменной окружения HOSTNAME UNIX-машины должна находиться строчка «nix». В моем случае это потребовало исправления файла /etc/hostname. Не забудьте проверить, видят ли машины DNS-имена друг друга и нет ли проблем с firewall. Теперь можно приступить к созданию конфигурационного файла для библиотек kerberos, находящегося по адресу /etc/krb5.conf. Сам файл состоит из пяти секций, каждая из которых может включать в себя либо имена и значения отдельных переменных, например: [section] key = value boolean1 = true boolean2 = false либо информацию, объединенную в структуру с определенным именем: [section] struct = { key1 = value1 key2 = value2 ... }
Пример файла: [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = DOMAIN.RU dns_lookup_kdc = false dns_lookup_realm = false [realms] DOMAIN.RU = { kdc = controller.domain.ru admin_server = controller.domain.ru default_domain = domain.ru } [domain_realm] .domain.ru = DOMAIN.RU domain.ru = DOMAIN.RU domain = DOMAIN.RU DOMAIN = DOMAIN.RU Следующим шагом создадим пользователя в Active Directory, имя которого UNIX-машина будет использовать для Kerberos-аутентификации себя. Для этого на контроллере домена в меню «Пуск» откройте «Administrative Tools –> Active directory Users and Computers», выберите нужный контейнер и создайте там пользователя. В качестве параметров можно запретить ему менять пароль (галочка «User cannot change password») и убрать необходимость его менять со временем (галочка «Password never expires»). Допустим, что вы создали пользователя с именем unixuser и паролем SuperPass667.
Далее создаем файл, в который экспортируем секретный ключ: для этого в консоли cmd.exe на контроллере домена требуется выполнить команду: C:>ktpass -princ host/NIX$@DOMAIN.RU -mapuser unixuser -pass SuperPass667 -out nix.keytab где:
Теперь требуется переместить полученный файл на UNIX-машину любым возможным способом. Это можно сделать через ftp/sftp или забросить через веб-сервер, как вам больше нравится. В консоли UNIX запустите программу ktutil и в ее командной строке импортируйте keytab-файл: # ktutil > rkt /root/nix.keytab > list
> wkt /etc/krb5.keytab > quit где /root/nix.keytab – путь к импортируемому файлу, а /etc/krb5.keytab – файл со всеми секретными ключами для данного клиента. После всех этих длительных манипуляций можно проверить работу клиентской части kerberos, выполнив следующую команду: # kinit DomainUser где DomainUser – имя любого доменного пользователя. Если после этого не появилось сообщений об ошибках, значит, библиотека функционирует исправно. Однако помните, что эта команда не использует секретный ключ из /etc/krb5.keytab, а генерирует свой на основе введенного вами пароля, так что если на этом этапе ошибок не появилось, то это еще не означает, что они не возникнут в дальнейшем. Настройка samba При установке этого программного продукта проблем возникнуть не должно, поэтому конкретных указаний по установке здесь дано не будет, и вы можете руководствоваться своими собственными вкусами: собирать из исходников вручную, использовать готовые бинарные пакеты или запускать специализированные программы обновления вашего дистрибутива. После установки следует создать конфигурационный файл для самбы по адресу /etc/samba/smb.conf. Его структура содержит два блока:
Сами настройки рассмотрим на примере: # Имя домена, с которым требуется работать workgroup = DOMAIN # Доменное имя машины, которое должно совпадать с dns-именем и переменной среды HOSTNAME netbios name = NIX # Описание сервера, видимое в «Сетевом окружении» server string = Unix Server # Разделитель названия домена и учетной записи. В Windows это знак «», но в этом случае он может вызвать проблемы # как символ начала escape-последовательности, поэтому его потребуется заменить. По умолчанию идет знак «+», но «/» привычнее winbind separator = / # Использовать домен по умолчанию. Внешне будет проявляться отсутствием доменного префикса перед учетной записью winbind use default domain = yes # Область идентификаторов пользователей, на которую будут отображаться доменные аккаунты idmap uid = 7000-10000 # Область идентификаторов групп, на которую будут отображаться доменные группы idmap gid = 7000-10000 # Автоматически нумеровать пользователей и группы winbind enum users = yes winbind enum groups = yes # Шаблон домашнего каталога для доменных пользователей. Впоследствии будет создаваться автоматически template homedir = /home/DOMAIN/%U # Шаблон командного интерпретатора для доменных пользователей template shell = /bin/bash # Режим безопасности. В режиме ads для аутентификации samba использует исключительно Active Directory, # не обращая внимания на локальные аккаунты security = ads # Шифровать ли пароли. По умолчанию контроллер домена не работает с открытыми паролями. encrypt passwords = yes # Реалм Kerberos, используемый для аутентификации realm = DOMAIN.RU # Параметр, включающий поддержку выбора алгоритмов шифрации в процессе работы. Необходимость использования зависит # от настроек контроллера домена. На Win2003 включен по умолчанию client use spnego = yes # Адрес контроллера домена password server = controller.domain.ru # Шаблон имен файлов логов, где %m – имя машины log file = /var/log/samba3/%m.log # Уровень подробности логов. На первых порах желательно поднять это значение до 4, что позволит достаточно точно # диагностировать проблему. log level = 2 # Максимальный размер лог-файлов. 0 – неограничено. max log size = 0 # Список сетевых интерфейсов, с которыми будет работать демон interfaces = 192.168.1.14 # Не трогать остальные сетевые интерфейсы bind interfaces only = yes # Пример папки # Название [html] # Список пользователей, у которых есть право использовать эту папку. В данном случае это все доменные пользователи. # Знак @ обозначает группу. valid users = @"DOMAIN/Domain Users" # Путь, на который ссылается сама папка path = /var/www/htdocs # Чувствительна ли папка к регистру букв case sensitive = no # Будет ли видна папка в «Сетевом окружении» browseable = yes # Владелец файла при записи в папку force user = root # Группа, назначаемая файлу при записи force group = apache # Можно ли зайти на папку без пароля public = no # Можно ли в нее писать writable = yes # Является ли папка принтером printable = no # Маска создаваемых файлов create mask = 0640 # Пользователи, имеющие полный контроль над папкой admin users = @"DOMAIN/Domain Admins" На следующем шаге потребуется проверить, не осталось ли в Active Directory записей для подопытной машины. Для этого просмотрите ветку Computers. После этого включаем UNIX-машину в домен, исполнив на ней команду: # net ads join -U DomainAdministrator Если в результате исполнения этой команды вы увидите строчку «Joined domain DOMAIN.», то появился повод открывать шампанское. Но в большинстве случаев на этом шаге всплывают все ошибки, допущенные на предыдущих этапах. Вот несколько советов:
Если все прошло успешно, то самое время осуществить первый запуск самбы. Как показывает практика, лучше для этого использовать стартовые скрипты системы в /etc/init.d, чтобы не изобретать велосипед при загрузке. Для корректной работы всей системы должны стартовать следующие демоны:
Настройка запуска именно трех демонов вместо обычных двух (smbd и nmbd) зависит от дистрибутива, в Gentoo для этого следует отредактировать файл /etc/conf.d/samba, руководствуясь находящимися в нем комментариями. Также можно включить режим отладки, добавив в опции запуска всех трех демонов ключ -D с параметром, который определяет количество отладочной информации, записываемой в логи. Больше 4 его делать не стоит, так как в противном случае логи станут очень быстро разрастаться. В случае, если что-то не запустилось, то читаем лог снова, исправляем выявленные ошибки, и запускаем – этот цикл придется повторять до тех пор, пока все не пройдет успешно. Теперь можно проверить, нормально ли работают расшаренные папки, зайдя по адресу file://nix.domain.ru с любой Windows-машины, являющейся членом домена. Аутентификация в системе На данный момент с аутентификацией в Active Directory полноценно работает только самба, остальные сервисы на подопытной UNIX-машине о ней не ведают. Проблема управления большим количеством аккаунтов возникла значительно раньше появления AD, да и, пожалуй, появления Windows-систем в целом. Во времена рассвета UNIX возникла идея централизованного хранения информации о пользователях, чтобы избежать ее дублирования на разных компьютерах. Как решение возникшей проблемы была создана система NIS/NIS+ – Network Information Service, позволявшая компьютеру-клиенту проводить аутентификацию пользователей, с помощью информации, хранящейся на центральном сервере. В Linux сама реализация NIS/NIS+ уходит глубоко в системные библиотеки glibc, поэтому для приложений, работающих на клиенте, нет никакой разницы, с каким пользователем они имеют дело: локальным или удаленным. К тому же реализация была сделана по модульному принципу, что много лет спустя и было использовано разработчиками samba. В дистрибутиве самбы есть модуль libnss_winbind.so, при помощи которого подопытная машина научится преобразовывать абстрактные идентификаторы пользователей, раздаваемые сервером winbindd, в привычные имена. Подключить этот модуль можно в файле /etc/nsswitch.conf. Интересующий нас фрагмент выглядит следующим образом: passwd: files group: files shadow: files Каждая строчка файла отвечает за элемент системы аутентификации – разрешение числовых идентификаторов в привычные имена. Для того чтобы добавить возможность работы с доменными аккаунтами, следует привести этот файл к следующему виду: passwd: files winbind group: files winbind shadow: files Теперь пора проверить работоспособность всей настраиваемой системы – умеет ли подопытная машина полноценно работать с доменными аккаунтами (перед выполнением следующей команды не помешает на всякий случай перезапустить samba): # getent passwd Если на экране консоли, как в «Матрице», замелькала разная информация, по структуре своей напоминающая файл /etc/passwd, причем среди записей попадаются доменные аккаунты, то проверка прошла успешно, с этих пор компьютер не знает различий между доменными и локальными пользователями. Но есть одно небольшое но. Дело в том, что на многих UNIX-системах для аутентификации пользователей и назначения им идентификаторов используется библиотека PAM (Pluggable Authentication Modules). По умолчанию она настроена так, что проходить аутентификацию имеют право только локальные пользователи, да и то не все и не везде. Как видно из названия, библиотека построена по модульному принципу, причем за каждым сервисом, требующим аутентификации, можно закреплять свой список используемых модулей. Настройка PAM специфична для каждого дистрибутива Linux, не говоря уже о BSD и прочих реализациях UNIX, так что предлагать готовое решение для чего-то одного было бы несправедливо. По этой причине рассмотрим основы конфигурации, а конкретное их применение каждый найдет для себя сам. PAM – центр всей безопасности системы. Неграмотная его настройка может привести к достаточно разнообразным последствиям: как к тому, что в систему сможет войти кто угодно, так и к тому, что в нее больше никто никогда не войдет, даже администратор. Для последнего случая стоит постоянно держать несколько открытых незадействованных терминалов, при помощи которых в любой момент можно будет исправить допущенную фатальную ошибку. Вероятность этого невелика, но все же такая предосторожность не помешает. Все параметры системы PAM указаны в нескольких файлах, находящихся в каталоге /etc/pam.d, так что перед внесением каких-либо изменений в конфигурацию стоит сделать ее резервную копию. Название файла – это имя программы, к которой следует применять находящиеся в нем настройки. Конфигурация PAM организована в виде стека, то есть модули работают цепочкой, и если один из модулей, имеющий влияние на весь ход процесса аутентификации, решил закрыть или предоставить доступ в систему, то модули, следующие за ним, останутся незадействованными. Для упрощения настройки существует способ заполнять стек модулей из соседних файлов конфигурации. Обычно это используется для указания глобальных параметров аутентификации, единых для всех сервисов, а отдельные файлы лишь по необходимости дополняют существующие глобальные настройки. Если ваша система PAM изначально была настроена с использованием одного общего файла конфигурации system-auth и ссылками на него из соседних, то стоит править только его, чтобы доменные пользователи смогли входить в систему наряду с локальными. В противном случае придется редактировать все файлы конфигурации для необходимых сервисов. Структура самого файла состоит из построчного списка модулей. Формат строки каждого модуля следующий: [тип] [влияние] [название модуля] [параметры] где:
Рассмотрим следующий пример: # сразу загружаем все пользовательские переменные окружения (модуль всегда возвращает положительный результат) auth required /lib/security/pam_env.so # Если пользователь есть в локальной базе, то пускаем его (это условие достаточно для входа в систему) auth sufficient /lib/security/pam_unix.so likeauth nullok # Если предыдущий пункт не сработал, то запретить вход (модуль всегда возвращает отрицательный результат) auth required /lib/security/pam_deny.so В дистрибутиве самбы есть PAM-модуль pam_winbind.so, который нам потребуется для дальнейшей работы. Стоит проверить, был ли он скопирован при установке в каталог /lib/security, и если его там нет, то поместить его туда руками. Основываясь на предыдущем примере, фрагмент конфигурации, позволяющий проводить аутентификацию при помощи samba, будет выглядеть следующим образом: auth required /lib/security/pam_env.so # Если пользователь есть в локальной базе, то пускаем его (это условие достаточно для входа в систему) auth sufficient /lib/security/pam_unix.so likeauth nullok # Если аутентификация в AD сработала, то разрешаем доступ (это условие достаточно для входа в систему) auth sufficient /lib/security/pam_winbind.so use_first_pass # Если предыдущий пункт не сработал, то запретить вход (модуль всегда возвращает отрицательный результат) auth required /lib/security/pam_deny.so Параметр use_first_pass требуется для того, чтобы pam_winbind.so не переспрашивал у пользователя пароль, а использовал тот, который был введен для pam_unix.so. Настало время проверить работоспособность системы PAM: попробуйте в соседней консоли зайти в систему под любым доменным пользователем. В случае неудачи нужно попробовать войти под локальным пользователем, и если это тоже не сработает, то в настройках определенно допущена ошибка. О причинах возможных неполадок много информации можно почерпнуть из системных логов. Последним шагом является наведение порядка в плане безопасности, так как неразумно пускать на UNIX-машину всех пользователей домена. Для решения этой проблемы существует модуль pam_require.so, который, основываясь на членстве пользователя в определенной группе, решает, пустить ли его. Нужно лишь создать группу в AD, добавить в нее пользователей и подключить сам модуль: account required /lib/security/pam_require.so root @unixoids Не переусердствуйте с длиной названия группы, так как glibc иногда не очень адекватно реагирует на длинные имена (более 8 символов).
Пользователи из домена изначально не имеют домашнего каталога. О нем есть лишь небольшое упоминание в его атрибутах, и для того чтобы доменные пользователи не чувствовали себя обделенными, нужно автоматизированно создавать эти каталоги. Для этого существует модуль pam_mkhomedir.so, который берет шаблон домашнего каталога (по умолчанию /etc/skel), копирует его в надлежащее для него место и выставляет необходимые права: session required /lib/security/pam_mkhomedir.so umask=0077 Цель достигнута. UNIX-машина теперь может полноценно взаимодействовать с доменом и доменными пользователями. Остается только не забыть добавить самбу в список запускаемых при загрузке сервисов и с чувством выполненного долга начать ею пользоваться. |
РОМАН ГРЕБЕННИКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
