Содержание
Введение
Зачастую возникает необходимость ввести Linux-машину в существующий домен Windows. Например, чтобы сделать файловый сервер с помощью Samba. Сделать это очень просто, для этого вам понадобятся клиент Kerberos, Samba и Winbind.
Перед установкой желательно обновиться:
sudo aptitude update sudo aptitude upgrade
Установить всё это добро можно командой:
sudo aptitude install krb5-user samba winbind
Также может понадобиться установить следующие библиотеки:
sudo aptitude install libpam-krb5 libpam-winbind libnss-winbind
Либо, если вы используете Ubuntu Desktop, те же пакеты можно поставить через менеджер пакетов Synaptic.
Далее вам потребуется настроить все вышеперечисленные инструменты для работы с вашим доменом. Допустим, вы хотите войти в домен DOMAIN.COM, доменконтроллером которого является сервер dc.domain.com с IP адресом 192.168.0.1. Этот же сервер является и первичным DNS сервером домена. Кроме того допустим у вас есть второй доменконтроллер1), он же DNS — dc2.domain.com с IP 192.168.0.2. Ваш же компьютер будет называться smbsrv01.
Настройка DNS
Для начала необходимо изменить настройки DNS на вашей машине, прописав в качестве DNS сервера доменконтроллер2) и в качестве домена поиска — нужный домен.
Если у вас статический IP-адрес, то в Ubuntu Desktop это можно сделать через Network Manager, в Ubuntu Server необходимо изменить содержимое файла /etc/resolv.conf
на примерно такое:
domain domain.com search domain.com nameserver 192.168.0.1 nameserver 192.168.0.2
В современных дистрибутивах файл resolv.conf создается автоматически и править вручную его не нужно.
Для получение нужного результата нужно добавить необходимые изменения в файл: /etc/resolvconf/resolv.conf.d/head
Данные которые будут добавлены в него, будут автоматически вставлены в файл /etc/resolv.conf
Если IP-адрес динамический и присваивается DHCP сервером то после перезагрузки resolv.conf может формироваться «неправильный» resolv.conf’ , например присутствует только один nameserver 192.168.0.1 и не указаны domain и search. Нужно отредактировать /etc/dhcp/dhclient.conf
. Чтобы появились записи domain и search нужно убрать комментарий перед строкой supersede domain-name, и вписать свой домен:
supersede domain-name "domain.com";
Чтобы добавить еще один nameserver нужно убрать комментарий перед prepend domain-name-servers и указать ip сервера:
prepend domain-name-servers 192.168.0.2;
Для применения изменений остается перезапустить службу:
/etc/init.d/networking restart
Теперь убедитесь, что вы задали нужное имя компьютера в файле /etc/hostname
:
smbsrv01
Кроме того необходимо отредактировать файл /etc/hosts
так, чтобы в нём была запись с полным доменным именем компьютера и обязательно коротким именем хоста, ссылающаяся на один из внутренних IP:
# Имена этого компьютера 127.0.0.1 localhost 127.0.1.1 smbsrv01.domain.com smbsrv01
Сразу нужно проверить что нормально пингуется наш контроллер домена, по короткому и полному имени, чтобы в будушем не получать ошибки что контроллер домена не найден:
ping dc ping dc.domain.com
Не обязательно, но если вы что-то поменяете — перезагрузите компьютер для применения изменений.
Настройка синхронизации времени
Далее необходимо настроить синхронизацию времени с доменконтроллером. Если разница будет более 5 минут мы не сможем получить лист от Kerberos.
Для единовременной синхронизации можно воспользоваться командой:
sudo net time set dc
Если в сети существует сервер точного времени, то можно воспользоваться им или любым публичным:
ntpdate ntp.mobatime.ru
Автоматическая же синхронизация настраивается с помощью ntpd
, это демон будет периодически выполнять синхронизацию. Для начала его необходимо установить:
sudo aptitude install ntp
Теперь исправьте файл /etc/ntp.conf
, добавив в него информацию о вашем сервере времени:
# You do need to talk to an NTP server or two (or three). server dc.domain.com
После чего перезапустите демон ntpd
:
sudo /etc/init.d/ntp restart
Теперь пора настраивать непосредственно взаимодействие с доменом.
Настройка авторизации через Kerberos
Начнём с настройки авторизации в домене через протокол Kerberos. Вам потребуется изменить файл /etc/krb5.conf
. В общем случае он выглядит так:
[libdefaults] default_realm = DOMAIN.COM kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true v4_instance_resolve = false v4_name_convert = { host = { rcmd = host ftp = ftp } plain = { something = something-else } } fcc-mit-ticketflags = true [realms] DOMAIN.COM = { kdc = dc kdc = dc2 admin_server = dc default_domain = DOMAIN.COM } [domain_realm] .domain.com = DOMAIN.COM domain.com = DOMAIN.COM [login] krb4_convert = false krb4_get_tickets = false
Вам, конечно, нужно изменить domain.com
на ваш домен и dc
и dc2
на ваши доменконтроллеры. Кстати, возможно вам понадобится написать полные имена доменконтроллеров dc.domain.com
и dc2.domain.com
. Поскольку у меня прописан домен поиска в DNS, то мне это делать не нужно.
Обратите особое внимание на регистр написания имени домена — везде, где домен написан в верхнем регистре, его обязательно нужно писать именно в верхнем регистре. Иначе волшебным образом ничего может не заработать.
Это не все возможные опции настройки Kerberos, только основные. Однако их обычно достаточно.
Теперь настало время проверить, что мы можем авторизоваться в домене. Для этого выполните команду
kinit username@DOMAIN.COM
Вместо username естественно стоит вписать имя существующего пользователя домена.
Имя домена необходимо писать заглавными буквами!
Если вы не получили никаких ошибок — значит вы настроили всё верно и домен отдаёт вам билет Kerberos. Кстати, некоторые распространённые ошибки перечислены чуть ниже.
Убедиться в том, что билет получен, можно выполнив команду
klist
Удалить все билеты (они вам вообще говоря не нужны) можно командой
kdestroy
Итак, будем считать, что авторизацию вы настроили, пора настроить непосредственно вход в домен, об этом после списка распространённых ошибок kinit
.
Распространённые ошибки kinit
kinit(v5): Clock skew too great while getting initial credentials
Это значит, что у вашего компьютера не синхронизировано время с доменконтроллером (см. выше).
kinit(v5): Preauthentication failed while getting initial credentials
Вы ввели неверный пароль.
kinit(v5): KDC reply did not match expectations while getting initial credentials
Самая странная ошибка. Убедитесь, что имя realm в krb5.conf
, а так же домен в команде kinit
введены большими буквами:
DOMAIN.COM = { # ...
kinit username@DOMAIN.COM
kinit(v5): Client not found in Kerberos database while getting initial credentials
Указанного пользователя не существует в домене.
Настройка Samba и вход в домен
Для того, чтобы войти в домен, необходимо прописать правильные настройки в файле /etc/samba/smb.conf
. На данном этапе вас должны интересовать только некоторые опции из секции [global]
. Ниже — пример части файла конфигурации Samba с комментариями по поводу значения важных параметров:
[global] # Эти две опции нужно писать именно в заглавном регистре, причём workgroup без # последней секции после точки, а realm - полное имя домена workgroup = DOMAIN realm = DOMAIN.COM # Эти две опции отвечают как раз за авторизацию через AD security = ADS encrypt passwords = true # Просто важные dns proxy = no socket options = TCP_NODELAY # Если вы не хотите, чтобы самба пыталась при случае вылезти в лидеры в домене или рабочей группе, # или даже стать доменконтроллером, то всегда прописывайте эти пять опций именно в таком виде domain master = no local master = no preferred master = no os level = 0 domain logons = no # Отключить поддержку принтеров load printers = no show add printer wizard = no printcap name = /dev/null disable spoolss = yes
После того, как вы отредактируете smb.conf
выполните команду
testparm
Она проверит вашу конфигурацию на ошибки и выдаст суммарную сводку о нём:
# testparm Load smb config files from /etc/samba/smb.conf Loaded services file OK. Server role: ROLE_DOMAIN_MEMBER Press enter to see a dump of your service definitions
Как видно мы задали правильные параметры для того, чтобы наш компьютер стал членом домена. Теперь пора попытаться непосредственно войти в домен. Для этого введите команду:
net ads join -U username -D DOMAIN
И в случае успеха вы увидите что-то похожее на:
# net ads join -U username -D DOMAIN Enter username's password: Using short domain name -- DOMAIN Joined 'SMBSRV01' to realm 'domain.com'
Используемые параметры команды net
-U username%password
: Обязательный параметр, вместо username
необходимо подставить имя пользователя с правами администратора домена, и указать пароль.
-D DOMAIN
: DOMAIN
— собственно сам домен, домен можно и не указывать, но лучше всё же это всегда делать — хуже не будет.
-S win_domain_controller
: win_domain_controller
, можно не указывать, но бывают случаи когда автоматически сервер не находит контроллер домена.
createcomputer=«OU/OU/…»
: В AD часто используется OU (Organizational Unit), есть в корне домена OU = Office, в нем OU = Cabinet, чтобы сразу добавить в нужный можно указать так: sudo net ads join -U username createcomputer=«Office/Cabinet».
Если больше никаких сообщений нет — значит всё хорошо. Попробуйте попинговать свой компьютер по имени с другого члена домена, чтобы убедиться, что в домене всё прописалось так, как надо.
Так же можно набрать команду:
net ads testjoin
Если все хорошо, можно увидеть:
#net ads testjoin Join is OK
Но иногда после сообщения о присоединении к домену выдаётся ошибка наподобие3):
DNS update failed!
Это не очень хорошо, и в этом случае рекомендуется ещё раз прочитать раздел про настройку DNS чуть выше и понять, что же вы сделали не так. После этого нужно удалить компьютер из домена и попытаться ввести его заново. Если вы твердо уверены, что всё настроили верно, а DNS всё равно не обновляется, то можно внести вручную запись для вашего компьютера на ваш DNS сервер и всё будет работать. Конечно, если нет никаких других ошибок, и вы успешно вошли в домен. Однако лучше всё же разберитесь, почему DNS не обновляется автоматически. Это может быть связано не только с вашим компьютером, но и с некорректной настройкой AD.
Прежде чем выяснять, почему же не обновляется DNS, не забудьте перезагрузить компьютер после введения в домен! Вполне возможно, что это решит проблему.
Если всё прошло без ошибок, то поздравляем, вы успешно вошли в домен! Можете заглянуть в AD и убедиться в этом. Кроме того хорошо бы проверить, что вы можете видеть ресурсы в домене. Для этого установите smbclient
:
sudo aptitude install smbclient
Теперь можно просматривать ресурсы компьютеров домена. Но для этого нужно иметь билет kerberos, т.е. если мы их удалили, то получаем опять через kinit (см. выше). Посмотрим какие ресурсы предоставлены в сеть компьютером workstation
:
smbclient -k -L workstation
Вы должны увидеть список общих ресурсов на этом компьютере.
Настройка Winbind
Если вам необходимо как-либо работать с пользователями домена, например, настраивать SMB-шары с разграничением доступа, то вам понадобится кроме самой Samba ещё и Winbind — специальный демон, служащий для связи локальной системы управления пользователями и группами Linux с сервером Active Directory. Проще говоря Winbind нужен, если вы хотите видеть пользователей домена на своём компьютере с Ubuntu.
Winbind позволяет спроецировать всех пользователей и все группы AD в вашу Linux систему, присвоив им ID из заданного диапазона. Таким образом вы сможете назначать пользователей домена владельцами папок и файлов на вашем компьютере и выполнять любые другие операции, завязанные на пользователей и группы.
Для настройки Winbind используется всё тот же файл /etc/samba/smb.conf
. Добавьте в секцию [global]
следующие строки:
# Опции сопоставления доменных пользователей и виртуальных пользователей в системе через Winbind. # Диапазоны идентификаторов для виртуальных пользователей и групп. idmap uid = 10000 - 40000 idmap gid = 10000 - 40000 # Эти опции не стоит выключать. winbind enum groups = yes winbind enum users = yes # Использовать домен по умолчанию для имён пользователей. Без этой опции имена пользователей и групп # будут использоваться с доменом, т.е. вместо username - DOMAIN\username. # Возможно именно это вам и нужно, однако обычно проще этот параметр включить. winbind use default domain = yes # Если вы хотите разрещить использовать командную строку для пользователей домена, то # добавьте следующую строку, иначе в качестве shell'а будет вызываться /bin/false template shell = /bin/bash # Для автоматического обновления билета Kerberos модулем pam_winbind.so нужно добавить строчку winbind refresh tickets = yes
Параметры :
idmap uid = 10000 — 40000
idmap gid = 10000 — 40000
в новых версиях Samba уже устарели и при проверке конфига самбы с помощью testparm
будет выдваться предупреждение:
WARNING: The «idmap uid» option is deprecated
WARNING: The «idmap gid» option is deprecated
Чтобы убрать предупреждения нужно заменить эти строки на новые:
idmap config * : range = 10000-20000
idmap config * : backend = tdb
Теперь перезапустите демон Winbind и Samba в следующем порядке:
sudo /etc/init.d/winbind stop sudo smbd restart sudo /etc/init.d/winbind start
Запускаем
sudo testparm
Смотрим есть ли ошибки или предупреждения, если появится:
«rlimit_max: rlimit_max (1024) below minimum Windows limit (16384)»
Без перезагрузки можно устранить так:
ulimit -n 16384
Для сохранения после перезагрузки отредактировать файл /etc/security/limits.conf
# Добавить в конец файла строки: * - nofile 16384 root - nofile 16384
После перезапуска проверьте, что Winbind установил доверительные отношения с AD командой:
# wbinfo -t checking the trust secret for domain DCN via RPC calls succeeded
А так же, что Winbind увидел пользователей и группы из AD командами4):
wbinfo -u wbinfo -g
Эти две команды должны выдать список пользователей и групп из домена соответственно. Либо с префиксом DOMAIN\
, либо без него — в зависимости от того, какое значение вы указали параметру «winbind use default domain» в smb.conf
.
Итак, Winbind работает, однако в систему он ещё не интегрирован.
Добавление Winbind в качестве источника пользователей и групп
Для того, чтобы ваша Ubuntu прозрачно работала с пользователями домена, в частности, чтобы вы могли назначать пользователей домена владельцами папок и файлов, необходимо указать Ubuntu использовать Winbind как дополнительный источник информации о пользователях и группах.
Для этого измените две строчки в файле /etc/nsswitch.conf
:
passwd: compat group: compat
добавив к ним в конец winbind
:
passwd: compat winbind group: compat winbind
также рекомендую привести строку files в файле /etc/nsswitch.conf
к виду:
files: dns mdns4_minimal[NotFoud=return] mdns4
ubuntu server 14.04, файл /etc/nsswitch.conf
не содержал строку
«files: dns mdns4_minimal[NotFoud=return] mdns4»
вместо неё было:
«hosts: files mdns4_minimal [NOTFOUND=return] dns wins»
Которую я преобразовал в:
«hosts: dns mdns4_minimal[NotFoud=return] mdns4 files»
после чего всё заработало
Теперь проверьте, что Ubuntu запрашивает у Winbind информацию о пользователях и группах, выполнив
getent passwd getent group
Первая команда должна вам вернуть всё содержимое вашего файла /etc/passwd
, то есть ваших локальных пользователей, плюс пользователей домена с ID из заданного вами в smb.conf
диапазона. Вторая должна сделать тоже самое для групп.
Теперь вы можете взять любого пользователя домена и сделать его, например, владельцем какого-нибудь файла.
Авторизация в Ubuntu через пользователей домена
Несмотря на то, что все пользователи домена фактически стали полноценными пользователями системы (в чём можно убедиться, выполнив последние две команды из предыдущего раздела), зайти ни под кем из них в систему всё ещё нельзя. Для включения возможности авторизации пользователей домена на компьютере с Ubuntu необходимо настроить PAM на работу с Winbind.
Он-лайн авторизация
Для Ubuntu 10.04 и выше добавьте всего одну строку в файле /etc/pam.d/common-session
, т.к. PAM и так неплохо справляется с авторизацией:
session optional pam_mkhomedir.so skel=/etc/skel/ umask=0077
Для Ubuntu 13.10 чтобы появилось поле ручного ввода логина необходимо в любой файл из папки /etc/lightdm/lightdm.conf/
снизу добавить строку:
greeter-show-manual-login=true
Для Ubuntu 9.10 и ниже придется редактировать несколько файлов (но никто не запрещает использовать этот способ и в 10.04 — он тоже работает):
Последовательность строк в файлах имеет значение!
/etc/pam.d/common-auth
auth required pam_env.so auth sufficient pam_unix.so likeauth nullok try_first_pass auth sufficient pam_winbind.so use_first_pass krb5_auth krb5_ccache_type=FILE auth required pam_deny.so
/etc/pam.d/common-account
account sufficient pam_winbind.so account required pam_unix.so
/etc/pam.d/common-session
session optional pam_mkhomedir.so skel=/etc/skel/ umask=0077 session optional pam_ck_connector.so nox11 session required pam_limits.so session required pam_env.so session required pam_unix.so
/etc/pam.d/common-password
password sufficient pam_unix.so try_first_pass use_authtok nullok sha512 shadow password sufficient pam_winbind.so password required pam_deny.so
И, наконец, необходимо перенести запуск Winbind при загрузке системы после всех остальных служб (по умолчанию он запускается с индексом 20). Для этого в терминале выполните следующую команду:
sudo bash -c "for i in 2 3 4 5; do mv /etc/rc$i.d/S20winbind /etc/rc$i.d/S99winbind; done"
Что эквивалентно запуску для каждого уровня (в примере — 4) команды:
mv /etc/rc4.d/S20winbind /etc/rc4.d/S99winbind
В некоторых случаях winbind может иметь иной уровень запуска (например, S02winbind). Поэтому сначала проверьте имена файлов, вполнив команду «ls /etc/rc{2,3,4,5}.d/ | grep winbind» (без кавычек).
Готово, все настройки завершены. Перезагружайтесь и пытайтесь войти с учетной записью пользователя домена.
Офф-лайн авторизация
Часто возникает ситуация, когда домен-контроллер недоступен по различным причинам — профилактика, отключение света или вы принесли ноутбук домой и хотите поработать. В этом случае для Winbind можно настроить кэширование учетных записей пользователей домена. Для этого необходимо сделать следующее.
Добавьте в секцию [global]
файла /etc/samba/smb.conf
следующие строки:
[global] # Возможность оффлайн-авторизации при недоступности доменконтроллера winbind offline logon = yes # Период кэширования учетных записей, по умолчанию равен 300 секунд winbind cache time = 300 # Необязательная настройка, но избавляет от нудных пауз, указываем контроллер домена dc, # можно указать и ip, но это является плохим тоном password server = dc
Обычно этого достаточно. Если же возникают ошибки, то необходимо создать файл /etc/security/pam_winbind.conf
со следующим содержанием5):
Внимание! При использовании советов ниже может возникать совершенно случайная ошибка «Сбой аутентификации»! Поэтому все что Вы делаете, Вы делаете на свой страх и риск!
# # pam_winbind configuration file # # /etc/security/pam_winbind.conf # [global] # turn on debugging debug = no # request a cached login if possible # (needs "winbind offline logon = yes" in smb.conf) cached_login = yes # authenticate using kerberos krb5_auth = yes # when using kerberos, request a "FILE" krb5 credential cache type # (leave empty to just do krb5 authentication but not have a ticket # afterwards) krb5_ccache_type = FILE # make successful authentication dependend on membership of one SID # (can also take a name) ;require_membership_of = silent = yes
Файл /etc/pam.d/gnome-screensaver
в таком случае принимает вид:
auth sufficient pam_unix.so nullok_secure auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so
А также изменяется файл /etc/pam.d/common-auth
:
auth optional pam_group.so auth sufficient pam_unix.so nullok_secure use_first_pass auth sufficient pam_winbind.so use_first_pass auth required pam_deny.so
Ссылки
В этой статье будет описан процесс добавления Linux-машины (Ubuntu 20.04) в домен Windows AD.
Шаг 1. Установка пакетов и подготовка
sudo apt updatesudo apt upgrade
После этого установите требуемые пакеты.
sudo apt -y install realmd sssd sssd-tools libnss-sss libpam-sss adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
Далее мы настроим все инструменты. Вам требуется знать:
- Домен: office.local
- IP DNS-сервера: 192.168.0.1
- IP второго DNS-сервера: 192.168.0.2
Шаг 2. Настройка DNS
Откройте конфигурационный файл netplan:
sudo nano /etc/netplan/*.yaml
Если вы видите там «dhcp4: true», то есть ваш DHCP-сервер настроен корректно, переходите к следующему шагу. Если вы настраиваете параметры сетевого подключения вручную, ознакомьтесь с примером настройки:
network:ethernets:enp0s3:addresses:- 192.168.0.15/24gateway4: 192.168.0.10nameservers:addresses: [192.168.0.1, 192.168.0.2]search:- office.localoptional: trueversion: 2
- addresses — это IP, назначаемый сетевой карте;
- gateway4 — IP роутера;
- nameservers — DNS-сервера;
- search — целевой домен.
sudo netplan apply
Шаг 3. Обнаружение домена, присоединение к нему и проверка результата.
В первую очередь требуется обнаружить домен:
realm discover office.local
Вы увидите что-то подобное. Это означает, что настройки сети верны и машина получила ответ от домена. Если нет, вам необходимо проверить настройки сети, домен и работоспособность DNS.
office.localtype: kerberosrealm-name: OFFICE.LOCALdomain-name: office.localconfigured: no...
Затем присоединитесь к домену AD. Замените admin1 на имя администратора и укажите пароль.
realm join -U admin1 office.localPassword for admin1:
Проверьте, возможен ли прием информации о пользователе AD. Замените user1 на имя пользователя вашего домена.
id user1@office.localuid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)
Шаг 4. Последние настройки и авторизация.
Необходимо произвести настройку, чтобы в будущем каждый раз не добавлять имя домена к имени пользователя.
sudo nano /etc/sssd/sssd.conf
Измените значение use_fully_qualified_names на False. Перезагрузите и проверьте:
sudo systemctl restart sssdid useruid=687821651(user1@office.local) gid=687800512(user1@office.local) groups=687800512(domain users@office.local)
Теперь нужно настроить создание домашних каталогов для пользователей AD при входе в систему.
sudo nano /etc/pam.d/common-session#add this line in the end of filesession optional pam_mkhomedir.so skel=/etc/skel umask=077
Войдите в систему как пользователь AD.
su – userPassword:Creating directory '/home/user1@office.local'.user1@ubuntu-server:~$
Это означает, что вы успешно вошли в систему как пользователь AD.
Также вы можете разрешить авторизацию для некоторых пользователей и групп AD или же ограничить других. В приведенном ниже примере настроен запрет для всех пользователей, кроме user0, user1 и группы Main Admins.
sudo realm deny –allsudo realm permit user0@office.local user1@office.localsudo realm permit -g 'Main Admins'
Настройка пользователей AD для получения root-прав такая же, как и для локальных, но выполняется в другом файле.
sudo nano /etc/sudoers.d/admins
Добавьте к нему нужные строки. Например:
user ALL=(ALL) ALL%Domain\\ Admins ALL=(ALL) ALL
191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А
+7 (812) 403-06-99
700
300
ООО «ИТГЛОБАЛКОМ ЛАБС»
191028
Санкт-Петербург
Литейный пр., д. 26, Лит. А
+7 (812) 403-06-99
700
300
ООО «ИТГЛОБАЛКОМ ЛАБС»
Время на прочтение
3 мин
Количество просмотров 91K
Была необходимость ввести в домен Windows машину с Ubuntu. Для этих целей обычно используют Samba и Winbind. Но возможен альтернативный вариант с sssd, краткое руководство по нему ниже.
Для примера будем использовать:
Домен = contoso.com
Контроллер домена = dc.contoso.com
Запускаем терминал Ubuntu:
1. Переключаемся под рута
sudo -i
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 <hostname>.contoso.com <hostname>
5. Пробуем получить Kerberos ticket от имени администратора домена:
root@ubuntu:~# kinit YourDomainAdmin
YourDomainAdmin@CONTOSO.COM's Password:
Проверяем:
root@ubuntu:~# 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:
kdestroy
6. Создаем файл /etc/sssd/sssd.conf со следующим содержимым:
[sssd]
services = nss, pam
config_file_version = 2
domains = contoso.com
[nss]
entry_negative_timeout = 0
debug_level = 3
[pam]
debug_level = 3
[domain/contoso.com]
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 = <HOSTNAME>$
ldap_krb5_init_creds = true
krb5_keytab = /etc/sssd/<HOSTNAME>.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, вызываем
pam-auth-update
и отмечаем пункты sss auth и makehomdir. Это автоматически добавит
строчку выше в common-session и она не будет перезатерта при обновлении системы.
Теперь мы можем логиниться на машине доменными пользователями, которым разрешен вход.
P.S.: Можно дать права на использование sudo доменным группам. Используя visudo, редактируем файл /etc/sudoers, или лучше, как рекомендует maxzhurkin и iluvar, создаем новый файл в /etc/sudoers.d/ и редактируем его
visudo -f /etc/sudoers.d/ваш_файл
добавляем требуемую группу — например, Domain Admins (если в названии группы есть пробелы — их необходимо экранировать):
%Domain\ Admins ALL=(ALL) ALL
P.S.S.: Спасибо gotch за информацию о realmd. Очень удобно — если не нужны специфические настройки, то ввод машины в домен занимает, по сути, три (как заметил osipov_dv четыре) команды:
1. Устанавливаем нужные пакеты:
sudo apt install realmd samba-common-bin samba-libs sssd-tools krb5-user adcli
2. Редактируем файл /etc/hosts, указываем FQDN для данного хоста:
127.0.0.1 localhost
127.0.1.1 <hostname>.contoso.com <hostname>
3. Проверяем, что наш домен виден в сети:
realm discover contoso.com
4. Вводим машину в домен:
sudo realm --verbose join contoso.com -U YourDomainAdmin --install=/
5. Редактируем настройки PAM
sudo pam-auth-update
Дополнительный плюс данного варианта — сквозная авторизация на файловых ресурсах домена.
Для того чтоб при входе не указывать дополнительно к логину домен, можно добавить суффикс по умолчанию. В файле /etc/sssd/sssd.conf, в блоке [sssd] добавляем строку:
default_domain_suffix = contoso.com
In this short guide we will learn how to connect machine with Ubuntu (20.04) installation to Active Directory.
Before we begin
Domain data:
I already set Active Directory on Windows Server 2019 Standard.
Domain name: winlin.local
Domain Controller name: WinLinDC
Domain Controller IP address: 10.0.0.31/24
Active Directory DNS IP: 10.0.0.31/24
I installed DNS on the domain controller itself.
I also created domain user named: zeljko.m@winlin.local
Ubuntu client data:
I used Ubuntu 20.04 as a client for this guide.
Machine name: winlinubcl2
Machine IP address: 10.0.0.34
Prerequisites
Updates
First, we will start with updating
sudo apt update -y
Hostname and DNS
Since we want to join Ubuntu machine (name winlinubcl2) to Windows domain named winlin.local, we need to change Ubuntu machine name to match active directory (AD) naming…
sudo hostnamectl set-hostname winlinubcl2.winlin.local
We will check machine name by entering
hostnamectl
For the DNS part, like with Windows client machine you wish to join to AD – linux machines also need to have domain controller (or separate DNS server for domain, if configured) IP address under DNS.
In my case, DNS server IP is same as my domain controller ip – 10.0.0.31.
There are a couple of ways to do this.
If your Linux machine is getting IP address and DNS from DHCP server, make sure that you are in the same network, and that DNS IP is already in domain or on domain controller.
I’m doing this manually on Ubuntu 20.04 that has GUI.So this is how my settings look like. I set everything manually.
If you are doing this on a machine without GUI, only in shell you will have to do it through netplan.
Again, check your IP settings by entering
ip a
Then check DNS settings by entering
systemd-resolve --status | grep Current
and you can also check default gateway by typing in
ip r
If there is a need to change IP and DNS settings, do following
First we need to find out how your netplan file is named. To find out type following in
ls -la /etc/netplan
My file is named 01-network-manager-all.yaml. Your may be named differently, so mark that.
Next, we need to edit that file (change 01-network-mananger-all.yaml to your filename.
sudo nano /etc/netplan/01-network-manager-all.yaml
You should enter something like this. Be very careful about indentations, because yaml files are very picky on that front.
If you want to check your indentation to be sure it is ok, you can install tool like yamllint.
network:
ethernets:
ens33:
addresses:
- 10.0.0.34/24
gateway4: 10.0.0.1
nameservers:
addresses:
- 10.0.0.31
version: 2
To apply changes type in
sudo netplan apply
Ok ,that is it for the hostnames and DNS, I like to reboot machine after these settings to be sure everything is fine.
Installation
We will now install all required packages for our domain join adventure
sudo apt update -y
sudo apt -y install realmd libnss-sss libpam-sss sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
Discover domain
We will now check if we can discover our windows domain. Change winlin.local for your domain name.
sudo realm discover winlin.local
The information we got back is good, we can proceed further.
Add Ubuntu machine to Active Directory
Finally, we will join our Ubuntu machine to our windows domain.
Change Administrator if the account name of your domain admin is different. Change winlin.local to your domain name.
The command is
sudo realm join -U Administrator winlin.local
If everything went ok, you will be asked for your domain admin password, and that will be it.
Let’s check if the authentication is working and we can get id of domain users. I will use domain user named zeljko.m@winlin.local, change that for your domain user and domain name.
id zeljko.m@winlin.local
If we go to the Windows Server 2019 that serves as a domain controller for winlin.local domain, under Users and Computers in Computers container we can see that winLinUbCL2 machine is added to the domain. That is great.
Before we do a first login from Ubuntu to Windows Domain
First, we will set creation of home directories for domain users.
We need to edit
sudo nano /etc/pam.d/common-session
and enter following to the end of the file
session optional pam_mkhomedir.so skel=/etc/skel umask=077
Optionally, you can set your system to login only using name without domain part. So, I could login to my Ubuntu install by only using zeljko.m instead of zeljko.m@winlin.local.
If you wish to enable this:
sudo nano /etc/sssd/sssd.conf
Change line use_fully_qualified_names = True to
use_fully_qualified_names = False
Ok, let’s now try and login with our domain user to our Ubuntu machine.
su - zeljko.m@winlin.local
If we done everything correctly, we should be prompted for domain users password, and there should also be message that home directory for the user is created.
Limit access for domain users to ssh/console
If you want to permit user to access ssh or console, you will use following command. By the way, on my Ubuntu 20.04 install domain users can login via ssh to Ubuntu install by default.
To permit access to user, use following
sudo realm permit zeljko.m@winlin.local
To permit access to group, type in following
sudo realm permit -g 'Domain Admins'
Practical way would be, to deny login to all, and then add permits to exceptions, so that would look like this
sudo realm deny --all
sudo realm permit zeljko.m@winlin.local
sudo realm permit -g 'Domain Admins'
You can also permit all, and add multiple user or groups using one line, so that would look like
sudo realm permit --all
sudo realm permit zeljko.m@winlin.local mario.l@winlin.local
sudo realm permit -g 'Domain Admins' 'Users'
On winlinubcl1 I entered deny –all command and then tried to access that machine from winlinubcl2.
Deny works, nobody from domain can log in into winlinubcl1 machine.
After I entered permit command for user zeljko.m, he was able to login, while user mario.l was still unable to login.
Add domain users/groups as local sudoers on Ubuntu
And, the last one for this guide, domain users are unable to execute sudo commands on Ubuntu.
To change this we will have to edit sudoers file, there are a couple of ways to do it, I will show you one.
You will have to do this obviously as a local account on Ubuntu, not the domain one.
sudo usermod -aG sudo zeljko.m@winlin.local
In case you defined in sssd.conf that you don’t use domain extension then you will have to run above command without winlin.local domain extension.
Option number 2
Everything works after executing command. You can do this by also editing /etc/sudoers file.
If you do it that way, you will have to execute it with visudo
sudo visudo -f /etc/sudoers
To add sudo permissions to a user, you will have to edit
zeljko.m@winlin.local ALL=(ALL) ALL
If you wish to add a group, you will enter (in section for groups in the file)
%group1@winlin.local ALL=(ALL) ALL
This can also be done via /etc/sudoers.d/somefilename, but I haven’t managed to get it to work in Ubuntu 20.04 I have installed (I haven’t used . or ~ signs in files, or comamnds…)
Conclusion
That is it, we have basic setup for Ubuntu machine on windows domain.
Disclaimer
Do you want to be able to login to your Ubuntu machines with AD users and apply Active Directory authentication? Read here how.
1. Install required packages
Login to your Ubuntu machine via SSH. First we will need to install some packages. You can issue the following command to install everything we need:
sudo apt install -y realmd libnss-sss libpam-sss sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir packagekit
2. Update hostname of Ubuntu to AD domain
Change the hostname of the Ubuntu machine to match the AD domain. For example if the fully qualified domain of your Active Directory is “ad.mycompany”, and your ubuntu machine is called “ubuntu” then the hostname should be “ubuntu.ad.mycompany”. Change these values to match your environment.
sudo hostnamectl set-hostname ubuntu.ad.mycompany
3. Disable systemd-resolved
Next we need to disable the default systemd-resolved service. This service is installed by default on Ubuntu and acts as a local DNS/DNSSEC resolver to the Ubuntu server.
However as we will be using the Active Directory server as the authoritative DNS server, we need to disable it. Issue the following commands to disable this service:
sudo systemctl disable systemd-resolved.service sudo systemctl stop systemd-resolved.service
There is one more step, and that is that we need to configure the IP address of the AD server. Open the file “/etc/resolv.conf” in your favorite editor:
sudo nano /etc/resolv.conf
The contents of this file should look like this:
# This file is managed by man:systemd-resolved(8). Do not edit. # # This is a dynamic resolv.conf file for connecting local clients to the # internal DNS stub resolver of systemd-resolved. This file lists all # configured search domains. # # Run "resolvectl status" to see details about the uplink DNS servers # currently in use. # # Third party programs must not access this file directly, but only through the # symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way, # replace this symlink by a static file or a different symlink. # # See man:systemd-resolved.service(8) for details about the supported modes of # operation for /etc/resolv.conf. nameserver 127.0.0.53 options edns0 trust-ad search ad.mycompany
Change the following row to match the IP address of your AD server (for example 10.0.0.10):
nameserver 10.0.0.10
Save and close the file. Now we are ready to join the domain.
4. Join the AD domain
Issue the following commands to join the Linux server to the AD domain. Note: change the “Administrator” user to a user which is a Domain Admin in the AD.
realm discover ad.mycompany sudo realm join -U Administrator ad.mycompany
You will now be prompted for a password. Enter the password of the “Administrator” username you entered above. Note: this user should be part of the Domain Admin group in the AD.
After a few seconds the operation should be complete and your machine should have succesfully joined the AD. We just need to follow a few more steps to setup auto-creation of home directories.
5. Setup auto-creation of home directories
When a new user logins to the server, they don’t have a home directory by default. However we can set this up so the creation of the home directory happens automatically.
Open the file “/usr/share/pam-configs/mkhomedir” with your favorite editor.
sudo nano /usr/share/pam-configs/mkhomedir
Change the value of the 2 lines below as specified:
Default: yes Priority: 900
Additionally, delete the following line:
Session-Interactive-Only: yes
The resulting file should look like this:
Name: Create home directory on login Default: yes Priority: 900 Session-Type: Additional Session: optional pam_mkhomedir.so
Now save and close the file.
Then, issue the following command to modify the central authentication policy:
sudo pam-auth-update
A GUI screen like below should appear. Check the “create home directory on login” option (with spacebar). Afterwards press <enter> to save the changes
6. Restart SSSD service
The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. We need to restart it to make the changes we made earlier come into effect. Afterwards we will be able to logon with an AD user to the Ubuntu machine.
Restart the SSSD service with the following command:
sudo systemctl restart sssd
7. (Optional) allow only certain AD groups to login
This step is optional. However if you want to only allow a certain AD group (or groups) to login to this machine, you can specify it as follows:
First, setup a “deny all” rule to deny all AD users by default:
sudo realm deny --all
Then, configure the AD security groups that are allowed to login. For example if you want to only allow the custom group “linux users” to login, do the following:
sudo realm permit -g linux\ users@ad.mycompany
Note: the backslash is used as an escape for the ” ” space character.
8. (Optional) specify sudo permissions for AD users
Optionally, you can also specify which AD users or groups should have sudo (admin) rights on this machine. To do this, we will create a new file called “/etc/sudoers.d/domain-admins”:
sudo nano /etc/sudoers.d/domain-admins
In this file, you can create a new record for every AD user or group which need to have sudo rights. For example, to give the AD “domain admins” group sudo rights on this machine (good practice), add the following line:
%domain\ admins@ad.mycompany ALL=(ALL) ALL
Another example, if we want to give the custom AD group called “linux users” sudo rights, we would add the following:
%linux\ users@ad.mycompany ALL=(ALL) ALL
9. Ready to login with AD user
Now everything is set-up to be able to login with an AD user to your Linux server. To test this, execute the following command from either the local Linux server itself or another server in the domain:
ssh ad.mycompany\\ad_user@ip_address_of_linux_server
Enter the password of the AD user when prompted. After that you should see the following messages:
Creating directory '/home/ad_user@ad.mycompany'. Welcome to Ubuntu 20.04.3 LTS (GNU/Linux 5.11.0-40-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support: https://ubuntu.com/advantage
The Ubuntu server is now successfully joined to the Windows AD!