Настройка керберос centos linux

Авторизация на SQUID через Active Directory

Инструкция подразумевает, что у нас уже есть рабочий Squid-сервер. В противном случае, настраиваем, используя инструкцию Установка и настройка Squid на CentOS.

Наш сервер будет принимать как наиболее безопасную Kerberos-авторизацию, так и NTLM. Для компьютеров в домене будет поддерживаться прозрачная LDAP-аутентификация. Все команды выполняются на примере системы Linux CentOS 7.

Подготовка

Настройка времени

Интеграция с Active Directory требует минимального расхождения времени с контроллером домена. Устанавливаем утилиту chrony:

yum install chrony

Запускаем службу для синхронизации времени:

systemctl enable chronyd —now

Имя сервера

Задаем имя сервера следующей командой:

hostnamectl set-hostname proxy.domain.local

* где proxy — имя сервера; domain.local — доменное имя, используемое в сети.

Настройка на контроллере домена

Создание учетной записи

Открываем консоль управления пользователями и добавляем нового со стандартными правами. От этой учетной записи будут выполняться запросы к AD DS.

В своем примере мы создаем пользователя squid.

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

Создание keytab-файла

В двух словах, данный файл позволяет установить легитимность нашего Linux-сервера. Создается он на контроллере домена и копируется на последний.

Для создания файла переходим на контроллер домена и от имени администратора запускаем Powershell или обычную командную строку. Вводим:

ktpass /princ HTTP/proxy.domain.local@DOMAIN.LOCAL /mapuser squid@DOMAIN.LOCAL /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass «password» /out C:\proxy.keytab

* где proxy.domain.local — полное имя нашего squid-сервера; DOMAIN.LOCAL — наш домен; squid@DOMAIN.LOCAL — учетная запись в AD для выполнения запросов (создана на шаге выше); password — пароль, который будет задан пользователю (должен соответствовать требованию AD).
* регистр важен.

В нашем примере, после выполнения команды на контроллере домена в корне диска С появится файл proxy.keytab. Его копируем на Linux-сервер, например, при помощи WinSCP.

Настройка CentOS

Kerberos

Устанавливаем следующие пакеты:

yum install cyrus-sasl-gssapi krb5-workstation krb5-devel

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

Редактируем следующие строки:

[libdefaults]
.
default_realm = DOMAIN.LOCAL
..

[realms]
DOMAIN.LOCAL = <
kdc = 192.168.0.15
kdc = 192.168.0.16
kdc = 192.168.0.17
admin_server = domain.local
>

* DOMAIN.LOCAL — наш домен; kdc — перечень контроллеров домена; admin_server — первичный контроллер (в данном примере будет использоваться случайный).

Проверяем настройки krb, запросив тикет:

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

Ticket cache: KEYRING:persistent:0:0
Default principal: domainuser@DOMAIN.LOCAL

Valid starting Expires Service principal
15.05.2018 10:08:33 15.05.2018 20:08:33 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 22.05.2018 10:08:30

Проверяем keytab-файл, который мы перенесли на сервер с контроллера домена:

kinit -V -k -t /etc/squid/proxy.keytab HTTP/proxy.domain.local@DOMAIN.LOCAL

* где /etc/squid/proxy.keytab — путь до keytab-файла; HTTP/proxy.domain.local@DOMAIN.LOCAL — принципал, который был задан при создании файла.

Картина, примерно, следующая:

Ticket cache: KEYRING:persistent:0:krb_ccache_9MN6pt8
Default principal: HTTP/proxy.domain.local@DOMAIN.LOCAL

Valid starting Expires Service principal
16.05.2018 09:35:20 16.05.2018 19:35:20 krbtgt/DOMAIN.LOCAL@DOMAIN.LOCAL
renew until 23.05.2018 09:35:20

Зададим файлу следующие права:

chown squid:squid /etc/squid/proxy.keytab

chmod u+rwx,g+rx /etc/squid/proxy.keytab

Устанавливаем следующие пакеты:

yum install samba-winbind samba-winbind-clients pam_krb5 krb5-workstation

authconfig —enablekrb5 —krb5kdc=domain.local —krb5adminserver=domain.local —krb5realm=domain.LOCAL —enablewinbind —enablewinbindauth —smbsecurity=ads —smbrealm=domain.LOCAL —smbservers=domain.local —smbworkgroup=domain —winbindtemplatehomedir=/home/%U —winbindtemplateshell=/bin/bash —enablemkhomedir —enablewinbindusedefaultdomain —update

* где domain.local — это наш домен, domain — домен в сокращенной нотации. Регистр важен.
* если после ввода команды мы увидим ошибку Job for winbind.service failed because the control process exited with error code. See «systemctl status winbind.service» and «journalctl -xe» for details — игнорируем ее. Она возникает из-за того, что наш сервер еще не в домене.

Добавляем сервер в домен:

net ads join -U administrator

* где administrator — учетная запись в AD с правами на ввод компьютеров в домен.

Разрешаем автозапуск winbind и запускаем его:

systemctl enable winbind

systemctl start winbind

Проверяем, что наш сервер умеет обращаться к службе каталогов:

* первая команда проверяет возможность отправлять запросы на контроллер домена; вторая — выводит список групп, находящихся в каталоге.

Настройка SQUID

Для скрипта запуска squid добавим следующее:

KRB5_KTNAME=/etc/squid/proxy.keytab
export KRB5_KTNAME

* в данном случае, мы задаем переменную KRB5_KTNAME, в которой указан путь до кейтаб файла.

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

auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth -d -s HTTP/proxy.domain.local@DOMAIN.LOCAL
auth_param negotiate children 20
auth_param negotiate keep_alive on

auth_param ntlm program /usr/bin/ntlm_auth —diagnostics —helper-protocol=squid-2.5-ntlmssp —domain=DOMAIN
auth_param ntlm children 10
auth_param ntlm keep_alive off

* где /usr/lib64/squid/negotiate_kerberos_auth — путь до библиотеки аутентификации по kerberos, ее путь может отличаться — это зависит от версии системы; HTTP/proxy.domain.local@DOMAIN.LOCAL — учетная запись в keytab.

Также настраиваем, чтобы squid требовал аутентификацию. Для этого в секции acl добавим:

acl auth proxy_auth REQUIRED

http_access allow localnet

http_access allow auth

* в нашем случае acl localnet использовалась для предоставления доступа.

Проверяем настройки конфигурационного файла:

И если ошибок нет:

squid -k reconfigure

Проверка

Для проверки на сервере открываем лог:

tail -f /var/log/squid/access.log | grep dmosk

* dmosk — учетная запись в AD, от которой будем проверять работу squid.

Теперь на клиентском компьютере заходим в систему под нашей учетной записью (в данном примере, dmosk) и грузим любой сайт.

На сервер в логах должны появиться записи, примерно, такого вида:

1526474100.078 240 192.168.1.16 TCP_TUNNEL/200 934 CONNECT syndication.twitter.com:443 dmosk HIER_DIRECT/134.144.40.72 —
1526474100.743 45 192.168.1.16 TCP_TUNNEL/200 559 CONNECT login.vk.com:443 dmosk HIER_DIRECT/187.244.139.145 —

Авторизация на основе групп AD

Ранее, мы предоставили доступ к сети Интернет любому пользователю Active Directory. Теперь ограничим доступ с помощью групп AD DS.

Для начала, создаем 2 группы пользователей, например:

1. squidusers. Пользователи squid, которым будет предоставлен доступ к сети Интернет с ограничениями.
2. squidsuperusers. Этим пользователям будет предоставлен неограниченный доступ.

Теперь на прокси-сервере открываем конфигурационный файл squid:

Добавляем после настройки аутентификации:

external_acl_type squid_users_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g squidusers@DOMAIN.LOCAL
external_acl_type squid_superusers_from_ad_krb ttl=300 negative_ttl=60 %LOGIN /usr/lib64/squid/ext_kerberos_ldap_group_acl -g squidsuperusers@DOMAIN.LOCAL
external_acl_type squid_users_from_ad_ntlm %LOGIN /usr/lib64/squid/ext_wbinfo_group_acl -d

• squid_users_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidusers в домене DOMAIN.LOCAL.
• squid_superusers_from_ad_krb — произвольное название acl, авторизованных пользователей в AD через kerberos, принадлежащих группе squidsuperusers в домене DOMAIN.LOCAL.
• squid_users_from_ad_ntlm — произвольное название acl, авторизованных пользователей в AD через NTLM.

#acl auth proxy_auth REQUIRED
acl squid_users_acl_krb external squid_users_from_ad_krb
acl squid_superusers_acl_krb external squid_superusers_from_ad_krb
acl squid_users_acl_ntlm external squid_users_from_ad_ntlm squidusers
acl squid_superusers_acl_ntlm external squid_superusers_from_ad_ntlm squidsuperusers

• squid_users_acl_krb — произвольное название acl для всех, кто входит в squid_users_from_ad_krb;
• squid_superusers_acl_krb — произвольное название acl для всех, кто входит в squid_superusers_from_ad_krb;
• squid_users_acl_ntlm — произвольное название acl для всех, кто входит в squid_users_from_ad_ntlm;
• squid_superusers_acl_ntlm — произвольное название acl для всех, кто входит в squid_superusers_from_ad_ntlm;

* предыдущую acl для общей аутентификации комментируем.

#http_access allow auth

http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm

http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm

* разрешаем доступ для созданных ранее acl; предыдущее разрешение для всех пользователей AD запрещаем. На данном этапе разницы между пользователями групп squidusers и squidsuperusers нет — позже мы настроим ограничение доступа к сайтам, где будем применять разные группы для предоставления различных прав.

Перечитываем конфигурацию прокси-сервера:

squid -k reconfigure

Ограничение доступа к сайтам

Мы рассмотрим простой пример блокировки двух сайтов. Доступ к ним будет ограничен в рабочее и ночное время для пользователей группы squidusers. Пользователи группы squidsuperusers будут иметь полный доступ ко всем сайтам.

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

В разделе с ACL добавим 2 строки:

acl BLOCKED url_regex -i «/etc/squid/denysite»
acl BLOCKED_ACCESS time 18:00-23:59

* в данном примере мы создаем acl BLOCKED для сайтов, доступ к которым будем блокировать; список сайтов будем хранить в файле /etc/squid/denysite. Второй acl BLOCKED_ACCESS будем использовать для предоставления доступа к заблокированным сайтам, но с промежуток с 18:00 до 23:59.

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

http_access allow squid_superusers_acl_krb
http_access allow squid_superusers_acl_ntlm

http_access allow BLOCKED BLOCKED_ACCESS
http_access deny BLOCKED

http_access allow squid_users_acl_krb
http_access allow squid_users_acl_ntlm

* как видим, мы добавили правила блокировки после пользователей группы squidsuperusers — таким образом, на последних они не будут распространяться. Данные правила разрешают заблокированные сайты в указанный ранее промежуток времени и блокируют доступ к сайтам, перечисленным в файле /etc/squid/denysite.

Создаем файл /etc/squid/denysite:

* в данном примере мы блокируем доступ к социальным сетям facebook и ВКонтакте.

Перечитываем конфигурацию squid:

squid -k reconfigure

Возможные ошибки

1. Password set failed! 0x00000020

Возникает при попытке создать keytab на контроллере домена.

Причина: учетная запись, которая используется в ключе /mapuser находится в одном из подразделений, названных с применением кириллицы.

Решение: перенесите учетную запись для связывания в подразделение, названное на латинице, например, CN=Users,dc=domain,dc=local.

Читайте также

Другие инструкции по SQUID, которые могут показаться интересными:

Источник

Настройка Kerberos-аутентификации с использованием смарт-карт

В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

Краткое введение

Kerberos – сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию – оба пользователя через сервер подтверждают личности друг друга.

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal. Такой зоопарк возник из-за ограничений США на экспорт криптографических средств защиты информации, на сегодня эта ситуация вокруг MIT Kerberos уже улеглась. В статье мы рассмотрим процесс настройки для MIT Kerberos V5.

Терминология Kerberos

• Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
• Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
• Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
• Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
• Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Файлы настроек Kerberos

На сервере:

• /etc/krb5kdc/kdc.conf — настройки KDC

На клиенте и сервере:

• /etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

Настройка рабочего окружения

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

Настройка сети

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Установка необходимых пакетов

На сервере нам потребуются:

• krb5-kdc – сервис KDC
• krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
• krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

На клиент надо поставить следующие пакеты:

• krb5-user – базовый набор утилит для работы клиентской аутентификации
• krb5-config – файлы настроек Kerberos
• krb5-pkinit
• libpam-krb5 – модуль PAM для использования Kerberos-аутентификации
• pcscd, opensc, libengine-pkcs11-openssl – пакеты, необходимые для работы с токенами

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

• Default realm: AKTIV-TEST.RU
• Имена серверов (admin server и KDC): aktiv-test.ru (он же прописан в /etc/hosts на клиенте)
• Пользователь: testuser@AKTIV-TEST.RU

Настройка Kerberos

Базовые настройки

Настройка аутентификации по открытому ключу

На сервере:

Создадим ключевую пару и сертификат нашего «УЦ». Здесь мы сгененируем ключ УЦ и создадим самоподписанный сертификат с помощью openssl. В реальном мире ключ естественно надо надежно защитить от попадания в чужие руки.
Создадим ключевую пару для KDC, заявку на сертификат и выпишем его сами себе.
Здесь нам потребуется специальный файл расширений OpenSSL (pkinit_extensions), в котором будут указаны дополнительные поля сертификатов, используемых в Kerberos. В частности, мы зададим:

• Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
• otherName – поле, задающее нашего принципала, для которого выписывается сертификат

После этого перенесем следующие файлы в /var/lib/krb5kdc/:

• kdc.pem
• kdckey.pem
• cacert.pem

На сервере отредактируем настройки Kerberos (файл /etc/krb5kdc/kdc.conf) для использования ключей и сертификатов сервера и УЦ:
Далее на сервере необходимо включить предварительную аутентификацию для нашего пользователя.

Дальнейшие действия будем выполнять на клиенте

Настройка PAM-аутентификации с использованием Kerberos

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду
и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в предыдущей статье.

Заключение

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения. Такое решение может применяться в корпоративном секторе, а аутентификация по смарт-картам будет приятным бонусом как для администраторов, так и для пользователей сети компании.

Источник