SSO-подключение к серверу Ubuntu Server 14.04 LTS по протоколу SSH с помощью PuTTY с компьютера на базе Windows в домене Active Directory

Продолжая тему интеграции систем на базе Linux в доменную инфраструктуру Active Directory (AD), в этой заметке мы рассмотрим вопрос настройки Single sign-on (SSO) при подключении к Linux-серверу на базе Ubuntu Server 14.04 LTS по протоколу SSH с клиентских компьютеров под управлением Windows. Начнём с настроек на стороне Linux-сервера, который будет выступать в качестве сервера SSH на базе пакета OpenSSH (описание установки и базовой настройки рассмотрено ранее).

Для начала включим поддержку GSSAPI для службы сервера OpenSSH и пропишем ограничение по группам доступа:

sudo nano -Y sh /etc/ssh/sshd_config

Фрагмент изменённых и добавленных строк конфигурационного файла:

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

# User groups access contol
AllowGroups adm kom-srv-linux-administrators

Разрешённые группы нужно указывать через пробел. В списке могут фигурировать как локальные (для локальных пользователей) так и доменные (для доменных пользователей) группы доступа, при этом их названия должны быть указаны в нижнем регистре, так как их возвращает команда groups для текущего пользователя.

Для вступления изменений в силу перезапускаем службу сервера SSH:

sudo service ssh restart

***

Теперь нам нужно реализовать возможность для Kerberos-подсистемы представляться разным службам от имени принципала (SPN) HOST/{ServerFQDN}@{DomainFQDN}.
Посмотрим что возвращает команда:

sudo net ads keytab list

Warning: "kerberos method" must be set to a keytab method to use keytab functions.
Vno  Type                                     Principal
  3  des-cbc-crc                              HTTP/kom-ad01-squid.holding.com@HOLDING.COM
  3  des-cbc-md5                              HTTP/kom-ad01-squid.holding.com@HOLDING.COM
  3  arcfour-hmac-md5                         HTTP/kom-ad01-squid.holding.com@HOLDING.COM
  3  aes256-cts-hmac-sha1-96                  HTTP/kom-ad01-squid.holding.com@HOLDING.COM
  3  aes128-cts-hmac-sha1-96                  HTTP/kom-ad01-squid.holding.com@HOLDING.COM

Как видно, мы получаем список ключей, которые хранятся в keytab-файле указанном в параметре default_keytab_name конфигурационного файла /etc/krb5.conf, который мы задали ранее конфигурируя систему для Squid. Однако в силу того, что дополнительно мы создавали файл /etc/default/squid3 где прописали путь к keytab-файлу необходимому для Squid, мы смело можем отключить параметр default_keytab_name конфигурационного файла /etc/krb5.conf,
чтобы в системе по умолчанию использовался файл /etc/krb5.keytab. Итак, отредактируем файл krb5.conf:

sudo nano -Y sh /etc/krb5.conf

Закомментируем в нём ранее записанную нами строку:

#    default_keytab_name = /etc/squid3/PROXY.keytab

***

Добавляем в дефолтный keytab-файл (/etc/krb5.keytab) записи типа HOST/* с помощью команды: 

sudo net ads keytab add HOST/{ServerFQDN>}@{DomainFQDN} -U {domain_admin_login}

что в нашем случае будет выглядеть как: 

sudo net ads keytab add HOST/kom-ad01-gw10.holding.com@HOLDING.COM –U vasya-a

***

Отредактируем конфигурационный файл Samba4: 

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

Добавим в него строчку: 

kerberos method  = secrets and keytab

***

Снова выполним команду вывода списка доступных SPN и убедимся в том, что выводятся данные файла /etc/krb5.keytab и в них есть записи вида HOST/{ServerFQDN}@{DomainFQDN} 

sudo net ads keytab list

Vno  Type                                      Principal
100014  des-cbc-crc                            HOST/kom-ad01-gw10.holding.com@HOLDING.COM
100014  des-cbc-md5                            HOST/kom-ad01-gw10.holding.com@HOLDING.COM
100014  aes256-cts-hmac-sha1-96                HOST/kom-ad01-gw10.holding.com@HOLDING.COM
100014  aes128-cts-hmac-sha1-96                HOST/kom-ad01-GW10.holding.com@HOLDING.COM
100014  arcfour-hmac-md5                       HOST/kom-ad01-GW10.holding.com@HOLDING.COM
100014  des-cbc-crc                            HOST/KOM-AD01-GW10@HOLDING.COM
100014  des-cbc-md5                            HOST/KOM-AD01-GW10@HOLDING.COM
100014  aes128-cts-hmac-sha1-96                HOST/KOM-AD01-GW10@HOLDING.COM
100014  aes256-cts-hmac-sha1-96                HOST/KOM-AD01-GW10@HOLDING.COM
100014  arcfour-hmac-md5                       HOST/KOM-AD01-GW10@HOLDING.COM

***

Переходим на компьютер под управлением Windows и настраиваем SSH-клиента PuTTY. В категории настроек Session в поле Host Name указываем FQDN имя Linux-сервера, так как оно зарегистрировано в DNS (то же имя, которое мы использовали при добавлении в keytab-файл).

В категории настроек Connection > Data включаем опцию Use system username, чтобы использовалось имя текущего пользователя Windows (будет указано в скобках):

В категории настроек Connection > Auth > GSSAPI включаем опции Attempt GSSAPI… и Allow GSSAPI…

Пробуем выполнить подключение кнопкой Open.

Подключение должно пройти прозрачно без запроса ввода пароля в контексте пользователя, из под которого в данный момент запущен SSH-клиент PuTTY.

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

***

В случае если подключиться через SSН с помощью PuTTY без явного указания пароля не получается (выходит предложение ввести пароль) включаем расширенное логирование в конфигурационном файле sshd_config

sudo nano -Y sh /etc/ssh/sshd_config

Фрагмент файла отвечающий за функции логирования: 

# Logging
SyslogFacility AUTH
#LogLevel INFO
LogLevel DEBUG3

После сохранения файла перезапускаем службу сервера SSH и запускаем наблюдение за системным логом аутентификации: 

sudo service ssh restart
sudo tail -f /var/log/auth.log

***

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

Manual Pages OpenSSH - sshd_config