Linux машина в домене Windows AD
Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.
Для примера будем использовать:
Контроллер домена = dc.contoso.com
Запускаем терминал Ubuntu:
1. Переключаемся под рута
2. Устанавливаем необходимые пакеты
apt install sssd heimdal-clients msktutil
3. Редактируем /etc/krb5.conf, в качестве отступов используется табуляция
[libdefaults]default_realm = CONTOSO.COM [realms]
CONTOSO.COM = <
kdc = DC
admin_server = dc.contoso.com
default_domain = contoso.com
> [login]
krb4_convert = true
krb4_get_tickets = false [domain_realm]
.contoso.com = CONTOSO.COM
contoso.com = CONTOSO.COM
4. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:
127.0.0.1 localhost
127.0.1.1 .contoso.com
5. Пробуем получить Kerberos ticket от имени администратора домена:
# kinit YourDomainAdmin
YourDomainAdmin@CONTOSO.COM’s Password:
# klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: YourDomainAdmin@CONTOSO.COM
Issued Expires Principal
Dec 1 15:08:27 2018 Dec 2 01:08:22 2018 krbtgt/CONTOSO.COM@CONTOSO.COM
Если тикет получен успешно, то теперь можно сгенерировать Kerberos principals для данного хоста, регистр важен:
msktutil -c -b ‘CN=YourComputersOU’ -s HOST/HOSTNAME.contoso.com -k /etc/sssd/HOSTNAME.keytab —computer-name HOSTNAME —upn HOSTNAME$ —server dc.contoso.com —user-creds-only
msktutil -c -b ‘CN=YourComputersOU’ -s HOST/HOSTNAME -k /etc/sssd/HOSTNAME.keytab —computer-name HOSTNAME —upn HOSTNAME$ —server dc.contoso.com —user-creds-only
Сейчас наш хост должен отобразиться в списке компьютеров в каталоге. Если все так — удаляем полученный Kerberos ticket:
6. Создаем файл /etc/sssd/sssd.conf со следующим содержимым:
services = nss, pam
config_file_version = 2
domains = contoso.com
entry_negative_timeout = 0
debug_level = 3
ad_domain = contoso.com
ad_server = dc.contoso.com
enumerate = false
id_provider = ad
auth_provider = ad
chpass_provider = ad
access_provider = simple
simple_allow_groups = users # каким группам разрешено логиниться, через запятую. Есть ограничение — названия групп должны быть с маленькой буквы.
ldap_schema = ad
ldap_id_mapping = true
fallback_homedir = /home/%u
default_shell = /bin/bash
ldap_sasl_mech = gssapi
ldap_sasl_authid = $
ldap_krb5_init_creds = true
krb5_keytab = /etc/sssd/ .keytab
Описание параметров конфигфайла sssd можно посмотреть тут
Устанавливаем права доступа для файла sssd.conf:
chmod 600 /etc/sssd/sssd.conf
Перезапускаем SSSD service
service sssd restart
7. Редактируем настройки PAM
редактируем файл /etc/pam.d/common-session, после строки
session required pam_unix.so
session required pam_mkhomedir.so skel=/etc/skel umask=0022
переопределить параметры через системные настройки PAM, вызываем
и отмечаем пункты sss auth и makehomdir . Это автоматически добавит
строчку выше в common-session и она не будет перезатерта при обновлении системы.
Теперь мы можем логиниться на машине доменными пользователями, которым разрешен вход.
P.S.: Можно дать права на использование sudo доменным группам. Используя visudo, редактируем файл /etc/sudoers, или, создаем новый файл в /etc/sudoers.d/ и редактируем его
visudo -f /etc/sudoers.d/ваш_файл
добавляем требуемую группу — например, Domain Admins (если в названии группы есть пробелы — их необходимо экранировать):
LiveStreet
GNU/Linux → Контроллер домена на Linux?
Добрый день.
Хотелось бы поделиться с вами одним интересным моим опытом – Контроллер домена на Linux. В данной статье я скорее всего напишу небольшой мини обзор систем с помощью которых я пытался реализовать альтернативу ActiveDirectory.
Немного истории:
Написано мною в Январе 2009: Вообще я далеко не профи в *nix системах, но всё таки активно интересуюсь и изучаю их. В компании, где я работаю, около 3-4 моих серверов на базе Debian и FreeBSD. Которые выполняют различные задачи для обеспечения основных бизнес процессов компании.
По поводу домена на linux я слышал множество упрёков и похвал. И вот более года назад задался вопросом поднятия домена на Linux. Во первых просто интересно, а во вторых он абсолютно бесплатен, что и требовала компания где я работал. За год перебрал кучу вариантов, кучу сборок. Поднимал в ручную… ldap+samba+krb на BSD и Linux системах. Но мне казалось что всё это не то. Либо безумно неудобно управлять, либо куча лишнего. Куча лишнего было в готовых дистрибутивах (аля-домен за одну минуту.). Было боязно внедрять их в мою не большую и не маленькую компанию(Более 80-100 рабочих станций в одном только офисе). Во первых неизвестно что и как разработчики делали с дистрибутивом, во вторых электронная поддержка на иностранном языке ))) А самому разгребать последствия не хочется.
Чуть ниже я напишу мини обзор некоторых готовых вариантов поднятия домена. А в самом низу читайте мои итоги и выводы относительно всего этого опыта. Прошу заметить что выводы мои собственные и никого ни к чему не призывают… просто так решил.
1.Mandriva Directory Server.
Пожалуй самый удачный вариант из всех что имеется. Ничего лишнего (то что лишнее можно спокойно выключить). Mandriva Directory Server это не тупо сборка или готовый дистрибутив который можно развернуть за 5 минут. MDS это пожалуй единственный вариант который совмещает в себе ручную работу системного администратора по сборке и настройке основных компонентов домена + готовые решения от Mandriva по управлению всеми основными службами контроллера домена. Кстати говоря эти решения нужно так же ставить и настраивать в ручную.
Управление производится через удобный Web интерфейс.
Mandriva Directory Server может управлять следующими службами:
1.Расширенный почтовый сервер Postfix, с поддержкой Imap и POP3 сервера (Dovecot), с проверкой на вирусы и фильтрации почты (Amavis, Spamassassin, ClamAV), SMTP сервером, с поддержкой квот, SSL и TSL. (можно не ставить )
2.Сам контроллер домена (Ldap+samba)
3.Корпоративный кэширующий прокси сервер (SQUID). (Можно не ставить)
4.DNS сервер (Bind).
5.CUPS сервер печати
6.Управлением общими сетевыми ресурсами.
7.Служба DHCP
8.Перемещаемые профиля
*Плюс к этому MDS не ограничивает вас в службах сервера. Вы можете так же оснастить сервер к примеру NFS сервером, антивирусной защитой и т.д.
Так же есть система плагинов… которые пишутся на уровне PHP и Phyton (есть офф документация).
Собственно этот вариант мне и подошёл.
Довольно интересное решение… созданное Сергеем Бутаковым, (город Лесной Свердловской области. Написано на сайте )
Распространяется в качестве готового дистрибутива основанного на GNU/Linux (какой именно непонятно).
Это специализированный дистрибутив, заточенный только под надобности сервера. По поводу того, можно ставить на него ещё что ни будь или нет… ничего не могу сказать.
Управление производится на уровне консоли а так же имеется удобный web интерфейс.
Основные возможности
Централизованное управление учётными данными пользователей
Сервер динамической сетевой настройки узлов (DHCP)
Первичный контроллер Samba домена (совместимый с MS Windows NT4 PDC) с поддержкой перемещаемых профилей и домашних каталогов пользователей
Файловый сервер (протокол SMB/CIFS)
Немного не понятный проект. Распространяется в качестве готового дистрибутива на базе CentOS… в который напихано всё что можно.
«ClarkConnect мощнейшее серверное программное решение разработанное для малых и средних организаций. Тем не менее ClarkConnect поставляется с эксклюзивным перечнем функций и интегрированных служб, решение которое легко конфигурируется через удобный web-интерфейс.» (С)
Не понравился он мне тем что в нём есть много лишнего. Мне бы не хотелось делить на сервере контроллер домена и интернет шлюз.
ClarkConnect это интегрированный антивирус который проверяет на вирусы всё… почту трафик и шары. Так же это backup сервер, интернет сервер, сервер ldap, samba, VPN, Mysql, Mail, FTP и т.д.
Имеется Community Edition версия. А для тех кто хочет поддержку, могут приобрести Enterprise версию.
Так же есть неофициальный русский сайт с поддержкой.
4.Fedora Directory Server (она же 389 Directory Server)
Отличный проект. Периодически обновляющийся и имеющий большой потенциал. К сожалению детально его изучить не удалось.
Собственно Mandriva Directory Server построен на базе Fedora Directory Server. Только FDS немного глобальнее.
Здесь и поддержка синхронизации с Active Directory доменом (на базе 2000/2003 win), и управление производится через java консоль. Так же есть несколько интересных приблуд.
Используя одно из этих решений вы получаете домен уровня NT4. Тобишь Samba3+Ldap. Этот стандарт ниже чем домен на базе Windows 2003\2008.
На мой взгляд данные решения подойдут компаниям в которых парк машин не превышает 80.
Плюсы данного решения состоят в том, что оно бесплатное а так же есть возможность интегрировать БЕЗ ПРОБЛЕМ *nix машины на уровне ldap.
Windows машины ведут в домене на Linux себя как рыба в воде. Всё отлично работает, профиля сохраняются… подключаются сетевые диски и даже есть возможность реализовать частично ГРУППОВЫЕ ПОЛИТИКИ (http://hidx.wordpress.com/2009/01/28/gpo-samba-domen/), но только на уровне NT4 домена.
Глобальные GPO которые есть в Windows 2003\2008 реализовать не получится. Это в принципе основная причина которая затрудняет использование данного домена в организациях с 100+ парком машин.
Я остановился на Mandriva Directory Server на базе Debian Lenny. Вот только, внедрил я её уже в другую организацию.
В любом случае опыт который получаешь в процессе сборки домена, очень полезен.
Комментарии ( 6 )
Если нужен не абстрактный DS, а есть вполне конкретная задача вида «домен», лучше смотреть не FDS / 389DS, а FreeIPA (http://www.freeipa.org/). Пишут его люди сильно близкие к авторам FDS / 389DS, в основе все тот же FDS / 389DS, но при этом «из коробки» с ним интегрирован типовой обвес домена — dhcp, dns, ntp, kerberos и т.д.
Мое сугубое имхо — самый сильный вариант для домена из полностью Linux-машин. Samba пока что надо подстраивать руками, так что для смешанного домена работает не совсем «из коробки». Ждем доработки в следующих версиях.
Linux машина в домене Windows AD с помощью sssd и krb5
Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.
Для примера будем использовать:
Домен = contoso.com
Контроллер домена = dc.contoso.com
Запускаем терминал Ubuntu:
1. Переключаемся под рута
2. Устанавливаем необходимые пакеты
3. Редактируем /etc/krb5.conf, в качестве отступов используется табуляция
4. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:
5. Пробуем получить Kerberos ticket от имени администратора домена:
Если тикет получен успешно, то теперь можно сгенерировать Kerberos principals для данного хоста, регистр важен:
Сейчас наш хост должен отобразиться в списке компьютеров в каталоге. Если все так — удаляем полученный Kerberos ticket:
6. Создаем файл /etc/sssd/sssd.conf со следующим содержимым:
Описание параметров конфигфайла sssd можно посмотреть тут
Устанавливаем права доступа для файла sssd.conf:
Перезапускаем SSSD service
7. Редактируем настройки PAM
редактируем файл /etc/pam.d/common-session, после строки
переопределить параметры через системные настройки PAM, вызываем
и отмечаем пункты sss auth и makehomdir. Это автоматически добавит
строчку выше в common-session и она не будет перезатерта при обновлении системы.
Теперь мы можем логиниться на машине доменными пользователями, которым разрешен вход.
P.S.: Можно дать права на использование sudo доменным группам. Используя visudo, редактируем файл /etc/sudoers, или лучше, как рекомендует maxzhurkin и iluvar, создаем новый файл в /etc/sudoers.d/ и редактируем его
добавляем требуемую группу — например, Domain Admins (если в названии группы есть пробелы — их необходимо экранировать):
P.S.S.: Спасибо gotch за информацию о realmd. Очень удобно — если не нужны специфические настройки, то ввод машины в домен занимает, по сути, три (как заметил osipov_dv четыре) команды:
1. Устанавливаем нужные пакеты:
2. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:
3. Проверяем, что наш домен виден в сети:
4. Вводим машину в домен:
5. Редактируем настройки PAM
Дополнительный плюс данного варианта — сквозная авторизация на файловых ресурсах домена.
Для того чтоб при входе не указывать дополнительно к логину домен, можно добавить суффикс по умолчанию. В файле /etc/sssd/sssd.conf, в блоке [sssd] добавляем строку:
Редакторский дайджест
Присылаем лучшие статьи раз в месяц
Скоро на этот адрес придет письмо. Подтвердите подписку, если всё в силе.
Похожие публикации
Search Ads официально возвращается в Россию
Как (и зачем) бесплатно парсить ключи и объявления конкурентов из Яндекс.Директ и Google Ads
13 примеров настройки правил в Google Ads [инструкция]
Курсы
AdBlock похитил этот баннер, но баннеры не зубы — отрастут
Комментарии 31
(у вас в начале текста contoso.com потом contoso.domain)
Лучше добавить — «используя visudo»
Файлы в /etc/sudoers.d/ правятся по тем же правилам, что и /etc/sudoers:
Просто так править файлы в /etc/sudoers.d/ не стоит
На счет PBIS ничего сказать не могу, не пробовал, но вот на счет GSSAPI — SMB:
Так тут GSSAPI как раз используется. Есть одно немаловажное различие: SMB не говорит в чем у него проблема при попытке ввода в домен — просто с ошибкой вываливается, а msktutil при —verbose говорит. Например:
modify_ext: ldap_modify_ext_s failed (Insufficient access)
ldap modification of CN=…
failed while trying to change msDs-supportedEncryptionTypes to 28.
Error was: Insufficient access