Ошибка в работе samba в домене ad – id: username: no such user

Ошибка в работе samba в домене AD — id: username: No such user

Столкнулся на днях с неожиданной ошибкой в samba, на которую потратил пару часов, пока не разобрался, в чем дело. Проблема возникла на файловом сервере linux, включенном в домен Windows. Использовал свою стандартную конфигурацию, но тут она почему-то подвела.

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

В этот раз все то же самое было. У меня имелась система CentOS 6. Добавил ее в домен, как описано в статье, заменив некоторые команды, так как они отличаются в 6-й и 7-й версии. Прошел все проверки, все было на первый взгляд нормально.

Залил файлы, выставил права, стал заходить на шару и удивился, что меня не пускает на нее. Причем странно не пускает. Зайти можно только залогинившись администратором домена, которым я добавлял сервер в домен. Всех остальных пользователей самба не пускала. В логах были следующие ошибки:

receive_smb_raw_talloc failed for client 10.1.4.189 read error = NT_STATUS_CONNECTION_RESET kerberos_kinit_password [email protected] failed: Preauthentication failed

При этом все проверки wbinfo возвращают пользователей, группы, доверительные отношения и прочее. Билетик керберос нормально получается. Файл nsswitch.conf был правильно отредактирован, все как полагается. Не проходила следующая проверка:

# id domainuser id: domainuser: No such user

и getent:

# getent passwd

выводил только локальных пользователей, а должен и доменных.

При этом, если сделать тоже самое с пользователем, под которым я заводил машину в домен, то команда возвращает верные данные о пользователе. Я хорошенько проверил все конфиги, сравнил их с другими серверами. Все как везде, но почему-то не работает. Перезапуски служб и перезагрузка не помогала.

Ответ нашел в интернете, хотя и не разу. Некоторые советы по решению схожих ошибок мне не помогли. А помогло вот что. У меня в конфмге самбы есть такие строки:

idmap config * : range = 10000-20000 idmap config * : backend = tdb

После того, как я их заменил на:

idmap config * : backend = rid idmap config * : range = 5000-10000000 idmap config * : base_rid = 0

Все заработало. Простая смена backend с tdb на rid не помогала, необходимы были дополнительные параметры. Я до конца не стал вникать, что это такое и в чем принципиальная разница. Понял только, что через этот инструмент winbind взаимодействует с утилитами AD. После замены бэкенда все заработало как и должно.

Почему именно здесь проявилась эта ошибка я не понял. Все конфиги специально сверил с еще одним таким же сервером, введенным в этот же домен пол года назад.

Помогла статья? Есть возможность отблагодарить автора

Источник: https://serveradmin.ru/oshibka-v-rabote-samba-v-domene-ad-id-username-no-such-user/

Настройка Samba сервера с авторизацией через Active Directory в Debian

Постановка задачи такая:

Есть в сети сервер, выполняющий функции файлопомойки, под управлением Linux. Помимо сервера в сети есть виндовые машины, которые должны хранить файлы на этом сервере. У каждого пользователя на сервере должна быть личная папка и одна общая для всех пользователей.

Все вроде бы просто — поставил Самбу, наделал пользователей идентичных виндовым и радуйся жизни. Так в принципе оно и было какое-то время, но захотелось перемен — решил немного автоматизировать и упростить администрирование своей файлопомойки, т.к. юзеры растут как грибы и «надо шото делать».

Исходя из этого, было решено построить такую схему:

развернуть АД и прикрутить к нему файлсервер Samba с аутентификацией через Active Directory. При этом, когда пользователь впервые подключается к серверу, автоматически создается личная папка, которая доступна как шара только конкретному пользователю.

С настройкой АД все понятно (скучно). А вот с настройкой Самбы пришлось поиграться. Как сделать это в Debian lenny я и расскажу в данной статье.

Рассчитываем что контроллер домена и ДНС у нас уже настроены.

Winbind — это демон, который позволяет Самбе узнавать пользователей AD и общаться с ними как с локальными.

Kerberos используется для интеграции Samba в Active DIrectory. Открываем его конфиг и подставляем свои параметры (выделил красным):

Проверяем правильность настроек:

domain_user — пользователь с правами входа в домен. Если все правильно — команда завершиться без вывода на экран. У меня все прошло без ошибок, но вот самые распространенные из них:

Неправильный логин или пароль пользователя domain_user.

Стоит проверить правильность конфига и настройки ДНС.

Несоответствие времени на контроллере домена и на нашем сервере. Синхронизировать время с Active Directory можно командой:

Теперь настроим Самбу и Winbind. Мой работающий конфиг ниже, можно просто скопировать его подставив свои данные (выделил красным):

Внимание! Имя домена указывается в верхнем регистре.

Раздел [Homes] и расшаренные папки могут отличаться от указанных. В моем конфиге они настроены в соответствии с требованиями, описанными в начале статьи.

В моем случае smbusers — группа в Active Directory, пользователи которой будут иметь доступ к общей папке и к личным папкам. Что бы домашняя директория создавалась автоматически в /home/samba/имя_пользователя, когда пользователь впервые подключается к серверу Samba, помимо настроек в /etc/samba/smb.conf, нужно прописать также определенную запись в /etc/pam.d/samba:

umask=0077 — соответствует правам доступа 0700.

skel=/etc/samba/skel/ — путь к папке, содержимое которой будет скопировано в созданную директорию.

Далее открываем /etc/nsswitch.conf и редактируем указанные строки:

Рестартуем сервисы:

Вводим компьютер в домен:

domain_user — пользователь домена, у которого достаточно привилегий для присоединения компьютера к домену.

Проверим работу winbindd:

Эти команды должны вывести список пользователей и список групп соответственно.

Что бы проверить воспринимаются ли доменные пользователи как локальные, можно воспользоваться командой:

Должны получить что-то типа:

Вот и все.

Теперь, при подключении к нашему серверу с винды под доменной учетной записью domain_user, мы должны видеть 2 расшаренные папки — «domain_user» и «Public». При этом папка domain_user будет создана в /home/samba если не существовала ранее.

Источник: http://hutpu4.net/linux-open-source/nastrojka-samba-servera-s-avtorizaciej-cherez-active-directory-v-debian.html

Samba в роли контроллера домена Active Directory

В четвертой версии Samba появилась возможность использовать сервер с Linux в качестве контроллера домена. И, хотя это давно перестало быть новостью, я надеюсь, что многим пригодится информация из этой и следующих статей. Итак, сегодня я настрою контроллер домена на Ubuntu Server 16.04 в стандартной конфигурации, а заодно расскажу и покажу, как это сделать.

Установка пакетов

Одной только Samba нам будет недостаточно. Для аутентификации пользователей понадобится Kerberos, о котором уже говорилось ранее, для синхронизации времени — NTP, для управления правами доступа — ACL (система, многим известная как «виндовые галочки»).

Если в сети присутствуют принтеры, которыми нужно управлять удаленно, придется установить и настроить СUPS. Samba 4 содержит встроенный DNS с ограниченной функциональностью, поэтому я буду использовать именно его.

Если требуется полноценный DNS-сервер, добавьте в список BIND.

Устанавливаем минимальный набор, необходимый для нашей задачи:

sudo apt install samba samba-tool krb5-user ntp aclПакет acl, вероятно, уже установлен у вас в системе, поскольку он входит в стандартный набор Ubuntu 16.04, 16.10 и 17.04. Весьма вероятно, что он никуда не денется и в следующих версиях.

Kerberos попросит указать область по умолчанию. Можно оставить поля пустыми, позже мы все равно получим сгенерированный автоматически конфиг Kerberos.

Настройка Samba и Kerberos

Для формирования файла /etc/samba/smb.conf воспользуемся утилитой samba-tool. То же самое в случае необходимости можно сделать и вручную, просто вписав соответствующие строки.

Для начала переименуем стандартный smb.conf, чтобы позволить samba-tool создать для нас новый.

sudo mv /etc/samba/smb.conf /etc/samba/smb.conf.old

Базовый вариант команды для формирования конфига Samba в роли контроллера домена выглядит так:

sudo samba-tool domain provision –use-rfc2307 –interactiveСюда могут быть добавлены дополнительные параметры, но о самом необходимом нас и без того спросят. Кроме того, в случае проблем вы можете сделать логи более подробными, добавив ключ -d и число от 0 до 10. Значение по умолчанию — 1.

Теперь вам нужно лишь вводить данные в ответ на соответствующие запросы. В квадратных скобках указывается значение по умолчанию, если оно подходит, достаточно просто нажать Enter.

Realm	полное_имя_домена
Domain	короткое_имя_домена
Server Role	оставляем по умолчанию (dc)
DNS Backend	если не планируется отдельный DNS-сервер, оставьте SAMBA_INTERNAL
DNS Forwarder IP Adress

Источник: http://www.linuxrussia.com/samba-as-domain-controller.html

Файловый сервер Samba в домене FreeIPA

Продолжение разговора об импортозамещении. В предыдущих статьях мы рассматривали вопрос о создании домена на основе FreeIPA и настривали доверительные отношения между доменами FreeIPA и Active Directory. Но импортозамещение не ограничивается только заменой Active Directory и MS Exchange.

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

В этой статье пойдет речь о создании файлового сервера на основе Samba и его связи с доменами FreeIPA и Active Directory (невозможно же сразу переехать на новый домен – некоторое время части пользователей придется работать в домене от MS и им необходимо предоставить доступ на ресурсы, управляемые FreeIPA).

На начало работ мы имеем:

Установленный и настроенный контроллер домена FreeIPA

Имя ПК – dc.rpn.loc
IP адрес – 192.168.20.105
Realm – RPN.LOC

Установленный и настроенный контроллер домена MS Active Directory

Имя ПК – dcwin.win.loc
IP адрес – 192.168.20.199
Имя домена – WIN.LOC

Между долменами настроены транзитивные доверительные отношения уровня леса. Т.е. пользователи обоих доменов могут получать доступ на ресурсы другого домена.

Все работы будут проводиться на ОС Rosa Cobalt (он же CentOS 7, RedHat 7)

Установка файлового сервера

Входные данные:

Имя ПК – fs.rpn.loc
IP адрес – 192.168.20.198

Устанавливаем ОС в режиме минимальной установки.
Добавляем необходимые пакеты:# yum install ipa-client ipa-server-trust-ad sssd-libwbclient samba samba-client
Вносим изменения в файл /etc/hosts (т.е. добавляем данные вновь установленного файлового сервера)192.168.20.198 fs.rpn.loc fs
Добавляем сервер в качестве рядового сервера в домен FreeIPA# ipa-client-install –mkhomedir
Добавляем правила в локальный файервол:# firewall-cmd –permanent –add-service=samba # firewall-cmd –reload
Добавляем правило для работы Samba в Selinux (если не отключили ранее и планируем использовать):setsebool -P samba_enable_home_dirs on &

Настраиваем контроллер FreeIPA для работы с файловым сервером

Переходим в консоль сервера FreeIPA и производим следующие действия:

Добавляем сервис cifs для работы Samba:# ipa service-add cifs/fs.rpn.loc
Разрешаем серверу Samba читать пароли:# ipa permission-add “CIFS server can read user passwords” –attrs={ipaNTHash,ipaNTSecurityIdentifier} –type=user –right={read,search,compare} –bindtype=permission # ipa privilege-add “CIFS server privilege” # ipa privilege-add-permission “CIFS server privilege” –permission=”CIFS server can read user passwords” # ipa role-add “CIFS server” # ipa role-add-privilege “CIFS server” –privilege=”CIFS server privilege” # ipa role-add-member “CIFS server” –services=cifs/fs.rpn.loc

Настраиваем Samba для авторизации в домене FreeIPA

Переходим в консоль файлового сервера и производим следующие действия:

Извлекаем keytab на сервер samba.# kinit -kt /etc/krb5.keytab # ipa-getkeytab -s dc.rpn.loc -p cifs/fs.rpn.loc -k /etc/samba/samba.keytab
Проверяем, может ли файловый сервер читать атрибуты пользователя в домене FreeIPA:# kinit admin # ldapsearch -Y gssapi “(uid=username)”
Если пользователь сгенерировал новый пароль с момента установки adtrust, даже администратор не может видеть атрибут ipaNTHash.
Чтобы подтвердить, что служба samba может читать ipaNTHash, используем ее keytab и находим этот атрибут.# kdestroy -A # kinit -kt /etc/samba/samba.keytab cifs/fs.rpn.loc # ldapsearch -Y gssapi “(ipaNTHash=*)” ipaNTHash
Создаем (вносим изменения) в файл /etc/samba.smb.conf. В итоге этот файл должен выглядеть примерно так:[global] debug pid = yes realm = RPN.LOC workgroup = RPN domain master = No domain logons = Yes ldap suffix = dc=rpn,dc=loc ldap group suffix = cn=groups,cn=accounts ldap user suffix = cn=users,cn=accounts ldap machine suffix = cn=computers,cn=accounts ldap admin dn = cn=Directory Manager ldap ssl = off log file = /var/log/samba/log.%m max log size = 100000 domain logons = Yes registry shares = Yes disable spoolss = Yes dedicated keytab file = FILE:/etc/samba/samba.keytab kerberos method = dedicated keytab #passdb backend = ipasam:ldapi://%2fvar%2frun%2fslapd-RPN-LOC.socket #passdb backend = ldapsam:ldapi://%2fvar%2frun%2fslapd-RPN-LOC.socket passdb backend = ipasam:”ldap://dc.rpn.loc” security = ads create krb5 conf = No rpc_daemon:lsasd = fork rpc_daemon:epmd = fork rpc_server:tcpip = yes rpc_server:netlogon = external rpc_server:samr = external rpc_server:lsasd = external rpc_server:lsass = external rpc_server:lsarpc = external rpc_server:epmapper = external ldapsam:trusted = yes idmap config * : backend = tdb [homes] comment = Home Directories valid users = %S, %D%w%S browseable = No read only = No inherit acls = Yes [FS_Share] comment = Test share on FS server path = /opt/share writeable = yes browseable = yes valid users = @admins # Разрешаем группе “admins” из домена FreeIPA доступ к ресурсу write list = @admins # Разрешаем группе “admins” из домена FreeIPA доступ с правом записи к ресурсу guest ok = No inherit acls = Yes create mask = 0660 directory mask = 0770
Проверяем конфигурацию с помощью команды testparm
Запускаем Samba и добавляем в автозапуск:# systemctl start smb # systemctl enable smb

Проверка доступа к общему ресурсу

Переходим в консоль любого ПК, входящего в наш домен FreeIPA. На нем должен быть установлен пакет samba-client. Проверяем доступ к общему ресурсу с автоизацией по kerberos:

$ kinit admin $ smbclient -k //fs.rpn.loc/FS_Share

Если все нормально, то мы получаем доступ и видим содержание общего каталога:

lp_load_ex: changing to config backend registry Domain=[RPN] OS=[Windows 6.1] Server=[Samba 4.4.4] smb: > ls . D 0 Tue Dec 26 16:24:47 2017 .. D 0 Mon Dec 25 12:21:13 2017 111 D 0 Tue Dec 26 12:05:02 2017 222 D 0 Tue Dec 26 12:13:04 2017 333 D 0 Tue Dec 26 12:36:10 2017 444 D 0 Tue Dec 26 12:36:55 2017 555 D 0 Tue Dec 26 12:49:43 2017 666 D 0 Tue Dec 26 12:51:21 2017 777 D 0 Tue Dec 26 16:22:12 2017 888 D 0 Wed Dec 27 09:56:20 2017 18855936 blocks of size 1024. 17173020 blocks available smb: >

Для доступа с ПК под управлением Windows открываем File Explorer и в строке адреса вводим: \fs.rpn.locFS_Share

Важно: при подключении в данной конфигурации обязательно использовать полное имя ПК, а не IP адрес.
Подключение может осуществить любой клиент в домене или в домене с которым настроены доверительные отношения.

Доступ к общему ресурсу пользователям из доверенного домена

Доступ к общему ресурсу возможно получить из ПК, находящегося в довереннолм домене. Необходимо только ввести имя и пароль пользователя из домена FreeIPA, которому разрешен доступ. Но это не удобно и зачастую на практике неприемлимо.
Настроим разрешение на доступ пользователям из доверенного домена Active Directory.

В Active Directory есть группа пользователей “WinUsers”, которым необходимо предоставить доступ к общему ресурсу Samba. Для этого:

Открываем в браузере консоль управления сервером FreeIPA.
Создаем группу trust-fs-users для связи с доверенным доменом. Тип группы – внешняя
Открываем свойства созданной группы. Переходим на вкладку “External” и нажимаем кнопку “Добавить”.
Задаем имя группы в домене Active Directory:
Переходим в раздел групп и создаем POSIX группу “fs-users” для доступа файловому ресурсу:
Нажимаем “Добавить и редактировать” и добавляем ранее созданную внешнюю группу:
Далее в файл /etc/samba/smb.conf в раздел описания общего ресурса добавляем имя созданной POSIX группы:[FS_Share] comment = Test share on FS server path = /opt/share writeable = yes browseable = yes valid users = @admins @fs-users write list = @admins @fs-users guest ok = No inherit acls = Yes create mask = 0660 directory mask = 0770
Перезапускаем сервис Samba:# systemctl restart smb

В итоге мы получили на файловом сервере общий ресурс, к которому имеют доступ с прозрачной авторизацией как пользователи из домена FreeIPA, так и из доверенного домена Active Directory. Остается только настроить права доступа разным группам на уровне файловой системы.

Прочитано 1058 раз Последнее изменение Четверг, 28 декабря 2017 11:56

Источник: https://www.arus.ru/index.php/component/k2/item/10557-fajlovyj-server-samba-v-domene-freeipa

Управление доступом к файловым серверам Samba в домене Windows на базе AD

Мы продолжаем серию статей про взаимодействие Linux и Windows. Эта статья посвящена управлению доступом к серверам Samba из домена AD.

В отличие от предыдущих статей, где в качестве примера использовалась тестовая сеть, эта статья базируется на реальной, «боевой» сети Московского энергетического института. В сети МЭИ зарегистрировано около 25000 пользователей.

Сеть объединяет все учебные корпуса МЭИ с более чем 4500 рабочими станциями.

Мы рассмотрим настройку доступа к серверу Samba, предоставляющему пользователям следующие услуги: •доступ к персональному каталогу пользователя; •доступ к общим каталогам;

•управление доступом как с использованием средств Samba, так и с использованием средств Windows.

Про сеть МЭИ

Информационно-вычислительная сеть Московского энергетического института (ИВС МЭИ) использует доменную структуру Windows на базе AD. Наша сеть поддерживает несколько доменов. Доменом верхнего уровня является домен mpei.local. Домен public.mpei.local предназначен для пользователей МЭИ, домен init.mpei.

local предназначен для сотрудников Информационно-вычислительного центра МЭИ. Сервер, который мы настраиваем, представляет собой кластерное файловое хранилище и предназначен для размещения каталогов пользователей — сотрудников ИВЦ МЭИ и сотрудников МЭИ (пользователи домена INIT и PUBLIC) и общих каталогов.

Операционная система сервера — Ubuntu Linux 12.04 LTS.

•Backups Предназначен для хранения резервных копий. Доступ к каталогу имеют администраторы доменов.

•Каталоги ISOs и Software Предназначены для хранения образов дисков дистрибутивов операционных систем и другого программного обеспечения, используемого в ИВС МЭИ. Информация, размещенная в этих каталогах, доступна всем пользователям, но запись разрешена только администраторам доменов.
•Каталог VMImages Предназначен для хранения образов виртуальных машин, применяемых в ИВС МЭИ. Этот каталог доступен всем пользователям, запись разрешена только администраторам доменов.
•Каталоги пользователей Предназначены для размещения файлов пользователей.

Кластерное файловое хранилище создано на основе распределенного объектового хранилища и файловой системы Ceph. Более подробно о Ceph можно прочесть на сайте проекта — www.ceph.com. В состав хранилища входят три сервера, которые одновременно являются хранилищами объектов и управляют размещением данных.

Доступ к файловой системе хранилища осуществляется через шлюз, который является клиентом хранилища Ceph с одной стороны, а с другой — предоставляет доступ к этому хранилищу через Samba. Шлюзовая машина представляет собой виртуальную машину на базе KVM, работающую на серверах с Ceph. Именно эта шлюзовая машина и будет тем сервером, который мы настраиваем для организации доступа.

Операционная система — тоже Ubuntu Linux 12.04 LTS. Наш сервер называется filer.mpei.local.

Способ организации кластерного файлового хранилища не является определяющим для решения задачи управления доступом. Для создания такого хранилища могут быть использованы самые различные технологии и их реализации.

Необходимо отметить, что в нашей сети зарегистрировано большое количество пользователей — около 25000. Поэтому создание каталогов для них является весьма трудоемкой задачей. При этом далеко не все пользователи будут иметь свои каталоги на файловом хранилище.

Отсюда следует, что создание каталогов должно производиться автоматически, при первом соединении пользователя с сервером.

Способ автоматического создания каталогов пользователей при использовании командной оболочки Linux рассматривался ранее в статье про настройку CentOS.

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

Способ включения сервера Samba на базе Ubuntu Linux уже рассматривался раньше. Мы включаем наш сервер в домен верхнего уровня mpei.local. Для авторизации пользователей мы будем использовать winbind.

Поскольку у нас используется несколько доменов, то целесообразно в разделе глобальной конфигурации Samba в файле smb.conf указать:

winbind use default domain = no

Отключив эту опцию, мы поясняем Samba, что пользователи без указания доменного имени будут рассматриваться как локальные пользователи сервера, а для остальных случаев необходимо указывать доменное имя. Это необходимо сделать, поскольку пользователи могут иметь совпадающие имена в различных доменах.

При правильном включении сервера filer в домен в ответ на запрос getent passwd мы должны увидеть список пользователей всех доменов, а в ответ на запрос getent group — список групп всех доменов. Если это не так, следует проверить содержимое файла /etc/nsswitch.conf, который должен выглядеть так:

root@filer:~# cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc “Name Service Switch”' for information about this file. passwd: compat winbind
group: compat winbind
shadow: compat
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
root@filer:~#

Следует проверить, как авторизуются пользователи Samba. Для этого посмотрим содержимое файла /etc/pam.d/samba:

root@filer:~# cat /etc/pam.d/samba
@include common-auth
@include common-account
@include common-session-noninteractive
root@filer:~#

Как видно, файл очень простой и состоит из ссылок на файлы /etc/pam.d/common-auth, /etc/pam.d/common-account и /etc/pam.d/common-session-noninteractive.
Соответственно, следует проверить и содержимое этих файлов, на предмет использования ими модуля pam_winbind.so.

В подавляющем большинстве случаев нет необходимости править содержимое файлов системы PAM, расположенных в /etc/pam.d. Но у нас есть требование автоматического создания каталогов пользователей при первом входе в систему. Для нашей конфигурации в файл /etc/pam.

Читайте также: Бэкап всех баз mysql в отдельные файлы

d/common-session-noninteractive нужно добавить строку

session required pam_mkhomedir.so skel=/etc/skel umask=0077

Можно включить эту строку и в файл /etc/pam.d/common-session. Наличие этой строки вызывает модуль pam_mkhomedir.so (более подробно можно прочесть на http://manpages.ubuntu.com/manpages/maverick/man8/pam_mkhomedir.8.

html или http://www.ibm.com/developerworks/ru/library/l-pam/index.html) для автоматического создания домашнего каталога пользователя при входе в систему.

В результате вывод команды getent passwd должен выглядеть примерно так:

PUBLICkhorkov:*:28972:10007:Хорьков Сергей Николаевич:/ceph/home/PUBLIC/khorko :/bin/bash

Поля соответствуют полям файла /etc/passwd, стандартного места хранения данных о пользователях в системах Linux и Unix.

Поля именуются так: •login name •optional encrypted password •numerical user ID •numerical group ID •user name or comment field •user home directory •optional user command interpreter При подключении к домену Windows на базе AD поле login name представляет собой комбинацию имени домена и имени пользователя, где разделителем является либо обратный слэш (), либо символ, определенный в опции winbind separator. Поле password представляется символом *, что означает внешний источник паролей.

Значения полей UID и GID формируются на основе опций idmap uid и idmap gid (или idmap config) файла конфигурации Samba.

Поле user home directory формируется на основе опции template homedir файла конфигурации Samba. А поле user command interpreter — на основе значения опции template shell файла конфигурации Samba.

На основании этого вывода мы можем сказать, что домашний каталог для пользователя khorkov в домене PUBLIC будет /ceph/home/PUBLIC/khorkov. Именно этот каталог и должен автоматически создаваться. Таким образом, наш файл /etc/samba/smb.conf в разделах global и homes выглядит следующим образом:

[global] log file = /var/log/samba/log.%m obey pam restrictions = yes map to guest = bad user encrypt passwords = true dns proxy = no netbios name = Filer server string = %h server (Samba, Ubuntu) unix password sync = yes workgroup = MPEILOCAL os level = 20 security = ads syslog = 4 panic action = /usr/share/samba/panic-action %d usershare allow guests = yes max log size = 1000 pam password change = yes realm = MPEI.LOCAL idmap uid = 10000-50000 idmap gid = 10000-50000 template shell = /bin/bash template homedir = /ceph/home/%D/%U winbind enum groups = yes winbind enum users = yes winbind refresh tickets = yes acl compatibility = auto map acl inherit = yes usershare path = /var/lib/samba/usershares
[homes] comment = Home Directories browseable = no path = /ceph/home/%D/%U read only = no create mask = 0700 directory mask = 0700 valid users = PUBLIC%S INIT%S

Большая часть параметров уже рассматривалась в предыдущих статьях (например, http://habrahabr.ru/post/171057/ или http://habrahabr.ru/post/143190/). Остановимся подробнее на тех опциях, которые имеют значение для безопасности и управления доступом.

Опция obey pam restrictions = yes дает директиву серверу Samba подчиняться указаниям, изложенным в директивах pam для учетных записей пользователей и сессий. В нашем случае — мы согласны с командой на создание домашнего каталога.

Опции acl compatibility = auto и map acl inherit = yes разрешают серверу Samba устанавливать режим совместимости списков доступа к файлам и наследование списков доступа. Эти параметры имеют важное значения для поддержки Samba управления доступом от Windows-клиентов.

Для корректной работы необходимо, чтобы файловая система, на которой размещен разделяемый ресурс Samba, поддерживала POSIX ACL. Для этого необходимо установить соответствующие пакеты в Linux (для Ubuntu это acl и attr).

Далее, в секции [homes] определяются каталоги пользователей. Путь к каталогам определяется опцией path. В файле конфигурации Samba действуют правила подстановки.

В частности, %D заменяется на краткое имя домена, %U — на имя пользователя, %S — на имя сессии (совпадает с именем пользователя). Доступ к каталогам определяется для чтения-записи, о чем говорит опция read only = no.

Опция valid users описывает список пользователей, которым разрешен доступ (регистрация) к этому каталогу. Важное значение имеют опции create mask (маска прав при создании файла) и directory mask (права при создании каталога).

В любом случае владельцем домашнего каталога, создаваемых файлов и каталогов будет пользователь, соединившийся с ресурсом. При этом uid и gid пользователя определяются в соответствии с результатом команды getent passwd.

Учтите, что в 99% случаев имя группы будет Domain users. Указанные значения 0700 дают пользователю полные права на доступ к файлам или каталогам и запрещают доступ всем остальным (в том числе и группе).

Для разрешения доступа группе на чтение третий октет должен быть равен либо 4 (чтение), либо 5 (чтение и исполнение). Об определении прав доступа в Linux можно прочесть в любой книге по этой операционной системе.

Значения опции valid users ограничивает список пользователей, имеющих доступ к каталогу, пользователями доменов INIT и PUBLIC.

Теперь перейдем к настройкам общих каталогов на примере настройки каталога Software:

[Software] browseable = yes comment = Various soft read only = yes valid users = MPEILOCAL%U PUBLIC%U INIT%U path = /ceph/data/Software inherit acls = yes inherit owner = yes inherit permissions = yes map acl inherit = yes nt acl support = yes write list = @”MPEILOCALenterprise admins” @”PUBLICDomain admins” @”IN
ITDomain admins” PUBLICkhorkov admin users = PUBLICkhorkov hide unreadable = yes

Описание пути к разделяемому каталогу и ограничения для пользователей мы уже рассматривали. Опция nt acl support = yes дает директиву Samba отображать права доступа Windows на права доступа Linux.

Опции inherit acls = yes, inherit owner = yes, inherit permissions = yes и map acl inherit = yes указывает на поддержку Samba наследования прав и списков доступа. Опция hide unreadable = yes скрывает от пользователя нечитаемые каталоги и файлы.
Опция admin users задает список пользователей, имеющих административные права (права суперпользователя).

Опция write list задает список пользователей, имеющих права записи в этот каталог. При создании каталога следует определить его принадлежность. Большей частью достаточно владельцем назначить root, а группу определить как Domain users (в нашем случае — как MPEILOCALDomain users).

Списки пользователей могут задаваться как в виде DOMAINuser (пользователи домена), так и в виде user (пользователи самого сервера). Можно задавать их и в виде наименований групп, предваряя имя группы символом @. В списке поля разделяются пробелами. Имена групп Windows, в случае, когда они состоят из более чем одного слова, следует заключать в кавычки.

В нашем примере мы дали разрешение на чтение каталога Software всем пользователям доменов MPEILOCAL, INIT и PUBLIC, а право на запись — для администраторов доменов. Остальные каталоги (Backups, ISOs и VMimages) настраиваются аналогично вышеприведенному примеру.

Подключимся к серверу filer (рис. 1).

Рис. 1. Доступ к серверу Samba.

Проверим доступ к домашнему каталогу (рис. 2).

Рис. 2. Доступ к домашнему каталогу.

Можно проверить права доступа на создание и удаление файлов и каталогов. Домашний каталог с точки зрения Linux выглядит следующим образом:

root@filer:~#
root@filer:~# ls -l /ceph/home/PUBLIC/khorkov
total 0
drwx—— 1 PUBLICkhorkov PUBLICdomain users 45360157 Oct 11 19:36 For Cisco
root@filer:~#

Как видим, права на любые действия с файлами принадлежат только владельцу. Если сейчас попытаться внести изменения в настройки доступа средствами Windows, то мы получим ошибку о запрете записи (рис. 3).

Рис. 3. Ошибка задания прав.

Эта ошибка задания прав на каталог, к которому пользователь имеет все права, возникает потому, что файловая система, где размещен каталог, не поддерживает списки доступа. На файловой системе с поддержкой списков доступа такой ошибки не возникает. Проверить наличие этой поддержки можно командой:

root@filer:~# tune2fs -l /dev/sda1
tune2fs 1.42 (29-Nov-2011)
Filesystem volume name:
Last mounted on: /
Filesystem UUID: e4136579-9486-4e54-a8cf-6b28d4015e92
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux

Здесь мы видим, что файловая система на устройстве /dev/sda1 поддерживает управление доступом. Включение поддержки acl возможно при монтировании файловой системы Linux, либо через утилиту tune2fs.

Список файловых систем, поддерживающих acl, можно узнать в справочном руководстве (man) по команде mount в разделе FILESYSTEM SPECIFIC MOUNT OPTIONS.

Можно посмотреть и сами списки доступа, командой

root@filer:~# getfacl /srv
getfacl: Removing leading '/' from absolute path names
# file: srv
# owner: root
# group: root
user::rwx
user:MPEILOCAL134horkovsn:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:MPEILOCAL134horkovsn:rwx
default:group::—
default:mask::rwx
default:other::— root@filer:~#

Для задания списков доступа из командной строки Linux можно воспользоваться командой setfacl или командой smbcacls. Правда, интерфейс этих команд достаточно сложный, и целесообразнее использовать окно настроек доступа Windows.

Мы предоставляли управление доступом к серверу Samba в основном через редактирование файла /etc/samba/smb.conf. Это один из самых простых и эффективных способов. Существует масса графических приложений для настройки Samba, поставляемых вместе с дистрибутивом Linux.

Можно также использовать web-средства управления, такие как swat или webmin. Достоинством swat, например, является встроенная документация — не нужно постоянно переключаться между настройками и справочным руководством.

Но и swat, и webmin грешат ошибками в настройках.

Заключение

Таким образом, мы успешно выполнили задачу по настройке доступа к файловому серверу Samba в домене Windows на базе AD.

Работа выполнена на базе Информационно-вычислительного центра МЭИ.

Мы будем рады вашим замечаниям и предложениям. У нас есть возможности собрать тестовую сеть, на которой отладить различные варианты и конфигурации систем для обеспечения их взаимодействия.

Источник: http://www.pvsm.ru/linux/29666

[Active Directory] Ubuntu в домене Windows AD | Сисодминиум

Некоторое время назад на работе достался мне для работы ноутбук HP ProBook 6460b. Ну и пришла в голову идея поставить на него вместо надоевшей Windows 7 Pro давно понравившуюся мне Ubuntu 14.04 Trusty LTS.

Выбор операционной системы связан с тем, что Ubuntu я использую на домашнем ноутбуке и мне захотелось иметь такую же систему на рабочем компьютере.

Потому, что постоянное переключение между ОСями дома и на работе быстро надоело мне и я решился на установку Ubuntu на рабочем ноуте. Начну по порядку.

Процесс установки Убунты на ноутбук не буду пересказывать потому, что не вижу в этом смысла из-за большого количества таких мануалов на просторах интернета. Скажу только то, что устанавливал с флешки, а образ на флешку писал на рабочем ноутбуке под Windows 7 Pro с помощью программы Rufus. Хватит про установку, перейдем к процессу введения в домен.

При вводе в домен Windows я пользовался стандартной инструкцией по вводу в домен. В процессе ввода в домен возникали проблемы самого разного характера (в основном связанные с моей невнимательностью и легкой кривизной рук 🙂 ). Да инструкция на русском языке есть и она довольно хороша, но я все же пользовался не только этой инструкцией, но и другими подсказками с прочих сайтов и форумов. Поэтому я решил собрать из всех одну свою.
Первое что необходимо сделать это — правильно и вполне логично! — обновиться:

Далее нас потребуется установить клиенты Kerberos, Samba и Winbind для нормальной и адекватной работы в домене Windows. Сделать это можно одной командой:

Лично я пробовал два варианта установки: первый — как указано выше — установка всех необходимых пакетов одной строкой, и второй — установка каждого паке в отдельности. Честно признаюсь, что меня больше устроил и больше понравился вариант отдельной установки каждого пакета.

Поясню это тем, что при комплексной установке у меня начальная настройка пакета Kerberos не происходила, и я решил (точнее не решил, а мне пришлось из-за кривизны рук и невнимательности переустанавливать полностью Ubuntu и соответственно все необходимые пакеты) ставить все пакеты по отдельности в вышеуказанном порядке.

Это дало свои плоды. На этапе установки пакеты Kerberos произошла его полная настройка где указывались все необходимые параметры для работы в домене (собственно сам домен, необходимые для авторизации DC, рабочие группы или зоны). Далее я поставил Самбу и Винбинд с которыми каких-либо заморочек не было.

Так же я установил указанные желательными библиотеки libpam-krb5, libpam-winbind и libnss-winbind. Их я устанавливал одной командой, т.к. они не требуют никаких ручных настроек и просто желательно их присутствие в системе.

Для простоты и дальнейшей ясности процесса будем считать нашим доменом по умолчанию DOMAIN.RU, доменконтроллером которого будет first.domain.ru с ip-адресом 192.168.1.2. Он же будет нашим первичным DNS сервером домена.

Коме того представим в нашем домене еще один доменконтроллер second.domain.ru с ip-адресом 192.168.1.3. Ну и компьютер наш будет называться work-ubuntu.

Настройка DNS

Для начала необходимо изменить настройки DNS на вашей машине, прописав в качестве DNS сервера доменконтроллер и в качестве домена поиска — нужный домен.
Если у вас статический IP-адрес, то в Ubuntu Desktop это можно сделать через Network Manager, в Ubuntu Server необходимо изменить содержимое файла /etc/resolv.conf на примерно такое:

В современных дистрибутивах файл resolv.conf создается автоматически и править вручную его не нужно. Для получение нужного результата нужно добавить необходимые изменения в файл: /etc/resolvconf/resolv.conf.d/head Данные которые будут добавлены в него, будут автоматически вставлены в файл /etc/resolv.conf.

Если IP-адрес динамический и присваивается DHCP сервером то после перезагрузки resolv.conf может формироваться «неправильный» resolv.conf, например присутствует только один nameserver 192.168.1.1 и не указаны domain и search. Нужно отредактировать /etc/dhcp/dhclient.conf.

Чтобы появились записи domain и search нужно убрать комментарий перед строкой supersede domain-name, и вписать свой домен:

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

Теперь необходимо проверить файл /etc/hostname и убедиться в том, что мы правильно задали имя нашего ноутбука.

Кроме всего прочего необходимо отредактировать файл /etc/hosts так, чтобы в нем была запись с полным доменным именем и обязательно с коротким именем. У меня получился такой формат:

Сразу необходимо проверить, что наш контроллер домена пингуется нормально по короткому и по полному доменному именам:

Не обязательно конечно, но как говорится в инструкции «желательно» при внесении каких-либо изменений делать перезагрузку. Лично я так и делал.

Настройка синхронизации времени

Тут собственно говоря ничего сложного! Я просто единожды выполнил команду:

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

Собственно переходим к самому основному: настройка авторизации через Kerberos

Настройка авторизации по протоколу Kerberos осуществляется простым редактированием файла /etc/krb5.conf. Вот примерный его вид:

Вы естественно указываете вместо DOMAIN.RU и first свои домен и контроллер домена. Особое внимание обращаю на соблюдение регистра — все что написано в верхнем регистре пишется в верхнем регистре!

Это конечно далеко не все, что настраивается но уже сейчас возможно проверить способность авторизации в домене. Для этого достаточно выполнить команду:

Вместо vasya и DOMAIN.RU вы так же указываете свои имя пользователя и домен. Команда так же регистрозависима! Если вы после выполнения данной команды получаете завпрос на ввод пароля от указанного пользователя и не получаете никаких ошибок, значит у вас все прекрасно. В противном случае еще раз перепроверьте все измененные вами файлы на правильность (внимательно изменяйте все ваши файлы).

Убедиться в том, что билет получен, можно с помощью команды:

Будем считать, что авторизация вы настроили и билет получен. Теперь настроим вход в домен.

Настройка Samba и вход в домен

Для того, чтобы войти в домен, необходимо прописать правильные настройки в файле /etc/samba/smb.conf. На данном этапе нас интересуют только некоторые параметры секции [global]. Вот примерный вариант файла:

Теперь необходимо проверить внесенные изменения на правильность (точнее себя на внимательность и руки на кривость 🙂 ) следующей командой:

В случае правильного изменения файла /etc/samba/smb.conf вы увидите примерно следующее:

Данное сообщение известит вас о том, что вы правильно внесли все изменения и настала пора наконец-таки осуществить вход в домен. Для этого необходимо выполнить следующую команду:

В случае успешного входа вы увидите на экране примерно следующее:

Я снова не стану описывать все возможные ошибки, потому что и ежу понятно, что если появились ошибки значит ты сделал что-то не так. Поэтому скажу только одно: RTFM friend!

На данном этапе вы можете установить себе smbclient

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

Вы должны будете увидеть список доступных ресурсов на доменконтроллере

Переходим к настройке Winbin

Если вам необходимо работать с пользователями домена, например, настраивать SMB-шары с разграничением доступа, то вам понадобится кроме самой Samba ещё и Winbind — специальный демон, служащий для связи локальной системы управления пользователями и группами Linux с сервером Active Directory. Проще говоря Winbind нужен, если вы хотите видеть пользователей домена на своём компьютере с Ubuntu.

Winbind позволяет спроецировать всех пользователей и все группы AD в вашу Linux систему, присвоив им ID из заданного диапазона. Таким образом вы сможете назначать пользователей домена владельцами папок и файлов на вашем компьютере и выполнять любые другие операции, завязанные на пользователей и группы.

Для настройки Winbind используется всё тот же файл /etc/samba/smb.conf. Добавьте в секцию [global] следующие строки:

Строки с параметрами idmap config указаны с новыми параметрами не характерными для старых версий Samba, поэтому на данном этапе будьте внимательнее. Старый формат этих строк можно посмотреть в официальной инструкции по вводу в домен.

Теперь вам необходимо перезапустить демон Winbind и Samba. Для этого соблюдая порядок команд, выполните их поочередно:

Запускаем:

Смотрим есть ли ошибки или предупреждения, если появится: «rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)», то отредактировать файл /etc/security/limits.conf:

После перезапуска проверьте, что Winbind установил доверительные отношения с AD командой

А так же, что Winbind увидел пользователей и группы из AD командами:

Эти две команды должны выдать список пользователей и групп из домена соответственно. Либо с префиксом DOMAIN, либо без него — в зависимости от того, какое значение вы указали параметру «winbind use default domain» в /etc/samba/smb.conf.

Итак, Winbind работает, однако в систему он еще не интегрировал.

Добавление Winbind в качестве источника пользователей и групп

Для того, чтобы ваша Ubuntu прозрачно работала с пользователями домена, в частности, чтобы вы могли назначать пользователей домена владельцами папок и файлов, необходимо указать Ubuntu использовать Winbind как дополнительный источник информации о пользователях и группах.

Для этого измените две строчки в файле /etc/nsswitch.conf:

добавив к ним в конце winbind:

Так же рекомендую привести строку hosts: в файле /etc/nsswitch.conf к виду:

Теперь можно проверить, что Ubuntu запрашивает у Winbind информацию о пользователях и группах выполнив по очереди следующие команды:

После выполнения первой команды вы должны увидеть содержимое вашего файла /etc/passwd и пользователей вашего домена AD из указанного диапазона в файле /etc/samba/smb.conf. Вторая команда вернет все то же самое, только для групп.

Авторизация в Ubuntu через пользователей домена

Несмотря на то, что все пользователи домена фактически стали полноценными пользователями системы (в чём можно убедиться, выполнив последние две команды из предыдущего раздела), зайти ни под кем из них в систему всё ещё нельзя. Для включения возможности авторизации пользователей домена на компьютере с Ubuntu необходимо настроить PAM на работу с Winbind.

Он-лайн авторизация

Для он-лайн авторизации я лично подредактировал парочку файлов. Первый файл, который я редактировал это /etc/pam.d/common-session и добавил в него всего одну строчку:

Вторым был файлик /etc/lightdm/user.conf. В него необходимо добавить строчку в самый конец файла:

На этом собственно говоря все готово! Перезагружаемся и входим под учетной записью доменного пользователя.

Офф-лайн авторизация

Часто возникает ситуация, когда домен-контроллер недоступен по различным причинам — профилактика, отключение света или вы принесли ноутбук домой и хотите поработать.

В этом случае для Winbind можно настроить кэширование учетных записей пользователей домена. Для этого необходимо сделать следующее. Добавьте в секцию [global] файла /etc/samba/smb.

conf следующие строки:

Обычно этого достаточно. Если же возникают ошибки, то необходимо создать файл /etc/security/pam_winbind.conf со следующим содержанием:

Файл /etc/pam.d/gnome-screensaver в таком случае принимает вид:

А также изменяется файл /etc/pam.d/common-auth:

На этом вроде бы все 🙂