зачем_вводить_системы_linux_в_домен_microsoft
Table of Contents
Зачем вводить системы Linux в домен Microsoft
Анонс вебинара
Запись вебинара
Реклама вебинара
-
В интернете множество статей, описывающих добавление в домен Microsoft систем Linux. Очень часто там отсутствует ответ на главный вопрос — зачем это делать? Давайте разберемся и всегда ли это необходимо, и как вообще решать задачи Single Sign-On (SSO) и workplace innovation (WPI) при использовании домена Microsoft и рабочих станций и сервисов Linux
Техническое задание
-
На предприятии используется Microsoft Active Directory. Сотрудники должны иметь возможность с любой рабочей станции linux работать в личном окружении (рабочий стол, документы, настройки) а так же, с общими с корпоративными файлами совместно с пользователями систем Windows.
Шаг 1. Исходное состояние стенда
Система windows server
-
Учетная запись user1 в group1
-
В домене только windows система client2
-
В DNS нет linux систем
Система linux gate
-
Шлюз в Интернет
-
DHCP
Рабочие станции
windows
-
client2 введена в домен Active Directory
linux
-
client1 и clietn3
gate# dhcp-lease-list
Шаг 2. Файловый сервис на linux
-
Создаем файлы и каталоги в личном и общем сетевом ресурсе
-
Отлогиниваемся
Шаг 3. Рабочие станции на linux
3.1 Использование kerberos для работы с Microsoft AD
3.2 Работа с файловыми ресурсами Microsoft из linux
3.3 Аутентификация пользователей в linux через Microsoft Active Directory
-
Подключаемся как user1 в консоли vbox, проверяем наличие TGT, отключаемся
3.4 Автоматическое создание учетных записей после аутентификации через Microsoft Active Directory
-
Подключаемся как userN в консоли vbox, проверяем наличие TGT
3.5 Монтирование домашнего каталога ручном режиме
user1$ klist user1$ cd / # klist # cp -v /tmp/krb5cc_`id -u user1`_* /tmp/krb5cc_0 # klist # mount.cifs //gate.corp13.un/user1 -o rw,user,sec=krb5,vers=3.1.1,uid=`id -u user1`,gid=`id -g user1` /home/user1/ # ls -l /home/user1
-
Отключаемся в консоли vbox
# rm /tmp/krb5cc_0 # umount /home/user1/
3.6 Автоматическое монтирование домашнего каталога
-
Использование pam_script для автоматического монтирования домашнего каталога по протоколу CIFS с GSSAPI/Kerberos аутентификацией
-
Подключаемся как user1 в консоли vbox, проверяем наличие файлов, созданных из windows в домашнем каталоге и отлогиниваемся
# umount /home/user1/
3.7 Подключение общего файлового ресурса компании пользователями linux
-
Обсуждаем описание точек монтирования в файле /etc/fstab для протокола cifs и GSSAPI аутентификация
# cat /usr/share/libpam-script/pam_script_auth
#!/bin/bash if ! id $PAM_USER &>/dev/null; then useradd -m -s /bin/bash $PAM_USER echo //gate.corp13.un/corp_share /home/$PAM_USER/Public cifs rw,user,sec=krb5,noauto,vers=3.1.1 0 0 >> /etc/fstab fi
-
Создаем в Active Directory учетную запись user2, включаем в group1 и подключаемся ей через linux GUI
Шаг 4. Клонируем конфигурацию рабочей станции
gate# dhcp-lease-list gate# client1=192.168.13.101 gate# clientN=192.168.13.102 gate# ssh $clientN clientN# DEBIAN_FRONTEND=noninteractive apt -y install krb5-user cifs-utils nfs-common libpam-krb5 libpam-script gate# scp -3 $client1:/etc/krb5.conf $clientN:/etc/ gate# scp -3 $client1:/etc/pam.d/common-auth $clientN:/etc/pam.d/ gate# scp -3 $client1:/usr/share/libpam-script/pam_script_auth $clientN:/usr/share/libpam-script/ gate# scp -3 $client1:/usr/share/libpam-script/pam_script_ses_open $clientN:/usr/share/libpam-script/
Исправления и альтернативные варианты
0. Wrong path for pam_script.so
1. Создание несуществующих в AD учетных записей
В вебинаре создание учетной записи происходит до проверки ее подлинности, поэтому лучше расположить модули так:
# cat /etc/pam.d/common-auth
... auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000 auth [success=1 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_deny.so auth sufficient pam_script.so auth required pam_permit.so ...
2. Через 10 часов сессия монтирования домашнего каталога устаревает
Вариант решения — не удалять в скрипте /tmp/krb5cc_0 и обновлять TGT через cron
client1:~# crontab -l
0 */8 * * * kinit -R >/dev/null 2>&1
Усиливается проблема (уже была) параллельного подключения нескольких пользователей к рабочей станции
3. Желательно удалять возможные записи для пользователя в /etc/fstab перед его созданием в скрипте
Особенно, если для отладки пользователи постоянно создаются/удаляются
... sed -i.bak -e "//home/$PAM_USER/d" /etc/fstab ...
4. Можно поручить монтирование домашних каталогов systemd
# cat /usr/share/libpam-script/pam_script_auth
#!/bin/bash if ! id $PAM_USER &>/dev/null; then useradd -m -s /bin/bash $PAM_USER sed -i.bak -e "//home/$PAM_USER/d" /etc/fstab echo //gate.corp13.un/$PAM_USER /home/$PAM_USER cifs rw,user,sec=krb5,noauto,vers=3.1.1,uid=`id -u $PAM_USER`,gid=`id -g $PAM_USER` 0 0 >> /etc/fstab echo //gate.corp13.un/corp_share /home/$PAM_USER/Public cifs rw,user,sec=krb5,noauto,vers=3.1.1 0 0 >> /etc/fstab systemctl daemon-reload fi
# cat /usr/share/libpam-script/pam_script_ses_open
#!/bin/sh cp /tmp/krb5cc_`id -u $PAM_USER`* /tmp/krb5cc_0
· Last modified: 2022/10/15 21:33 by
val
Содержание
Введение
Зачастую возникает необходимость ввести 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 - DOMAINusername. # Возможно именно это вам и нужно, однако обычно проще этот параметр включить. 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
ООО «ИТГЛОБАЛКОМ ЛАБС»
Перед администраторами иногда встают задачи интеграции Linux серверов и рабочих станций в среду домена Active Directory. Обычно требуется:
1. Предоставить доступ к сервисам на Linux сервере пользователям домена.
2. Пустить на Linux сервер администраторов под своими доменными учётными данными.
3. Настроить вход на Linux рабочую станцию для пользователей домена, причём желательно, чтобы они могли при этом вкусить все прелести SSO (Я, например, не очень люблю часто вводить свой длинный-предлинный пароль).
Обычно для предоставления Linux системе пользователей и групп из домена Active Directory используют winbind либо настраивают библиотеки nss для работы с контроллером домена Active Directory по LDAP протоколу. Но сегодня мы пойдём иным путём: будем использовать PowerBroker Identity Services (Продукт известен также под именем Likewise).
Установка.
Есть две версии продукта: Enterprise и Open. Мне для реализации моих задач хватило Open версии, поэтому всё написанное далее будет касаться её.
Получить Open версию можно на сайте производителя, но ссылку Вам предоставят в обмен на Ваше имя, название компании и e-mail.
Существуют 32-х и 64-х пакеты в форматах rpm и deb. (А также пакеты для OS X, AIX, FreeBSD, SOlaris, HP-UX)
Исходники (Open edition) доступны в git репозирории: git://source.pbis.beyondtrust.com/pbis.git
Я устанавливал PBIS на Debian Wheezy amd64:
Содержимое пакета устанавливается в /opt/pbis. Также в системе появляется новый runscript lwsmd, который собственно запускает агента PBIS.
В систему добавляется модуль PAM pap_lsass.so.
Утилиты (большей частью консольные), необходимые для функционирования PBIS, а также облегчающие жизнь администратору размещаются в /opt/pbis/bin
Ввод в домен.
Перед вводом в домен следует убедиться, что контроллеры домена доступы и доменные имена корректно разворачиваются в ip. (Иначе следует настроить resolv.conf)
Для ввода в домен предназначены две команды: /opt/pbis/bin/domainjoin-cli и /opt/pbis/bin/domainjoin-gui. Одна из них работает в командной строке, вторая использует libgtk для отображения графического интерфеса.
Для ввода в домен потребуется указать: имя домена, логин и пароль доменного пользователя с правами для ввода ПК в домен, контейнер для размещения объекта компьютера в домене — всё то же самое, что и при вводе в домен windows ПК.
После ввода в домен потребуется перезагрузка.
Обратите внимание — PBIS умеет работать с сайтами Active Directory. Клиент PBIS будет работать с контроллерами того сайта, в котором он находится!
После перезагрузки.
После перезагрузки и id, и getent выдадут вам пользователей и группы домена (национальные символы обрабатываются корректно. Пробелы заменяются на символ "^").
В доменной DNS зоне появится запись с именем вашего ПК.
Не спешите входить от имени доменного пользователя. Сначала имеет смысл (но вовсе не обязательно) настроить PBIS.
Одно из отличий Enterprise версии — возможность управлять этими настройками через GPO.
Стоит обратить внимание на HomeDirPrefix, HomeDirTemplate.
Я также сразу задал «RequireMembershipOf — только пользователи, члены групп или SID из этого списка могут авторизоваться на компьютеры.
Описание каждого параметра можно получить, например так:
Значение параметра устанавливается например так:
Обратите внимание — PBIS не использует атрибуты SFU либо иные другие атрибуты Acrive Directory для получения loginShell пользователя, а также его uid и gid.
loginShell для доменных пользователей задаётся в настройках PBIS, причём установка различных loginShell различным пользователям — возможна только в Enterprise версии.
uid формируется как хэш SID пользователя.
gid — как хэш SID primaryGroup пользователя.
Таким образом на двух ПК пользователь получит всегда одинаковые uid и gid.
Теперь можно входить в систему от имени доменного пользователя. После входа доменного пользователя обратите внимание на вывод klist — PBIS получит для пользователя необходимые билеты kerberos. После этого можно безпроблемно обращаться к ресурсам на windows ПК (Главное, чтобы используемое ПО поддерживало GSSAPI). Например: теперь я без дополнительных запросов паролей (и пароль мой нигде не сохранён!) открываю любые smb ресурсы домена в Dolphin. Также Firefox (при настройке network.negotiate-auth.trusted-uris) позволяет использовать SSO при доступе к Web-порталам с доменной авторизацией (естественно если SSO настроена на сервере)
А как же SSO при доступе к ресурсам на Linux ПК?
Можно и так! PBIS заполняет /etc/krb5.keytab и поддерживает его актуальным. Поэтому серверное ПО с поддержкой GSSAPI может быть сконфигурировано для SSO.
Например, для доступа к серверу по ssh, в конфигурационный файл /etc/ssh/sshd_config (путь в вашей системе может отличаться)
И при подключении указать доменное имя компьютера (присутствующее в его SPN — иначе билет kerberos не сможет быть выписан)
UsePAM yes
(PBIS предоставляет модуль для PAM в том числе)
Также логично будет добавить директиву AllowGroups и указать через пробел доменные группы, пользователям которых вы намерены дать доступ к ssh серверу.
На клиентском Linux ПК в конфигурацию клиента ssh достаточно включить:
Естественно на клиентском Linux компьютере должен быть настроен kerberos. Простейший способ выполнить это условие — так же ввести клиентский компьютер в домен и работать от имени доменного пользователя.
На клиентском Windows ПК (члене домена) при использовании Putty следует в свойствах SSH соединения установить флаг Attempt GSSAPI authentification (SSH-2 only) (В разных версиях этот пункт называется по-разному).
Также в секции Connection —> Data можно поставить переключатель в позицию Use system username
Если вы намереваетесь организовать таким образом ssh доступ администраторов к linux серверам — хорошей идеей будет запретить на них вход root по ssh и добавить linux-администраторов (а ещё лучше их доменную группу) в файл sudoers.
Это не единственные сценарии применения PBIS. если статья покажется Вам интересной — в следующей напишу как организовать samba файловый сервер в домене для доменных пользователей без winbind.
Дополнительную информацию по теме можно получить на форуме сообщества PowerBroker Identity Services: forum.beyondtrust.com
UPD. К преимуществам PowerBroker Identity Services я могу отнести:
- Хорошую повторяемость (сравните последовательность действий этой статье с инструкцией по настройке winbind)
- Кэширование данных из каталога (доменный пользователь может войти на ПК, когда домен не доступен, если его учётные данные в кэше)
- Для PBIS не требуется формирование в каталоге AD дополнительных атрибутов пользователя
- PBIS понимает сайты AD и работает с контроллерами своего сайта.
- Большую безопасность (samba создаёт учётку компьютера с не истекающим паролем)
- В платной версии (если возникнет такая необходимость) PBIS агент управляем через GPO (хотя это можно и вычеркнуть. если вы не намерены её покупать)
UPD 2 Пришла обратная связь от пользователя sdemon72. Возможно кому-то будет полезно.
Здравствуйте! Попробовал ваш рецепт на свежей linuxmint-18-mate-64bit, все получилось с некоторыми оговорками: 1. С получением программы через сайт у меня возникли сложности (не захотел писать реальный номер телефона, а бутафорский не прокатил — пришло письмо с сомнениями по его поводу), зато нашел репозиторий с наисвежайшими версиями: repo.pbis.beyondtrust.com/apt.html 2. При запуске программы выдает ошибки, чтобы их избежать, нужно перед запуском сделать следующее: 2.1. Установить ssh: sudo apt-get install ssh 2.2. Поправить /etc/nsswitch.conf: hosts: files dns mdns4_minimal [NOTFOUND=return] (т.е. переносим dns с конца строки на вторую позицию) 2.3. Поправить /etc/NetworkManager/NetworkManager.conf: #dns=dnsmasq (т.е. комментируем эту строчку) 2.4. Перезапустить network-manager: sudo service network-manager restart
После этого все сработало на ура! Буду очень благодарен, если внесете эти дополнения в статью, т.к. в поиске по сабжу она выпадает в первых строках. Оставлять комментарии я не могу (запрещает сайт), поэтому пишу вам лично.
Если интересно — история моих изысканий тут: linuxforum.ru/topic/40209
С уважением, Дмитрий
UPD 3: Почему бесплатную версию PBIS не получится применить в большой компании
В бесплатной версии работает только один алгоритм генерации UNIX iD (uid и gid) по SID доменного пользователя. Так вот он не обеспечивает уникальности
этих идентификаторов. Когда у вас очень старый домен или просто много пользователей очень высок риск, что два и более пользователя получат одинаковые идентификаторы в системе с OpenPBIS. В платной версии есть возможность выбора между алгоритмами генерации id, но она стоит значительно дороже аналогичного продукта от Quest Software ;(.
Источник
Введение
Зачастую возникает необходимость ввести 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
Не обязательно, но если вы что-то поменяете — перезагрузите компьютер для применения изменений.
Настройка синхронизации времени
Настройка авторизации через 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 [email protected]
Вместо username естественно стоит вписать имя существующего пользователя домена.
Имя домена необходимо писать заглавными буквами!
Если вы не получили никаких ошибок — значит вы настроили всё верно и домен отдаёт вам билет Kerberos. Кстати, некоторые распространённые ошибки перечислены чуть ниже.
Убедиться в том, что билет получен, можно выполнив команду
klist
Удалить все билеты (они вам вообще говоря не нужны) можно командой
kdestroy
Итак, будем считать, что авторизацию вы настроили, пора настроить непосредственно вход в домен, об этом после списка распространённых ошибок kinit
.
Распространённые ошибки kinit
Настройка Samba и вход в домен
Используемые параметры команды 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 - DOMAINusername. # Возможно именно это вам и нужно, однако обычно проще этот параметр включить. 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 запрашивает у 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
Взято с сайта — http://help.ubuntu.ru/wiki/%D0%B2%D0%B2%D0%BE%D0%B4_%D0%B2_%D0%B4%D0%BE%…
Что бы ограничить вход пользователей домена на машинку нужно довбавить в
/etc/pam.d/login
account required pam_access.so
и в /etc/security/access.conf
— : group : ALL
Contents
-
Introduction
- Used terms
- Kerberos
-
Join AD domain
- Required software
- Join
- Testing
-
Setup Authentication
- nsswitch
- Testing
- PAM
-
Final configuration
- One last thing
- Usage
- Automatic Kerberos Ticket Refresh
- Troubleshooting
-
Resources
- Automated Methods
Introduction
This Howto describes how to add an Ubuntu box in an Active Directory domain and to authenticate the users with AD.
Note: Centrify Express and Likewise Open are alternative solutions for Linux systems to authenticate to an Active Directory domain. For Centrify Express see DirectControl. For Likewise Open see LikewiseOpen.
Used terms
term |
definition |
AD |
Active Directory |
DC |
Domain Controller |
lab.example.com |
AD domain |
win2k3.lab.example.com |
DC FQDN |
10.0.0.1 |
DC IP |
LAB.EXAMPLE.COM |
Kerberos Realm |
linuxwork |
computername of the Ubuntu workstation |
linuxwork.lab.example.com |
FQDN of the Ubuntu workstation |
ntp.example.com |
timeserver (NTP) |
Kerberos
The first step in joining an Active Directory domain is to install and configure Kerberos. See Samba/Kerberos for details.
Join AD domain
Required software
You need to install the winbind and samba packages. The packages smbfs and smbclient are useful for mounting network shares and copying files.
Ubuntu 10.04 and later should also install the libnss-winbind and libpam-winbind packages.
The package smbfs is optional, but includes useful client utilities, including the smbmount command. Also useful is the smbclient package, which includes an FTP-like client for SMB shares.
Join
The first step in joining the Active Directory domain is to edit /etc/samba/smb.conf:
file: /etc/samba/smb.conf
[global] security = ads realm = LAB.EXAMPLE.COM # If the system doesn't find the domain controller automatically, you may need the following line # password server = 10.0.0.1 # note that workgroup is the 'short' domain name workgroup = LAB # winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/%D/%U template shell = /bin/bash client use spnego = yes client ntlmv2 auth = yes encrypt passwords = yes winbind use default domain = yes restrict anonymous = 2
Adding valid users = @»Domain Users» to the [global] section will allow all Domain Users to see all of the shares avaliable without a password. This is the equivlient to allowing «Everyone» to read all shares. If you want to restrict reading a share then you will have to specify valid users for that share.
The «winbind use default domain» parameter is useful in single-domain enterprises and causes winbind to treat any username that isn’t qualified with a domain name as a username in the domain to which winbind is joined. Omit this parameter if you are concerned about confusion between local accounts on your systems and accounts in the default domain. The «winbind separator» directive is optional, and the default value is the usual backslash «» Domain and User separator. You can use «+» if you know of a specific reason «» will not work in your environment.
Be sure to restart the Samba and Winbind services after changing the /etc/samba/smb.conf file:
sudo /etc/init.d/winbind stop sudo /etc/init.d/samba restart sudo /etc/init.d/winbind start
Request a valid Kerberos TGT for an account using kinit, which is allowed to join a workstation into the AD domain. Now join to the domain, if the ticket was valid you should not need to supply a password — even if prompted you should be able to leave it blank.
This next step gave me the error: kinit(v5): Cannot resolve network address for KDC in realm LAB.EXAMPLE.COM while getting initial credentials even though nslookup win2k3 and host 10.0.0.1 would both return the correct entries. To correct this problem, I had to edit my /etc/hosts file and add the following to it: 10.0.0.1 win2k3.lab.example.com
sudo kinit Administrator@EXAMPLE.COM sudo net ads join Using short domain name – LAB Joined 'linuxwork' to realm 'LAB.EXAMPLE.COM'
If the Kerberos auth was valid, you should not get asked for a password. However, if you are not working as root and are instead using sudo to perform the necessary tasks, use the command sudo net ads join -U username and supply your password when prompted. Otherwise, you will be asked to authenticate as root@LAB.EXAMPLE.COM instead of a valid account name. You can also supply a password if you don’t want to get prompted. Just use net ads join -U <username>%<password> for this. Maybe it’s useful for unattended installations where you want to add machines to an AD automatically.
If your Active Directory server is not running DDNS as well (eg. if you’re running a separate DNS server) you may get the error:
sudo net ads join Failed to join domain: failed to find DC for domain LAB.EXAMPLE.COM
To fix this, specify the AD server to the «net join» command:
sudo net ads join -S WIN2K3 -U <username>%<password>
You’ll get a warning about not being able to update DNS, but you will successfully join the AD!
Testing
Using a clean install of 10.04, I did not have to modify any PAM files to get authentication working. I had to edit common-session to get the home directories created, but that is it.
Setup Authentication
nsswitch
file: /etc/nsswitch.conf
passwd: compat winbind group: compat winbind shadow: compat
I needed to add hosts: files dns to /etc/nsswitch.conf to avoid the settings in /etc/hosts to be ignored.
Don´t forget to restart winbind again after editing /etc/nsswitch.conf!!!
Testing
You can check that the Domain has successfully been joined by:
wbinfo -u
You should get a list of the users of the domain.
I needed to make shadow: compat winbind in /etc/nsswitch.conf to make wbinfo -u work.
And a list of the groups. Be patient these queries can take time.
wbinfo -g
Check Winbind nsswitch module with getent.
This step may or may not work. If you only see local users, try connecting with a Windows machine anyways. (Tested under Ubuntu 9.10 x64)
sudo getent passwd root:x:0:0:root:/root:/bin/bash ... LAB+administrator:x:10000:10000:Administrator:/home/LAB/administrator:/bin/bash LAB+gast:x:10001:10001:Gast:/home/LAB/gast:/bin/bash ...
Note that the domain name (here, «LAB+») is displayed by getent only if you have not set winbind use default domain = yes in smb.conf.
sudo getent group root:x:0: daemon:x:1: bin:x:2: ... LAB+organisations-admins:x:10005:administrator LAB+domänen-admins:x:10006:manuel,administrator LAB+domänen-benutzer:x:10000: LAB+domänen-gäste:x:10001: LAB+linux-admins:x:10004:manuel ...
PAM
With this configuration you can access the workstation with local accounts or with domain accounts. On the first login of a domain user a home directory will be created. This PAM configuration assumes that the system will be used primarily with domain accounts. If the opposite is true (i.e., the system will be used primarily with local accounts), the order of pam_winbind.so and pam_unix.so should be reversed. When used with local accounts, the configuration shown here will result in a failed authentication to the Windows/Samba DC for each login and sudo use. This can litter the DC’s event log. Likewise, if local accounts are checked first, the /var/log/auth.log will be littered with failed logon attempts each time a domain account is accessed.
Note: You can use pam-auth-update to add the necessary entries for winbind authentication. If you installed libpam-winbind above, this step is all you need to do to configure pam. You may want to add the line to automatically create the home directory.
sudo pam-auth-update
This PAM configuration does not acquire a Kerberos TGT at login. To acquire a ticket, use kinit after logging in, and consider using kdestroy in a logout script.
file: /etc/pam.d/common-account
account sufficient pam_winbind.so account required pam_unix.so
file: /etc/pam.d/common-auth
auth sufficient pam_winbind.so auth sufficient pam_unix.so nullok_secure use_first_pass auth required pam_deny.so
On a Ubuntu 7.10 (Gutsy Gibbon) and 9.04 (Jaunty Jackalope) systems, these changes to pam.d/common-auth result in not being able to log in as a local user, for example by ssh. Your luck may be better, but test immediately just in case.
This one allows login for AD users and local users (tested with Ubuntu 9.10)
file: /etc/pam.d/common-auth
auth sufficient pam_unix.so nullok_secure auth sufficient pam_winbind.so require_membership_of=domänen-admins use_first_pass auth requisite pam_deny.so auth required pam_permit.so auth optional pam_ecryptfs.so unwrap
ecryptfs does not work with AD users. Login is successful with local users and AD users which are members of AD group domänen-admins
file: /etc/pam.d/common-session
session required pam_unix.so session required pam_mkhomedir.so umask=0022 skel=/etc/skel
file: /etc/pam.d/sudo
auth sufficient pam_winbind.so auth sufficient pam_unix.so use_first_pass auth required pam_deny.so @include common-account
Final configuration
Each domain needs a directory in /home/.
sudo mkdir /home/LAB
One last thing
If you want to be able to use an active directory account to manage your Ubuntu box, you need to add it to the sudoers file. For that, you will need to edit the file /etc/group an add your username to the admin group and whatever other group you need(plugdev,audio,cdrom just to mention a few). it will be like:
....... admin:x:117:olduser,ActiveDirectoryUser .......
Where, olduser, is your current linux user and, ActiveDirectoryUser, is the new administrator. Another way to make a Domain Group a sudoer in your ubuntu is to edit the file /etc/sudoers (using the command ‘visudo’) and add the following line
%adgroup ALL=(ALL) ALL
Where, adgroup, is a group from your active directory. Keep in mind that spaces in the group name are not allowed. You can use ‘%domain admins’, without quotes.
Usage
Logon with DOMAIN+USERNAME, unless you included «winbind use default domain» in your smb.conf, in which case you may log in using only USERNAME.
login: LAB+manuel Password: ***** ... LAB+manuel@linuxwork:~$
Automatic Kerberos Ticket Refresh
To have pam_winbind automatically refresh the kerberos ticket
Add the winbind refresh tickets line to smb.conf :
file: /etc/samba/smb.conf
# winbind separator = + winbind refresh tickets = yes idmap uid = 10000-20000
And modify /etc/pam.d/common-auth:
file: /etc/pam.d/common-auth
auth sufficient pam_winbind.so krb5_auth krb5_ccache_type=FILE auth sufficient pam_unix.so nullok_secure use_first_pass auth required pam_deny.so
Troubleshooting
If the Winbind PAM module in /var/log/auth.log says that the AD-user is not existing restart winbind. It might be best to restart the whole workstation.
sudo /etc/init.d/winbind restart
If when logging into the machine one gets a «no logon servers» error winbindsamba may not be starting properly. Try restarting them manually, and then logging in.
-If a manual restart works, then to fix this issue one needs to change scripts S20samba and S20winbind to S25samba and S25winbind in the /etc/rc2.d, rc3.d, rc4.d, rc5.d folders. The understanding is that this causes samba and winbind to startup later in the boot order for each runlevel. So that they start after S24avahi-daemon. If you then find that you must wait a bit before you can log in, you need to set «winbind enum users» and «winbind enum groups» in /etc/samba/smb.conf to ‘no’.
name service cache daemon
The name service cache daemon (nscd) can interfere with winbind, as winbind maintains its own cache. Remove it.
sudo apt-get remove nscd
Some names or groups are resolved with getent, but others are not
The range of your idmap parameter is not wide enough to encompass all the users or groups
idmap uid = 16777216-33554431 idmap gid = 16777216-33554431
Adding more than one Linux machine to a Windows network
The above procedure allows you to add as many Linux machines as you like. However, the UID assigned to a given user may not be the same across all the machines. It created file ownership & rights issues when files/folders are shared between these machines. See Question #21806 on https://answers.launchpad.net/ubuntu/ for details. Therefore it is advisable to specify the UID mapping method
idmap backend = rid:YOURDOMAIN=70000-1000000 idmap uid = 70000-1000000 idmap gid = 70000-1000000 winbind use default domain = yes security = ADS
The newer syntax is (with old style you can get NT_STATUS_OBJECT_NAME_COLLISION in /var/log/samba/log.winbindd)
idmap domains = YOURDOMAIN idmap config YOURDOMAIN:backend = rid idmap config YOURDOMAIN:range = 70000-1000000 winbind use default domain = yes security = ADS
Resources
-
The Samba and Active Directory Wiki contains very detailed instructions.
Automated Methods
The SADMS package allows for automated joining to Active Directory through a GUI interface. http://sadms.sourceforge.net/
CategorySecurity
Состояние перевода: На этой странице представлен перевод статьи Active Directory integration. Дата последней синхронизации: 31 октября 2015. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.
Важно: Так как Arch Linux использует систему распространения rolling release,возможно,некоторая информация на странице может быть устаревшей из-за изменений в пакетах или конфигурациях,сделанных разработчиками. Никогда слепо не следуйте этой или любой другой инструкции. Когда в инструкции сказано изменить какой-либо файл, обязательно сделайте бэкап. Проверяйте дату последней проверки статьи.
Основной задачей системных администраторов являются попытки совместного изпользования разнообразных окружений. Мы имеем в виду смешивание разных серверных операционных систем (Обычно Microsoft Windows & Unix/Linux). Управление пользователями и аутентификацией на данный момент является наиболее сложной задачей. Популярнейший способ решения это задачи — Directory Server. Существует много открытых и коммерческих решений для разный типов *NIX; однако, только немногие решают проблему взаимодействия с Windows. Активный Каталог (AD) — служба каталогов созданная Microsoft для доменных сетей Windows. Он входит в большинство операционных систем Windows Server. Сервера,на которых запущен AD, называются контроллерами доменов(domain controllers)
Активный каталог используется как главное средство администрирования сети и безопасности.Он отвечает за аутентификацию и авторизацию все пользователей и компьютеров в доменной сети Windows, назначая и следя за правилами безопасности для всех компьютеров в сети, также устанавливая и обновляя ПО на компьютерах в этой сети. Например,когда пользователь авторизуется в компьютер,который является частью доменной сети, AD проверяет его пароль и яляется он обычным пользователем или же системным администратором.
Активный католог использует Lightweight Directory Access Protocol (LDAP) версий 2 и 3, Kerberos и DNS.
Эти же стандарты доступны в Linux, но их комбинирование — непростая задача. Эта статья поможет вам настроить хост Arch Linux для аутентификация в домене AD.
Эта статья объясняет, как интегрировать хост Arch Linux в сущестующий домен AD.
Перед продолжением у вас должен быть существующий домен AD, и пользователь с правами на добавление пользователей и компьютерных аккаунтов.
Эта сатья не предназначена ни как полное описание AD,ни как полно описание работы с Samba. Обратитесь к разделу ресурсов для дополнительной информации.
Терминология
Если вы не знакомы с AD, здесь приведены некоторые ключевые слова, которые будет полезно знать.
- Домен(Domain) : Имя,используемое для группы компьютеров и аккаунтов.
- SID : Каждый компьютер,присоединяющийся к сети должен иметь уникальный SID / Системный идентификатор.
- SMB : Блок сообщения сервера.
- NETBIOS: Network naming protocol used as an alternative to DNS. Mostly legacy, but still used in Windows Networking.
- WINS: Windows Information Naming Service. Used for resolving Netbios names to windows hosts.
- Winbind: Protocol for windows authentication. Протокол для авторизации windows.
Настройка
Настройка AD
Важно: Эта часть не была проверена, продолжайте с отсторожностью.
Обновление GPO
Возможно, нужно будет отключить Digital Sign Communication (Always) в настройках групп AD. А именно:
Local policies
->Security policies
->Microsoft Network Server
->Digital sign communication (Always)
-> выбратьdefine this policy
и поставить «галочку» наdisable
.
Если вы используете Windows Server 2008 R2, то вам нужно настроить GPO в GPO for Default Domain Controller Policy -> Computer Setting -> Policies -> Windows Setting -> Security Setting -> Local Policies -> Security Option -> Microsoft network client: Digitally sign communications (always)
Настройка Linux хоста
Следующие несколько шагов — начало конфигурации хоста. Вам понадобиться root или sudo доступ.
Установка
Установите следующие пакеты:
- samba, см. Samba
- pam-krb5
- ntp или openntpd, см. также NTPd или OpenNTPD
Обновление DNS
AD сильно зависит от DNS. Вам нужно будет обновить /etc/resolv.conf
, чтобы использовать контроллеры доменов AD:
/etc/resolv.conf
nameserver <IP1> nameserver <IP2>
Замените <IP1> и <IP2> IP адресами для сервера AD.Есили ваши AD домены не позволяют использовать DNS форвардинг или рекурсию,возможно,придётся добавить некоторые вещи.
Если ваша машина имеет дуалбут Windows и Linux, стоит использовать разные имена DNS и netbios для linux,если обе операционные системы будут членами одного домена.
Настройка NTP
См. NTPd или OpenNTPD для инструкции по настройке NTP. Стоит отметить, что OpenNTPD больше не поддерживается.
При настройке используйте IP адреса серверов AD.Как альтернативу можно использовать другие NTP сервера,которые обеспечат синхронизацию AD в то же место.Тем не менее,AD обычно запускают NTP в качестве службы.
Убедитесь,что демон настроен на sync automatically on startup.
Kerberos
Допустим,что ваша AD называется example.com. Далее допустим что ваша AD управляется двумя доменными контроллерами, главным и вторичным, которые называются PDC и BDS, pdc.example.com и bdc.example.com соответственно. Их адреса будут,например, 192.168.1.2 и 192.168.1.3. Следите за написанием,верхний регистр очень важен.
/etc/krb5.conf
[libdefaults] default_realm = EXAMPLE.COM clockskew = 300 ticket_lifetime = 1d forwardable = true proxiable = true dns_lookup_realm = true dns_lookup_kdc = true [realms] EXAMPLE.COM = { kdc = PDC.EXAMPLE.COM admin_server = PDC.EXAMPLE.COM default_domain = EXAMPLE.COM } [domain_realm] .kerberos.server = EXAMPLE.COM .example.com = EXAMPLE.COM example.com = EXAMPLE.COM example = EXAMPLE.COM [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false retain_after_close = false minimum_uid = 0 debug = false } [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/kdc.log admin_server = FILE:/var/log/kadmind.log
Примечание: Heimdal 1.3.1 не принимает DES шифрование,которое необходимо для аутентификации AD до Windows Server 2008. Скорее всего вам придётся добавить
allow_weak_crypto = true
в раздел [libdefaults]
Создание ключа Kerberos
Теперь во можете запросить ключи для AD (верхний регистр необходим):
kinit administrator@EXAMPLE.COM
Можно использовать любое имя пользователя,у которого есть права администратора домена.
Подтверждение ключа
Запустите klist чтобы проверить,получили ли вы токен,должно быть нечто подобное:
# klist
Ticket cache: FILE:/tmp/krb5cc_0 Default principal: administrator@EXAMPLE.COM Valid starting Expires Service principal 02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 02/05/12 21:27:47
pam_winbind.conf
Если вы получаете ошибки «/etc/security/pam_winbind.conf не найден»,создайте этот файл и отредактируйте его следующим образом:
/etc/security/pam_winbind.conf
debug=no debug_state=no try_first_pass=yes krb5_auth=yes krb5_cache_type=FILE cached_login=yes silent=no mkhomedir=yes
Samba
Samba — бесплатная реализация протокола SMB/CIFS. Также она включает инструменты для Linux машин,которые заставляют их вести себя будто Windows сервера и клиенты.
Примечание: Настройка может разниться в зависимости от конфигурации сервера Windows. Будьте готовы изучать и решать проблемы.
В этом разделе мы сначала сфокусируемся на работе аутентификации с помощью изменения секции ‘Global’. Далее, мы вернёмся к остальным.
/etc/samba/smb.conf
[Global] netbios name = MYARCHLINUX workgroup = EXAMPLE realm = EXAMPLE.COM server string = %h Arch Linux Host security = ads encrypt passwords = yes password server = pdc.example.com idmap config * : backend = rid idmap config * : range = 10000-20000 winbind use default domain = Yes winbind enum users = Yes winbind enum groups = Yes winbind nested groups = Yes winbind separator = + winbind refresh tickets = yes template shell = /bin/bash template homedir = /home/%D/%U preferred master = no dns proxy = no wins server = pdc.example.com wins proxy = no inherit acls = Yes map acl inherit = Yes acl group control = yes load printers = no debug level = 3 use sendfile = no
Теперь надо «объяснить» Samba, что мы будет использовать базы даннх PDC для аутенификации.Будем использовать winbindd, который входит в поставку Samba.Winbind указывает UID и GID Linux машины для AD. Winbind использует UNIX реализацию RPC вызовов, Pluggable Authentication Modules (aka PAM) и Name Service Switch (NSS), чтобы разрешить допуск пользователей и Windows AD на Linux-машинах. Лучшая часть winbindd то,что вам не нужно размечать самому, от вас требуется только указать диапазон UID и GID! Именно их мы объявили в smb.conf.
Обновите файл настроек samba чтобы включить демона winbind
/etc/conf.d/samba
##### /etc/conf.d/samba ##### #SAMBA_DAEMONS=(smbd nmbd) SAMBA_DAEMONS=(smbd nmbd winbindd)
Далее, настройте samba
так, для запуска вместе со стартом системы. См. Daemons для подробностей.
Запуск и проверка сервисов
Запуск Samba
Надеемся,вы ещё не перезагрузились! Хорошо. Если у вас запущена X-сессия — выходите из неё,чтобы проверить вход в другой терминал не выходя из своей сессии.
Запуск Samba (включая smbd, nmbd и winbindd):
Если вы проверите список процессов,то заметите,что на самом деле winbind не запустился. Быстрый осмотр логов говорит,что SID для этого хоста может быть получен от домена:
# tail /var/log/samba/log.winbindd
[2012/02/05 21:51:30.085574, 0] winbindd/winbindd_cache.c:3147(initialize_winbindd_cache) initialize_winbindd_cache: clearing cache and re-creating with version number 2 [2012/02/05 21:51:30.086137, 2] winbindd/winbindd_util.c:233(add_trusted_domain) Added domain BUILTIN S-1-5-32 [2012/02/05 21:51:30.086223, 2] winbindd/winbindd_util.c:233(add_trusted_domain) Added domain MYARCHLINUX S-1-5-21-3777857242-3272519233-2385508432 [2012/02/05 21:51:30.086254, 0] winbindd/winbindd_util.c:635(init_domain_list) Could not fetch our SID - did we join? [2012/02/05 21:51:30.086408, 0] winbindd/winbindd.c:1105(winbindd_register_handlers) unable to initialize domain list
Присоединение к Домену
Вам нужен аккаунт администратора AD чтобы сделать это. Пусть наш логин: Administrator. Комана — ‘net ads join’
# net ads join -U Administrator
Administrator's password: xxx Using short domain name -- EXAMPLE Joined 'MYARCHLINUX' to realm 'EXAMPLE.COM'
Перезапуск Samba
winbindd не смог запуститься потому,что пока что мы не домен.
Перезапустите сервис Samba и winbind тоже должен запуститься.
NSSwitch говорит Linux хосту как получить игформацию из различных источников и к каком порядке это сделать. В нашем случае мы добаим AD как дополнительный источник для пользователей, групп и хостов.
/etc/nsswitch.conf
passwd: files winbind shadow: files winbind group: files winbind hosts: files dns wins
Проверка Winbind
Проверим, может ли winbind получить доступ к AD. Следующие команды возвращают список пользователей AD:
# wbinfo -u
administrator guest krbtgt test.user
- Note мы создали пользователя AD ‘test.user’ в домменом контоллере.
Можно сделать то же самое для групп AD:
# wbinfo -g
domain computers domain controllers schema admins enterprise admins cert publishers domain admins domain users domain guests group policy creator owners ras and ias servers allowed rodc password replication group denied rodc password replication group read-only domain controllers enterprise read-only domain controllers dnsadmins dnsupdateproxy
Проверка nsswitch
Дабы убедиться,что наш хост имеет доступ к домену для пользователей и групп, мы проверим настройки nsswitch, используя ‘getent’. Следующий вывод показывает,как оно дожно выглядеть на нетронутом Arch Linux:
# getent passwd
root:x:0:0:root:/root:/bin/bash bin:x:1:1:bin:/bin:/bin/false daemon:x:2:2:daemon:/sbin:/bin/false mail:x:8:12:mail:/var/spool/mail:/bin/false ftp:x:14:11:ftp:/srv/ftp:/bin/false http:x:33:33:http:/srv/http:/bin/false nobody:x:99:99:nobody:/:/bin/false dbus:x:81:81:System message bus:/:/bin/false ntp:x:87:87:Network Time Protocol:/var/empty:/bin/false avahi:x:84:84:avahi:/:/bin/false administrator:*:10001:10006:Administrator:/home/EXAMPLE/administrator:/bin/bash guest:*:10002:10007:Guest:/home/EXAMPLE/guest:/bin/bash krbtgt:*:10003:10006:krbtgt:/home/EXAMPLE/krbtgt:/bin/bash test.user:*:10000:10006:Test User:/home/EXAMPLE/test.user:/bin/bash
Для групп:
# getent group
root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon sys:x:3:root,bin adm:x:4:root,daemon tty:x:5: disk:x:6:root lp:x:7:daemon mem:x:8: kmem:x:9: wheel:x:10:root ftp:x:11: mail:x:12: uucp:x:14: log:x:19:root utmp:x:20: locate:x:21: rfkill:x:24: smmsp:x:25: http:x:33: games:x:50: network:x:90: video:x:91: audio:x:92: optical:x:93: floppy:x:94: storage:x:95: scanner:x:96: power:x:98: nobody:x:99: users:x:100: dbus:x:81: ntp:x:87: avahi:x:84: domain computers:x:10008: domain controllers:x:10009: schema admins:x:10010:administrator enterprise admins:x:10011:administrator cert publishers:x:10012: domain admins:x:10013:test.user,administrator domain users:x:10006: domain guests:x:10007: group policy creator owners:x:10014:administrator ras and ias servers:x:10015: allowed rodc password replication group:x:10016: denied rodc password replication group:x:10017:krbtgt read-only domain controllers:x:10018: enterprise read-only domain controllers:x:10019: dnsadmins:x:10020: dnsupdateproxy:x:10021:
Проверка команд Samba
Попробуйте некоторые команды,чтобу увидеть,может ли Samba взаимодействовать с AD:
# net ads info
[2012/02/05 20:21:36.473559, 0] param/loadparm.c:7599(lp_do_parameter) Ignoring unknown parameter "idmapd backend" LDAP server: 192.168.1.2 LDAP server name: PDC.example.com Realm: EXAMPLE.COM Bind Path: dc=EXAMPLE,dc=COM LDAP port: 389 Server time: Sun, 05 Feb 2012 20:21:33 CST KDC server: 192.168.1.2 Server time offset: -3
# net ads lookup
[2012/02/05 20:22:39.298823, 0] param/loadparm.c:7599(lp_do_parameter) Ignoring unknown parameter "idmapd backend" Information for Domain Controller: 192.168.1.2 Response Type: LOGON_SAM_LOGON_RESPONSE_EX GUID: 2a098512-4c9f-4fe4-ac22-8f9231fabbad Flags: Is a PDC: yes Is a GC of the forest: yes Is an LDAP server: yes Supports DS: yes Is running a KDC: yes Is running time services: yes Is the closest DC: yes Is writable: yes Has a hardware clock: yes Is a non-domain NC serviced by LDAP server: no Is NT6 DC that has some secrets: no Is NT6 DC that has all secrets: yes Forest: example.com Domain: example.com Domain Controller: PDC.example.com Pre-Win2k Domain: EXAMPLE Pre-Win2k Hostname: PDC Server Site Name : Office Client Site Name : Office NT Version: 5 LMNT Token: ffff LM20 Token: ffff
# net ads status -U administrator | less
objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user objectClass: computer cn: myarchlinux distinguishedName: CN=myarchlinux,CN=Computers,DC=leafscale,DC=inc instanceType: 4 whenCreated: 20120206043413.0Z whenChanged: 20120206043414.0Z uSNCreated: 16556 uSNChanged: 16563 name: myarchlinux objectGUID: 2c24029c-8422-42b2-83b3-a255b9cb41b3 userAccountControl: 69632 badPwdCount: 0 codePage: 0 countryCode: 0 badPasswordTime: 0 lastLogoff: 0 lastLogon: 129729780312632000 localPolicyFlags: 0 pwdLastSet: 129729764538848000 primaryGroupID: 515 objectSid: S-1-5-21-719106045-3766251393-3909931865-1105 ...<snip>...
Настройка PAM
Теперь мы будем менять разные правила в PAM, чтобы допустить пользователей AD к использованию системы для входа и к sudo доступу. Когда вы меняете правила, запоминание их порядка и помечены ли они как required или как sufficient критически важно,если вы хотите,чтобы всё работало,как вы задумали.Вам не стоит отклоняться от этих правил,если только вы не знаете как писать правила для PAM
В случае со входом,PAM следует сначала запросить аккаунт AD и проверять локальные аккаунты только если аккаунту AD не соответствует локальный аккаунт.Поэтому, мы добавим записи,которые включат pam_winbindd.so
в процесс аутентификации.
Главный процесс аутентификации в конфигурации PAM Arch Linux находится в /etc/pam.d/system-auth
. Начав со стандартной конфигурации из pambase
, измените её следующим образом:
system-auth
Раздел «auth»
Найдите строку:
auth required pam_unix.so ...
Удалите её, и замените следующим:
auth [success=1 default=ignore] pam_localuser.so auth [success=2 default=die] pam_winbind.so auth [success=1 default=die] pam_unix.so nullok auth requisite pam_deny.so
Раздел «account»
Найдите строку:
account required pam_unix.so
Под ней допишите следующее:
account [success=1 default=ignore] pam_localuser.so account required pam_winbind.so
Раздел «session»
Найдите строку:
session required pam_unix.so
Под ней допишите следующее:
session required pam_mkhomedir.so umask=0022 skel=/etc/skel session [success=1 default=ignore] pam_localuser.so session required pam_winbind.so
Раздел «password»
Найдите строку:
password required pam_unix.so ...
Удалите её и замените следующими:
password [success=1 default=ignore] pam_localuser.so password [success=2 default=die] pam_winbind.so password [success=1 default=die] pam_unix.so sha512 shadow password requisite pam_deny.so
Проверка входа
Теперь запустите новую сессию/войдите через ssh и попробуйте войти,использую данные аккаунта AD. Имя домена опционально, так как это было задано в настройках Winbind как ‘default realm’. Заметьте,что в случае с ssh, вам нужно изменить /etc/ssh/sshd_config
, чтобы он разрешал аутентификацию через kerberos: (KerberosAuthentication yes)
.
test.user EXAMPLE+test.user
Оба должны работать. Стоит подметить,что /home/example/test.user
будет создан автоматически.
Войдите в другую сессию использую аккаунт Linux. Удостоверьтесь,что всё ещё можете войти как root — запомните,что вы должны быть под аккаунтом root как минимум в одной сессии!
Настройка общих файлов
Ранее мы пропустили настройку общих файлов. Теперь,когда всё работает, вернитесь к /etc/smb.conf
и добавьте эксопрт для хостов,которые вы желаете сделать доступными в Windows
/etc/smb.conf
[MyShare] comment = Example Share path = /srv/exports/myshare read only = no browseable = yes valid users = @NETWORK+"Domain Admins" NETWORK+test.user
В примере выше, ключевое слово NETWORK. Не путайте его с именем домена. Для добавления групп,добавьте символ ‘@’ к группе. Заметьте, Domain Admins
заключается в «цитаты», чтобы Samba корректно считывала их,когда просматривает файл конфигурации.
Добавление файла keytab и включение беспарольного входа на машину через Kerber и ssh
Это объясняет,как сгенерировать keytab файл,который вам нужен,например,чтобы включить беспарольный вход на машину через Kerber и ssh с другой машины в том же домене. Допустим, что у вас много компьютеров в домене и вы только что добавили сервер/рабочую станцию использую описание выше в ваш домен, в котором пользователям нужен ssh для работы — например рабочаю станция GPU или вычислительный узел OpenMP и т.д. В этом случае вам, наверное, не захочется вводить пароль каждый раз при входе. С другой стороны аутентификация с помощью ключа используется множеством пользователей, в этом случае нужных полномочий для,например,монтирования общего NFSv4 с Kerberos. Так что это поможет включить беспарольные входы на машины используя «kerberos ticket forwarding».
Создание key tab файла
Запустите ‘net ads keytab create -U administrator’ как суперпользователь дабы создать keytab файл в ‘/etc/krb5.keytab’. Она напишет ваи,что необходимо включить аутентификацию с помощью keytab в файле конфигурации, чтобы мы могли совершить следующий шаг. Иногда возникают проблемы, если файл krb5.keytab уже существует,в таком случае нужно переименовать его и запустить команду ещё раз, это должно помочь.
# net ads keytab create -U administrator
Проверьте содержание файла следующим образом:
# klist -k /etc/krb5.keytab
Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 4 host/myarchlinux.example.com@EXAMPLE.COM 4 host/myarchlinux.example.com@EXAMPLE.COM 4 host/myarchlinux.example.com@EXAMPLE.COM 4 host/myarchlinux.example.com@EXAMPLE.COM 4 host/myarchlinux.example.com@EXAMPLE.COM 4 host/MYARCHLINUX@EXAMPLE.COM 4 host/MYARCHLINUX@EXAMPLE.COM 4 host/MYARCHLINUX@EXAMPLE.COM 4 host/MYARCHLINUX@EXAMPLE.COM 4 host/MYARCHLINUX@EXAMPLE.COM 4 MYARCHLINUX$@EXAMPLE.COM 4 MYARCHLINUX$@EXAMPLE.COM 4 MYARCHLINUX$@EXAMPLE.COM 4 MYARCHLINUX$@EXAMPLE.COM 4 MYARCHLINUX$@EXAMPLE.COM
Включение входа через keytab
Теперь вам нужно указать winbind,что он должен использовать keytab файлы,добавив следующий строки в /etc/samba/smb.conf:
/etc/samba/smb.conf
kerberos method = system keytab dedicated keytab file = /etc/krb5.keytab
В итоге всё должно выглядеть примерно так:
/etc/samba/smb.conf
[Global] netbios name = MYARCHLINUX workgroup = EXAMPLE realm = EXAMPLE.COM server string = %h Arch Linux Host security = ads encrypt passwords = yes password server = pdc.example.com kerberos method = system keytab dedicated keytab file = /etc/krb5.keytab idmap config * : backend = tdb idmap config * : range = 10000-20000 winbind use default domain = Yes winbind enum users = Yes winbind enum groups = Yes winbind nested groups = Yes winbind separator = + winbind refresh tickets = yes template shell = /bin/bash template homedir = /home/%D/%U preferred master = no dns proxy = no wins server = pdc.example.com wins proxy = no inherit acls = Yes map acl inherit = Yes acl group control = yes load printers = no debug level = 3 use sendfile = no
Перезапустите winbind.service с помощью ‘systemctl restart winbind.service’ с привелегиями суперпользователя.
# systemctl restart winbind.service
Проверьте,всё ли работает,получив тикет для вашей системы и запустив
# kinit MYARCHLINUX$ -kt /etc/krb5.keytab
Эта команда не должна написать ничего в консоль,ондако ‘klist’ должен показать что-то вроде этого:
# klist
Ticket cache: FILE:/tmp/krb5cc_0 Default principal: MYARCHLINUX$@EXAMPLE.COM Valid starting Expires Service principal 02/04/12 21:27:47 02/05/12 07:27:42 krbtgt/EXAMPLE.COM@EXAMPLE.COM renew until 02/05/12 21:27:47
Некоторые частые ошибки : a)забывают поставить $ или b) игнорируют чувствительный регистр — он должен быть точно таким же,как записьв keytab
Подготовка sshd на сервере
Всё,что нам нужно сделать — это добавить некоторые опции в sshd_config и перезапустить sshd.service.
Измените ‘/etc/ssh/sshd_config’ чтобы он выглядел так в нужных местах:
# /etc/ssh/sshd_config
... # Изсенить на no чтобы выключить s/key пароли ChallengeResponseAuthentication no # Опции Kerberos KerberosAuthentication yes #KerberosOrLocalPasswd yes KerberosTicketCleanup yes KerberosGetAFSToken yes # Опции GSSAPI GSSAPIAuthentication yes GSSAPICleanupCredentials yes ...
Перезапустите sshd.service:
# systemctl restart sshd.service
Добавление опций, нужных для клиента
Для начала нам нужно убедиться в том, что тикеты доступны для клиента. Обычно всё работает, но, на всякий случай, используйте следующий параметр:
forwardable = true
Далее надо добавить опции:
GSSAPIAuthentication yes GSSAPIDelegateCredentials yes
в наш файл .ssh/config
, который говорит ssh использовать эту опцию, как альтернативу: можно использовать ‘ssh -o’ (смотрите страницу справочного руководства ssh(1)).
Проверка установки
Клиент:
Убедитесь,что у вас правильный тикет, используя ‘kinit’. Затем подключитесь к своем машине через ssh
ssh myarchlinux.example.com
Вы должны подключится без просьбы ввести пароль
Если у вас также включна аутентификация ключем,нужно выполнить
ssh -v myarchlinux.example.com
чтобы увидеть,какой метод аутентификации используется на самом деле.
Для дебага вы можете включить DEBUG3 на сервере и посмотреть лог через ‘journalctl’
Настройка для полной аутентификации Kerberos без пароля.
Если ваши клиенты не используют доменные аккаунты на их локальных машинах (по какой бы то не было причине),довольно сложно будет научить их использовать ‘kinit’ перед тем,как ssh подключится к рабочей станции.Так что есть классный способ это решить:
Генерирование keytab, которые будет принимать AD
Пользователь должен выполнить:
ktutil addent -password -p username@EXAMPLE.COM -k 1 -e RC4-HMAC - enter password for username - wkt username.keytab q
Теперь провертьте файл:
kinit -kt username.keytab
Оно не должно спросить пароль, теперь просто скопируйте это в ‘~/.bashrc’, это позволит не вводит пароль каждый раз.
Интересно знать
Файл ‘username.keytab’ не спецефичен для машины,и,следовательно,может быть скопирован на другие машины. Например,мы создали файл на Linux машине и скопировали на Mac клиента так как команды в неё другие…
Смотрите также
- Wikipedia: Active Directory
- Wikipedia: Samba
- Wikipedia: Kerberos
- Samba: Documentation
- Samba Wiki: Samba & Active Directory[устаревшая ссылка 2020-08-02 ⓘ]
- Samba Man Page: smb.conf
Коммерческие решения
- Centrify
- Likewise
Модератор: Bizdelnick
-
Trojan
- Сообщения: 359
- Статус: Системный ламер
- ОС: CentOS 7
Необходимость ввода машины в Windows домен
В качестве предисловия: в локалке Windows 2003 домен. В локалке есть: естественно DNS, почтовый сервер, файерволл, VPN. Вышеперечисленные сервисы стоят на виндовых серверах. Нужно перевести сервера с Windows на Linux, а сервисы заменить их линуксовыми аналогами. Прочитав достаточное кол-во информации о вводе линуксовой машины в домен пришел к выводу, что сия процедура геморрой несусветный с непонятным исходом.
Отсюда вопросы: Есть ли в данном случае необходимость ввода машины в домен? Возможно ли поднять линуксовые почту, файерволл, ВПН и ДНС для работы в Windows домене, не вводя эту самую линуксовую машину в домен? Может ли Samba решить этот вопрос?
Всегда думай то, что говоришь и никогда не говори то, что думаешь.
-
allez
- Сообщения: 2223
- Статус: Не очень злой админ
- ОС: SuSE, CentOS, FreeBSD, Windows
Re: Необходимость ввода машины в Windows домен
Сообщение
allez » 29.01.2009 12:07
Trojan писал(а): ↑
29.01.2009 11:21
Возможно ли поднять линуксовые почту, файерволл, ВПН и ДНС для работы в Windows домене, не вводя эту самую линуксовую машину в домен?
Да, возможно.
Trojan писал(а): ↑
29.01.2009 11:21
Может ли Samba решить этот вопрос?
Samba вам понадобится лишь в том случае, если вы захотите перенести на Линукс контроллер домена. Ну и, разумеется, если вы задумаете создать линуксовый файл- или принт-сервер для виндовых клиентов.
Trojan писал(а): ↑
29.01.2009 11:21
Прочитав достаточное кол-во информации о вводе линуксовой машины в домен пришел к выводу, что сия процедура геморрой несусветный с непонятным исходом.
А вот тут позволю себе не согласиться. Не раз вводил линуксовые машины в AD, как руками (Slackware, Ubuntu 7.04), так и мышью (SUSE, Ubuntu 8.04) и особых проблем не встречал.
-
Trojan
- Сообщения: 359
- Статус: Системный ламер
- ОС: CentOS 7
Re: Необходимость ввода машины в Windows домен
Сообщение
Trojan » 29.01.2009 13:02
allez писал(а): ↑
29.01.2009 12:07
Да, возможно.
Получается, что можно просто прописать IPшники из диапазона локальной сети, подправить hosts и resolv.conf (если нужно) и этого будет достаточно, чтобы не введенные в домен Linux-сервера могли работать с локальным доменом?
allez писал(а): ↑
29.01.2009 12:07
Samba вам понадобится лишь в том случае, если вы захотите перенести на Линукс контроллер домена. Ну и, разумеется, если вы задумаете создать линуксовый файл- или принт-сервер для виндовых клиентов.
То есть Samba абсолютно не нужна?
allez писал(а): ↑
29.01.2009 12:07
А вот тут позволю себе не согласиться. Не раз вводил линуксовые машины в AD, как руками (Slackware, Ubuntu 7.04), так и мышью (SUSE, Ubuntu 8.04) и особых проблем не встречал.
Не правильно выразился. Имел ввиду не просто ввод машины в домен, а еще и вход на линуксовую машину введенную в домен с доменной учеткой. Хотя это уже другая тема.
Всегда думай то, что говоришь и никогда не говори то, что думаешь.
-
allez
- Сообщения: 2223
- Статус: Не очень злой админ
- ОС: SuSE, CentOS, FreeBSD, Windows
Re: Необходимость ввода машины в Windows домен
Сообщение
allez » 29.01.2009 13:19
Trojan писал(а): ↑
29.01.2009 13:02
Получается, что можно просто прописать IPшники из диапазона локальной сети, подправить hosts и resolv.conf (если нужно) и этого будет достаточно, чтобы не введенные в домен Linux-сервера могли работать с локальным доменом?
Уточните, пожалуйста, что вы подразумеваете под «работой с локальным доменом»?
Trojan писал(а): ↑
29.01.2009 13:02
Имел ввиду не просто ввод машины в домен, а еще и вход на линуксовую машину введенную в домен с доменной учеткой.
Вводится имя пользователя в виде «domain\user», затем пароль. Вот, собственно, и все. Некоторые версии некоторых DM (во загнул-то :)) позволяют выбрать домен входа. Конкретно — KDM в SUSE. В убунтовском GDM такой фичи после ввода машины в домен не появилось.
-
Trojan
- Сообщения: 359
- Статус: Системный ламер
- ОС: CentOS 7
Re: Необходимость ввода машины в Windows домен
Сообщение
Trojan » 29.01.2009 15:32
allez писал(а): ↑
29.01.2009 13:19
Уточните, пожалуйста, что вы подразумеваете под «работой с локальным доменом»?
Подразумеваю, что в локальной сети, организованной как домен, Linux-сервера, с установленными на них службами (почта, файерволл, ВПН и ДНС), НО не являющиеся членами этого домена, а лишь логически находящиеся в этой локальной сети (находящиеся в одном адресном пространстве), будут корректно обслуживать запросы клиентских машин домена, т.е. корректно будут отправляться/приниматься почта, фильтроваться траффик, разрешаться имена и т.д.
Получилось излишне дословно, но это я так для понятности вопроса.
Всегда думай то, что говоришь и никогда не говори то, что думаешь.