Простой домен на базе ROSA Enterprise Linux Server и Samba 3 с поддержкой перемещаемых профилей
Как я уже писал в одной из предыдущих статей, в более-менее большой компании рано или поздно возникает потребность в централизации. Одной из общепринятых практик в этом случае считается необходимость создания единой службы аутентификации для контроля за учётными записями и политиками.
Итак, что нам потребуется? Будем считаеть, что у нас есть уже установленный ROSA Enterpirse Linux Server (далее — RELS) и ROSA Directory Server (далее — RDS) на нём. Также заранее оговорим сетевые реквизиты.
Сервер располагается по адресу 192.168.100.1. Ему будет присвоен FQDN rels.int. Сервер и прочие компьютеры располагаются в подсети 192.168.100.0/24. Основной сервер DNS будет располагаться в том же домене, где ему будет присовено имя named.rosa.int.
Перед началом настройки удостоверимся, что команда hostname -f выдаёт что-то вроде:
Если же появляется какая-нибудь ошибка вроде «Не найдено имя хоста», то открываем файл /etc/hosts и прописываем FQDN-имя вручную. В нашем случае это будет выглядеть следующим образом:
Если этого не сделать, то ещё на этапе установки необходимых компонентов можно словить сообщение об ошибке, связанное с тем, что ROSA Directory Server не может найти FQDN-имя сервера. Из-за этого дальнейшая установка компонентов RDS будет прервана.
Установка и настройка
Если вы устанавливали сервер с нуля, указав в списке компонентов ROSA Directory Server, то на рабочем столе после входа в систему вы можете увидеть значок ROSA Server Setup (далее — RSS). Запускаем его и нашему взгляду предстаёт страница входа в консоль первоначальной настройки и установки компонентов RDS.
Если так получилось, что вы установили RELS без компонента RDS, то для этого нам необходимо установить командой yum install следующие пакеты:
mss-modules-base
mmc-agent
python-mmc-base
python-mmc-core
Остальные недостающие пакеты должны подтянуться в качестве зависимостей. Если всё сделано правильно, то в главном меню в разделе «Администрирование» появятся две иконки: ROSA Server Setup и ROSA Management Console.
После запуска RSS, для дальнейшей настройки следует нажать на ссылку «Перейти в ROSA Server Setup». Кстати, поскольку это веб-конфигуратор, то можно производить настройку не на самом сервере, а из локальной сети с компьютера системного администратора. Для этого следует обратиться по адресу: ip_адрес_сервера:8000/mss/. Например, в нашем случае это будет 192.168.100.1:8000/mss/.
После выбора пункта «Перейти в ROSA Server Setup», появится уведомление о недоверенном соединении. Игнорируем предупреждение и добавляем сертификат нашего сервера в исключения безопасности. После чего, в открывшемся окне вводим логин и пароль пользователя root.
После ввода учётных данных, мы попадаем на страницу с двумя раздельными блоками:
Раздел «Службы и инструменты сервера» нам сейчас не требуется, поэтому выбираем ROSA Directory Server. После выбора требуемого пункта, мы перейдём в раздел со списком компонентов, которые могут быть дополнительно установлены через веб-интерфейс ROSA Server Setup. Для установки компонентов PDC нам необходимо выбрать два пункта: «Samba PDC и фай-ловый сервер» и «DNS-сервер с RDS backend». После выбора нужных компонентов нажимаем «Установить компоненты» в самом низу.
Далее будет окно подтверждения выбора устанавливаемых компонентов, а затем, в качестве следующего шага можно наблюдать непосредственно сам процесс проверки и установки дополнительных компонентов, если они не были установлены до этого.
Следующим этапом у нас будет процесс задания первоначальных настроек для сервера LDAP, Samba и сервера DNS. Все настройки мы оговаривали в самом начале статьи. Если забыли, можете вернуться в начало статьи. Единственное замечание — обязательно требуется указать пароль в графе «Пароль RDS». Этот пароль в дальнейшем нам потребуется для доступа в консоль управления сервером и в идеальном варианте он не должен совпадать с паролем пользователя root, или паролем для ROSA Server Setup.
Также следует быть внимательным при выставлении чекбокса «Политика паролей».
Этот момент следует учесть очень внимательно. При указании опции «использовать политику паролей», задаваемые вами пароли должны быть не менее восьми символов в длину и содержать буквы и цифры. В противном случае, он не будет принят. Также при указании опции «Политика паролей» на создаваемого пользователя будет действовать ограничение по времени использования пароля и действия аккаунта. Все настройки связанные с парольной политикой можно будет в дальнейшем изменить в панеля управления пользователями. Срок действия аккаунта администратора по умолчанию равен 27 годам.
Имя Netbios для нашего сервера, которое будет отображаться в «Сетевом окружении», может быть задано произвольным образом, но для удобства оно совпадает с именем хоста. Про пароль и логин администратора домена, думаю, объяснять нет нужды. Нажимаем «Продолжить», подтверждаем свои действия на следующем шаге мастера нажатием кнопки «Выполните конфигурацию» и на этом первоначальная настройка закончена.
Для завершения развёртывания домена, нам потребуется провести небольшую дополнительную настройку сервера DNS. Для этого необходимо открыть главное меню и найти пункт Администрирование>ROSA Management Console. Если вы настраиваете сервер из локальной сети, то консоль настройки доступна по адресу ip_вашего_сервера/mmc.
После ввода логина root и пароля, который мы настраивали на этапе первичной настройки ROSA Directory Server, мы попадём на страницу управления параметрами сервера.
Если посмотреть на экран, то справа мы увидим раздел «Сеть», где ниже указаны пункты меню отвечающие за настройки сервера DNS. Нажимаем «Добавить DNS-зону» и переходим в раздел отвечающий за добавление зон DNS. Собственно, настройки представлены иллюстрацией ниже. Повторюсь, необходимые параметры мы описывали в самом начале статьи. Все настраивается предельно просто. Ошибиться не получится, поскольку вводимые параметры проверяются на корректность.
После нажатия на кнопку «Создать» внизу экрана появится уведомление об успешном создании зоны. После чего нужно перезапустить сервер DNS, перейдя в раздел «Управление службами сети».
Следующим этапом будет настройка сервера для работы с перемещаемыми профилями пользователей.
Для этого необходимо залогиниться под пользователем root на сервере и отредактировать содержимое /etc/samba/smb.conf. Ищем там секцию #profiles# и приводим её к такому виду:
Буква диска может быть любой, лишь бы не была занята чем-то ещё. Теперь переходим в самый конец файла smb.conf и полностью раскомментируем содержимое секции [profiles]. По умолчанию, пользовательские профили будут складироваться в /home/samba/profiles/%имя_пользователя%. По желанию, пути всегда можно переопределить. После всех правок, сохраняем изменения и перезапускаем демон Samba.
Настала пора перейти к созданию пользователя, помимо уже созданного пользователя admin, для проверки работы домена.
Заходим на главную страницу «ROSA Management Console» и выбираем пункт «Добавить пользователя». В открывшемся окне с формой, заполняем поля с именем пользователя и паролем.
В самом низу формы не забудьте снять галочку «Доступ к почте», если вы только перед этим не настраивали почтовый сервер. В противном случае, без заполнения поля «Почтовый адрес» вы не сможете создать учётную запись.
После нажатия кнопки «Подтвердить» учётная запись будет создана. При наличии Windows-машины, можно будет совершить вход в только что созданный домен.
Операционные система Windows XP подключается к такому домену без проблем. Но перед подключением рекомендуется сделать следующее: зайти под локальным администратором на компьютере с Windows, затем запустить gpedit.msc. В открывшемся редакторе групповых политик найти раздел Computer Configuration>Administrative Templates>System>User Profiles (в русскоязычной Windows это будет «Конфигурация компьютера>Административные шаблоны>Система>профили пользователей»). Там отыскать пункт «Do not check for user ownership for Roaming Profile Folders» (в русскоязычном варианте Windows «Не проверять права пользователя директорий перемещаемого профиля») и выставить его в положение Enabled, после чего перезагрузить компьютер и выполнить подключение к домену.
Для компьютеров под управлением Windows 7 тоже требуется проделать некоторые действия. Потребуется под локальным администратором до ввода в домен импортировать следующий .reg-файл: bugzilla.samba.org/attachment.cgi?id=4988&action=view После чего перезагрузиться. Дополнительные подробности по использованию Windows 7 в домене Samba можно найти здесь: wiki.samba.org/index.php/Windows7
По умолчанию сервер Samba также предоставляет возможности файлового сервера для хранения данных. В изначальной конфигурации которую мы описывали выше, для доступа открывается каталог Public.
Теперь настроим сервер так, чтобы он подключал этот общий ресурс автоматически для каждого пользователя.
Переходим в каталог /home/samba/netlogon и создаём там файл logon.bat со следующим содержимым:
Сохраняем и пробуем войти созданным нами пользователем. В «Моем компьютере» вы увидите подключенный диск H: который на самом деле является общим ресурсом.
Для дальнейшей работы в реальной сети предприятия, рекомендую перенастроить пути для пользовательских каталогов вроде «Мои документы», чтобы они хранились на сетевом диске без необходимости каждый раз таскать всё содержимое профиля по сети при подключении пользователя. Поскольку этот момент несколько выходит за рамки статьи, я оставляю вам его в качестве домашнего задания. 🙂
Теперь — всё. У вас в наличии есть готовый полноценный сервер аутентификации на базе Samba 3 для Windows и Linux-машин. Конечно, это на полноценную замену Active Directory от Microsoft не претендует, но тем не менее, какую-то дополнительную функциональность на базе этого можно будет прикрутить.
Заранее отвечая на вопрос о создании инструмента для развёртывания и управлении доменом на база Samba 4, который может полностью заменить Active Directory — да, планируется. Но сроки пока назвать не могу.
Вопросы, разумная критика и комментарии традиционно приветствуются.
Режим перемещаемых профилей
Режим перемещаемых профилей позволяет использовать домашние директории пользователей, расположенные на файловом ресурсе общего доступа, чтобы обеспечить получение домашней директории на разных виртуальных машинах.
Данный режим обеспечивает взаимодействие NFS-хранилищ и виртуальных машин. При подключении пользователя к виртуальной машине посредством Space Client, происходит монтирование сетевых ресурсов в виртуальную машину.
Режим перемещаемых профилей предназначен для работы с ОС Linux.
Подготовка
Для работы режима перемещаемых профилей, в локальной сети должен быть запущен сервер NFS.
На виртуальные машины должны быть установлены QEMU GuestAgent и клиент NFS.
Настройка
Настройки режима перемещаемых профилей расположены в разделе Настройки → Система → Профили.
Описание настроек
IP-адрес — IP-адрес сервера NFS;
Полный путь — путь к сетевой директории, расположенной на сервере NFS;
Путь монтирования — точка монтирования в ОС виртуальной машины.
Добавление домашних директорий пользователей
В локальной сети необходимо запустить сервер NFS.
IP-адрес этого сервера указывается в параметре IP-адрес.
На сервере NFS необходимо создать директорию в которой будут храниться профили пользователей. Полный путь этой директории указывается в параметре Полный путь.
В параметре Путь монтирования необходимо прописать /home/ .
На NFS сервере для каждого профиля пользователя необходимо добавить запись в файл настроек /etc/exports .
Перемещаемые профили для многих пользователей на ограниченном кол-ве ПК
Ув. специалисты! Прошу подсказать, как можно реализовать перемещаемые профили пользователей под Линукс и Виндовс. Вводная: есть много пользователей на ограниченном кол-ве машин. Например, 20 человек, проходной двор на 10-ти ПК. Пользователи — постоянно приходят новые и уходят старые. Движуха такая себе. Нужно как-то при логине «подтянуть» их профайл, чтобы не заводить их локально на каждом ПК. То есть, максимально отвязать от определенного рабочего места. Проприетарный софт очень не хотелось бы использовать.Тут есть эксперты в свободном ПО, я надеюсь, как-то можно такое замутить. Спасибо заранее огромное!
Я уже говорил, как элементарнейшим образом это делается: на центральном сервере хранятся все «хомяки», а монтируются они по nfs или sshfs. Элементарщина.
Конечно, можно. Странный вопрос.
а монтируются они по nfs или sshfs.
Дык а как реализовать это при логине в систему? Будет использоваться Gnome3 — копать в PostLogin скрипте? Уточните плиз,я неграмотный 🙂
Да элементарно: у меня файлы /etc/passwd, /etc/shadow и прочие, нужные для логина, лежали в отдельной директории; в /etc/ были симлинки туда. В хомяке по умолчанию — только один профиль. При запуске компьютера, если с сетью все ОК, в хомяк монтируется серверный хомяк, а в ту директорию с паролями — соответствующая директория с сервера. Все прозрачно. Дальше юзверь работает как с локальной системой.
Если сети нет, доступен «умолчальный» логин.