Всем привет!

Вот такой вопрос прозвучал в комментариях к этой статье, спасибо автору, а еще, нам на предприятие пришло вот такое распоряжение:

Если бы мы уже использовали инфраструктуру Microsoft AD, то выбрали бы миграцию на Samba 4, но задача касалась только вводимых в эксплуатацию рабочих станций Linux и мы выбрали “ванильный” MIT Kerberos.

В двух словах про Kerberos, это протокол аутентификации, позволяющий использовать свой логин и пароль на любом компьютере, подключенном к kerberos сфере (входящем в домен, в терминах Microsoft). Кроме того, он реализует технологию единого входа (Single Sign-On) что позволяет, например, предоставить “прозрачный” доступ в Интернет через прокси сервер с аутентификацией пользователей.

Итак, реализация:

Разворачиваем в сети kerberos сервер (Центр распределения ключей - Key distribution center - KDC). Очень важно правильно указать hostname системы и сделать соответствующие A и SRV записи в DNS:

# hostnamectl set-hostname kdc.corp.ru

$ nslookup -q=SRV _kerberos._udp.corp.ru
...
_kerberos._udp.corp.ru service = 1 0 88 kdc.corp.ru.
...
kdc.corp.ru    internet address = A.B.C.D

Устанавливаем программное обеспечение и инициализируем kerberos сферу - realm или домен, в терминах Microsoft (далее все инструкции приведены для Debian/Ubuntu)

kdc# apt install krb5-kdc krb5-admin-server

kdc# krb5_newrealm
...

kdc# service krb5-kdc restart

Добавляем учетные записи пользователей (в kerberos называются principal)

kdc# kadmin.local -q 'addprinc -pw somepassword1 ivanovii'

kdc# kadmin.local -q 'addprinc -pw somepassword2 petrovpp'

...

Теперь можно подключать к kerberos сфере (вводить в домен) рабочие станции, например, таким способом, и пользователи смогут работать на них, используя свои логины и пароли.

Далее, разворачиваем прокси сервер для аутентификации и учета доступа пользователей в Интернет (тоже, очень важно, указать корректный hostname и соответствующую A запись в DNS)

# hostnamectl set-hostname authproxy.corp.ru

authproxy# apt install squid

Добавляем в kdc principal сервиса HTTP, работающего на authproxy (у нас он будет использоваться браузером для SSO аутентификации в squid, но так же, может быть использован и c web сервером, например - apache) выгружаем ключи и копируем их на authproxy:

kdc# kadmin.local -q 'addprinc -randkey HTTP/authproxy.corp.ru'

kdc# kadmin.local -q 'ktadd -k authproxyhttp.keytab HTTP/authproxy.corp.ru'

kdc# scp authproxyhttp.keytab admin@authproxy:

Подключаем прокси сервер к kerberos сфере, копируем ключи в системный файл и предоставляем доступ к нему для сервиса squid:

authproxy# apt install krb5-user

authproxy# nano /etc/krb5.conf

[libdefaults]
default_realm = CORP.RU

authproxy# ktutil

ktutil:  rkt /home/admin/authproxyhttp.keytab
ktutil:  wkt /etc/krb5.keytab
ktutil:  exit

authproxy# chgrp proxy /etc/krb5.keytab

authproxy# chmod 640 /etc/krb5.keytab

Настраиваем прокси сервис на использование kerberos аутентификации:

authproxy# nano /etc/squid/conf.d/corp.conf

auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -d
acl authuser proxy_auth REQUIRED
http_access allow authuser

authproxy# service squid restart

Для работы через proxy на рабочих станциях Linux достаточно установить переменные окружения:

linuxclientN# nano /etc/environment

export http_proxy=http://authproxy.corp.ru:3128/
export https_proxy=http://authproxy.corp.ru:3128/
export no_proxy=localhost,127.0.0.1,corp.ru

Происходящие процессы аутентификации можно наблюдать в этих журнальных файлах (частой причиной проблем в работе протокола kerberos, кроме DNS, может быть расхождение времени в системах более чем на 5 минут).

kdc# tail -f /var/log/auth.log

authproxy# tail -f /var/log/squid/access.log

Аналогично можно настроить “прозрачный” доступ соответствующих программ к сервисам SMTP, IMAP, LDAP, XMPP, CIFS и, даже, SSH:)

В следующей статье планирую рассказать как мы дополнили “Cамое простое решение для Kerberos” реализацией GPO на основе ansible-pull и GitLab.

На этом все, спасибо, буду рад ответить на вопросы в комментариях!