Аутентификация и авторизация в домене 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
Дополнительные источники информации: