Прозрачная аутентификация к Ubuntu Server 12.04.5 c доменных компьютеров

Posted by

Продолжая тему интеграции системы на базе Ubuntu Server 12.04.5 в доменную инфраструктуру Active Directory (AD), в этой заметке я рассмотрю такой вопрос как настройка безпарольного подключения к системе Ubuntu с клиентских компьютеров под управлением Windows 7, т. е. это своего рода настройка (SSO).

Такую прозрачную аутентификацю я показывал у себя на блоге, как для

Windows XP

Windows 7

тем самым инициализировалось подключение к терминальному серверу Windows. А данная практическая заметка покажет еще один вариант использования Single sign-on.

Итак, в домене Polygon.local создал группу LinuxAdmin и включил в нее пользователя с учетной записью admin.

Данная заметка опирается на ниже следующие:

Как ввести систему Ubuntu 12.04 в домен polygon.local

После перезагрузки системы не похватывается получение тикета домена

Чтобы создавался пользовательский доменный каталог

 

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

ekzorchik@srv-serv:~$ sudo nano /etc/ssh/sshd_config

# Kerberos options

KerberosAuthentication yes

#KerberosGetAFSToken no

KerberosOrLocalPasswd yes

KerberosTicketCleanup yes

# GSSAPI options

GSSAPIAuthentication yes

GSSAPICleanupCredentials yes

AllowGroups adm LinuxAdmin

Сохраняем внесенные изменения.

 

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

Примет вывода групп в которых состоит текущий пользователь:

ekzorchik@srv-serv:~$ groups

ekzorchik adm cdrom sudo dip plugdev lpadmin sambashare domain users schema admins enterprise admins domain admins BUILTIN\administrators BUILTIN\users

, из вывод видно, что пользователь ekzorchik не принадлежит группе LinuxAdmin и ее нет в выводе, если же авторизовать под пользователем admin то и вывод будет другой:

ekzorchik@srv-serv:~$ su — admin

Password:Aa1234567

Password:Aa1234567

admin@srv-serv:~$ groups

domain users domain admins BUILTIN\administrators BUILTIN\users linuxadmin

, вывод показывает, что пользователь admin принадлежит группе linuxadmin.

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

ekzorchik@srv-serv:~$ sudo service ssh restart

ssh stop/waiting

ssh start/running, process 3283

Далее реализую возможность для Kerberosподсистемы представляться разным службам от имени записи вида: (SPN) HOST/{ServerFQDN}@{DomainFQDN}.

ekzorchik@srv-serv:~$ sudo rm /etc/krb5.keytab

ekzorchik@srv-serv:~$ sudo net ads keytab create -U ekzorchik

Enter ekzorchik’s password: указываю пароль — 712mbddr@

ekzorchik@srv-serv:~$ sudo net ads keytab add HOST/srv-ad.polygon.local@POLYGON.local -U ekzorchik

Processing principals to add…

Enter ekzorchik‘s password:712mbddr@

, где U ekzorchik (вместо данной учетной записи указывается любой доменный пользователь состоящей в группе Domain Admins)

 

Теперь посмотрим, что получим из вывода команды:

ekzorchik@srv-serv:~$ sudo net ads keytab list

Vno Type Principal

2 DES cbc mode with CRC-32 host/srv-serv.polygon.local@POLYGON.LOCAL

2 DES cbc mode with RSA-MD5 host/srv-serv.polygon.local@POLYGON.LOCAL

2 ArcFour with HMAC/md5 host/srv-serv.polygon.local@POLYGON.LOCAL

2 DES cbc mode with CRC-32 host/srv-serv@POLYGON.LOCAL

2 DES cbc mode with RSA-MD5 host/srv-serv@POLYGON.LOCAL

2 ArcFour with HMAC/md5 host/srv-serv@POLYGON.LOCAL

2 DES cbc mode with CRC-32 SRV-SERV$@POLYGON.LOCAL

2 DES cbc mode with RSA-MD5 SRV-SERV$@POLYGON.LOCAL

2 ArcFour with HMAC/md5 SRV-SERV$@POLYGON.LOCAL

2 DES cbc mode with CRC-32 HOST/srv-ad.polygon.local@POLYGON.local

2 DES cbc mode with RSA-MD5 HOST/srv-ad.polygon.local@POLYGON.local

2 ArcFour with HMAC/md5 HOST/srv-ad.polygon.local@POLYGON.local

 

Далее редактирую конфигурационный файл Samba 3.6.3:

ekzorchik@srv-serv:~$ sudo nano /etc/samba/smb.conf

kerberos method = secrets and keytab

Сохраняем внесенные изменения

Теперь переключаюсь на компьютер (W7X86) под управлением Windows 7, авторизовавшись под доменной учетной записью admin и настраиваю SSHклиент => PuTTY.

Session:

Host Name (or IP address) = srv-serv

Port = 22

, где srv-serv – это запись уже через оснастку DNS заведена на домен контроллере в ручную сопоставлением IP и DNS.

Connection — Data

Use system username (admin)

, где admin – имя текущего пользователя Windows

Connection – SSH – Auth – GSSAPI (включаем опции)

Attempt GSSAPI authentication (SSH-2 only)

Allow GSSAPI credential delegation

После снова переходим в Session и сохраняем настройки данного подключения:

Saved Sessionsуказываем по имени сервера к которому подключаемся и нажимаем Save
Настраиваю Putty клиент для прозрачной аутентификации

Пробую выполнить подключение кнопкой «Open», на запроc об принятии SSH токена соглашаюсь нажав «ДА»

Принимаю токен подключения через SSH

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

Прозрачное подключение происходит успешно

Если же Вы все таки выводится предложение ввести пароль:

Если все таки выводится пароль, то активируем подробные логи

Для расследования данного инцидента потребуется включить подробное логирование в конфигурационном файле sshd_config:

ekzorchik@srv-serv:~$ sudo nano /etc/ssh/sshd_config

было:

# Logging

SyslogFacility AUTH

LogLevel INFO

привел к виду:

# Logging

SyslogFacility AUTH

LogLevel DEBUG3

Сохраняю внесенные изменения.

На рабочей станции снова инициализируем подключение через клиент Putty и переключившись на консоль работы с сервером Ubuntu смотрим расширенные логи подключения с целью обозначить проблемы и решить:

ekzorchik@srv-serv:~$ sudo tail -f /var/log/auth.log | grep w7x86.polygon.local

Sep 14 16:03:26 srv-serv sshd[3369]: User admin from w7x86.polygon.local not allowed because none of user’s groups are listed in AllowGroups

, как видно у меня в конфиге /etc/ssh/sshd_config группа задана с использование заглавного написания, а нужно было указать просто без этого, сам же ведь себе выше в заметке привел пример вывода команды groupsвот и моя невнимательность., исправляю:

ekzorchik@srv-serv:~$ sudo nano /etc/ssh/sshd_config

AllowGroups adm linuxadmin

Сохраняю изменения и перезапускаю демон SSH:

ekzorchik@srv-serv:~$ sudo service ssh restart

ssh stop/waiting

ssh start/running, process 3381

Проверю снова подключение через клиент Putty и на этот раз проблем нет. Так перед тем как паниковать, советую почитать логи, а уже потом если все таки не удается решить проблемы на основе сообщений логов уже Googleить.

Решил проверить, а смогу ли я на этой рабочей станции но уже под учетной записью ekzorchik проделать такой фокус (ведь состоит в группу adm), настроил клиент Putty и тоже получилось авторизоваться. Работает.

Пробую повторить под учетной записью alektest и получаю ошибку, ну не совсем чтобы ошибку, а запрос ввода пароля для аутентификации:

Using username «alektest».

alektest@srv-serv’s password:

ввожу пароль: Aa1234567

но не пускает,

Using username «alektest».

alektest@srv-serv’s password:

Access denied

, а оно и правильно, ведь он не состоит ни в какой группе, кроме «Domain Users”. Да и к тому же в логах фиксирую:

ekzorchik@srv-serv:~$ sudo tail -f /var/log/auth.log | grep alektest

Sep 14 17:46:32 srv-serv sshd[5455]: debug1: userauth-request for user alektest service ssh-connection method none [preauth]

Sep 14 17:46:32 srv-serv sshd[5455]: User alektest from w7x86.polygon.local not allowed because none of user’s groups are listed in AllowGroups

Sep 14 17:46:32 srv-serv sshd[5455]: input_userauth_request: invalid user alektest [preauth]

Sep 14 17:46:32 srv-serv sshd[5455]: debug1: userauth-request for user alektest service ssh-connection method gssapi-with-mic [preauth]

Sep 14 17:46:32 srv-serv sshd[5455]: debug1: PAM: initializing for «alektest»

На основе всего того что приведено выше, считаю что заметка полностью имеет право быть опубликованной на моем блоге. Пошаговые действия по именованию заметки полностью расписаны. Мне же остается только попрощаться с читателями и сказать — «До встречи», с уважением автор блога ekzorchik.

Leave a Reply

Ваш e-mail не будет опубликован. Обязательные поля помечены *

1 × 3 =