Кто помнит, я на своем блоге показывал как настроить технологию SSO (Single Sing-on) применительно в доменной структуре для авторизации пользователей на терминальном сервере через доменную аутентификацию без какого-либо запроса ввода связки логин&пароль со стороны пользователя при подключении к терминальному серверу. Это было замечательно сделано и воплощено на одной из работ.
Но вот тут я себе задал вопрос, а ведь можно использовать SSO для авторизации и на Ubuntu–системах, к примеру DokuWiki, GLPI, Redmine, OwnCloud для внутренний нужд, а не городить огород различных доступом. Плюс мне стало интересно, а как прикрутить Single Sing-On к веб серверу Apache2.
Итак текущий стенд чтобы все можно было наложить на боевую структуру, все должно быть приближено к реальности.
- Домен контроллер на базе Windows Server 2016 (srv-dc.polygon.local) 192.168.2.2
- Mikrotik в роли шлюза (192.168.2.1)
- Ubuntu 14.04.5 Server amd64 с ролью LAMP (srv-trusty.polygon.local) 192.168.2.100
Предварительные настройки:
Система Ubuntu 14.04 с обновленным ядром поставленным по заметке.
На домен контроллере в оснастке DNS созданы A записи: srv-gw.polygon.local & srv-trusty.polygon.local
Начинаю.
Шаг №1: Действия на домен контроллере.
Авторизуюсь на домен контроллере с правами группу «Администраторы домена» и создаю специального пользователя, для эксперимента делать это я буду через консоль командной строки, но Вы можете через GUI-оснастку «Пользователи и компьютеры Active Directory»:
C:\Windows\system32>dsadd user "cn=webserver,ou=it,dc=polygon,dc=local" -pwd Aa1234567 -mustchpwd no -canchpwd no -pwdneverexpires yes -UPN webserver@polygon.local dsadd Успешно:cn=webserver,ou=it,dc=polygon,dc=local
Для пояснения указанных параметров:
-pwd → указываю пароль на создаваемую учетную запись
-mustchpwd → при входе пользователя в домен у него не будет запрашиваться чтобы он его поменял.
-canchpwd → пользователь не может менять пароль.
-pwdneverexpires → срок действия пароля никогда не истекает.
-UPN → имя входа пользователя пред–Windows 2000
Далее по аналогии, как я делал когда настраивал SQUID для работы в домене создаю keytab–файл:
C:\Windows\system32>ktpass -princ HTTP/srv-trusty.polygon.local@POLYGON.LOCAL -mapuser webserver@POLYGON.LOCAL -pass Aa1234567 -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out %userprofile%\srv-trusty.keytab Targeting domain controller: srv-dc.polygon.local Using legacy password setting method Successfully mapped HTTP/srv-trusty.polygon.local to webserver. Key created. Output keytab to C:\Users\ekzorchik\srv-trusty.keytab: Keytab version: 0x502 keysize 78 HTTP/srv-trusty.polygon.local@POLYGON.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x17 (RC4-HMAC) keylength 16 (0x58705ad7aee5c92df1aa249430acad10)
Если посмотреть в оснастке «Пользователи и компьютеры Active Directory» на свойства учетной записи webserver вкладка «Учетная запись» можно будет видеть, что для этой учетной записи создан keytab файл который будет использоваться с системы srv-trusty.polygon.local
Затем передаем данный keytab файл на систему srv-trusty.polygon.local такими способами которыми можно из Windows системы достучаться (к примеру: WinSCP клиент и т. д.) до Ubuntu системы или наоборот:
ekzorchik@srv-trusty:~$ sudo mount -t cifs //192.168.2.2/C$ /media/cdrom -o username=ekzorchik,domain=polygon.local,password=712mbddr@ ekzorchik@srv-trusty:~$ sudo cp /media/cdrom/Users/ekzorchik/srv-trusty.keytab /etc/ ekzorchik@srv-trusty:~$ sudo umount /media/cdrom
Шаг №2: Действия на Ubuntu системе.
ekzorchik@srv-trusty:~$ sudo nano /etc/hostname srv-trusty.polygon.local ekzorchik@srv-trusty:~$ sudo nano /etc/hosts 192.168.2.100 srv-trusty.polygon.local srv-trusty 192.168.2.1 srv-gw.polygon.local srv-gw 192.168.2.2 srv-dc.polygon.local srv-dc
Устанавливаю пакет для работы Kerberos аутентификации:
ekzorchik@srv-trusty:~$ sudo apt-get install -y krb5-user libapache2-mod-auth-kerb
Редактирую файл krb5.conf:
ekzorchik@srv-trusty:~$ cp /etc/krb5.conf ~/krb5.conf.backup
ekzorchik@srv-trusty:~$ sudo vi /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = POLYGON.LOCAL
default_keytab_name = /etc/srv-trusty.keytab
dns_lookup_kdc = false
dns_lookup_realm = false
forwardable = true
ticket_lifetime = 24h
[realms]
POLYGON.LOCAL = {
kdc = srv-dc.polygon.local
default_domain = POLYGON.LOCAL
admin_server = srv-dc.polygon.local
}
[domain_realm]
.polygon.local = POLYGON.LOCAL
polygon.local = POLYGON.LOCAL
Но прежде чем идти дальше нужно проверить, а отрабатывает ли авторизация в Active Directory с созданным выше билетом:
ekzorchik@srv-trusty:~$ kinit -kV -p HTTP/srv-trusty.polygon.local
Using default cache: /tmp/krb5cc_1000
Using principal: HTTP/srv-trusty.polygon.local@POLYGON.LOCAL
Authenticated to Kerberos v5
Ответ да билет работает. Но так как это было тестирование то билет пока можно удалить:
ekzorchik@srv-trusty:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/srv-trusty.polygon.local@POLYGON.LOCAL
Valid starting Expires Service principal
03/14/2018 19:42:16 03/15/2018 05:42:16 krbtgt/POLYGON.LOCAL@POLYGON.LOCAL
renew until 03/15/2018 19:42:16
ekzorchik@srv-trusty:~$ kdestroy
Чтобы Web–сервис Apache2 мог воспользоваться kerberos билетом нужно выдать ему разрешения:
ekzorchik@srv-trusty:~$ sudo chown root:www-data /etc/srv-trusty.keytab
ekzorchik@srv-trusty:~$ sudo chmod 640 /etc/srv-trusty.keytab
Устанавливаю пакет LAMP в систему:
ekzorchik@srv-trusty:~$ sudo tasksel install lamp-server
New password for the MySQL "root" user:712mbddr@Repeat password for the MySQL "root" user:712mbddr@
Т.к. я сейчас описываю суть авторизации с помощью SSO, то нацеливать доступ буду к тестовой странице с выводом при обращении через URL браузера http://srv-trusty, а ответ я получаю: «Apache2 Ubuntu Default Page», то вот доступ к этой странице я закрою Kerberos авторизацией:
ekzorchik@srv-trusty:~$ sudo vi /etc/apache2/sites-available/000-default.conf
<VirtualHost *:80>
<Location />
AuthType Kerberos
AuthName "Access Kerberos"
KrbAuthRealms POLYGON.LOCAL
KrbServiceName HTTP/srv-trusty.polygon.local
Krb5Keytab /etc/srv-trusty.keytab
KrbMethodNegotiate On
KrbMethodK5Passwd On
require valid-user
</Location>
</VirtualHost *:80>
Активирую изменения путем перезапуска Web–сервера:
ekzorchik@srv-trusty:~$ sudo service apache2 restart
* Restarting web server apache2 [fail]
* The apache2 configtest failed.
Output of config test was:
AH00526: Syntax error on line 26 of /etc/apache2/sites-enabled/000-default.conf:
Invalid command 'KrbAuthRealms', perhaps misspelled or defined by a module not included in the server configuration
Action 'configtest' failed.
Так что тут у нас, нашел решение — у меня не подгружен модуль:
ekzorchik@srv-trusty:~$ sudo a2enmod auth_kerb
Enabling module auth_kerb.
ekzorchik@srv-trusty:~$ sudo service apache2 restart
Шаг №3: Возвращаю к браузеру и обновляю страницу с URL адресом: http://srv-trusty
Указываю к примеру:
Имя пользователя:alektestПароль:Aa1234567
и нажимаю OK, после чего меня пропускает до дефолтной страницы приветствия об установленном Web-сервисе apache2. Где учетная запись — это самая обычная учетная запись с группой «Пользователи домена». Итого, что и требовалось — я разобрал в шагах, как настроить авторизацию внутри Apache2 через доменную аутентификацию. Надеюсь данная заметка поможет Вам и мне в дальнейшем. С уважением автор блога Олло Александр aka ekzorchik.