Включаем Ubuntu в состав домена Windows
Встала задача подключить ноутбук с ОС Ubuntu к домену Windows. Если в ОС Windows это сделать проще простого, то в линуксе нужно проделать небольшие манипуляции.
И так, для примера привожу нужную для дальнейшего мануала информацию:
- Компьютер-сервер с ОС Windows Server 2008 R2:
- Имя: Server2008R2
- Домен: myserver.com
- Роль: контроллер домена ActiveDirectory, DNS-сервер
- IP-адрес: 172.17.1.3
- Маска сети: 255.255.255.0
- Шлюз: 172.17.1.1
- Виртуальная машина с ОС Windows Server 2008 R2:
- Имя: FileServer
- Домен: myserver.com
- Роль: вторичный контроллер домена ActiveDirectory с настроенной реплекацией
- IP-адрес: 172.17.1.6
- Маска сети: 255.255.255.0
- Шлюз: 172.17.1.1
- Ноутбук с ОС Ubuntu 11.04:
- Имя: LaptopUbuntu
- Сетевые настройки: через DHCP (получает от роутера с IP-адресом 172.17.1.1)
Т.к. нашей задачей является подключить ноутбук к домену mydomain.com, то необходимо проделать следующие действия:
sudo apt-get install krb5-user ntp samba winbind
krb5-user — пакет для протокола Kerberos, который используется для аутентификации в Windows;
ntp — позволяет синхронизировать время в контроллером домена;
samba — позволяет стать членом домена;
winbind — позволяет использовать учетную запись пользователя из ActiveDirectory.
Теперь перейдем непосредственно к настройкам:
sudo gedit /etc/resolv.conf
Изменить содержимое на следующее:
domain myserver.com
search myserver.com
nameserver 172.17.1.3
Задаем нужное имя ноутбука (LaptopUbuntu) в следующем файле:
sudo gedit /etc/hostname
sudo gedit /etc/hostname
Меняем так, чтобы было (секцию IPv6 не трогаем):
127.0.0.1 localhost
172.17.1.2 LaptopUbuntu.myserver.com LaptopUbuntu
Теперь для применения изменений необходимо перезагрузить ноутбук. После перезагрузки у меня, почему-то, все отредактированные выше файлы сбросились в первоначальное содержимое. Немного подумав, я понял, что виноват тому значащийся в сетевых настройках включенный DHCP. Через Network Manager я отключил DHCP, выбрал пункт «ручная настройка», а затем опять проделал то, что написано выше. Хотя, часть значений параметров можно вписать через все тот же Network Manager.
Открываем следующий файл:
sudo gedit /etc/ntp.conf
и вписываем в него следующее:
sudo /etc/init.d/ntp restart
Далее приступим к настройке Kerberos. Редактируем файл:
sudo gedit /etc/krb5.conf
Заполняем его следующей информацией:
[libdefaults]default_realm = MYSERVER.COM
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true [realms]
MYSERVER.COM = <
kdc = SERVER2008R2
kdc = FILESERVER
admin_server = SERVER2008R2
default_domain = MYSERVER.COM
> [domain_realm]
.domain.com = MYSERVER.COM
domain.com = MYSERVER.COM
[login]
krb4_convert = false
krb4_get_tickets = false
Теперь настраиваем Samba:
sudo gedit /etc/samba/smb.conf
Приводим секцию [global] к следующему содержанию:
workgroup = MYSERVER.COM
realm = MYSERVER.COM
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
Для проверки правильности заполнения конфигурационного файла Samba, можно выполнить команду testparm, которая выведет информацию о том, что в конфигурации ошибок нет, либо они есть.
Теперь перейдем к настройке Winbind, если мы хотим использовать учетные записи из ActiveDirectory у себя на ноутбуке.
Опять редактируем файл:
sudo gedit /etc/samba/smb.conf
И в секцию [global] добавляем:
idmap uid = 10000 — 40000
idmap gid = 10000 — 40000
winbind enum groups = yes
winbind enum users = yes
winbind use default domain = yes
template shell = /bin/bash
winbind refresh tickets = yes
winbind offline logon = yes
winbind cache time = 1440
После чего необходимо перезапустить демоны:
sudo /etc/init.d/winbind stop
sudo smbd restart
sudo /etc/init.d/winbind start
Далее идем и редактируем следующий файл:
sudo gedit /etc/nsswitch.conf
Добавляем в конец строк passwd и group слово winbind, т.е. файл должнен выглядеть так:
passwd: compat winbind
group: compat winbind
И самое последнее: в файл /etc/pam.d/common-session добавить следующую строчку:
session optional pam_mkhomedir.so skel=/etc/skel/ umask=0077
Демонстрация всего того, что описано выше, будет в одной из следующих заметок.
Аутентификация и авторизация в домене Active Directory при подключении к серверу Ubuntu Server 14.04 LTS
В одной из прошлых заметок мы рассмотрели процедуру присоединения сервера на базе Ubuntu Server 14.04 LTS к домену Active Directory (AD) для обеспечения работы процедур аутентификации и авторизации на прокси-сервере Squid 3.3. Тем самым мы упростили доступ рядовых доменных пользователей к ресурсам Интернет. Однако не стоит забывать и об администраторах. Использование локальных учетных записей для аутентификации и авторизации администраторов на Linux-серверах может доставлять свои неудобства, когда количество таких серверов в организации увеличивается. В этой заметке мы рассмотрим процедуры настройки сервера Ubuntu направленные на упрощение процедур аутентификации и авторизации при входе в Linux-систему путём использования учетных записей пользователей и групп безопасности домена AD.
Как и в предыдущих заметках посвященных теме интеграции Linux в AD, в качестве хранилища доменных учетных записей пользователей и групп в нашем примере будут использоваться контроллеры домена под управлением ОС Microsoft Windows Server 2012 R2.
Прежде чем приступим, хочу сделать одно важное замечание. В этой заметке мы будем выполнять корректировку некоторых системных конфигурационных файлов, отвечающих за работу аутентификации и авторизации для локального и удалённого входа в Linux-систему. Поэтому, перед тем как начать подобные корректировки, настоятельно рекомендую сделать резервную копию системы, например снапшот виртуальной машины, ибо в случае некорректных настроек PAM мы сможем получить проблемы со входом в систему (например после перезагрузки сервера).
Устанавливаем плагин для Samba4 (nss_winbind) и поддержку Winbind для PAM:
Проверяем работу Kerberos пытаясь получить билет для какого-нибудь доменного пользователя.
Проверяем наличие билета Kerberos
Очищаем кэш билетов:
Конфигурация Samba4 по умолчанию для новых пользователей подразумевает создание домашнего каталога пользователя по шаблону ( template homedir ) /home/<Домен>/ <Логин>с отсутствием оболочки ( template shell ). Немного изменим конфигурацию /etc/samba/smb.conf задав параметр описывающий оболочку
Новое содержимое smb.conf :
Обратите внимание на то, что по сравнению с конфигурационным файлом приведённым для примера ранее , добавился также ряд других параметров, нацеленных не конкретно под нашу задачу, а для оптимизации работы процессов Samba.
После изменения диапазона idmap в smb.conf не плохо бы сбросить кэш Winbind:
Для вступления новой конфигурации smb.conf перезапускаем службы Samba:
Добавляем возможность использования Winbind в системный конфигурационный файл nsswitch.conf
Дописываем winbind в строки passwd и group . Результирующий файл будет выглядеть так:
Убеждаемся в том, что ниже указанные команды возвращают список как локальных пользователей и групп так и доменных:
Обратите внимание на то, что при большом количестве пользователей и групп в домене вывод getent может работать некорректно в том случае, если в конфигурации smb.conf диапазон idmap недостаточно велик. Хотя на самом деле у нас нет необходимости получать полный список всех групп и пользователей домена, а достаточно выполнить проверку для какой-то одной конкретной группы, например для доменной группы безопасности, которую мы специально создали для объединения администраторов серверов Linux…
…и для доменной учетной записи любого пользователя, которую мы планируем использовать для входа на наш Ubuntu Server…
Создадим в каталоге домашних папок пользователей подкаталог для доменных пользователей в соответствии с настройками нашего smb.conf (в качестве имени каталога используем NetBIOS-имя домена):
Проверим, что после установки библиотеки libpam-winbind соответствующие PAM-модули для Winbind активирован.
Правим файл /etc/pam.d/common-session . В конец файла добавим строку определяющую директиву создания домашнего каталога в случае его отсутствия:
Результирующий файл (без вывода комментариев) получится следующий:
Правим файл /etc/pam.d/common-auth . В строку описывающую вызов pam_winbind.so добавляем дополнительный параметр require_membership_of , в котором указываем имя доменной группы безопасности. В эту группу будут входить пользователи, которым мы хотим разрешить вход на наш Linux-сервер. Имя группы желательно указывать с учётом регистра, то есть так, как она создана в домене AD. Указанная группа должна быть группой глобального типа (область действия в домене AD).
Результирующий файл (без вывода комментариев) получится следующий:
Обратите внимание также на то, что в указанные файлы не стоит вносить никаких других изменений кроме указанных, даже таких простых, как например, изменение отступов в существующих параметрах. В противном случае мы потеряем возможность управлять включением/выключением PAM-модулей через конфигуратор pam-auth-update. Проверить то, как после ручной правки pam-auth-update воспринимает common-файлы, можно просто запустив его и если что-то ему не понравится, он сообщит нам об этом:
Если же всё таки где-то напортачили, то можно заставить pam-auth-update исправить параметры common-файлов в их исходные значения выбрав в указанном сообщении Yes, либо отдельной командой:
Остальные common-файлы привожу информативно. В них мы редактировать вручную ничего не будем, так как конфигуратор pam-auth-update уже внёс все необходимые правки со ссылкой на winbind.
Результирующий файл /etc/pam.d/common-account (без вывода комментариев):
Результирующий файл /etc/pam.d/common-password (без вывода комментариев):
Результирующий файл /etc/pam.d/common-session-noninteractive (без вывода комментариев):
После указанных настроек проверяем вход в систему используя учетные данные пользователя домена AD. В качестве логина указываем доменный логин пользователя (без доменной части). При этом проверяем, то что в систему удаётся войти только тем пользователям, которые включены в доменную группу безопасности KOM-SRV-Linux-Administrators . В случае возникновения проблем при входе следим за системным логом аутентификации:
Замечено, что в случае, если в домене AD в свойствах групп безопасности, членом которых является аутентифицируемый пользователь, присутствует непустой атрибут sIDHistory (группа ранее была мигрирована в текущий домен из другого домена), то в процессе входа в Linux может появляться ряд сообщений типа:
Это связано с тем, что после аутентификации и авторизации для пользователя запускается shell-оболочка, которая была назначена пользователю согласно параметра template shell конфигурационного файла smb.conf . То есть в нашем случае выполняется оболочка /bin/bash . В текущей своей версии оболочка bash при запуске выполняет скрипт /etc/bash.bashrc . Если мы откроем этот скрипт, то увидим, что в нём присутствует такой фрагмент кода:
Этот участок скрипта используется для банального вывода подсказки о том, что для выполнения административных действий требуется использовать sudo. При этом здесь выполняется проверка членства залогинившегося пользователя в группах вызовом утилиты groups, которая в свою очередь при вызове в контексте доменного пользователя будет пытаться вернуть список доменных групп в которые он входит. При этой операции используется Winbind, у которого есть проблемы с чтением из домена AD групп имеющих непустой атрибут sIDHistory.
Чтобы избавиться от вывода подобного рода сообщений при входе в систему есть два простых решения. Либо закомментировать представленный выше участок кода в файле /etc/bash.bashrc , либо для доменных пользователей использовать альтернативную shell-оболочку, например zsh (при этом надо поменять параметр template shell конфигурационного файла smb.conf на /bin/zsh и перезапустить службы Samba). Я предпочёл первый способ.
Итак, мы уже имеем возможность локального и удалённого (по SSH) входа на наш Linux-сервер используя учётную запись пользователя домена AD с ограничением по членству в доменной группе безопасности. Однако для выполнения таким пользователем административных действий в Linux-системе, нам потребуется включить для этого пользователя возможность выполнения sudo. Проще всего будет выдать данное разрешение не для конкретного пользователя, а сразу для указанной доменной группы. Для этого нам потребуется внести изменения в системный конфигурационный файл /etc/sudoers . Прямая правка этого файла не рекомендуется, поэтому воспользуемся специальным инструментом visudo, который при сохранении файла sudoers выполняет его проверку:
Приведу фрагмент файла, в котором описываются группы доступа имеющие возможность выполнять sudo (здесь была добавлена последняя строчка фрагмента):
После сохранения файла снова входим в систему доменным пользователем и пробуем выполнить любую команду с sudo.
На этом всё. В следующей заметке мы рассмотрим процедуру настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows
Дополнительные источники информации: