Настройка samba в домене windows
Обновлено: 04.07.2024
Функционал обычного файлового сервера неизменно остается одним из самых популярных и востребованных в работе среднестатистического офиса. Сегодня я расскажу как установить и настроить файловый сервер Samba с авторизацией в AD и управлением доступом с помощью доменных учетных записей. Сразу скажу, что тема это достаточно трудная и хрупкая, очень часто что-то идет не так, нужно неплохо ориентироваться в теме, чтобы решать возникающие проблемы.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на . Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда. Прежде чем начинать настройку файлового сервера samba, прочитайте полностью материал, чтобы решить, каким способом будете настраивать. По ходу написания статьи у меня получились 2 принципиально разных решения.Введение
Ранее я рассказывал как сделать очень простую и быструю настройку самбы, когда доступ ограничивается либо внутренними пользователями самбы, либо с помощью ip. Если вас такой формат эксплуатации файлового сервера устраивает, то читать дальше не обязательно. Используйте приведенную статью, и у вас все получится очень быстро.
Для более сложной настройки самбы с авторизацией в Active Directory будем разбираться дальше. Существует как минимум 2 способа добавления linux сервера в домен Windows Server:
- Использовать известное и универсальное средство winbind.
- Либо воспользоваться менее популярным, но как мне кажется, более удобным и простым в настройке - sssd.
Пример добавления linux сервера в домен с помощью winbind я приводил в одной из своих статей по настройке sams с авторизацией в AD. Утилиту sssd я использовал, когда настраивал авторизацию в linux с помощью доменный учетных записей. В этой статье я воспользуюсь sssd для интеграции в виндовый домен.
Если у вас еще нет готового сервера, то можете воспользоваться моими материалами на эту тему — установка и настройка centos 7. Так же рекомендую настроить iptables для корректной работы сервера с доменом windows. Далее я не буду касаться этого вопроса, мы просто отключим фаерволл, потому что его настройка не тема этой статьи.
Настраивать файловую шару samba будем на сервере под управлением CentOS 7 следующей версии:
Вводные слова я все сказал. Начнем настройку самбы с ввода сервера в домен.
Добавляем сервер к домену через realm
Я не буду придумывать ничего нового, а полностью воспользуюсь инструкцией из приведенной выше статьи по настройке авторизации доменных учеток на сервере, но при этом не буду настраивать саму авторизацию. В данном случае мне это не нужно.
Итак, отключаем firewall и SELinux, если не сделали это раньше. Если не хотите отключать, то настройте сами. Данная настройка выходит за рамки статьи.
Выполняем команду, чтобы не ждать перезагрузки для применения изменений.
| xs.local | название домена |
| 10.1.3.4 | ip адрес контроллера домена |
| xs-winsrv.xs.local | полное имя контроллера домена |
| xs-design | имя сервера centos, который вводим в домен |
| admin51 | учетная запись администратора домена |
Настроим синхронизацию времени с контроллером домена. Это важно, у вас должно быть одинаковое время с контроллером домена. Проверьте его и убедитесь, что стоят одинаковые часовые пояса.
Устанавливаем утилиту для синхронизации времени chrony:
Добавляем в конфиг /etc/chrony.conf адрес контроллера домена. И делаем его единственным сервером для синхронизации, остальные удаляем.
Сохраняем конфиг, запускаем chrony и добавляем в автозагрузку.
Проверим, что с синхронизацией.
Устанавливаем софт, который понадобится для дальнейшей работы.
Делаем проверку перед вводом в домен.
Заводим в домен.
Если не получили никакой ошибки, значит все прошло нормально. Можно зайти на контроллер домена и проверить, появился ли наш linux сервер в домене.
Проверьте на самом сервере, что он нормально обращается к домену и получает информацию об учетных записях. Показываю на примере доменной учетной записи control.
Еще несколько проверок.
Сервер завели в домен. Приступаем к основному - настройке samba с интеграцией в AD.
Настройка Samba с интеграцией в AD через sssd
Устанавливаем сам файловый сервер самба.
Рисуем ему примерно такой конфиг.
Запускаем службу smb.service и добавляем в автозагрузку.
Теперь идем проверять подключение к сетевому диску с какой-нибудь виндовой машины. Здесь меня ждало полное разочарование. Ничего не работало. Я бился над решение проблемы примерно 2 дня, но не смог победить. Перелопатил весь гугл по запросу "sssd samba", но не смог заставить работать эту связку.
Мне стало жаль тратить время на поиски готового решения с sssd, хотя мне очень хотелось получить рабочий вариант, так как с winbind достаточно часто возникают проблемы. Я надеялся от них избавиться переходом на sssd, но не получилось. Статью не стал переделывать, сохранив то, что уже настроил. Может быть у вас заработает.
Попутно узнал, что sssd не поддерживает NTLM авторизацию, только kerberos. Я не знаю, по какой причине, но у меня самба, судя по логам, упорно пыталась авторизовать пользователя по ntlm. В итоге, я прекратил попытки и вернулся к старому проверенному варианту с winbind. Далее расскажу, как настроить файловый сервер samba для работы в домене windows с помощью winbind.
Вводим CentOS 7 в домен с помощью winbind
Если у вас виртуальная машина, проще установить ее с нуля. Если не хочется по какой-то причине, можно просто удалить все установленные ранее пакеты через команду yum remove. Я поступил именно так.
Устанавливаем недостающие пакеты:
Не забудьте о настройке синхронизации времени, которую мы делали на предыдущих шагах. Надо это проделать, если вы сразу начали настройку с данного пункта. Так же убедитесь, что все в порядке с dns, и контроллеры домена пингуются по именам.
Формируем конфиг для kerberos.
Для удобства дублирую таблицу с информацией, чтобы не пришлось скролить страницу вверх.
| xs.local | название домена |
| 10.1.3.4 | ip адрес контроллера домена |
| xs-winsrv.xs.local | полное имя контроллера домена |
| xs-design | имя сервера centos, который вводим в домен |
| admin51 | учетная запись администратора домена |
Вывод после работы команды у меня такой:
Это не страшно, продолжаем настройку. Заводим сервер с CentOS в домен:
На выходе получил:
В принципе, ничего страшного. Нам придется самим создать A запись на DNS сервере. Я не понимаю, почему иногда она не создается автоматически. Во время написания статьи, я использовал один сервер, у него не было этой ошибки при вводе в домен. Когда проверял статью на втором сервере, получил эту ошибку. Проверяем на контроллере домена в списке компьютеров наш сервер и создаем руками А запись, соответствующую имени сервера и его IP адресу.
Теперь рисуем конфиг для самбы примерно такой.
У меня русский язык на контроллере домена, поэтому и имена групп на русском. Проблем с этим не возникает. Не забудьте создать директорию /mnt/shara.
Запускаем samba и winbind и добавляем в автозагрузку.
Выполняем ряд проверок, чтобы убедиться, что все в порядке, winbind работает и samba будет получать актуальную информацию о пользователях и группах домена.
Последние две команды должны вывести список всех пользователей и групп домена.
Проверим теперь авторизацию в домене.
В данном случае control — имя пользователя домена, pass — его пароль. Успешная проверка выглядит так, как у меня. В завершении проверок посмотрим, корректно ли система сопоставляет доменные учетные записи локальным.
Все в порядке. Теперь все готово для корректной работы файлового сервера на основе Samba с доменными учетными записями. В завершении настроек, сделаем администратора домена владельцем нашей шары.
Проверяем, что получилось.
Уберем доступ на чтение у всех остальных, оставим полные права для пользователя admin51 и на чтение у пользователей домена.
Идем на любую виндовую машину и пробуем зайти на шару по адресу \\ip-адрес-сервера. Попадаем на нашу шару.
Если не получилось зайти, проверьте настройки iptables. На время отладки можно их отключить. Так же убедитесь, что у вас запущена служба smb.service.Смотрим расширенные параметры безопасности:
Получилось то, что хотели. Управлять правами доступа можно через windows acl с любой машины windows, где учетная запись пользователя домена будет обладать необходимыми правами. Если по какой-то причине это не получится (а я с такими ситуациями сталкивался достаточно часто), на помощь придут консольные утилиты getfacl для проверки прав и setfacl для изменения прав. Документация по этим командам есть в сети и легко ищется. Я рекомендую всегда использовать эти команды, когда вы выполняете изменение прав по большому дереву каталогов. Через консоль выставление прав будет выполнено раз в 5-10 быстрее, чем через windows acl. На больших файловых архивах разница может быть в десятки минут или даже часы.
Настройка прав доступа на файлы в Samba
Сделаю небольшое пояснение по правам доступа в файловом сервере samba. Вопрос этот сложный и объемный. Ему можно посвятить и отдельную статью. Но для полноты картины по настройке самбы, расскажу самое основное.
Как я уже ранее сказал, изменять права доступа к каталогам на файловом сервере можно с помощью команды setfacl. Давайте сейчас посмотрим на права доступа, которые установлены:
С такими правами что-то создавать в папке сможет только пользователь admin51, а пользователи домена смогут только просматривать файлы и каталоги. Сделаем более прикладной вариант. Добавим права доступа на чтение и запись еще одной доменной группе - gr_it.
Обращаю внимание, что иногда при копировании команд setfacl они не отрабатывают, выдавая не очень понятную ошибку:
Наберите команду с клавиатуры, либо просто удалите и наберите снова ключ -m, он почему-то при копировании часто дает эту ошибку.
Смотрим, что получилось:
То, что надо. Теперь пользователи группы gr_it имеют полные права на шару. Создадим одним таким пользователем папку test1 на нашей шаре и посмотрим, какие права она получит.
Права на папку имеет только ее создатель и больше никто. Для того, чтобы наследовались права с вышестоящего каталога, необходимо на этот вышестоящий каталог добавить дефолтные права доступа. Примерно вот так.
Смотрим, что получилось:
Создадим теперь тем же пользователем еще одну папку test2 и проверим ее права.
Применилось наследование с вышестоящих папок. Не забывайте про дефолтные права и учитывайте их при настройке прав доступа на файловом сервере.
Для удобной и корректной работы с правами доступа я обычно для крупных, корневых директорий выставляю права аккуратно через setfacl в консоли. Какие-то мелкие изменения по пользователям и группам в более низших иерархиях директорий делаю через windows acl с какой-нибудь виндовой машины.
Еще важно знать одну особенность выставления прав доступа в linux. В моей практике часто требуется дать какому-нибудь пользователю доступ в одну директорию, которая располагается там, где у пользователя нет вообще никаких прав. В windows эта проблема решается просто - даются права на конкретную папку, а пользователю кладется ярлык на эту папку. В итоге он имеет доступ к нужной директории и больше никуда.
В linux так сделать не получится. Для того, чтобы дать таким образом доступ на отдельную директорию пользователю, необходимо, чтобы по всем вышестоящим директориям у него были права на исполнение, то есть X. Их придется выставлять вручную по всем вышестоящим папкам. Результат будет такой же, как и в винде - пользователь получит доступ на чтение только в указанную папку, но для этого придется выполнить больше действий. Если не знаешь этот нюанс, можно потратить много времени, прежде чем поймешь, в чем проблема.
Заключение
Скажу откровенно - мне не нравится, как работают файловые сервера samba с интеграцией в виндовом домене. Но настраивать их приходится часто, так как востребованный функционал. Востребован в первую очередь потому, что не требует вообще никаких денег за лицензии, и работает на минимальной конфигурации железа. Вот список типичных проблем при работе самбы в домене:
- Иногда через windows acl права перестают выставляться, возникают неинформативные ошибки, по которым невозможно понять, что не так.
- Я достаточно регулярно наблюдаю ситуацию, когда слетают соответствия доменных учеток линуксовым UID. В итоге права доступа превращаются в ничего не значащий набор цифр и перестают работать.
- При переносе данных с одного сервера на другой трудно сохранить права доступа. Можно поступить вот так для копирования прав доступа, либо как-то заморочиться, чтобы на всех серверах у вас были одинаковые UID доменных учетных записей. Я не разбирал этот вопрос подробно.
Если у вас есть возможность настроить файловый сервер на windows, либо обойтись линуксом без домена, то сделайте так. Существенно упростите настройку и дальнейшую эксплуатацию. Данную статью еще можно дополнить некоторыми моментами, которые я рассказал ранее, а что не рассказал, постараюсь раскрыть позже и добавить сюда ссылки на статьи:
-
.
- Настройка корзины для сетевых дисков samba. . .
Буду рад любым полезным замечаниям, исправлениям, советам по настройке файлового сервера samba. Я потратил значительное время, чтобы поделиться своими знаниями и опытом с остальными. Надеюсь, кто-то поделится чем-то полезным со мной. В том числе ради этого я и пишу статьи. Они расширяют мой кругозор и закрепляют полученные знания.
В сегодняшней статье я опишу и продемонстрирую процесс подключения Samba к доменной сети Windows в качестве рядового участника.
Поскольку этот сайт посвящен Ubuntu, я пропущу все, что касается настройки контроллера домена и подключения прочих компьютеров. Скажу лишь, что доменная сеть подразумевает использование машин с Windows, одна или несколько из которых будут считаться контроллерами. Контроллер служит центром авторизации, хранит учетные записи пользователей других компьютеров и позволяет ими управлять. Локальные учетные записи при этом хотя и не исключаются как таковые, но становятся необязательными. Кроме того, контроллер предоставляет ряд других возможностей по управлению прочими компьютерами.
Для демонстрации я буду использовать виртуальные машины, подключенные к единой внутренней сети, тоже виртуальной.
Так как Linux и Windows хранят данные об учетных записях и группах по-разному, нам понадобится Winbind, чтобы пользователи разных ОС могли благополучно пройти аутентификацию. Нам также понадобится Kerberos (клиентская часть). Kerberos представляет собой сетевой протокол, необходимый для авторизации клиента и сервера и использующийся в самых разных ОС.
Установим несколько пакетов:
В процессе установки Kerberos задаст несколько вопросов. Для начала он попросит указать область. Впишите сюда имя домена вместе с доменной зоной (те, которые вы указывали при настройке контроллера), обязательно в верхнем регистре.
Далее нужно указать сервер Kerberos. Смело вписывайте сюда полное имя контроллера домена, поскольку он по совместительству является и указанным сервером.
Затем нужно ввести имя управляющего хоста области. Если контроллер домена у вас один, просто впишите его имя еще раз. После этого установка необходимых пакетов будет завершена.
Обязательным условием успешной настройки является одинаковое время на контроллере и подключаемом компьютере. Можно проверить и настроить время вручную, но гораздо лучше позаботиться о том, чтобы наш компьютер синхронизировал время с контроллером автоматически. Для этого установим еще один пакет:
Связываемся с контроллером.
Если вы правильно настроили DHCP на контроллере домена, Ubuntu будет автоматически получать IP и подключаться к сети. Загляните в /etc/resolv.conf и убедитесь, что напротив параметра nameserver стоит IP нашего контроллера, а напротив параметра search — имя домена.
Если у вас, как и у меня, напротив nameserver указан адрес 127.0.1.1, не пытайтесь изменить его напрямую, все ваши правки исчезнут после первой же перезагрузки.
Содержимое /etc/resolv.conf должно измениться на правильное. Чтобы убедиться, что связь налажена, можно попробовать пропинговать контроллер:
Если на каждый отправленный запрос был получен ответ, значит, все в порядке.
Теперь, когда мы убедились, что связь установлена, перезапустим ntp, чтобы одновременно применить внесенные ранее изменения и синхронизировать время с контроллером:
В старых руководствах говорится о необходимости отредактировать конфигурационный файл Kerberos /etc/krb5.conf. Сейчас этот шаг в большинстве случаев не нужен, поскольку необходимые параметры мы уже ввели на этапе установки.
Пробуем запросить тикет у Kerberos на контроллере:
Если вы не получили ошибку — скорее всего, аутентификация прошла успешно. Проверить можно так:
Если все получилось, вы увидите нечто подобное:
То, что вы видите на скриншоте, означает, что Kerberos на контроллере домена аутентифицировал пользователя и выдал разрешение на подключение. Осталось внести корректировки в настройки Samba и позаботиться о соответствии пользователей Windows и Linux с помощью Winbind.
Вот мы и сделали компьютер с Samba участником доменной сети. Мы установили необходимые пакеты, позаботились о синхронизации времени с контроллером домена, изменили параметры Network Manager, убедились в том, что связь установлена и, более того, контроллер выдает пропуск нашему компьютеру. Теперь продолжим работу, настроив Samba и Winbind, а в конце убедимся, что наш компьютер виден с контроллера как участник Active Directory.
Редактируем конфигурационный файл Samba.
Еще в первой статье из этой серии я рекомендовал создать резервную копию конфига Samba. В этом нет острой необходимости, но если что-то пойдет не так, у вас будет возможность быстро вернуться к исходному варианту. Если вы не создали копию ранее, рекомендую сделать это сейчас:
Теперь можно переходить к редактированию:
Найдите секцию [global] — все изменения мы будем выполнять в ней.
Для начала замените значение параметра workgroup на имя (только имя сервера, т. е. то, что находится до точки) вашего контроллера домена в верхнем регистре. Поскольку в моем случае контроллер домена имеет полное имя LINUXRUSSIA.LABS, получится следующее:
Далее добавляем (или меняем, если он есть) параметр security, выставляя ему значение ADS. Таким способом мы даем понять Samba, что заниматься аутентификацией и авторизацией пользователей будет контроллер домена.
Следующий обязательный параметр — realm. Он определяет область Kerberos. Впишите сюда полное имя контроллера домена. Параметр encrypt passwords должен иметь значение yes, поскольку Windows не допускает использование не зашифрованных паролей. Samba по умолчанию тоже предпочитает шифрование, но лучше указать это явно.
После этого добавьте еще несколько опций для Winbind.
Положительное значение winbind use default domain необходимо для того, чтобы можно было указывать имена пользователей без имени домена, которое будет подставляться автоматически. Необязательный, но полезный параметр. Будьте с ним осторожны при использовании локальных учетных записей или двух и более контроллеров.
Idmap config * : range определяет диапазоны идентификаторов пользователей и групп, которые выделяются для учетных записей Windows. Очень важно проследить, чтобы id из указанного диапазона не пересекались с существующими и возможными локальными пользователями и группами.
Если вы посмотрите в файл /etc/login.defs в Ubuntu 16.04, то заметите, что максимально возможный id для useradd и groupadd — 60000, то есть пересечение с указанными нами значениями теоретически может случиться. Но в реальности очень маловероятно, что в вашей системе когда-нибудь будет около 10000 локальных пользователей или групп — именно это число мы указали в качестве минимального id для Winbind.
Сохраняем smb.conf и запускаем testparm, чтобы проверить, не допустили ли мы ошибку. Если все в порядке, вывод будет примерно таким:
Еще одна небольшая правка. В /etc/hosts необходимо указать следующее:
В моём случае это выглядит так:
Если вы не знаете, где найти имя компьютера, загляните в терминал - оно указано после имени пользователя и символа @.
Введение Samba в домен и проверка результата.
Если вы все настроили правильно, осталось выполнить всего одну команду. Вот она:
Чтобы убедиться, посмотрим на результат с точки зрения сервера Windows. Идем в диспетчер серверов, там выбираем Пользователи и компьютеры Active Directory (в вашей версии названия могут немного отличаться), далее из списка слева выбираем Computers. Вот она, наша машина с Ubuntu:
Если вы захотите создать общедоступную папку на компьютере с Samba, повторите те же действия, которые мы выполняли в первых статьях. Никаких принципиальных отличий в этом случае не будет. Есть только одна особенность: учетные записи. О том, как ими управлять при использовании сервера с Samba в качестве участника доменной сети мы поговорим в другой раз.
Одна из важнейших задач Active Directory — централизованное управление пользователями. Единое хранилище учетных записей и единый центр аутентификации дают массу преимуществ: возможность быстро и легко заменить одну или несколько рабочих станций, доступ администратора и пользователей к своей учетной записи с любого места, быстрое подключение нового участника и т. д. Но как все это реализовать? Сегодня я расскажу об этом.
Учетные записи домена в Ubuntu.
Прежде всего, необходимо сообщить Ubuntu, что помимо локальной базы данных пользователей существует еще одна, за связь с которой отвечает Winbind. Для этого откройте файл /etc/nsswitch.conf и найдите следующие строки:
В обеих после compat добавьте winbind. Больше ничего трогать не нужно (во всяком случае, мне не потребовалось, хотя в документации официальном сайте Ubuntu есть другая информация). Для проверки я поищу пользователя Администратор, который точно существует на контроллере домена и отсутствует на локальном компьютере:
Вы тоже можете выполнить такую проверку, только не забудьте подставить нужное имя пользователя и убедиться, что контроллер доступен по сети. Если он недоступен (например, выключен), получить оттуда учетные записи не выйдет.
Но радоваться еще рано — залогиниться, используя имя и пароль, созданные на контроллере домена, сейчас не выйдет. Сначала необходимо внести еще одну правку. Откройте /etc/pam.d/common-session и вставьте туда следующую строку:
Дело в том, что на каждого пользователя в Linux приходится набор обязательных файлов. Для пользователя, созданного на сервере с Windows, таких файлов, разумеется, не существует. Для решения этой проблемы мы вызываем модуль PAM (системы аутентификации в Linux) pam_mkhomedir.so, который отвечает за создание пользовательских директорий. Параметр skel (skeleton directory) определяет путь к папке с необходимыми файлами. Как только будет создана директория для подключившегося пользователя, в нее будет скопировано содержимое скелетной (отсюда и название) папки. Созданные таким образом домашние директории сохраняются и после выхода пользователя. Кстати, если вы хотите, чтобы каждый подключившийся пользователь имел в своей папке инструкцию или что-либо еще, вы можете разместить это в /etc/skel.
И вот теперь… вы все еще не можете залогиниться, поскольку видите нечто вроде этого:
Как сменить имя пользователя, если поля для его ввода просто нет, а среди перечисленных вариантов есть только локальные учетные записи? Для этого создайте файл /etc/lightdm/lightdm.conf.d/50-user-config.conf и поместите в него следующее:
После следующей загрузки на экране приветствия появится поле для логина.
Введите сюда имя пользователя, созданного на контроллере домена, а затем и пароль. Давайте посмотрим в домашнюю директорию. Кроме стандартных папок и файлов здесь присутствует и файл, который я предварительно поместил в /etc/skel.
Оболочка командной строки и домашние директории для пользователей домена.
Выше я уже рассказывал об автоматически создаваемых домашних директориях для пользователей домена, но пропустил одну важную деталь: мы можем указать, где именно они будут создаваться. По умолчанию домашняя директория подключившегося пользователя домена находится в:
Если сеть имеет сложную структуру и большое количество пользователей, это очень удобно. Такая структура позволяет избежать хаоса, а кроме того — не допустит проблем при совпадении имен пользователей разных доменов.
Но вы можете создать собственную структуру.
Кроме обычных названий папок можно использовать переменные:
| %D | название домена |
| %U | имя пользователя |
| %N | имя сервера домашних директорий |
Например, вариант, используемый по умолчанию (приведен выше), записывается так:
В качестве оболочки командной строки по умолчанию используется /bin/false. На практике это означает, что подключившийся пользователь домена в принципе не будет иметь доступа к командной строке. Если точнее, он будет автоматически выброшен из нее сразу же после входа. Даже если вы попробуете залогиниться в командной строке, ничего не выйдет. Это поведение можно изменить, указав в качестве оболочки командной строки bash. Добавьте в /etc/samba/smb.conf:
Имейте в виду, что это затронет всех пользователей контроллера. Каждый из них теперь получит доступ к командной строке, а заодно — и возможность входить без графического интерфейса.
Samba — ПО на Linux для организации общего доступа к файлам в среде Windows. Серверная часть открывает общий доступ к папкам Ubuntu для внешних пользователей. Клиентская часть позволяет получить доступ к сетевым папкам samba.
Есть у меня аппаратный сервер с операционной системой Ubuntu Server 18.04.5 LTS. На сервере имеется большой том, который планируется использовать в качестве файлового хранилища.
IP и DNS
Серверу назначен прямой IP адрес, hostname внесён в DNS сервер. Причём DNS сервер для Linux машин отдельный от доменного, но оба они умеют резолвить адреса друг друга. Подробно на этом не будем останавливаться.
AD аутентификация
В операционной системе уже настроена доменная аутентификация, можно логиниться на сервер под учётной записью Active Directory, права доступа тоже управляются с помощью доменных групп. Аутентификацию на сервере не я настраивал, поэтому описывать процесс подробно не буду. Скажу только, что доменную аутентификацию можно сделать разными способами. Читайте про krb5-user (пакет для протокола Kerberos, который используется для аутентификации в Windows) и/или winbind (позволяет использовать учетную запись пользователя из Active Directory). Я winbind не использую.
NTP
Время должно быть синхронизировано. Если расхождение по времени больше пяти минут, то мы не получим тикет от Kerberos. В общем, аутентификация не заработает. Не буду описывать процесс настройки ntp.
Ссылки
Установка samba
Самба настраивается в файле /etc/samba/smb.conf. Старый файл можно переименовать в smb.conf.bak, чтобы подсматривать параметры по умолчанию:
Указываем глобальные настройки:
- workgroup — NETBIOS ИМЯ ДОМЕНА (или РАБОЧАЯ ГРУППА, если нет домена), в заглавном регистре
- realm — ДОМЕН, в заглавном регистре
- server string — имя сервера, которое будет отображаться в сетевом окружении
- log file — логи
- max log size — размер логов
- log level — уровень логирования
- panic action — действия при краше самбы, по умолчанию отправляет письмо админу
- passdb backend — место хранения паролей
- obey pam restrictions — поддержка PAM аутентификации, непонятно зачем она включена по умолчанию, потому что PAM аутентификация не может использоваться при "encrypt passwords = yes", а encrypt passwords при этом устарел и по умолчанию включен.
- unix password sync — синхронизация паролей пользователей samba с локальными паролями, в AD не работает
- passwd program — программа для синхронизации паролей, в AD не работает
- passwd chat — текст для работы с паролями, в AD не работает
- pam password change — поддержка смены пароля в PAM
- security = ads — поддержка AD, самба ведёт себя как член домена.
- dns proxy — обращаться ли к DNS для определения DNS имени по NETBIOS имени.
- domain master — главный обозреватель домена
- local master — главный обозреватель подсети
- preferred master — предпочтительный обозреватель домена
- load printers — загружать принтеры
- printing — интерпретация статуса принтеров
- show add printer wizard — отображать иконку добавления принтера
- printcap name — определение списка принтеров
- disable spoolss — поддержка SPOOLSS (для принтеров)
- usershare max shares — папки пользователей
- usershare allow guests — папки гостей
- idmap config — настройки сопоставления SID с пользователями и группами POSIX
Давайте расшарим какую-нибудь папку, например, /u01/cron/, создаю её.
Назначаю владельца и группу папки (пользователь и группа доменные!)
Добавляем секцию в /etc/samba/smb.conf:
- [NAME] — имя шары
- path — путь к папке
- valid users — кому можно войти
- read list — кто имеет права на чтение
- write list — кто имеет право на запись
- read only — только чтение
После изменения файла smb.conf не помешает проверить его утилитой testparm:
Добавим сервер в домен:
В случае успеха увидим что-то типа:
У меня надпись немного другая:
Сервер в домен добавился, но не прописался в DNS. В моём случае это нормально, потому как сервер прописан в DNS другой зоны, отличной от доменной. В AD сразу переношу его из папки Computers в нужный мне организационный юнит.
Начиная знакомство с linux самое первое что мы пытаемся поставить это прокси-сервер squid и файл-сервер samba. Не смотря на обилие документации установка и настройка samba не редко вызывает множество проблем, как на старте, так и в процессе эксплуатации.
В этой статье я постараюсь описать процесс установки и настройки samba файл-сервера для функционирование в домене Windows.
1. Установка и настройка kerberos
Устанавливаем необходимы пакеты:
Для правильной работы kerberos необходима точная синхронизация времени с контроллером домена. Открываем файл /etc/ntp.conf, комментируем все теги server и добавляем наш контроллер домена:
Добавляем в автозапуск и запускаем сервис ntpd:
Открываем файл /etc/hosts и проверяем соответствие IP-адресов и имен, не правильно заполненный /etc/hosts может стать причиной множества ошибок:
Приводим файл /etc/krb5.conf к следующему виду:
Получаем тикет от контроллера домена:
Проверяем полученный тикет:
2. Установка и настройка samba
Устанавливаем необходимые пакеты:
Приводим файл /etc/samba/smb.conf к следующему виду:
Для проверки правильности конфигурационного файла у самбы есть замечательная утилита testparm:
Вводим сервер в домен:
Включаем в автозапуск и запускаем сервисы smb и winbind:
Редактируем файлик /etc/nsswitch.conf и добавляем после следующих строчек слово winbind. Этим действием мы указываем в каком порядке и где системе искать имена-пароли пользователей и групп.
Теперь сервер готов к работе.
3. Заключение
Я как-то пытался проанализировал экономический фактор установки бесплатной samba в качестве файл-сервера.
На сегодняшний день samba хоть и может использоваться в роли контроллера домена, но до полноценной Active Directory с групповыми политиками ей еще далеко, и использовать ее на 100 человек пользователей вряд ли кто будет. Отсюда получается, что один Windows-сервер у нас уже есть и необходимые CALs тоже.
Таким образом корпоративная лицензия Win2k8Std для файлового сервера обойдется приближенно в 700$. Будет ли дешевле установить, полноценно настроить и обслуживать samba с Shadow Copy, DFS и сетевой корзиной? По-моему нет.
Из-за особенностей организации сети и кеширования HOME версии крайне фигово работают в качестве файл-сервера. Тут то очень хорошо может закрыть эту задачу линуховый файлсервер. Особенно если на него пошло не совсем помоечное железо, а микросеть собрана прямыми руками на гигабите.
да на малых предприятиях никакого экономического обоснования ставить АД нету, а статья отличная =)
@andrey
Спасибо за исправления, на моей орфографии сказывается честно заработанная твердая четверка по русскому языку. Если хочешь оставь аську, я тебе перед каждой публикацией буду скидывать ссылку на статью для проверки.
В обоих случаях никакой потребности в AD и никакого намека на расширение. Наоборот, с 2008 года съеживаемся: кризис пока еще не ушел.
Так что статья правильная, нужная. Единственно, что я бы добавил, это пример описания нескольких папок с разными правами доступа для групп пользователей.
@дядя Миша
Года четыре назад я работал в одной чудесной аутсорсинговой компании и периодично натыкался на небольшие фирмы состоящие начиная от 2-х человек и кончая 30. Особенно радовали юристы кучковавшиеся по 2-3 человека в разных фирмах и частях города, самое печальное что во всех случаях с небольшими фирмами получался дремучий лес, у одних так и у других этак. Даже помнится записи по всем делал что бы не путать
Расскажи как у тебя сделано:
1. Имена локальных пользователей
2. Раздельный доступ к ресурсам
3. Доступ в интернет
4. Пакет офисных програм
5. Почта
@miha
Здесь думаю стоит с тобой согласиться, выкладывать из своего кармана дело трудное. Видимо я уже просто привык работать с населением около 200 человек и рассчитывать экономию средств по принципу затрачено в месяц.
Я использую самбу только в филиалах по 10-15 человек, для которых немножко урезали финансирование ИТ из-за не высокой прибыли. Мои кеи увы не хотят работать с Linux или BSD, поэтому приходится придерживаться MS, что бы не завязывать все на себя.
сейчас штуки типа Zentyal разворачивают смолбизнес сервер с прорвой служб, включая домен, управляемых из GUI галками, очень запросто. Необходимость AD в мелких (до
100 узлов) вообще сомнительна.
@SirYorik
Zentyal заслуживает внимания, разработчики молодцы сделали все красиво и доступно, возможно как раз этого и не хватало для небольших офисов. Но я по простоте своей душевной не люблю работать с такими продуктами
Таким образом если в организации с 50-ю пользователями раз в месяц возникает задача что-то установить или внести какие-либо изменения сразу на всех компьютерах, то использование AD полностью окупит себя за год.
Использую Samba + LDAP + Gosa(админка) на FreeBSD, в офисе 100 чел.
Все разделено по правам. Все летает уже 2 года
На клиентских компьютерах Windows XP? Какой прикладной софт используется?
Подсчет лицензий во втором случае будет вестись точно также как и в первом.
Если ты хочешь, что бы все компы были в домене Windows, то тебе так или иначе придется купить CALs на всех пользователей или все устройства, хотя бы для того чтобы они могли легально авторизироваться на контроллере домена.
@Alsigned
Спасибо за разъяснения. Я так и думал, но надеялся на лазейку .
А про мультиплексоры я и раньше читал, но как-то это не очень есть гуд, так ка я могу дать комплексную шару (шара непосредственно samba сервера + примонтированная шара виндового сервера). Здесь у на буду конфликтовать 2 лицензии: Виндовая и GPL.
PS: Я обычно стараюсь предложить какое-нибудь изящное решение, но здесь если не планируется переход на СПО и из недостающих лицензий только один Windows Server и 120 шт CAL, то эффективнее купить лицухи.
Приветствую, коллега!
На самом деле, при auth methods = winbind, ставить пакет krb5-workstation не обязательно. Samba и без него через winbind корректно работает.
У всех ПК в доменной сети не должно быть разницы во времени более 5 минут. Иначе билет тебе не выдастся. Как лечить? Я вылечил ntpd )))
Удачи!
Статья прекрасная и единственная толковая, спасибо огромное.
Одна только проблема: при присоединении к домену дает Fail to join domain: failed to find DC for domain
Ошибка скорее всего все-таки в конфигах krb5.conf и smb.conf, к примеру krb5.conf очень придирчив к большим и маленьким буквам. Также причиной может быть отсутствие соединение с DC или ошибка в DNS записях служб из _msdcs.
Без текста конфигов диагностики не получится.
Извини за кучу вопросов, заранее благодарен за ответ
1. A-запись должна обновляться сама, но этому могут мешать настройки зоны, либо samba может быть собрана без –with-dns-updates.
2. Видимо у тебя очень старый CentOS, который существовал еще до отмены перевода летнего и зимнего времени. Нужно правильно выставить часовой пояс.
3. Именно так только добавлять нужно в valid users, read users и write users.
4. Кроме разрешений в конфиге самбы, есть еще и разрешения на папку, если у админа нет прав на папку, то его туда не пустит.
Можно раздать права для виндовых групп и пользователей непостредсвенно на папки, с того момента как мы дописали winbind в файл /etc/nsswitch.conf виндовые пользователи и группы могут использоваться в системе наравне с локальными.
Настройки Kerberos:
Код:
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = TEST.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[domain_realm]
.test.local = TEST.LOCAL
test.local = TEST.LOCAL
[appdefaults]
pam = debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
>
Не пойму в чем причина, подскажите пожалуйста.
Для простого подключения к домену достаточно получить тикет через kinit.
Спасибо за ответ, получается krb-kdc мне не нужен)) ошибку я победил созданием базы для krb-kdc утилитой krb5_util.
kinit сработал нормально, однако после команды net ads join -U Admin выдало ошибку. krb-kdc я отключил.
Как я понял сейчас CentOS не настроен как клиент? Куда смотреть?
Понимаешь ли в чем дело, net ads join обращается к smb.conf и работает согласно параметров заданных в нем. Что у тебя в /etc/samba/smb.conf?
cat /etc/samba/smb.conf
[global]
Выдал тоже самое. DC называется mars.galactica.local. Тестовая linux машина Saturn. Проверил еще раз настройки, не могу понять, где ошибка.
[global]
dos charset = cp866
unix charset = utf-8
display charset = utf-8
workgroup = GALACTICA
realm = GALACTICA.LOCAL
netbios name = SATURN
server string = SQL SERVER
security = ADS
auth methods = winbind
allow trusted domains = No
password server = mars.galactica.local
time server = No
domain master = No
ldap ssl = no
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
case sensitive = No
Читайте также: