Собрание статей и заметок преимущественно по администрированию операционных систем Linux и Windows (но не только). Цель - собрать в одном месте полезное и интересное, что то вроде записной книжки. Большая часть скопирована целиком или скомпилирована из найденного в интернете, и я никоим образом не предендую на авторство, которое мне не принадлежит, чукча не писатель, чукча читатель. Некоторые же статейки - написаны мной, в качестве шпаргалок по мотивам прохождения некоторых квестов.
Сегодня хочу рассмотреть сервер 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:
3. Настроим файл /etc/resolv.conf, задав полное имя домена для автоматической подстановки к именам хостов и адреса DNS серверов локальной сети (более подробно об этом файле в статье Настройка сети в Linux):
4. Настроим файл Name Service Switch - /etc/nsswitch.conf для указания в каком порядке NSS осуществляет поиск имен пользователей, паролей, хостов, сетей и т. д. (указаны только модифицированные строки):
Согласно приведенных настроек, при поиске имен пользователей, групп и паролей Linux будет последовательно обращаться к встроенной базе данных (файлам /etc/passwd, /etc/group, /etc/shadow), затем – к демону winbind. При разрешении имени хоста сначала будет использоваться файл /etc/hosts, затем DNS и, в последнюю очередь, служба имен NetBIOS. Это может пригодиться, если в вашей сети есть хосты, не зарегистрированные в DNS, но имеющие имена NetBIOS, к примеру, компьютеры под управлением Windows в составе рабочей группы.
Настройка SAMBA
1. Проверим, поддерживает ли установленный пакет работу с протоколом Kerberos и каталогом LDAP:
Если у вас вывод похож на указанный значит все ок. Если вывод не содержит строчек с надписями 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:
Для синхронизации времени можно использовать, так же команду 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, то имя пользователя необходимо вводить в формате domain_admin@AD.LOCAL. Сообщения выводимые после выполнения команды обозначают следующее:Using short domain name -- AD и Joined 'FILES' to realm 'ad.local' указывают на удачный ввод в домен. Если после выполнения команды не было ошибки Join to domain is not valid, значит скорее всего, ввод в домен произведен успешно.
но тем не менее сервер был включен в домен. В списках рассылки видел, что эта ошибка связана с некорректной работой библиотек отвечающих за 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
Если включение в домен завершилось ошибкой, необходимо:
Проверить настройки DNS на Linux и убедиться, что команда hostname -f выводит корректное FQDN-имя хоста.
Проверить, в состоянии ли утилиты nslookup или dig разрешить имя КД Active Directory в IP.
Проверить, поддерживает ли установленный пакет samba работу с Kerberos и LDAP.
Если вышеуказанные шаги не помогли, можно выполнить тестовое подключение к домену с увеличенным значением 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.
Создав указанный конфиг, при создании каталогов и файлов в разделяемом ресурсе, они будут созданы с владельцем и основной группой, к которой принадлежит создавший объекты владелец, а так же с маской по-умолчанию:
Для файлов - 0744, для каталогов - 755, то есть, при создании файлов - у группы и остальных будут отрезаны биты записи и исполнения, а при создании каталогов - биты записи:
Соответственно, удалить или изменить файл смогут либо сами владельцы файлов, либо root. Чтобы избежать этой проблемы и чтобы все пользователи могли читать и писать во все файлы, необходимо добавить следующие параметры в описание ресурса:
[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'ом Вашего пользователя в домене и управлять всеми общими ресурсами с полными правами:
При внесении доменных пользователей в данный файл необходимо указывать полное имя в независимости от параметра winbind use default domain. Так же, возможно указать несколько пользователей или доменную группу разделенные пробелами.
Для сопоставления групп домена и групп UNIX, необходимо выполнить:
$ net groupmap modify ntgroup="Domain_Group" unixgroup=namegroup
При этом, сопоставление сохраняется в одном из 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, необходимо проделать следующие шаги:
Установить пакет cups (мне так же необходимо было установить пакет hplip, т.к. используются преимущественно принтеры от HP и пакет smbclient) и настроить сервер печати по вашим нуждам. Как настраивать сервер печати, я писал в статьях Сервер печати на Linux и Как работает SAMBA ч.2. Поэтому обойдусь только указанием настроек из smb.conf.
Добавить нужные принтеры через веб-интерфейс CUPS.
Раскомментировать в smb.confпараметры
# принтеры нам нужны
printing = CUPS
cups options = raw
show add printer wizard = yes
Закомментировать параметры в smb.conf:
# принтеры нам не нужны
#load printers = no
#show add printer wizard = no
#disable spoolss = yes
Добавить 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
По вкусу настроить параметры по умолчанию для принтера через каталог "Принтеры и Факсы" на сервере самба, ибо у меня почему-то по-умолчанию устанавливался размер бумаги - Letter.
Пользоваться сетевой печатью.
На моем сервере пришлось устанавливать единый драйвер для всех принтеров сети. Это привело к некоторым проблемам при установке драйверов. При этом, 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, т.к. принтеры уже у нас установлены, драйвер тоже уже добавлен на сервер. Основная команда привязки принтера к драйверу выглядела так:
Отдельное спасибо 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. В файловом сервере было организовано несколько типовых примеров каталогов общего доступа. Буду очень рад вашим комментариям и дополнениям.