Доброго времени, читатели и гости! Сегодня на своем блоге хочу рассмотреть сервер SAMBA, как член домена Active Directory на Windows 200x. Хочу сказать, что изначально статья планировалась с темой “дополнительный контроллер домена Active Directory Windows 200x на Linux“, но к сожалению, SAMBA может работать не более чем в режиме контроллера домена NT4 (по крайней мере, версия samba 3.х). В 4 версии SAMBA планируется режим работы в качестве полноценного контроллера домена Active Directory, но данная версия только разрабатывается и даже не вышел альфа-релиз, поэтому ставить эксперименты с сырым продуктом пока не хочется. Итак, давайте остановимся на работе SAMBA, как члена доменной структуры Active Directory. Большинство дистрибутивов Linux поддерживают интеграцию с AD “из коробки”, но тру-админ должен понимать и разбираться, как все это работает. Поэтому в данной статье я рассмотрю интеграцию Linux и Windows.

Введение (теория)

Как мы знаем из прошлой статьи, основным протоколом SAMBA является SMB/CIFS. Основные задачи данного протокола – обеспечение доступа к файлам и каталогам на удаленной машине и сетевая печать. C годами данный протокол совершенствовался и с каждой новой версией поддерживал более защищенные методы аутентификации. Поддержку различных уровней аутентификации можно увидеть на приведенной иллюстрации слева, взятой с wiki журнала Linuxformat.

Итак, существует четыре основных метода аутентификации SMB/CIFS:

Открытым текстом. Использование данного метода крайне не рекомендуется, т.к. пароль передается не зашифрованым. Данный вид в современных системах по умолчанию – отключен. В SAMBA шифрование можно отключить глобальным параметром encrypted password = no в файле smb.conf.

LM (LAN Manager). Использовался в Windows до WinXP. В Samba включен по умолчанию.

NTLM/NTLMv2. Используется для аутентификации в рабочих группах. Samba совместима с NTLMv2. При аутентификации используются легко подбираемые хэши паролей.

Kerberos. В настоящее время, Kerberos является самой защищенной системой, используется криптография с секретным ключом. Применяется в доменах Active Directory (AD). Samba, начиная с версии 3 полноценно поддерживает данный протокол в виде клиента.

kerberos

Остановлюсь на протоколе kerberos поподробней, ибо с ним мы и будем работать в AD. В сети, использующей Kerberos существуют три основных элемента: клиент, центр выдачи ключей-квитанций (KDC – Key Distribution Center) и сервер авторизации. Два последние чаще всего являются одной машиной. По своей сути, Kerberos обеспечивает доверительное обслуживание третьей стороной – сервером Kerberos. Данный сервер является доверенным для всех объектов сети (пользователи, сервисы, машины и т.п.). Объекты сети, доверяющие другим объектам сделать какую-то операцию, в терминологии Kerberos называются – принципалами. У всех принципалов в доверенной сети имеется секретный пароль (он же ключ, он же билет, он же тикет) с сервером kerberos, который позволяет принципалам проверить, что информация от сервера kerberos и других объектов сети – действительна и тем самым принципалы и сервер Kerberos друг-друга аутентифицируют.

Коротко, работа Kerberos заключается в следующем: клиент, предоставляя свои логин/пароль обращается к KDC, если данный клиент существует и введенные данные верны, сервер ключей выдает клиенту тикет на доступ к серверу авторизации. Сервер авторизации проверяет, разрешен ли клиенту доступ клиента к сервису и если разрешен, то выдает клиенту билет на доступ к ресурсу. При этом, расхождение часов клиента и серверов не должно быть более 5 минут. На самом деле, все гораздо сложнее. О кербкрос более подробно можно почитать в приведенных ссылках в конце статьи.

До определенного времени Kerberos являлся технологией, которую разрабатывал MIT (Massachusetts Institute of Technology) для целей США и имелся запрет на экспорт данной технологии. Но вскоре в Королевском Технологическом Институте (Royal Institute of Technology — KTH) в Европе была создана свободная реализация Kerberos, известная как проект Heimdal Kerberos. В итоге, обе разработки имеют свободные реализации, как MIT Kerberos, так и Heimdal Kerberos.

Протокол Kerberos в среде Active Directory работает в купе со следующими компонентами операционной системы:

• Служба доменных имен DNS
• Служба каталога LDAP
• Протокол SMB
• Служба Kerberos

Каждая из них выполняет свою работу, но если хотя бы один из этих компонентов будет функционировать неправильно, то ввод клиента в домен будет невозможен.

Linux в домене Active Directory

Для реализации взаимодействия пользователей Windows (с их SID) и локальных пользователей UNIX (имеющих идентификаторы UID и GID) существует несколько подходов:

Каталог LDAP AD как источник проверки подлинности. Active Directory и является типичным LDAPv3-каталогом, при этом, при проверке подлинности силами LDAP имя пользователя и пароль передаются без шифрования – открытым текстом. Это, естественно, небезопасно. Для решения данной проблемы возможно использовать шифрование SSL, но добавляет определенный объем танцев с бубном при дополнительной настройке AD, а так же лишнюю нагрузку на контроллер домена. При этом Name Service Switch (NSS) работает напрямую с LDAP. Данный вид хранения информации о соответствии пользователей Windows и Linux удобен при использовании NT4 PDC организованном на SAMBA с хранением информации в базе LDAP.

Демон Winbind. При данном способе, NSS настраивается на работу с Winbind, а Winbind в свою очередь занимается “разрешением” имен пользователей (точнее идентификаторов SID) в UID и GID с помощью LDAP, RPC и/или Kerberos – вызовов и создается (кэшируется) запись о пользователе в файлах демона winbindd: winbindd_idmap.tdb и winbindd_cache.tdb. Данный способ мы и будем рассматривать.

Если для получения информации о пользователях не используется LDAP Active Directory, каждый сервер SAMBA – член Active Directory поддерживает свою уникальную базу данных присоединений пользователей. Это значит, что почти бесспорным является тот факт, что пользователь, имеющий доступ к двум серверам – членам домена не имеет того же самого UID/GID на обоих серверах, в тоже время это прозрачно для пользователя сети Windows, потому что мы разграничиваем доступ к ресурсам на основании имен пользователей и групп, а не на основании UID и GID. Данные о пользователях хранятся (кэшируются) в файлах winbindd_idmap.tdb и winbindd_cache.tdb.

Введение Linux в домен Active Directory

Исходные данные

NetBIOS имя домена – AD
Полное имя домена – AD.local
Имена контроллеров домена – dc.AD.local и dc2.AD.local
IP контроллеров домена – 10.0.0.2 и 10.0.0.1 соответственно
Адресация локальной сети – 10.0.0.1/24 (он же 10.0.0.1/255.255.255.0)
IP SAMBA-сервера – 10.0.0.11
Имя SAMBA-сервера – files.AD.local

Подготовка системы

Пример включения в домен буду рассматривать на Debian 6. Все нижеуказанные шаги можно вполне применить к другому дистрибутиву. Samba предоставляет собой три демона: smbd, nmbd и winbindd. smbd – отвечает за общий доступ к файлам и принтерам, nmbd – за разрешение имен по протоколу SMB/CIFS, регистрацию компьютера в сети и некоторые другие задачи, которые на текущий момент нам не интересны, winbindd обеспечивает связь с контроллером домена Active Directory и аутентификацию пользователей домена. В Debian, демоны smbd и nmbd содержатся в пакете samba, а winbindd – в пакете winbind. Кроме демона winbind в последнем пакете содержится утилита net (кстати, очень похожа на одноименную утилиту от Win), позволяющую выполнять множество административных задач, в том числе присоединение машины к домену AD.

1. Установим пакеты samba и winbind (мне так же понадобилось установить пакет smbclient для использования rpcclient для управления принтерами и tdb-tools для tdbackup для управления базами tdb, в которых SAMBA хранит свои настройки при подключении к домену).

2. Настроим файл hosts, задав полное доменное имя (FQDN) для сервера и проверим сделанные настройки командой hostname:

root@files:~# cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       files.AD.local files
root@files:~# hostname -f
files.AD.local

3. Настроим файл /etc/resolv.conf, задав полное имя домена для автоматической подстановки к именам хостов и адреса DNS серверов локальной сети (более подробно об этом файле в статье Настройка сети в Linux):

root@files:~# cat /etc/resolv.conf
domain AD.local
search AD.local
nameserver 10.0.0.2
nameserver 10.0.0.1

4. Настроим файл Name Service Switch – /etc/nsswitch.conf для указания в каком порядке NSS осуществляет поиск имен пользователей, паролей, хостов, сетей и т. д. (указаны только модифицированные строки):

root@files:~# cat /etc/nsswitch.conf

passwd:         compat winbind
group:          compat winbind
shadow:         compat winbind

hosts:          files dns wins
..............

Согласно приведенных настроек, при поиске имен пользователей, групп и паролей Linux будет последовательно обращаться к встроенной базе данных (файлам /etc/passwd, /etc/group, /etc/shadow), затем – к демону winbind. При разрешении имени хоста сначала будет использоваться файл /etc/hosts, затем DNS и, в последнюю очередь, служба имен NetBIOS. Это может пригодиться, если в вашей сети есть хосты, не зарегистрированные в DNS, но имеющие имена NetBIOS, к примеру, компьютеры под управлением Windows в составе рабочей группы.

Настройка SAMBA

1. Проверим, поддерживает ли установленный пакет работу с протоколом Kerberos и каталогом LDAP:

root@files:~# smbd -b | grep KRB
HAVE_KRB5_H
HAVE_KRB5_LOCATE_PLUGIN_H
HAVE_ADDRTYPE_IN_KRB5_ADDRESS
HAVE_DECL_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE
HAVE_DECL_KRB5_GET_CREDENTIALS_FOR_USER
HAVE_INITIALIZE_KRB5_ERROR_TABLE
HAVE_KRB5
HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
HAVE_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE
HAVE_KRB5_C_ENCTYPE_COMPARE
HAVE_KRB5_C_VERIFY_CHECKSUM
HAVE_KRB5_DEPRECATED_WITH_IDENTIFIER
HAVE_KRB5_ENCRYPT_BLOCK
HAVE_KRB5_ENCRYPT_DATA
HAVE_KRB5_ENCTYPE_TO_STRING
HAVE_KRB5_ENCTYPE_TO_STRING_WITH_SIZE_T_ARG
HAVE_KRB5_FREE_DATA_CONTENTS
HAVE_KRB5_FREE_HOST_REALM
HAVE_KRB5_FREE_KEYTAB_ENTRY_CONTENTS
HAVE_KRB5_FREE_UNPARSED_NAME
HAVE_KRB5_FWD_TGT_CREDS
HAVE_KRB5_GET_CREDENTIALS_FOR_USER
HAVE_KRB5_GET_HOST_REALM
HAVE_KRB5_GET_INIT_CREDS_OPT_ALLOC
HAVE_KRB5_GET_INIT_CREDS_OPT_FREE
HAVE_KRB5_GET_PERMITTED_ENCTYPES
HAVE_KRB5_GET_RENEWED_CREDS
HAVE_KRB5_KEYBLOCK_IN_CREDS
HAVE_KRB5_KEYTAB_ENTRY_KEY
HAVE_KRB5_KEYUADE_APP_DATA_CKSUM
HAVE_KRB5_KT_FREE_ENTRY
HAVE_KRB5_LOCATE_KDC
HAVE_KRB5_MK_REQ_EXTENDED
HAVE_KRB5_PRINCIPAL2SALT
HAVE_KRB5_PRINCIPAL_COMPARE_ANY_REALM
HAVE_KRB5_PRINC_COMPONENT
HAVE_KRB5_PRINC_REALM
HAVE_KRB5_SET_DEFAULT_TGS_ENCTYPES
HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
HAVE_KRB5_SET_REAL_TIME
HAVE_KRB5_STRING_TO_KEY
HAVE_KRB5_TKT_ENC_PART2
HAVE_KRB5_USE_ENCTYPE
HAVE_KRB5_VERIFY_CHECKSUM
HAVE_LIBGSSAPI_KRB5
HAVE_LIBKRB5
HAVE_MAGIC_IN_KRB5_ADDRESS
HAVE_SHORT_KRB5_MK_ERROR_INTERFACE
HAVE_TICKET_POINTER_IN_KRB5_AP_REQ
KRB5_CREDS_OPT_FREE_REQUIRES_CONTEXT
KRB5_TICKET_HAS_KEYINFO
KRB5_VERIFY_CHECKSUM_ARGS
root@files:~# smbd -b | grep LDAP
HAVE_LDAP_H
HAVE_LDAP
HAVE_LDAP_ADD_RESULT_ENTRY
HAVE_LDAP_INIT
HAVE_LDAP_INITIALIZE
HAVE_LDAP_SASL_WRAPPING
HAVE_LDAP_SET_REBIND_PROC
HAVE_LIBLDAP
LDAP_SET_REBIND_PROC_ARGS

Если у вас вывод похож на указанный значит все ок. Если вывод не содержит строчек с надписями KRB5 и LDAP, значит нужно скачать исходники и собрать демон с поддержкой Kerberos. Как собирать ПО из исходников – я писал в статье Управление программным обеспечением в Linux.

2. Настроим САМБА для ввода в домен

root@files:~# # переместим оригинальный файл для ознакомления в будущем
root@files:~# mv /etc/samba/smb.conf /etc/samba/smb.conf.orig
root@files:~#
root@files:~# # создадим файл, следующего содержания,
root@files:~# # в котором будут содержаться комментарии:
root@files:~#
root@files:~# cat /etc/samba/smb.conf.comment
[global]
        # NetBIOS-имя хоста (должно совпадать с значением в hosts)
        netbios name = FILES
        # уровень безопасности (ads - член домена AD)
        security = ads
        # NetBIOS имя домена
        workgroup = AD
        # область работы kerberos \
        #      (совпадает с именем домена и записывается прописными буквами)
        realm = AD.LOCAL
        # метод аутентификации smbd (с помощью winbind)
        auth methods = winbind
        # имена сервера паролей - КД
        password server = dc.ad.local dc2.ad.local
        # настройки демона winbind:
                # мапить пользователей на следующий диапазон ЮИД
                idmap uid = 10000-20000
                # мапить группы на следующий диапазон ГИД
                idmap gid = 10000-20000
                # разделитель домена и объекта
                winbind separator = ^
                # разрешить приложениям (например passwd) перечислять пользователей
                #    и группы из домена AD (необязательно)
                winbind enum users = Yes
                winbind enum groups = Yes
                # разрешить сторонним приложениям ссылаться на пользователей AD
                #    как на локальных, не указывая имя домена и символ-разделитель
                winbind use default domain = yes
                # разрешить кэширование авторизованных пользователей
                #    (на случай, если КД станет недоступен) - на время настройки лучше отключить
                #winbind offline logon = yes
        # НЕ заставлять nmbd-сервер быть мастер-сервером Wins
        preferred master = No
        # оприеделить лог-файл (по умолчанию - сислог)
        log file = /var/log/samba/log.new
        # уровень логирования (можно менять от 0-минимальный до 9 - максимальный)
        log level = 3
        # действие при крушении демона
        panic action = /usr/share/samba/panic-action %d
        # принтеры нам не нужны
        #load printers = no
        #show add printer wizard = no
        #disable spoolss = yes
        # принтеры нам нужны
        printing = CUPS
        cups options = raw
        show add printer wizard = yes
        # использовать только порт 139
        #     (немного ускоряет обращения и избавляет от некоторых ошибок в логе)
        smb ports = 139
        # файл ручного мапинга пользователей
        username map = /etc/samba/smbusers
        # ускорим работу самба
        socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
 root@files:~# # проверим корректность файла и сформируем итоговый конфигурационный файл
root@files:~# testparm -s /etc/samba/smb.conf.comment > /etc/samba/smb.conf
Load smb config files from /etc/samba/smb.conf.comment
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Loaded services file OK.
Server role: ROLE_DOMAIN_MEMBER

В документации Samba указывается, что параметр password server не обязателен, поскольку Samba умеет находить сервер паролей, используя SRV-записи DNS. Однако автоопределение сервера паролей срабатывает не всегда, особенно в старых версиях Samba. В Windows 200x для отделения имени домена от имени пользователя используется обратная косая черта. В Linux это может привести к проблемам, поскольку данный символ трактуется как служебный, для решения данной проблемы введен параметр winbind separator, заменяющий \ на указанный символ.

После проведенных тестов, можно однозначно утвердить, что указанный параметр socket options однозначно в разы ускоряет работу samba.

3. Удаляем если есть (или переносим в резервные копии) файлы из /var/lib/samba/*.tdb. Данное действие актуально, если самба ранее была подключена к домену, т.к. в данных файлах хранятся кэш настроек SAMBA. Описание каждого файла можно почитать по ссылкам в конце статьи.

4. Синхронизируем время

Для корректной работы SAMBA, как клиента домена Active Directory, расхождение часов не должно превышать 5 минут. Точнее сказать – этого требует протокол Kerberos. Для решения вопроса синхронизации времени я предлагаю использовать демона ntpd. Как его установить я описывал в статье Сервер точного времени на Linux, поэтому ограничусь приведением рабочего конфига для клиента сети Windows:

root@files:~# cat /etc/ntp.conf
server dc.ad.local
server dc2.ad.local
restrict default ignore
restrict dc.ad.local noquery notrap
restrict dc2.ad.local noquery notrap
restrict 127.0.0.1 nomodify notrap

Для синхронизации времени можно использовать, так же команду net time set в cron.

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

Ввод SAMBA в домен Active Directory

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

root@files:~# net ads join -U domain_admin
Enter domain_admin's password:
Using short domain name -- AD
Joined 'FILES' to realm 'ad.local'

Вместо учетной записи «domain_admin» необходимо использовать имя пользователя с правом присоединения компьютера к домену. Стоит обратить внимание, что если в конфиге “самба” не указан параметр winbind use default domain, то имя пользователя необходимо вводить в формате [email protected]. Сообщения выводимые после выполнения команды обозначают следующее: Using short domain name — AD и Joined ‘FILES’ to realm ‘ad.local’ указывают на удачный ввод в домен. Если после выполнения команды не было ошибки Join to domain is not valid, значит скорее всего, ввод в домен произведен успешно.

У меня при первой попытке вывалилось сообщение

[2011/07/31 01:52:14.769838,  0] libads/kerberos.c:333(ads_kinit_password)
kerberos_kinit_password [email protected] failed: Preauthentication failed

но тем не менее сервер был включен в домен. В списках рассылки видел, что эта ошибка связана с некорректной работой библиотек отвечающих за Kerberos. Как избавиться от ошибки – решения не нашел.

Далее, для корректной работы SAMBA с доменной аутентификацией Active Directory, необходимо перезапустить демонов samba и winbind, после чего можно просмотреть список доменных учетных записей:

root@files:~# # попытка получить список пользователей до перезапуска служб
root@files:~# wbinfo -u
Error looking up domain users
root@files:~# # перезапуск служб
root@files:~# service samba restart
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
files ~ # service winbind restart
Stopping the Winbind daemon: winbind.
Starting the Winbind daemon: winbind.
root@files:~# # попытка получить список пользователей после перезапуска служб
root@files:~# wbinfo -u
FILES^nobody
guest
administrator
krbtgt
domain_user1
domain_user2
...
root@files:~# # попытка получить информацию о пользователе после перезапуска служб
root@files:~# id domain_user13
uid=10002(domain_user13) gid=10002(domain users) группы=10002(domain users),10007(it),10010(акцизный склад),10011(sql_ts),10006(it-dep),10007(it),10001(BUILTIN^users)
root@samba:~# getent passwd domain_user11
domain_user11:*:10002:10009::/home/AD/domain_user11:/bin/false

Все. После данных манипуляций наш Linux – в домене AD. И через сетевое окружение можно на него зайти без ввода пароля, только там не будет расшаренных ресурсов, их мы создадим позднее.

Диагностика SAMBA при включении в домен AD

Если включение в домен завершилось ошибкой, необходимо:

1. Проверить настройки DNS на Linux и убедиться, что команда hostname -f  выводит корректное FQDN-имя хоста.
2. Проверить, в состоянии ли утилиты nslookup или dig разрешить имя КД Active Directory в IP.
3. Проверить, поддерживает ли установленный пакет samba работу с Kerberos и LDAP.
4. Если вышеуказанные шаги не помогли, можно выполнить тестовое подключение к домену с увеличенным значением log level(параметр -d увеличивает уровень журналирования), тем самым выявив ошибку подключения:
   • net ads testjoin -d 10 -Udomain_admin

Для большего понимания взаимодействия SAMBA с инфраструктурой Active Directory приведу (справа) иллюстрацию (взято с Linuxformat).

Существует распространенное заблуждение, что Linux (samba) при входе в домен не в состоянии самостоятельно получить первую квитанцию от центра ключей Kerberos. Это заблуждение возникло потому что в официальном руководстве по SAMBA в одном из подготовительных шагов при введении SAMBA в AD приводится настройка файла /etc/krb5.conf и вызовов команды kinit. Данный файл содержит параметры автономного клиента Kerberos в локальной Linux и утилита linit использует именно настройки из файла /etc/krb5.conf.

Соответственно, настройка krb5.conf и выполнение kinit необходимо исключительно для тестирования связи с сервером Kerberos и выполнять эти настройки совсем не обязательно. Samba может самостоятельно выполнять весь цикл взаимодействия KDC, включая обновление квитанций по истечению срока их действия без применения сторонних утилит. Чтобы библиотеки Kerberos, которые использует самба для взаимодействия с KDC корректно были настроены и работали, SAMBA создает на базе информации из файла smb.conf файл /var/run/samba/smb_krb5/krb5.conf.AD, который и заменяет стандартный /etc/krb5.conf.

Создание разделяемых ресурсов SAMBA в домене Active Directory

Введение

Чтобы сразу избавить от ошибок в будущем при организации разделяемых ресурсов, хочу сказать, что при описании ресурсов в SAMBA конечный доступ к файлам и папкам определяется двумя параметрами. Первое – это параметры доступа, указанные в параметрах разделяемого ресурса, второе – права доступа к файловой системе. При этом, по-умолчанию, все пользователи самба обращаются к файловой системе с правами группы “остальные”, если в samba не указано иное (например подключившийся пользователь не мапится в локального пользователя UNIX). То есть, кроме того, что самба определяет права доступа к разделяемому ресурсу, она может подключающемуся пользователю назначить соответствие системному локальному пользователю Linux, так, что подключившийся пользователь будет получать доступ к файловой системе с правами какого-либо примапленного (читай – назначенного, образовано от англ. mapping  присоединение) локального пользователя Linux.

Это чем-то похоже на организацию доступа к файлам в Windows, в которой тек же есть права доступа к файловой системе (вкладка “Безопасность”) и права доступа к разделяемому ресурсу (вкладка “Доступ”).

Права файловой системы я рассматривал в статье Права доступа в Linux, т.к. эта тема очень актуальна для текущей статьи, напомню в двух словах о правах… Итак, права в Linux определяются тремя возможностями (чтение, запись и исполнение) для трёх групп пользователей (владелец, группа, все остальные). При этом семантика, применения прав к файлам и каталогам несколько расходится. Приведу небольшую таблицу с описанием прав доступа по отношению к файлам/каталогам:

Право	Для файла	Для каталога
Чтение (r или 4)	Чтение содержимого файла.	Просмотр содержимого каталога. Чтение списка файлов и подкаталогов.
Запись (w или 2)	Изменение содержимого файла или удаление файла.	Изменение списка файлов и подкаталогов. В том числе удаление, переименование файлов и подкаталогов.
Исполнение (x или 1)	Исполнение содержимого файла, как соответствующего набора команд.	Вход в каталог и вход в подкаталоги каталога.

Файловый сервер

Общий ресурс только на чтение

Для создания ресурса на чтение, достаточно добавить в smb.conf строки:

[root@files ~]# # определим общий ресурс
[root@files ~]# grep бмен -A4 /etc/samba/smb.conf.comment
[Обменник]
        # путь к каталогу
        path = /shares/obmen
        # комментарий к ресурсу
        comment = Общий ресурс на чтение на сервере Samba
[root@files ~]# # создадим каталог с правами:
[root@files ~]# ls -ld /shares/obmen/
drwxr-xr-x 2 root root 4096 Июл 31 20:07 /shares/obmen/

из листинга видно, что владелец и группа каталога – root и права каталога – rwxr-xr-x. Соответственно, полные права имеет только владелец (rwx) – root, группа же и “остальные” имеют право только на чтение и выполнение (r-xr-x). А т.к., согласно глобальных настроек SAMBA, пользователи у нас мапяться с ID в диапазоне от 10000 до 20000, соответственно, при доступе к файловой системе – пользователь обращается как “остальные”, соответственно имеет права r-x. Скажу даже больше, даже если мы зададим полные права на каталог для всех (chmod a+rwx /shares/obmen), то пользователи не смогут писать в каталог, пока мы в параметрах ресурса SAMBA не зададим данное разрешение.

Общий ресурс на чтение и запись для всех (файлопомойка)

Для организации абсолютной файлопомойки мы можем пойти следующим путем:

[root@files ~]# # зададим полные права "остальным" (rwx)
[root@files ~]# chmod o+rwx /shares/obmen
[root@files ~]# ls -ld /shares/obmen/
drwxr-xrwx 2 root root 4096 Июл 31 20:07 /shares/obmen/
[root@files ~]# # определим возможность записи в каталог в настройках ресурса
[root@files ~]# grep бмен -A6 /etc/samba/smb.conf.comment
[Обменник]
        # путь к каталогу
        path = /shares/obmen
        # комментарий
        comment = Общий ресурс на сервере Samba
        # включает возможность записи
        read only = no
[root@files ~]# testparm -s /etc/samba/smb.conf.comment > /etc/samba/smb.conf
Load smb config files from /etc/samba/smb.conf.comment
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Processing section "[Обменник]"
Loaded services file OK.
WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_DOMAIN_MEMBER
[root@files ~]# service samba restart
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.

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

[root@files ~]# testparm -v -s  /etc/samba/smb.conf.comment | grep mask
        ......
        create mask = 0744
        .......
        directory mask = 0755
        ......

Для файлов – 0744, для каталогов – 755, то есть, при создании файлов – у группы и остальных будут отрезаны биты записи и исполнения, а при создании каталогов – биты записи:

[root@files ~]# ls -laR /shares/obmen/
/shares/obmen/:
итого 12
drwxr-xrwx 3 root       root         4096 Июл 31 20:39 .
drwxr-xr-x 4 root       root         4096 Июл 31 20:07 ..
drwxr-xr-x 3 user1 domain users 4096 Июл 31 20:39 Новая папка

/shares/obmen/Новая папка:
итого 12
drwxr-xr-x 3 user1 domain users 4096 Июл 31 20:39 .
drwxr-xrwx 3 root       root         4096 Июл 31 20:39 ..
drwxr-xr-x 2 user1 domain users 4096 Июл 31 20:39 Новая папка

/shares/obmen/Новая папка/Новая папка:
итого 12
drwxr-xr-x 2 user1 domain users 4096 Июл 31 20:39 .
drwxr-xr-x 3 user1 domain users 4096 Июл 31 20:39 ..
-rwxr--r-- 1 user1 domain users    3 Июл 31 20:39 Новый текстовый документ.txt
-rwxr--r-- 1 user1 domain users    0 Июл 31 20:39 Новый точечный рисунок.bmp

Соответственно, удалить или изменить файл смогут либо сами владельцы файлов, либо root. Чтобы избежать этой проблемы и чтобы все пользователи могли ч/liитать и писать во все файлы, необходимо добавить следующие параметры в описание ресурса:

[root@files ~]# grep бмен -A10 /etc/samba/smb.conf.comment
[Обменник]
        # путь к каталогу
        path = /shares/obmen
        # комментарий
        comment = Общий ресурс на сервере Samba
        # включает возможность записи
        read only = no
        # доступ всем на все
        create mask = 0666
        directory mask = 0777

[root@files ~]# testparm -s /etc/samba/smb.conf.comment > /etc/samba/smb.conf
Load smb config files from /etc/samba/smb.conf.comment
rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)
Processing section "[Обменник]"
Loaded serv5 минутices file OK.
WARNING: You have some share names that are longer than 12 characters.
These may not be accessible to some older clients.
(Eg. Windows9x, WindowsMe, and smbclient prior to Samba 3.0.)
Server role: ROLE_DOMAIN_MEMBER
[root@files ~]# service samba restart
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.

В результате – все могут читать и все могут писать и удалять не зависимо от хозяина файла или каталога.

Общий ресурс только на чтение для определенной группы пользователей

Для создания ресурса на чтение для определенной группы пользователей, необходимо добавить в smb.conf строки:

[root@files ~]# # определим общий ресурс
[root@files ~]# grep Бух -A7 /etc/samba/smb.conf.comment
[Бухгалтерия]
        # путь к каталогу
        path = /shares/buh
        # комментарий
        comment = Каталог отдела Бухгалтерия
        # определим доступ для отдельной группы пользователей
        valid users = @"AD^Бухгалтерия", AD^domain_user
[root@files ~]# # создадим каталог с правами (у группы "остальные должны быть права r-x"):
[root@files ~]# ls -ld /shares/buh/
drwxr-xr-x 2 root root 4096 Июл 31 20:07 /shares/buh/

Параметр valid users определяет какой/им группе/ам пользователей или просто каким пользователям разрешен доступ к данному каталогу. Обратите внимание, что даже когда определен параметр winbind use default domain, требуется указание полного, определенного в домене имени пользователя, например valid users = @”DOMAIN\Domain Group”. Обратите внимание так же на использование двойных кавычек. Символ ^ – возможно у вас будет другой, в зависимости от указанного в глобальном параметре winbind separator. Так же, обращаю ваше внимание, что на каталог, указанный в параметре path разделенного ресурса должны быть права не менее r-x для группы “остальные”, чтобы подключенные пользователи могли читать файлы и просматривать содержимое каталога.

Общий ресурс только на чтение и запись для определенной группы пользователей

Для создания ресурса на чтение и запись для определенной группы пользователей, необходимо добавить в smb.conf строки:

[root@files ~]# # определим общий ресурс
[root@files ~]# grep Бух -A7 /etc/samba/smb.conf.comment
[Бухгалтерия]
        # путь к каталогу
        path = /shares/buh
        # комментарий
        comment = Каталог отдела Бухгалтерия
        # Определим доступ для записи
        read only = no
        # определим доступ для отдельной группы пользователей
        valid users = @"AD^Бухгалтерия", AD^domain_user
        # включить наследование прав доступа
        inherit permissions = Yes
[root@files ~]# # создадим каталог с правами (у группы "остальные должны быть права rwx"):
[root@files ~]# ls -ld /shares/buh/
drwxr-xrwx 2 root root 4096 Июл 31 20:07 /shares/buh/

Как видно, добавился неизвестный нам параметр inherit permissions = Yes, который задает наследовать права доступа к создаваемым файлам и каталогам от родительского. Это сделано опять же по причине того, что каталоги и файлы создаются с маской по-умолчанию.

Дополнительно

Указанные выше способы – это не единственное решение для ресурсов общего доступа для пользователей домена. Можно пойти другими путями, например назначить в файловой системе – группу-владельца каталога, поставить на каталог бит SGID для наследования владельца группы и в описании ресурса ограничиться двумя параметрами: path и read only =no.

Я, например, стараюсь использовать такую схему предоставления доступа к общим ресурсам: я стараюсь ставить права файловой системы на максимум и ограничивать доступ на уровне smb.conf и описания ресурса. То есть, права доступа на файлы у меня rw-rw-rw-, а на каталоги rwxrwxrwx и в описании ресурса я устанавливаю параметр inherit permissions для наследования указанных прав доступа. Либо можно указать параметры create mask = 0666 и directory mask = 0777, чтобы права задавались при создании файлов и каталогов. Ограничение на доступ к ресурсу через smb.conf устанавливаются параметрами valid users, write users и admin users. У этого способа так же есть дополнительный плюс. При необходимости переноса сервера на другую машину. достаточно будет сделать 3 вещи: 1. Перенести содержимое расшаренных ресурсов, 2. Назначить права 666 для файлов и 777 для каталогов и 3. Перенести Файл smb.conf. Без необходимости переноса всех баз SAMBA – tdb и отслеживания соответствия SID и локальных UID/GID.

Так же есть такой финт: в разделе [global] в smb.conf был указан параметр username map = /etc/samba/smbusers. Данный параметр очень удобен, т.к. позволяет присоединить пользователей Windows к локальным пользователям UNIX. Например, можно назначить root’ом Вашего пользователя в домене и управлять всеми общими ресурсами с полными правами:

root@samba:~# cat /etc/samba/smbusers
root = AD^domain_admin

При внесении доменных пользователей в данный файл необходимо указывать полное имя в независимости от параметра winbind use default domain. Так же, возможно указать несколько пользователей или доменную группу разделенные пробелами.

Для сопоставления доменных групп по-умолчанию (т.е. таких как Domain Admins, Domain Users и др, которые создаются в SAMBA автоматом, их еще можно просмотреть командой net groupmap list или getent group) и групп UNIX, необходимо выполнить:

$ net groupmap modify ntgroup="Domain_Group" unixgroup=namegroup

Для сопоставления новых доменных групп и групп UNIX, необходимо выполнить:

$ # добавление новой группы
$ net rpc group add "NewGroup"
$ # сопоставление групп
$ net groupmap modify ntgroup="NewGroup" unixgroup=newunixG

При этом, сопоставление сохраняется в одном из tdb файлов SAMBA.

Но! username map не работает, если в конфиге SAMBA на ресурс задан параметр valid users и пользователь, указанный в файле username map не входит в членов параметра valiud users. Чтобы обойти эту проблему, необходимо указать параметр admin users, который синтаксически аналогичен valid users, и определяет указанному пользователю работать с ресурсом в качестве пользователя root.

Кроме того, можно скрыть ресурс от общих глаз, если поставить параметр browseable = no, то ресурс не будет отображаться в проводнике, когда заходишь на сервер, но по полному пути доступ к нему будет.

Кроме стандартных прав (которых, кстати, вполне достаточно для решения основных задач по организации файлового сервера) функциональность можно расширить с помощью т.н. POSIX ACL, которые позволяют назначить права доступа нескольким владельцам или нескольким группам пользователей на уровне файловой системы.  POSIX ACL ограничены всё теми же правами rwx. Полноценно редактировать права доступа аналогично Windows, например, назначать пользователю право изменения прав безопасности там возможности нет. Про данную технологию я постараюсь написать отдельную статью, а так же дам ссылки в конце – почитать о POSIX ACL.

Сервер печати в домене Active Directory

Для запуска сервера печати на нашем сервере SAMBA в домене Active Directory, необходимо проделать следующие шаги:

1. Установить пакет cups (мне так же необходимо было установить пакет hplip, т.к. используются преимущественно принтеры от HP и пакет smbclient) и настроить сервер печати по вашим нуждам. Как настраивать сервер печати, я писал в статьях Сервер печати на Linux  и Как работает SAMBA ч.2. Поэтому обойдусь только указанием настроек из smb.conf.
2. Добавить нужные принтеры через веб-интерфейс CUPS.
3. Раскомментировать в smb.confпараметры

           # принтеры нам нужны
           printing = CUPS
           cups options = raw
           show add printer wizard = yes

4. Закомментировать параметры в smb.conf:

           # принтеры нам не нужны
           #load printers = no
           #show add printer wizard = no
           #disable spoolss = yes

5. Добавить 2 дополнительных раздела:

   [root@files ~]# grep "\[printers" -A15 /etc/samba/smb.conf.comment
   [printers]
           # опишем принтеры:
           comment = Очередь печати SMB
           # включаем возможность печати
           printable = yes
           # путь к спулеру
           path = /var/spool/samba
   
   [print$]
           # опишем каталог драйверов
           comment = Драйверы принтера
           # каталог драйверов
           path = /var/lib/samba/printers
           # можно писать
           read only = No

6. Перезапустить демонов cups, samba и winbind.
7. Добавить драйверы принтеров, как было описано в статье Как работает SAMBA ч.2 (автоматическая загрузка драйверов). Естественно, загружать драйвер нужно от доменного пользователя, указанного в /etc/samba/smbusers, как root.
8. По вкусу настроить параметры по умолчанию для принтера через каталог “Принтеры и Факсы” на сервере самба, ибо у меня почему-то по-умолчанию устанавливался размер бумаги – Letter.
9. Пользоваться сетевой печатью.

На моем сервере пришлось устанавливать единый драйвер для всех принтеров сети. Это привело к некоторым проблемам при установке драйверов. При этом, 7 шаг у меня немного растянулся и пришлось пользоваться шеллом для назначения драйвера принтеру. Меня спасла команда rpcclient. Об использовании данной команды можно почитать по ссылкам, приведенным в конце статьи. Итого, 7 шаг принял следующую последовательность:

7.1. Добавить драйвер принтера через каталог “Принтеры и факсы на севере files”: ПКМ по пустому месту – Свойства сервера. Вкладка “Драйверы – Добавить”

7.2. Назначение каждому принтеру необходимого драйвера с помощью команды rpcclient, согласно инструкции: http://samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-printing.html#id2644219. Необходимо выполнить шаги 2,3,7-15, т.к. принтеры уже у нас установлены, драйвер тоже уже добавлен на сервер. Основная команда привязки принтера к драйверу выглядела так:

rpcclient localhost -Udomain_admin%password -c /
 'setdriver printer_name "HP Universal Printing PS"'

Полезные команды управления SAMBA в домене AD

$ # отобразить (-L) список расшаренных ресурсов на хосте 10.0.0.11 анонимно (-N)
$ smbclient -N -L 10.0.0.11
$ # подключиться к ресурсу share хоста 10.0.0.11 с логином username и паролем passwd
$ smbclient //10.0.0.11/share -Uusername%passwd
$ # просмотреть содержимое tdb-базы (необходим пакет tdb-tool)
$ tdbdump /var/lib/samba/secrets.tdb
$ # список доменов в сети
$ wbinfo --all-domains
$ # информация о домене DOMAIN
$ wbinfo -D DOMAIN
$ # проверить связь с доменом
$ wbinfo -t

Что почитать

Протокол керберос:
в оригинале: http://web.mit.edu/kerberos/
дополнительно: http://www.oszone.net/4188/Kerberos
Описание файлов TDB SAMBA
http://samba.org/samba/docs/man/Samba-HOWTO-Collection/install.html#tdbdocs
Установка драйверов принтера с помощью утилиты rpcclient в 15 шагов
http://samba.org/samba/docs/man/Samba-HOWTO-Collection/CUPS-printing.html#id2644219
Отдельное спасибо http://wiki.linuxformat.ru/ за некоторую информацию
Главнейший документ о SAMBA: http://samba.org/samba/docs/man/Samba3-HOWTO/
Самба на русском: http://www.samba-doc.ru/
POSIX ACL в оригинале: http://www.suse.de/~agruen/acl/linux-acls/online/

Резюме

Хочу подвести маленький итог сегодняшней статье. Сегодня мы удачно (или неудачно ) интегрировали наш Linux в доменную структуру Active Directory. При этом, организовали файловое хранилище и сервер печати с автоматической загрузкой драйверов для клиентов Windows. В файловом сервере было организовано несколько типовых примеров каталогов общего доступа. Буду очень рад вашим комментариям и дополнениям.

Upd 2011.08.11: добавил параметр socket oprions

С Уважением, Mc.Sim!

---

Теги: Active Directory, CUPS, Debian, kerberos, Linux, Microsoft Windows, network, SAMBA