Поскольку этот сайт посвящен Ubuntu, я пропущу все, что касается настройки контроллера домена и подключения прочих компьютеров. Скажу лишь, что доменная сеть подразумевает использование машин с Windows, одна или несколько из которых будут считаться контроллерами. Контроллер служит центром авторизации, хранит учетные записи пользователей других компьютеров и позволяет ими управлять. Локальные учетные записи при этом хотя и не исключаются как таковые, но становятся необязательными. Кроме того, контроллер предоставляет ряд других возможностей по управлению прочими компьютерами.
Для демонстрации я буду использовать виртуальные машины, подключенные к единой внутренней сети, тоже виртуальной.
Устанавливаем пакеты.
Так как Linux и Windows хранят данные об учетных записях и группах по-разному, нам понадобится Winbind, чтобы пользователи разных ОС могли благополучно пройти аутентификацию. Нам также понадобится Kerberos (клиентская часть). Kerberos представляет собой сетевой протокол, необходимый для авторизации клиента и сервера и использующийся в самых разных ОС.
Установим несколько пакетов:
В процессе установки Kerberos задаст несколько вопросов. Для начала он попросит указать область. Впишите сюда имя домена вместе с доменной зоной (те, которые вы указывали при настройке контроллера), обязательно в верхнем регистре.
Далее нужно указать сервер Kerberos. Смело вписывайте сюда полное имя контроллера домена, поскольку он по совместительству является и указанным сервером.
Затем нужно ввести имя управляющего хоста области. Если контроллер домена у вас один, просто впишите его имя еще раз. После этого установка необходимых пакетов будет завершена.
Обязательным условием успешной настройки является одинаковое время на контроллере и подключаемом компьютере. Можно проверить и настроить время вручную, но гораздо лучше позаботиться о том, чтобы наш компьютер синхронизировал время с контроллером автоматически. Для этого установим еще один пакет:
Теперь откройте /etc/ntp.conf с правами суперпользователя и после строки #Specify one or more ntp servers закомментируйте имеющиеся серверы и впишите имя контроллера вместе с доменной зоной.
Связываемся с контроллером.
Если вы правильно настроили DHCP на контроллере домена, Ubuntu будет автоматически получать IP и подключаться к сети. Загляните в /etc/resolv.conf и убедитесь, что напротив параметра nameserver стоит IP нашего контроллера, а напротив параметра search — имя домена.
Если у вас, как и у меня, напротив nameserver указан адрес 127.0.1.1, не пытайтесь изменить его напрямую, все ваши правки исчезнут после первой же перезагрузки.
Рекомендованный для подобных исправлений /etc/resolvconf/resolv.conf.d/… править тоже не нужно, поскольку проблема в другом. Вместо этого откройте файл /etc/NetworkManager/NetworkManager.conf и закомментируйте строку dns=dnsmasq. Перезапустите Network Manager:
Содержимое /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 пользователей, зарегистрированных на контроллере домена. Давайте сделаем это сейчас.
Прежде всего, необходимо сообщить 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.
Оболочка командной строки и домашние директории для пользователей домена.
Выше я уже рассказывал об автоматически создаваемых домашних директориях для пользователей домена, но пропустил одну важную деталь: мы можем указать, где именно они будут создаваться. По умолчанию домашняя директория подключившегося пользователя домена находится в:
/home/имя_домена/имя_пользователя
Если сеть имеет сложную структуру и большое количество пользователей, это очень удобно. Такая структура позволяет избежать хаоса, а кроме того — не допустит проблем при совпадении имен пользователей разных доменов.
Но вы можете создать собственную структуру.
Кроме обычных названий папок можно использовать переменные:
%D | название домена |
%U | имя пользователя |
%N | имя сервера домашних директорий |
Например, вариант, используемый по умолчанию (приведен выше), записывается так:
/home/%D/%U
В качестве оболочки командной строки по умолчанию используется /bin/false. На практике это означает, что подключившийся пользователь домена в принципе не будет иметь доступа к командной строке. Если точнее, он будет автоматически выброшен из нее сразу же после входа. Даже если вы попробуете залогиниться в командной строке, ничего не выйдет. Это поведение можно изменить, указав в качестве оболочки командной строки bash. Добавьте в /etc/samba/smb.conf:
Имейте в виду, что это затронет всех пользователей контроллера. Каждый из них теперь получит доступ к командной строке, а заодно — и возможность входить без графического интерфейса.