Аутентификация и авторизация в домене 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:

sudo apt-get install libnss-winbind libpam-winbind

---

Проверяем работу Kerberos пытаясь получить билет для какого-нибудь доменного пользователя.

kinit artur-p@HOLDING.COM

Проверяем наличие билета Kerberos

klist

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: artur-p@HOLDING.COM

Valid starting       Expires              Service principal
07/01/2014 14:06:14  07/02/2014 00:06:14  krbtgt/HOLDING.COM@HOLDING.COM
        renew until 07/02/2014 14:06:09

Очищаем кэш билетов:

kdestroy

---

Конфигурация Samba4 по умолчанию для новых пользователей подразумевает создание домашнего каталога пользователя по шаблону (template homedir) /home/{Домен}/{Логин} с отсутствием оболочки (template shell). Немного изменим конфигурацию /etc/samba/smb.conf задав параметр описывающий оболочку

sudo nano -Y sh /etc/samba/smb.conf

Новое содержимое smb.conf:

[global]
   netbios name = KOM-AD01-GW10
   workgroup = KOM
   security = ADS
   realm = HOLDING.COM
   password server = KOM-DC01, KOM-DC02, *
   encrypt passwords = yes

   interfaces = 10.0.0.0/8
   bind interfaces only = yes

   allow trusted domains = No
   winbind use default domain = yes
   winbind enum users  = yes
   winbind enum groups = yes

#   log level = 9

   idmap config *:backend = tdb
   idmap config *:range = 1000000-1999999
   idmap config KOM:backend = rid
   idmap config KOM:range = 10000-999999

   template homedir = /home/%D/%U
   template shell = /bin/bash
   winbind refresh tickets = yes

   preferred master = No
   local master = No
   domain master = No

   load printers = No
   show add printer wizard = No
   printcap name = /dev/null
   disable spoolss = Yes

Обратите внимание на то, что по сравнению с конфигурационным файлом приведённым для примера ранее, добавился также ряд других параметров, нацеленных не конкретно под нашу задачу, а для оптимизации работы процессов Samba.

После изменения диапазона idmap в smb.conf не плохо бы сбросить кэш Winbind:

sudo net cache flush

Для вступления новой конфигурации smb.conf перезапускаем службы Samba:

sudo service smbd restart
sudo service nmbd restart
sudo service samba restart
sudo service winbind restart

---

Добавляем возможность использования Winbind в системный конфигурационный файл nsswitch.conf

sudo nano -Y sh /etc/nsswitch.conf

Дописываем winbind в строки passwd и group. Результирующий файл будет выглядеть так:

# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat winbind
group:          compat winbind
shadow:         compat

hosts:          files dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

---

Убеждаемся в том, что ниже указанные команды возвращают список как локальных пользователей и групп так и доменных:

sudo getent passwd
sudo getent group

Обратите внимание на то, что при большом количестве пользователей и групп в домене вывод getent может работать некорректно в том случае, если в конфигурации smb.conf диапазон idmap недостаточно велик. Хотя на самом деле у нас нет необходимости получать полный список всех групп и пользователей домена, а достаточно выполнить проверку для какой-то одной конкретной группы, например для доменной группы безопасности, которую мы специально создали для объединения администраторов серверов Linux…

sudo getent group 'KOM-SRV-Linux-Administrators'

kom-srv-linux-administrators:x:206484:artur-p,senya-l,petya-r

…и для доменной учетной записи любого пользователя, которую мы планируем использовать для входа на наш Ubuntu Server…

sudo getent passwd 'artur-p'

artur-p:*:98981:10513:Артур Пирожков:/home/KOM/artur-p:/bin/bash

---

Создадим в каталоге домашних папок пользователей подкаталог для доменных пользователей в соответствии с настройками нашего smb.conf (в качестве имени каталога используем NetBIOS-имя домена):

sudo mkdir /home/KOM

---

Проверим, что после установки библиотеки libpam-winbind соответствующие PAM-модули для Winbind активирован.

sudo pam-auth-update

---

Правим файл /etc/pam.d/common-session. В конец файла добавим строку определяющую директиву создания домашнего каталога в случае его отсутствия: 

sudo nano -Y sh /etc/pam.d/common-session

Результирующий файл (без вывода комментариев) получится следующий:

session [default=1]     pam_permit.so
session requisite       pam_deny.so
session required        pam_permit.so
session optional        pam_umask.so
session required        pam_unix.so
session optional        pam_winbind.so
session optional        pam_systemd.so
session required        pam_mkhomedir.so umask=0022 skel=/etc/skel

---

Правим файл /etc/pam.d/common-auth. В строку описывающую вызов pam_winbind.so добавляем дополнительный параметр require_membership_of, в котором указываем имя доменной группы безопасности. В эту группу будут входить пользователи, которым мы хотим разрешить вход на наш Linux-сервер. Имя группы желательно указывать с учётом регистра, то есть так, как она создана в домене AD. Указанная группа должна быть группой глобального типа (область действия в домене AD).

sudo nano -Y sh /etc/pam.d/common-auth

Результирующий файл (без вывода комментариев) получится следующий:

auth    [success=2 default=ignore]      pam_unix.so nullok_secure
auth    [success=1 default=ignore]      pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass require_membership_of=KOM-SRV-Linux-Administrators
auth    requisite                       pam_deny.so
auth    required                        pam_permit.so
auth    optional                        pam_cap.so

---

Обратите внимание также на то, что в указанные файлы не стоит вносить никаких других изменений кроме указанных, даже таких простых, как например, изменение отступов в существующих параметрах. В противном случае мы потеряем возможность управлять включением/выключением PAM-модулей через конфигуратор pam-auth-update. Проверить то, как после ручной правки pam-auth-update воспринимает common-файлы, можно просто запустив его и если что-то ему не понравится, он сообщит нам об этом:

Если же всё таки где-то напортачили, то можно заставить pam-auth-update исправить параметры common-файлов в их исходные значения выбрав в указанном сообщении Yes, либо отдельной командой:

sudo pam-auth-update --force

---

Остальные common-файлы привожу информативно. В них мы редактировать вручную ничего не будем, так как конфигуратор pam-auth-update уже внёс все необходимые правки со ссылкой на winbind.

Результирующий файл /etc/pam.d/common-account (без вывода комментариев):

account [success=2 new_authtok_reqd=done default=ignore]        pam_unix.so
account [success=1 new_authtok_reqd=done default=ignore]        pam_winbind.so
account requisite                       pam_deny.so
account required                        pam_permit.so

Результирующий файл /etc/pam.d/common-password (без вывода комментариев):

password        [success=2 default=ignore]      pam_unix.so obscure sha512
password        [success=1 default=ignore]      pam_winbind.so use_authtok try_first_pass
password        requisite                       pam_deny.so
password        required                        pam_permit.so

Результирующий файл /etc/pam.d/common-session-noninteractive (без вывода комментариев):

session [default=1]                     pam_permit.so
session requisite                       pam_deny.so
session required                        pam_permit.so
session optional                        pam_umask.so
session required        pam_unix.so
session optional                        pam_winbind.so

---

После указанных настроек проверяем вход в систему используя учетные данные пользователя домена AD. В качестве логина указываем доменный логин пользователя (без доменной части). При этом проверяем, то что в систему удаётся войти только тем пользователям, которые включены в доменную группу безопасности KOM-SRV-Linux-Administrators. В случае возникновения проблем при входе следим за системным логом аутентификации:

sudo tail -f /var/log/auth.log

---

Замечено, что в случае, если в домене AD в свойствах групп безопасности, членом которых является аутентифицируемый пользователь, присутствует непустой атрибут sIDHistory (группа ранее была мигрирована в текущий домен из другого домена), то в процессе входа в Linux может появляться ряд сообщений типа:

...
groups: cannot find name for group ID 11224
groups: cannot find name for group ID 11231
groups: cannot find name for group ID 11277
groups: cannot find name for group ID 12569
groups: cannot find name for group ID 12737
groups: cannot find name for group ID 12753
...

Это связано с тем, что после аутентификации и авторизации для пользователя запускается shell-оболочка, которая была назначена пользователю согласно параметра template shell конфигурационного файла smb.conf. То есть в нашем случае выполняется оболочка /bin/bash. В текущей своей версии оболочка bash при запуске выполняет скрипт /etc/bash.bashrc. Если мы откроем этот скрипт, то увидим, что в нём присутствует такой фрагмент кода:

# sudo hint
if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; then
    case " $(groups) " in *\ admin\ *)
    if [ -x /usr/bin/sudo ]; then
        cat <<-EOF
        To run a command as administrator (user "root"), use "sudo ".
        See "man sudo_root" for details.

        EOF
    fi
    esac
fi

Этот участок скрипта используется для банального вывода подсказки о том, что для выполнения административных действий требуется использовать 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 visudo

Приведу фрагмент файла, в котором описываются группы доступа имеющие возможность выполнять sudo (здесь была добавлена последняя строчка фрагмента):

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
%KOM-SRV-Linux-Administrators ALL=(ALL) ALL

После сохранения файла снова входим в систему доменным пользователем и пробуем выполнить любую команду с sudo.

---

На этом всё. В следующей заметке мы рассмотрим процедуру настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows

---

Дополнительные источники информации:

• Ubuntu.ru WIKI - Ввод компьютера в домен Windows
• Ubuntu Community Help Wiki - Active Directory Winbind How-to
• Samba manpages - smb.conf.5
• Habrahabr - Linux в домене Active Directory
• UNIX/LINUX TECH NOTES  - Authenticate Linux users by Windows AD: LDAP+Kerberos or Winbind method