FreeBSD в домене Windows: дополнительные возможности::Журнал СА 1.2007
www.samag.ru
     
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
Журнал "Системный администратор"
Журнал «БИТ»
Наука и технологии
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
20.12.2019г.
Просмотров: 5102
Комментарии: 0
Dr.Web: всё под контролем

 Читать далее...

04.12.2019г.
Просмотров: 6343
Комментарии: 0
Особенности сертификаций по этичному хакингу

 Читать далее...

28.05.2019г.
Просмотров: 7600
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 7924
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 6980
Комментарии: 0
Django 2 в примерах

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

 FreeBSD в домене Windows: дополнительные возможности

Архив номеров / 2007 / Выпуск №1 (50) / FreeBSD в домене Windows: дополнительные возможности

Рубрика: Администрирование /  Администрирование

Рашид Ачилов

FreeBSD в домене Windows: дополнительные возможности

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

Ваш компьютер может больше

В журнале №3 за 2005 г. была опубликована статья «FreeBSD в домене Microsoft Windows», где рассказывалось о том, как отказаться от регистрации локальных пользователей и использовать пользователей, предоставляемых доменом Microsoft Windows. На тот момент это было действительно достижением – отпала необходимость отслеживать создание новых пользователей и создавать аналогичные учетные записи на файловом сервере, что значительно облегчило работу. На момент написания той статьи существовали некоторые нерешенные проблемы, над которыми я работал все это время, да и проект Samba не стоял на месте. Результатом нашей постоянной совместной работы стало то, что подключение в домен Windows можно использовать для значительно больших целей, чем простая авторизация в домене, а именно:

  • Элементарный доступ к компьютеру через Microsoft Management Console.
  • Раздача прав на файлы и каталоги с использованием имен пользователей и групп из домена Windows.

Кроме того, были решены следующие вопросы:

  • Первая регистрация в системе. В прошлой статье была указана проблема: если новый пользователь добавлен через средства домена Microsoft Windows, то для него не создается домашнего каталога и автоматическое подключение ресурса может не сработать. Эта проблема была решена – для создания домашних каталогов для пользователей, регистрирующихся впервые с консоли (с использованием pam_winbind), был найден и доработан модуль pam_mkhomedir. Поскольку автор модуля не проявил никакого желания внести предложенный ему патч, то этот модуль, переименованный в pam_mkhome, с наложенным патчем был отправлен в дерево портов и скоро должен там появиться. Для пользователей, которые будут пользоваться только сетевыми ресурсами, было разработано два скрипта, которые автоматически создают домашний (или любой другой) каталог для пользователя, если данный каталог отсутствует.
  • Автоматическое монтирование сетевых ресурсов SMBFS «как в Windows». Здесь проблема заключается в очень скромной поддержке SMBFS во FreeBSD. По сути дела, после внесения в основную систему порта net/smbfs ничего не изменилось, хотя с тех пор прошло много времени. Но для FreeBSD team время словно остановилось. В настоящий момент задача автомонтирования решается скриптами из порта sysutils/mountsmb2, вызываемыми из логин-скрипта, но меня они не устраивают, поэтому ведется работа над PAM-модулем, который бы монтировал ресурсы во время входа в систему, используя с mountsmb2 один файл описания монтируемых ресурсов.

В статье для тестирования всюду использовалась 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.

Разберем приведенный пример поподробнее.

  • Секция [libdefaults] – default_realm указывает имя подсекции в секции [realms], указывающей, где размещены основные сервисы. Имя подсекции в секции [realms] должно в точности совпадать с написанием. dns_lookup_kdc задает необходимость искать расположение сервисов в DNS, используя записи SRV. Этот параметр следует устанавливать в yes, если на FreeBSD в /etc/resolv.conf указан DNS, работающий на контроллере домена. Теоретически сервер Active Directory может использовать внешний DNS-сервер, практически же приходится в любом случае (даже если он не будет использоваться) запускать DNS-сервер на контроллере домена, потому что иначе могут возникнуть проблемы с добавлением в домен рабочих станций Windows 2000. Следует иметь в виду, что начиная с версии 3.0.23d в пакете Samba обещана поддержка записей типа SRV, тех же самых, которые использует Windows для поиска контроллеров домена, поэтому рекомендуется в файл /etc/resolv.conf вписывать какой-нибудь последней строчкой адрес DNS-сервера AD.
  • Секция [realms]– делится на подсекции, каждая из которых описывает один realm. Необходимыми параметрами каждой подсекции являются записи, указывающие на расположение сервисов kdc (контроллер домена), kpasswd и kadmin. Для Active Directory это, как правило, один и тот же компьютер.
  • Секция [logging] – необязательная секция, указывающая настройки системы регистрации сообщений. Подробное описание смотрите в man krb5.conf.
  • Секция [domain_realm] – устанавливает соответствие между DNS-именами и realms. Приведенные две строчки – минимально необходимые для работы, они указывают, что все компьютеры из домена domain.ru и собственно компьютер domain.ru относится к realm DOMAIN.RU.

После создания файла /etc/krb5.conf надо получить билет администратора домена с помощью команды kinit:

# kinit administrator@DOMAIN.RU

administrator@DOMAIN.RU's Password:

kinit: NOTICE: ticket renewable lifetime is 1 week

Приведенный ответ является нормальным. После успешного завершения команды в каталоге /tmp должен появиться файл krb5cc_0. Ошибки (а их больше, чем хотелось бы) описаны в разделе «Возможные ошибки и их устранение».

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

# klist

Credentials cache: FILE:/tmp/krb5cc_0

        Principal: administrator@DOMAIN.RU

 

  Issued           Expires          Principal

Nov 27 16:25:29  Nov 28 02:25:29  krbtgt/DOMAIN.RU@DOMAIN.RU

После получения билета администратора домена можно к этому домену подключаться:

# net ads join -U administrator -w domain.ru

administrator's password:

Using short domain name -- DOMAIN_INC

Joined 'VMFREE' to realm 'DOMAIN.RU'

Здесь в параметре -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

Рисунок 1. Обьект «Компьютер», представляющий FreeBSD в AD

Помните, что Samba при подключении к домену выполняет поиск DC для заданного домена следующим образом (если запись найдена, поиск прекращается, используются найденные данные):

  • В gencaсhce.tdb ищется запись SAF/DOMAIN/DOMAIN.RU.
  • В gencache.tdb ищется запись NBT/DOMAIN.RU#1c.
  • Выполняется поиск DC через DNS посредством поиска записи SRV _ldap._tcp.dc._msdcs.DOMAIN.RU.
  • Выполняется поиск DC в соответствии с параметром name resolv order.

Если ни один из этапов поиска не позволил найти, как минимум, 1 DC, фиксируется ошибка.

На этом «настоящее» подключение к домену Windows закончено. Проверить правильность подключения можно в любое время командой:

# net ads testjoin

Join is OK

Если вместо этой надписи увидите «Join is not valid», подключение к домену по каким-либо причинам невозможно. Подробнее о том, что можно сделать в таком случае, сказано в разделе «Возможные ошибки и их устранение».

И вот теперь можно включать NTLMv2 (рис. 2).

Рисунок 2. Редактирование групповой политики для включения NTLMv2

Рисунок 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

Рисунок 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

Рисунок 4. Управление сервисами через консоль MMC на FreeBSD

Что еще можно сделать через MMC? Можно управлять локальными пользователями и группами, но ограниченно – почему-то создать пользователя или группу не удалось, можно только редактировать свойства, добавлять пользователей в группы, удалять группы и пользователей. Для создания локальных пользователей следует использовать smbpasswd:

# smbpasswd -a ftp

New SMB password:

Retype new SMB password:

Added user ftp.

При этом, если используется passdb backend = tdbsam (а он используется по умолчанию), пользователь должен существовать в системе.

Для создания локальных групп следует использовать net sam:

# net sam createlocalgroup moretest

Created local group moretest with RID 1002

net sam – это недокументированная часть команды net, предназначенная для непосредственного манипулирования данными о локальных и встроенных группах, хранящихся в файле group_mapping.tdb. Эта команда не работает с базой пользователей, подключаемой через passdb backend. Зато у нее есть встроенная справка, достаточная для работы с ней:

# net sam

net sam createbuiltingroup Create a new BUILTIN group

net sam createlocalgroup Create a new local group

net sam mapunixgroup Map a unix group to a domain group

net sam addmem Add a member to a group

net sam delmem Delete a member from a group

net sam listmem List group members

net sam list List users, groups and local groups

net sam show Show details of a SAM entry

net sam set Set details of a SAM account

net sam provision Provision a clean User Database

Использование учетных записей домена для назначения прав на локальные файлы

Пожалуй, это наиболее ценная возможность 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

при правах по умолчанию на каталог:

drwx------ 3 root     wheel    512 15 Oct 22:59 root/

привело к появлению следующих прав на каталог:

drwxrwx---+ 3 root     wheel    512 15 Oct 22:59 root/

К сожалению, изменять права на файлы или каталоги, добавлять или удалять ACL через «Properties» до сих пор невозможно – ошибок при этом не выдается, но и ничего не делается. Кроме того, ограничение на 16 групп тоже осталось и даже стало еще хуже – ведь теперь локальные группы объединяются с доменными. Зато каждый пользователь может входить в различные локальные группы на различных компьютерах, и на файлы, каталоги и ресурсы в smb.conf и персональных конфигурационных файлах можно назначать отдельные права для пользователей, и таких прав может быть сколь угодно много.

Автоматическое создание каталогов для новых пользователей

Одна из серьезных проблем корпоративных файл-серверов под управлением FreeBSD – необходимость вручную создавать домашние или иные каталоги для сотрудников, вновь принимаемых на работу. В небольших организациях, как правило, это делается вручную, но если компания крупная, это становится неприемлемым. В предыдущий раз этот вопрос оставался нерешенным, но сейчас я с удовольствием предложу вам его решение. В этом поможет PAM, который, как известно, может все или почти все, что относится к вопросам регистрации в системе.

Первая регистрация с консоли

При первой регистрации с консоли пользователь должен до запуска шелла получить домашний каталог и набор стандартных стартовых файлов, в противном случае в качестве домашнего каталога он получит каталог /:

login as: testip

SSH server: PAM authentication

Using keyboard-interactive authentication.

Password:

sshd2[4267]: WARNING: Could not chdir to home directory /usr/home/testip:

No such file or directory

Last login: Thu Oct 26 2006 23:24:26 +0700 from shelton.net

Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994

        The Regents of the University of California. All rights reserved.

 

FreeBSD 6.1-RELEASE (VmFree) #1: Mon Oct  9 02:29:51 NOVST 2006

> pwd

/

В портах существует модуль 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, который включает отладку. Теперь все работает как надо:

login as: testip

SSH server: PAM authentication

Using keyboard-interactive authentication.

Password:

Last login: Thu Oct 26 2006 23:48:44 +0700 from shelton.net

Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994

        The Regents of the University of California. All rights reserved.

 

FreeBSD 6.1-RELEASE (VmFree) #1: Mon Oct  9 02:29:51 NOVST 2006

> pwd

/usr/home/testip

Первое обращение по сети (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, если это необходимо.

  • Параметр skel задает расположение каталога «скелетов» – шаблонов конфигурационных файлов, копируемых в домашние каталоги пользователей. Используется при генерации checkuserhome.
  • Параметр dbackup задает расположение корневого каталога ресурса, в котором будут создаваться подкаталоги. Используется при генерации checkbackdir.
  • Параметры sysdirs и bdirs используются для задания списка подкаталогов, которые должны быть созданы в каталоге, создаваемом checkuserhome или checkbackdir соответственно.
  • Параметры sysmode и bmode соответственно задают права доступа, устанавливаемые на эти каталоги.

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

Возможные ошибки и их устранение

Для ошибок здесь поистине гигантский простор. Начнем мы с возможных ошибок при подключении в домен «по-настоящему».

Пожалуй, самая нелепая ошибка:

# kinit administrator@DOMAIN.RU

Exception: krb_error 0 Could not load configuration file

/usr/local/jdk1.4.2/jre/lib/security/krb5.conf

(No such file or directory) No error

KrbException: Could not load configuration file

/usr/local/jdk1.4.2/jre/lib/security/krb5.conf

(No such file or directory)

        at sun.security.krb5.Config.<init>(DashoA6275:139)

        at sun.security.krb5.Config.getInstance(DashoA6275:72)

        at sun.security.krb5.internal.tools.Kinit.<init>(DashoA6275:135)

        at sun.security.krb5.internal.tools.Kinit.main(DashoA6275:104)

В первый раз она просто повергает в немое изумление. А на самом деле все очень просто – на компьютере установлена виртуальная машина Java, и в ней тоже есть программа kinit. И если в настройках /usr/local/bin окажется впереди /usr/bin, вы именно такую картину и увидите.

# kinit administrator@DOMAIN.RU

administrator@DOMAIN.RU's Password:

kinit: krb5_get_init_creds: unable to reach any KDC in realm DOMAIN.RU

Такая ошибка может возникнуть, если неверно указан KDC, компьютер недоступен, там не запущен сервис или правила файерволла запрещают доступ к указанному компьютеру.

# /usr/bin/kinit administrator@domain.ru

administrator@domain.ru's Password:

kinit: krb5_get_init_creds: unable to reach any KDC in realm domain.ru

Имя для Kerberos должно набираться с учетом регистра! Данный пример показывает, что DOMAIN.RU и domain.ru – это разные вещи.

# net ads join -U administrator -w domain.ru

administrator's password:

[2006/10/29 00:49:58, 0] utils/net_ads.c:ads_startup(281)

  ads_connect: Operations error

Указывать имя 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

должны обязательно присутствовать там.

# net ads join -U administrator -w domain.ru

administrator's password:

Using short domain name -- DOMAIN_INC

Failed to set servicePrincipalNames. Please ensure that

the DNS domain of this server matches the AD domain,

Or rejoin with using Domain Admin credentials.

Disabled account for 'VMFREE' in realm '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:

# net rpc join -U administrator -w DOMAIN_INC

Password:

Joined domain DOMAIN_INC.

Обратите внимание, что здесь может быть использована только форма pre-Windows 2000 имени домена. При подключении таким способом будет невозможно использовать MMC для подключения к компьютеру.

При работе через MMC ошибиться практически негде. Не потому, что все работает как часы, а потому, что как раз мало что работает и просто нет места для ошибки. Единственное, что может вызвать недоумение, – это наименование и описание сервисов. Для добавления нового или изменения старого описания удалите registry.tdb. Описание можно набирать по-русски, но при этом текст должен быть в KOI8-R, а не в кодировке Windows. На рис. 5 видны два примера описаний – первое было набрано в KOI8-R, второе – в CP-1251.

Рисунок 5. Пример правильного и неправильного описания сервиса по-русски

Рисунок 5. Пример правильного и неправильного описания сервиса по-русски

Новое наименование добавьте в файл services/services_db.c и пересоберите пакет Samba. Например, добавим наименование для сервиса INN:

--- services_db.c.old   Sun Oct 15 03:04:58 2006

+++ services_db.c       Sun Oct 29 23:14:35 2006

@@ -80,6 +80,7 @@

                                                       "file transferring" },

  { "ssh2",         NULL, "SSH Secure Shell",         

"Provides service for secure connection for remote administration" },

  { "sshd",         NULL, "SSH Secure Shell",         

"Provides service for secure connection for remote administration" },

+  { "inn",           NULL, "InterNetwork News Server", NULL },

  { NULL, NULL, NULL, NULL }

};

При назначении прав на ресурсы с использованием 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 и наоборот.

Удачи!

  1. http://www.askd.ru/~shelton/newstore – упоминаемые в статье скрипты и патчи, а также доработанная версия модуля pam_mkhomedir, который называется pam_mkhome.
  2. Кондрин М. Развертываем Heimdal Kerberos. //«Системный администратор», №7, 2005 г. –  С. 20-25.

Комментарии отсутствуют

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

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru