 |
|
|
|
FreeBSD в домене Windows: дополнительные возможности
FreeBSD в домене Windows: дополнительные возможности Правильное подключение FreeBSD в домен Windows дает возможность работать с Active Directory для проверки паролей, членства в группах и т. д. Но это лишь некоторая часть того, для чего FreeBSD может использовать данную информацию. Ваш компьютер может больше В журнале №3 за 2005 г. была опубликована статья «FreeBSD в домене Microsoft Windows», где рассказывалось о том, как отказаться от регистрации локальных пользователей и использовать пользователей, предоставляемых доменом Microsoft Windows. На тот момент это было действительно достижением – отпала необходимость отслеживать создание новых пользователей и создавать аналогичные учетные записи на файловом сервере, что значительно облегчило работу. На момент написания той статьи существовали некоторые нерешенные проблемы, над которыми я работал все это время, да и проект Samba не стоял на месте. Результатом нашей постоянной совместной работы стало то, что подключение в домен Windows можно использовать для значительно больших целей, чем простая авторизация в домене, а именно:
Кроме того, были решены следующие вопросы:
В статье для тестирования всюду использовалась Microsoft Windows 2003 Server Enterprise Edition и FreeBSD 6.1 с Samba 3.0.24с. Чтобы избежать некоторой терминологической путаницы, всюду «домен» и «имя домена» обозначают не DNS-домен, а домен Windows (pre-Windows 2000). Подключаемся к домену Windows «по-настоящему» Подключение FreeBSD к домену Windows так, как оно было описано в предыдущей статье, представляет FreeBSD для Windows как Windows NT. Простой и надежный способ, обладающий тем не менее множеством недостатков, наиболее крупный из которых – отсутствие поддержки протокола NTLMv2, что делает контроллер домена весьма уязвимым к подбору паролей пользователей. Поэтому первым делом был решен вопрос с подключением к домену Active Directory так, как это делает настоящая Windows – с использованием службы Kerberos. Для реализации этого необходимо, чтобы Samba была собрана со следующими параметрами: # make WITH_ADS=yes WITH_LDAP=yes <другие параметры, если необходимо> При этом проводится автоматическое обнаружение программы Kerberos (MIT или Heimdal), и, если она отсутствует, вставляется соответствующая зависимость в порт. После сборки Samba каких-либо особых настроек делать не надо, за исключением: security = ads Это настроит программы пакета Samba на роль члена домена Active Directory. realm = domain.ru Это задает realm, к которому будет относиться данный компьютер. Параметр следует установить в значение, равное имени Active Directory, к которой будем подключаться. workgroup = DOMAIN_INC Проверьте, что значение параметра workgroup соответствует значению имени домена (pre-Windows 2000). Пример, приведенный выше, выбран не случайно – имя Active Directory и имя домена имеют разные области применения и совершенно не обязаны быть одинаковыми. В документации к пакету Samba рекомендуется также явно установить параметр: client use spnego = yes если версия Windows – 2003. Этот параметр задает использование описанного в RFC 2478 протокола согласования механизмов аутентификации. Перед запуском Samba необходимо создать конфигурационный файл системы Kerberos /etc/krb5.conf. Его формат достаточно подробно описан в man krb5.conf, поэтому я приведу только готовый рабочий пример с необходимыми комментариями. [libdefaults] default_realm = DOMAIN.RU dns_lookup_kdc = yes [realms] DOMAIN.RU = { kdc = win-dc.domain.ru kpasswd_server = win-dc.domain.ru admin_server = win-dc.domain.ru } [logging] default = SYSLOG:INFO:LOCAL1 [domain_realm] .domain.ru = DOMAIN.RU domain.ru = DOMAIN.RU Здесь мы исходим из предположения, что имя Active Directory – domain.ru, имя домена NT – DOMAIN_INC, контроллер домена установлен на компьютере с именем win-dc.domain.ru. Разберем приведенный пример поподробнее.
После создания файла /etc/krb5.conf надо получить билет администратора домена с помощью команды kinit:
Приведенный ответ является нормальным. После успешного завершения команды в каталоге /tmp должен появиться файл krb5cc_0. Ошибки (а их больше, чем хотелось бы) описаны в разделе «Возможные ошибки и их устранение». Проверить, что получен билет администратора домена и им можно пользоваться, вы можете командой klist:
После получения билета администратора домена можно к этому домену подключаться:
Здесь в параметре -U задается имя доменного пользователя с правами администратора домена (от его имени будет создан обьект «Компьютер»), в параметре -w – имя Active Directory или имя домена. Имя Active Directory можно задавать только в том случае, если в /etc/resolv.conf есть запись, указывающая на DNS, работающий на одном из контроллеров Windows-домена, и в /etc/krb5.conf указано dns_lookup_kdc=yes, в противном случае следует указывать имя домена (pre-Windows 2000 с точки зрения Windows-администраторов). Указанный здесь ответ является правильным, после этого в Active Directory должен появиться соответствующий обьект. Указание имени домена является более надежным и реже приводит к ошибкам, хотя включение в домен должно проходить как в том, так и в другом случае (рис. 1).
Рисунок 1. Обьект «Компьютер», представляющий FreeBSD в AD Помните, что Samba при подключении к домену выполняет поиск DC для заданного домена следующим образом (если запись найдена, поиск прекращается, используются найденные данные):
Если ни один из этапов поиска не позволил найти, как минимум, 1 DC, фиксируется ошибка. На этом «настоящее» подключение к домену Windows закончено. Проверить правильность подключения можно в любое время командой:
Если вместо этой надписи увидите «Join is not valid», подключение к домену по каким-либо причинам невозможно. Подробнее о том, что можно сделать в таком случае, сказано в разделе «Возможные ошибки и их устранение». И вот теперь можно включать NTLMv2 (рис. 2).
Рисунок 2. Редактирование групповой политики для включения NTLMv2 Кроме этого, в конфигурационном файле smb.conf нужно отключить NTLMv1, установив параметр: ntlm auth = no и LM, если он все еще включен (шифровка LM очень слабая и может быть легко взломана): lanman auth = no Убедиться в том, что используется именно NTLMv2, можно, включив отладку в Samba на уровень 5. Сделать это для одного пользователя проще через дополнительный файл конфигурации, который обычно подключается в самом конце конфигурационного файла smb.conf таком образом: include = /usr/local/samba/conf/smb.conf.%U то есть при загрузке конфигурационного файла обработчиком сеанса для пользователя administrator будет включен файл с именем smb.conf.administrator. Он содержит всего две строки: [global] log level = 5 После этого в файле log.administrator можно найти среди прочего большого количества отладочной информации следующие строчки: [2006/10/15 00:27:20, 3] libsmb/ntlmssp.c:ntlmssp_server_auth(672) Got user=[Administrator] domain=[DOMAIN] workstation=[CITYCAT] len1=24 len2=24 [2006/10/15 00:27:20, 5] auth/auth_ntlmssp.c:auth_ntlmssp_set_challenge(66) auth_context challenge set by NTLMSSP callback (NTLM2 Используем MMC Возможность использования MMC для управления Samba, работающей на UNIX, была настоящей маленькой революцией. Теперь администратор домена Windows может выполнять из привычной ему оболочки некоторый набор доступных операций по управлению сервером. Несмотря на пока еще очень скромный набор средств – на текущий момент все возможности управления исчерпываются запуском и остановом сервисов, само появление такой возможности вызывает бурный энтузиазм, и я нисколько не сомневаюсь в том, что вскоре их станет больше (рис. 3).
Рисунок 3. Консоль MMC после подключения к FreeBSD Для того чтобы задействовать возможность запуска и останова сервисов, необходимо создать подкаталог svcctl в каталоге, указанном в параметре libdir при сборке Samba (по умочанию /usr/local/samba), и поместить в этот каталог символические линки на все стартовые скрипты тех сервисов, управление которыми вы хотите вынести на MMC. Эти скрипты должны поддерживать параметры start и stop для соответственно запуска и остановки сервиса. Во все файлы скриптов должна в виде комментария быть добавлена строка: # Description: Описание сервиса, как оно будет отображаться Если этого не сделать, во все сервисы, которые не относятся к самому пакету Samba, будет подставлено «External Unix Service». Также в конфигурационном файле smb.conf следует указать список скриптов, которые будут вынесены в MMC. Список задается параметром: svcctl list = cups apache mysql ssh2 Список должен совпадать с именами символических линков (которые вовсе не обязательно совпадают с именами файлов, на которые они указывают). Если описание сервиса добавляется уже после того, как был хотя бы один раз указан параметр svcctl list, то, для того чтобы запомнить новое (или изменить старое) описание, необходимо удалить файл registry.tdb из каталога, указанного параметром lockdir при сборке Samba (рис. 4).
Рисунок 4. Управление сервисами через консоль MMC на FreeBSD Что еще можно сделать через MMC? Можно управлять локальными пользователями и группами, но ограниченно – почему-то создать пользователя или группу не удалось, можно только редактировать свойства, добавлять пользователей в группы, удалять группы и пользователей. Для создания локальных пользователей следует использовать smbpasswd:
При этом, если используется passdb backend = tdbsam (а он используется по умолчанию), пользователь должен существовать в системе. Для создания локальных групп следует использовать net sam:
net sam – это недокументированная часть команды net, предназначенная для непосредственного манипулирования данными о локальных и встроенных группах, хранящихся в файле group_mapping.tdb. Эта команда не работает с базой пользователей, подключаемой через passdb backend. Зато у нее есть встроенная справка, достаточная для работы с ней:
Использование учетных записей домена для назначения прав на локальные файлы Пожалуй, это наиболее ценная возможность winbind, одной из программ, составляющих пакет программ Samba. Что имеется в виду под использованием учетных записей домена? UNIX имел возможность назначить каждому файлу только одного владельца, одну группу владельцев и права «для всех прочих». Для корпоративных файл-серверов, где зачастую на файлы назначаются довольно-таки причудливые права, этого было явно недостаточно, и, чтобы выйти из положения, приходилось включать пользователя в большое количество групп и, достигая ограничения в 16 групп (максимальное число групп, в которые может входить пользователь), объяснять пользователям невозможность установить запрошенные права какими-нибудь придуманными «требованиями Windows». С появлением поддержки ACL в файловых системах FreeBSD все переменилось. Теперь на каждый файл или каталог можно назначить сколько угодно владельцев, групп владельцев и т. д. Все это управляется командами getfacl/setfacl с консоли, у которой только один недостаток – она не позволяет делать рекурсивные назначения. Поскольку система «знает» пользователей и группы домена, то их соответственно можно использовать для назначения прав в команде setfacl, а также в конфигурационном файле smb.conf. Приведу несколько примеров (все примеры взяты из рабочего файла, в котором подправлены только названия групп): [myshare1] comment = This is a comment path = /var/ftp/pub/quality write list = %D+user1,%D+user2, root Наиболее простой пример, в котором доступ по записи предоставляется двум пользователям домена user1 и user2, а также локальному пользователю root. Макрос %D, используемый в конфигурационных файлах пакета Samba, принимает значение имени домена (параметра workgroup из smb.conf), символ «+» – это тот символ, который был задан параметром winbind separator. Если в параметре winbind separatror был указан другой символ, следует использовать его. Также можно использовать макрос %w. В итоге строка %D+user1 превратится в DOMAIN_INC+user1. Каким образом система «разберется», где локальный пользователь, а где доменный? По наличию в строке символа «+» (или любого другого, заданного параметром winbind separator) – без него пользователь считается локальным, с ним – часть до символа считается именем домена, после – именем пользователя. Домен можно указывать и напрямую, и совсем не обязательно это должен быть тот же домен, что и в параметре workgroup. [myshare2] comment = More comments were here path = /usr/local/share/assembly write list = @"Group one", @"Group two", root valid users = %D+user1, %D+user2, root, @"Group one", @"Group two", OTHERDOM_AIN+user3 Пример более сложный, который показывает использование доменных групп, содержащих пробелы в названии, пользователей домена и локальных пользователей. Применяя дополнительные средства управления доступом в smb.conf (директивы inherit- и force-) будьте особенно внимательны – директивы inherit permissions, inherit owner и inherit acls ведут к наследованию соответственно прав, владельца и ACL-записей от родительского каталога, а директивы force user, force group и т. д. – к их принудительному заданию. При этом происходит следующее. При задании force user изменяется значение макроса %u. Если он используется для формирования пути к сетевому ресурсу, то можно неожиданно обнаружить, что создалась новая папка.Например, при использовании сетевого ресурса: [backup] comment = There are backup shares for each user path = /usr/share/dmbackup/%u если для пользователя administrator добавить в файл smb.conf.administrator строку: force user = oneuser то при подключении к ресурсу backup пользователь окажется в каталоге /usr/share/dmbackup/oneuser, а вовсе не в каталоге /usr/share/dmbackup/administrator. Задание force mode влияет на значение «прав по умолчанию». Например, задание в smb.conf.administrator: [backup] force create mode = 0666 при правах по умолчанию на каталог:
привело к появлению следующих прав на каталог:
К сожалению, изменять права на файлы или каталоги, добавлять или удалять ACL через «Properties» до сих пор невозможно – ошибок при этом не выдается, но и ничего не делается. Кроме того, ограничение на 16 групп тоже осталось и даже стало еще хуже – ведь теперь локальные группы объединяются с доменными. Зато каждый пользователь может входить в различные локальные группы на различных компьютерах, и на файлы, каталоги и ресурсы в smb.conf и персональных конфигурационных файлах можно назначать отдельные права для пользователей, и таких прав может быть сколь угодно много. Автоматическое создание каталогов для новых пользователей Одна из серьезных проблем корпоративных файл-серверов под управлением FreeBSD – необходимость вручную создавать домашние или иные каталоги для сотрудников, вновь принимаемых на работу. В небольших организациях, как правило, это делается вручную, но если компания крупная, это становится неприемлемым. В предыдущий раз этот вопрос оставался нерешенным, но сейчас я с удовольствием предложу вам его решение. В этом поможет PAM, который, как известно, может все или почти все, что относится к вопросам регистрации в системе. Первая регистрация с консоли При первой регистрации с консоли пользователь должен до запуска шелла получить домашний каталог и набор стандартных стартовых файлов, в противном случае в качестве домашнего каталога он получит каталог /:
В портах существует модуль pam_mkhomedir (security/pam_mkhomedir). Но он не работает. Точнее, он работает, но не так, как надо. Проверка наличия домашнего каталога выполняется в категории Session management. Логически это так, только на практике имеется такой побочный эффект, что первый раз пользователь все равно регистрируется так, как если бы у него не было домашнего каталога, потому что сначала запускается шелл, описанный для пользователя в /etc/master.passwd, а уже потом выполняются сервисы из секции Session management. Эта ситуация была исправлена переносом проверки наличия домашнего каталога в категорию Account management, и теперь создание домашнего каталога происходит действительно при первой регистрации в системе. Скачать доработанную версию модуля, который называется pam_mkhome, можно с [1]. Для запуска добавьте в файл сервиса (/etc/pam.d/system для регистрации с консоли, /etc/pam.d/ssh для SSH-сессий и т. д.) следующую строку: account required pam_mkhome.so mode=0700 Дополнительно можно указать параметры skel=<каталог>, который задает название каталога, в котором лежат «скелеты» типовых конфигурационных файлов и debug, который включает отладку. Теперь все работает как надо:
Первое обращение по сети (Microsoft Network) Спрос на регистрацию с консоли не очень-то велик. Пока еще не очень много организаций, где в качестве рабочих станций стоят Linux- и FreeBSD-машины. Более интересный вариант – автоматическое создание домашнего и других каталогов при первом обращении по сети Microsoft Network. Поскольку Samba не предусматривает такой возможности (пока, по крайней мере), мною был разработан скрипт, который, выполняясь от пользователя root, создает домашние и любые другие каталоги при первом подключении к ним. Делается это использованием парамера root preexec: root preexec = csh -c '/usr/local/sbin/checkuserhome %u %D %U' Указанный скрипт можно скачать с [1] в виде архива checkhomes-0.90.1.tar.bz2. Скрипт checkuserhome используется для создания домашних каталогов в ресурсе [homes], скрипт checkbackdir используется для создания персональных каталогов в произвольном ресурсе. Для установки скриптов их необходимо настроить на текущий конфигурационный файл Samba, для этого распакуйте архив в какой-нибудь каталог и запустите: # configure –prefix=/usr/local Вместо /usr/local вы можете указать любой другой каталог, где расположены каталог sbin и программа smbd. Configure проверит наличие ${prefix}/sbin/smbd и наличие конфигурационного файла, расположение которого было указано при сборке пакета Samba. При отсутствии файлов smbd в ${prefix}/sbin или smb.conf configure завершается с соответствующей диагностикой. Затем настройте параметры в файле checkhomes.conf, если это необходимо.
Если не нужно создавать никаких подкаталогов, нужно установить sysdirs (bdirs) равным пустой строке (sysdirs=””). После настройки checkhomes.conf запустите: # make для генерации скриптов; # make single для установки скрипта checkuserhome; # make double для установки cкрипта checkbackdir. Для чего используются эти скрипты? Checkuserhome проверяет наличие каталога, описанного в ресурсе [homes] для текущего пользователя, для чего скрипту и передаются макросы %u, %D и %U, представляющие соответственно имя пользователя текущего сервиса, имя домена (значение параметра workgroup=) и имя пользователя в текущей сессии. Разница между %u и %U здесь проявляется в том, что первый макрос расширяется в имя пользователя после проверки по файлу подстановок users.map, а второй макрос расширяется в имя пользователя до подстановки. Разумеется, заметной она будет только, если пользователь описан в файле users.map, например, пусть в нем содержится такая строчка: root=DOMAIN_INC+administrator root=DOMAIN_INC+moreadmin Для пользователей administrator и moreadmin будут созданы различные домашние каталоги. Если необходимо, чтобы все пользователи, которые соответствуют локальной учетной записи root, использовали один и тот же каталог, то в строке вызова, приведенной выше, заменить последний параметр с %U на %u. Checkbackdir используется для создания персонального каталога в произвольном ресурсе. Запускается добавлением в параметры ресурса в файле smb.conf, строчки: root preexec = csh -c '/usr/local/sbin/checkbackdir %u %D %U' Значения макросов, передаваемых скрипту, те же самые. Возможно, в будущем это будет интегрировано непосредственно в сам проект Samba. Автоматическое монтирование сетевых ресурсов Microsoft Windows при регистрации Пожалуй, это самая печальная тема. Печальна она тем, что к ней напрочь отсутствует хоть какой-либо интерес. Может быть, конечно, уже в Windows и не модно монтировать сетевые ресурсы, чтобы использовать однобуквенное символическое имя для обращения к ним, но мне все равно хотелось добиться того, чтобы зарегистрировался в системе – и все нужные сетевые ресурсы подключены. Сначала мной был разработан скрипт mountsmb, написанный на tcsh, потом он был переписан на sh и назван mountsmb2. В настоящее время он присутствует в портах (sysutils/mountsmb2). Скрипт снабжен небольшой документацией, в которой описано, как его установить и настроить. По сути дела, там все сводится к тому, чтобы настроить /etc/nsmb.conf, создать в домашнем каталоге файл .mssmbrc, формат которого описан в документации, и вставить в .cshrc строку, вызывающую монтирование всех описанных ресурсов. Естественно, каталоги, куда будут монтироваться ресурсы, должны заранее существовать. Монтирование выполняется последовательным вызовом mount_smbfs для всех перечисленных ресурсов. Настроить mountsmb2 не очень просто, но это связано не с недоработками скрипта, а исключительно со скромной, очень скромной реализацией SMB/CIFS во FreeBSD – скриптами, кроме того, что уже сделано, сделать больше нельзя. В настоящий момент ведутся работы по PAM-модулю, который бы выполнял подобную задачу. Существующие модули, известные мне, удалены из портов в связи с их старостью и заброшенностью. Позиция же FreeBSD Team по отношению к SMB/CIFS все больше напоминает буддистских обезьянок – «не вижу зла, не слышу зла, не делаю зла» – собственная, давно заброшенная реализация SMBFS (программа монтирования), и никакого желания взаимодействовать с Samba Team. Подобное снобистское невнимание к взаимодействию с Microsoft Network ничуть не способствует повышению престижа FreeBSD – трудно найти сеть, где бы не использовалась Microsoft Network, и игнорировать ее – значит сознательно ограничивать распространение системы. Возможные ошибки и их устранение Для ошибок здесь поистине гигантский простор. Начнем мы с возможных ошибок при подключении в домен «по-настоящему». Пожалуй, самая нелепая ошибка:
В первый раз она просто повергает в немое изумление. А на самом деле все очень просто – на компьютере установлена виртуальная машина Java, и в ней тоже есть программа kinit. И если в настройках /usr/local/bin окажется впереди /usr/bin, вы именно такую картину и увидите.
Такая ошибка может возникнуть, если неверно указан KDC, компьютер недоступен, там не запущен сервис или правила файерволла запрещают доступ к указанному компьютеру.
Имя для Kerberos должно набираться с учетом регистра! Данный пример показывает, что DOMAIN.RU и domain.ru – это разные вещи.
Указывать имя Active Directory вместо имени домена (pre-Windows 2000) можно только в том случае, если Samba способна найти DC с помощью DNS-запроса. Это может быть обеспечено либо указанием в /erc/resolv.conf адреса DC (на котором обязательно должен работать DNS, даже если он никем не используется), либо внесением в любой DNS соответствующих записей. Если и после этого подключение не проходит, проверьте секцию [domain_realm] файла /etc/krb5.conf – записи: .domain.ru = DOMAIN.RU domain.ru = DOMAIN.RU должны обязательно присутствовать там.
Возможны два варианта – либо, действительно, полное имя компьютера, используемое для формирования принципала HOST/computer.domain.tld, не совпадает с именем Active Directory, либо используется Samba 3.0.23c, в которой из-за ошибки такое сообщение может выдаваться даже при правильной настройке. Разрешение полного имени компьютера производится только через /etc/hosts, в нем не участвуют ни /etc/nsswitch.conf, ни gethostbyaddr(). Имя, разрешенное таким образом, будет отображаться в свойствах обьекта «Компьютер». Проверьте, как именуется компьютер в /etc/hosts, и обновите версию Samba до 3.0.23d. В качестве обходного пути могу посоветовать подключаться к домену не через ads, а через MS-RPC:
Обратите внимание, что здесь может быть использована только форма pre-Windows 2000 имени домена. При подключении таким способом будет невозможно использовать MMC для подключения к компьютеру. При работе через MMC ошибиться практически негде. Не потому, что все работает как часы, а потому, что как раз мало что работает и просто нет места для ошибки. Единственное, что может вызвать недоумение, – это наименование и описание сервисов. Для добавления нового или изменения старого описания удалите registry.tdb. Описание можно набирать по-русски, но при этом текст должен быть в KOI8-R, а не в кодировке Windows. На рис. 5 видны два примера описаний – первое было набрано в KOI8-R, второе – в CP-1251.
Рисунок 5. Пример правильного и неправильного описания сервиса по-русски Новое наименование добавьте в файл services/services_db.c и пересоберите пакет Samba. Например, добавим наименование для сервиса INN:
При назначении прав на ресурсы с использованием ACL в файловой системе, а также доменных учетных записей, наследования и принудительного переопределения (force-параметров) будьте очень внимательны – конструкция %D+administrator задает доменного пользователя, в то время как просто administrator – локального, наследование (inherit-параметры) задает права на файл или каталог, равными родительскому каталогу, тогда как force-параметры их переопределяют. Особенно внимательно нужно быть к параметру force user – при его использовании все действия выполняются от форсированного имени, в том числе подстановка макросов %u и %U. В настройке автосоздания каталогов при первой консольной регистрации ошибиться негде, если только pam_mkhome вообще получает управление. Для этого модуль должен быть указан как required в секции account политики pam для сервиса. Для отладки pam можно использовать программу pamtester (security/pamtester). В настройке автосоздания каталогов при первом подключении к сетевому ресурсу все ошибки диагностируются включением отладки в строке шебанга скрипта. Вывод скрипта checkhomes пойдет на консоль, а checkuserhome – в файл лога Samba. Все ошибки могут быть связаны скорее всего с неверными параметрами, передаваемыми из Samba. Также следует проверить наличие и доступность GNU awk, и не вызывается ли BSD awk вместо него. При всей их внешней схожести скрипты для GNU awk могут не работать в BSD awk и наоборот. Удачи!
|
Рашид Ачилов
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
