Всем привет!
Вот такой вопрос прозвучал в комментариях к этой статье, спасибо автору, а еще, нам на предприятие пришло вот такое распоряжение:
IMG_1.png
Если бы мы уже использовали инфраструктуру 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
На этом все, спасибо, буду рад ответить на вопросы в комментариях.