Аутентификация и авторизация в домене Active Directory при подключении к серверу Ubuntu Server 14.04 LTS

imageВ одной из прошлых заметок мы рассмотрели процедуру присоединения сервера на базе 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

image


Правим файл /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-файлы, можно просто запустив его и если что-то ему не понравится, он сообщит нам об этом:

image

Если же всё таки где-то напортачили, то можно заставить 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


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

Всего комментариев: 9 Комментировать

  1. Ruslan /

    Добрый день. У меня веселая "неделя". После того, как пересел за более "мощный" компьютер, захотелось поставить более свежую версию Ubuntu 14.04 (с 12.04). Пытаюсь ввести в домен AD, который находится на сервере WindowsServer 2003. На версии 12.04 - особых проблем не возникало - желаемого успеха добивался, а именно авторизация на ОС - с доменных учетных записей. На версии 14.04 - когда вот-вот и все готово - либо перегружаю компьютер, либо просто "выхожу из учетной записи" - у меня слетают графические драйвера (к слову, восстановить не получается). Либо приходится работать через консольную команду, либо снова перебивать систему и внимательно вбивать все настройки, который в конце-концов приводят к одному и тому же результату - слетают графические драйвера.
    Все мануалы по вводу 14.04 в домен AD - какие-то мутные и не законченные, везде свои способы решения.

    1. Алексей Максимов / Автор записи

      У меня нет систем Ubuntu с графической оболочкой, поэтому помочь Вам не смогу.

  2. Fred /

    Добрый день.
    Хочу сказать спасибо за статью, всё внятно и доступно изложено.
    Возник только вопрос. Не получается войти на сервер под доменной учетной записью.
    Ошибка из auth.log.

    Nov 26 16:18:12 ubuntuTGW login[1055]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty3 ruser= rhost= user=admin
    Nov 26 16:18:12 ubuntuTGW login[1055]: pam_winbind(login:auth): getting password (0x00000388)
    Nov 26 16:18:12 ubuntuTGW login[1055]: pam_winbind(login:auth): pam_get_item returned a password
    Nov 26 16:18:12 ubuntuTGW login[1055]: pam_winbind(login:auth): internal module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'admin')
    Nov 26 16:18:16 ubuntuTGW login[1055]: FAILED LOGIN (1) on '/dev/tty3' FOR 'admin', Authentication failure

    Билет kinit пользователей получает.
    getent passwd и getent group всё показывается, единственное что меня смущает, что:
    UID и GID,

    admin2:*:4294967295:4294967295:admin2:/home/TESTDM/admin2:/bin/bash
    ser123:*:4294967295:4294967295:ser:/home/TESTDM/ser123:/bin/bash

    testdm-ia:x:4294967295:
    sambagroup:x:4294967295:admin

    Это нормально?

  3. Обратная ссылка: Подключение Debian GNU/Linux 8.6 к домену Active Directory с помощью SSSD и realmd | Блог IT-KB /

  4. Вадим /

    Большое спасибо за статью. Тоже столкнулся с такой проблемой когда выходят такие вот ошибки:

    groups: cannot find name for group ID 11224

    (это же сообщение может выглядеть по-русски так:)

    groups: невозможно определить имя группы для ID 11224

    Чтобы подавить это сообщение по совету автора можно изменить содержимое скрипта /etc/bash.bashrc.
    Поработав над вариантами решения проблемы, предлагаю всего одно маленькое дополнение к команде
    $(groups 2>/dev/null),
    т.е. перенаправим все ошибки на нулевое устройство. Тогда фрагмент файла /etc/bash.bashrc будет выглядеть так:

    # sudo hint
    if [ ! -e "$HOME/.sudo_as_admin_successful" ] && [ ! -e "$HOME/.hushlogin" ] ; then
    case " $(groups 2>/dev/null) " 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

    Теперь после входа пользователя, аутентифицированного в домене AD через SAMBA сообщения о невозможности определить имя группы не появится! Команда groups определить все доступные группы, а ошибки отсеются на /dev/null.

    1. Алексей Максимов / Автор записи

      Если бы ещё этот хинт нёс какую-то смысловую нагрузку, имело бы смысл его оставлять. А так, по моему правильней вообще его закомментировать или удалить нафиг.

  5. Александр /

    Алексей, может подскажите, как через sssd автоматически всех доменных пользователей поместить в локальную группу линукс? Вручную получается, например через usermod -G доменный_пользователь. Можно наверное и через bash-скрипт, которому предоставить список пользователей и в цикле прокрутить usermod для каждого, однако это костыльное решение и точно не однократное. Какой-то штатный способ должен же быть

    1. Алексей Максимов / Автор записи

      Статья про winbind, а не про sssd. По настройке sssd есть отдельные статьи.

  6. Вячеслав /

    sudo service samba restart не заработает, потому что поругается на отсутствие соответствующего юнита. Нужно sudo service smbd restart
    Про sssd. С обновлением версии самбы начиная с 4.7 и 4.9(текущая) возникает куча ошибок и не работает аутентификация в AD. Рабочие ранее конфигурации и обновленные до актуальной версии самбы, перестают быть таковыми, настройка с нуля дает тот же эффект. Чтение манов не приносит эффекта. Пришлось смотреть в направлении winbind.

Добавить комментарий