Squid, Kerberos и LDAP
Материал из Xgu.ru
- Автор: Сергей Бондаренко
Содержание |
[править] Идентификация пользователей
Прокси-сервер Squid для предоставления доступа клиентов к ресурсам сети может осуществлять аутентификацию и авторизацию пользователей. Возможно построение взаимодействия с серверами Microsoft Active Directory путем аутентификации клиентов - членов домена, используя протокол Kerberos, и последующей авторизации членов групп домена.
[править] Принцип работы протокола Kerberos (схематически)
Участники схемы:
- Client (Пользователь) – пользователь, участник домена, запрашивающий доступ к ресурсам;
- AS (Authentication Server) - сервер аутентификации (например, Microsoft Active Directory);
- TGS (Ticket Granting Server) – сервер предоставления билетов (например, Microsoft Active Directory);
- SS (Service Server) – сервер предоставляющий доступ к ресурсам (например, прокси-сервер Squid);
- TGT (Ticket Granting Ticket) – билет для получения билета.
Определение протокола Kerberos а также более подробные пояснения его принципов работы можно почерпнуть из следующих источников:
[править] Конфигурация пользователя для работы с Kerberos
Конфигурации клиентской машины
Пользователь должен быть членом домена и находится в базе данных домен контролера Microsoft Active Directory. Клиентская машина должна находиться в базе домен контроллера.
ОС пользователей: Windows 2000 или новее, Mac OS X и Linux. Поддерживаемые веб-обозреватели (browser): Internet Explorer 7.0 или новее (версия IE < версии 7.0 не работает с Kerberos), Mozilla Firefox версии 3,6 или новее и Safari (тесты проведены с версией 5.0.3).
В настройках прокси веб-обозревателя установить полное доменное имя (FQDN) прокси-сервера (например, proxy_squid@domain.loc) и номер порта (например, 3180).
Конфигурация сервера Microsoft Active Directory
- Необходимо настроить сервер Active Directory.
- Настроить DNS сервер. Обязательно внести записи доменного имени прокси-сервера proxy_squid.domain.loc.
Необходимо создать пользователя в домене: proxy_squid. Пароль пользователя должен не иметь срока годности (password never expires). Для оптимального уровня безопасности, пароль должен состоять из восьми символов - это минимум (буквы, цифры, а также специальные символы). Для аутентификации прокси-сервера на контроллере домена и последующей идентификации пользователей прокси-сервером Squid, необходимо создать файл keytab. Keytab – это файл который содержит Kerberos Principal (хост, пользователь и домен) и ключи шифрования (определяются из пароля Kerberos). Это файл применяется для аутентификации в инфраструктуре Kerberos (при этом не нужно вручную вводить логин и пароль). Squid будет использовать keytab для аутентификации пользователей через протокол Kerberos.
После создания, файл keytab необходимо скопировать на прокси-сервер (например, в каталог /etc/).
Создание файла keytab в командной строке домен контролера Microsoft Active Directory:
ktpass -princ HTTP/proxy_squid.domain.loc@DOMAIN.LOC -mapuser nbtname\proxy_squid -pass "password*" -ptype KRB5_NT_SRV_HST -out HTTP7.keytab
- nbtname - netbios имя домена
- password – указать пароль.
|
|
realm для Kerberos (то, что пишется после @) обязательно писать ЗАГЛАВНЫМИ буквами! |
Конфигурация сетевого доступа к прокси-серверу
- Разрешить доступ прокси-серверов в сеть Интернет и обратно по протоколам: HTTP, HTTPS, SSH, FTP, DNS;
- Разрешить доступ прокси-серверов в локальную сеть (ЛВС) и обратно используя порты:
- Kerberos, TCP/UDP: 88, 464, 749, 750; TCP: 4444;
- Ldap, TCP/UDP: 389;
- Squid, TCP: 3180;
- SSH, TCP: 22, 10010, 10011;
- Msft-gc, TCP: 3268;
- Klogin, TCP: 543;
- Kshell, TCP: 544;
- Tell, TCP: 754;
- Eklogin, minipay, TCP: 2105;
- DNS, TCP/UDP: 53;
- HTTPS, TCP: 443;
- HTTP, TCP: 80;
- NTP, UDP: 123;
- ICMP.
[править] Конфигурация прокси-сервера Squid на базе ОС Linux
Пример для ОС CentOS
Прокси-серверу необходимо присвоить имя (hostname): proxy_squid.domain.loc.
Необходимо проверить доступность DNS сервера с помощью программ dig и nslookup. Если DNS сервер не настроен, настроить DNS. Имя прокси-сервера, должно быть занесено в базу DNS сервера.
Необходимо проверить синхронизацию времени на прокси-сервере, домен контролере и клиенте. Для правильной работы протокола Kerberos, разница во времени должна быть не больше 5 минут. Синхронизировать прокси-сервер с NTP сервером можно с помощью ntpdate.
Установка с FTP репозитория пакетов для Kerberos аутентификации, пакета Squid 3.0 и библиотеки SASL (Simple Authentication and Security Layer):
yum install cyrus-sasl-gssapi krb5-workstation krb5-devel squid3
Изменение прав доступа для keytab файла (это файла, который ранее был сформирован на домен контролере с помощью команды ktpass).
chown squid:squid /etc/HTTP7.keytab chmod u+rwx,g+rx /etc/HTTP7.keytab
Проверка правильности созданного файла keytab:
kinit –V –k –t /etc/HTTP7.keytab HTTP/proxy_squid.domain.loc@DOMAIN.LOC
Если файл создан верно, выполнится аутентификация в домене: Authenticated to Kerberos v5.
Посмотреть полученный билет Kerberos можно с помощью команды klist.
Изменение конфигурации аутентификации Kerberos.
В файл /etc/krb5.conf необходимо внести следующие изменения:
[logging]
default = FILE:/var/log/kerberos/krb5libs.log
kdc = FILE:/var/log/kerberos/krb5kdc.log
admin_server = FILE:/var/log/kerberos/kadmind.log
[libdefaults]
default_realm = DOMAIN.LOC
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = true
proxiable = true
default_tgs_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
default_tkt_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
permitted_enctypes = rc4-hmac des-cbc-crc des-cbc-md5
[realms]
DOMAIN.LOC = {
#Перечень домен контроллеров
kdc = 192.168.1.5
kdc = 192.168.1.6
kdc = 192.168.1.7
admin_server = 192.168.1.5 default_domain = domain.loc
}
[domain_realm]
.domain.loc = DOMAIN.LOC
domain.loc = DOMAIN.LOC
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
[login]
krb4_convert = true
krb4_get_tickets = false
Для автоматической аутентификации через Squid, необходимо внести следующие изменения в исполняемый файл /etc/init.d/squid
KRB5_KTNAME=/etc/HTTP7.keytab export KRB5_KTNAME
Если необходимо использовать для работы прокси-сервера Squid не стандартный порт (например, 3180), открыть этот порт в SELinux.
semanage port -a -t http_cache_port_t -p tcp 3180 service squid start
[править] Аутентификация пользователей Active Directory
Настройка аутентификации в конфигурационном файле /etc/squid/squid.conf. Для аутентификации используется встроенная в Squid программа squid_kerb_auth.
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -d -s HTTP/proxy_squid.domain.loc@DOMAIN.LOC auth_param negotiate children 20 auth_param negotiate keep_alive on
[править] Авторизация пользователей Active Directory
Авторизация пользователей через Kerberos
Правим squid.conf
external_acl_type (тут задаем произвольное имя для squid) Internet_User ttl=300 negative_ttl=60 %LOGIN
/usr/libexec/squid/ext_kerberos_ldap_group_acl -a -g (а тут указываем имя группы из AD) Group_Internet_User -D DOMAIN.LOCAL
И так для всех необходимых групп. Всё, никаких паролей и страшных строчек LDAP авторизации.
Авторизация пользователей через LDAP
Необходимо авторизовать аутентифицированного пользователя с помощью squid_ldap_group.
Проверка авторизации пользователя в командной строке:
/usr/lib/squid/squid_ldap_group -R -b "dc=domain,dc=loc" -f "(&(objectclass=user)(sAMAccountName=%v)(memberof=cn=%a,OU=ProxyServer,OU=Services,OU=KYIV,DC=domain,DC=loc))" -D "proxy_squid@domain.loc" -W "/etc/squid/pass*" -K -d 192.168.1.5 192.168.1.6 192.168.1.7
Опция –W указывает на путь к файлу, который содержит пароль. Пользователем файла должен быть squid. Пароль должен совпадать с паролем в Kerberos keytab файле, сформированном ранее при помощи ktpass.
Если при вводе данных в формате пользователь группа получаем вывод OK, значит - авторизация работает. Если авторизация не работает, необходимо проверить путь хранения группы на контроллере домена (для этого можно использовать команду ldapsearch).
Если проверка работает, добавить конфигурацию для squid_ldap_group в /etc/squid/squid.conf:
Параметр %LOGIN в описании внешней группы указывает на то, перед проверкой на вхождение в эту группу, пользователя необходимо аутентифицировать
external_acl_type ldap_check ttl=1200 %LOGIN /usr/lib/squid/squid_ldap_group -R -b "dc=domain,dc=loc" -f "(&(objectclass=user)(sAMAccountName=%v)(memberof=cn=%a,OU=ProxyServer,OU=Services,OU=KYIV,DC=domain,DC=loc))" -D "proxy_squid@domain.loc" -W "/etc/squid/pass*" -K -d 192.168.1.5 192.168.1.6 192.168.1.7
[править] Определение правил доступа для пользователей
Проверка через Kerberos
acl Internet_User external Internet_User http_access allow Internet_User
Проверка через LDAP
Группе GG-KV-GOUP0 и GG-KV-GROUP1 предоставлен доступ в Интернет через Squid. Группа GG-KV-GROUP0 не получает доступа к файлам в Интернете, тип которых указан в файле /etc/squid/blocked (для определения типов файлов можно использовать регулярные выражения). Группа GG-KV-GROUP0 получает доступ ко всем файлам тип которых не указан в файле /etc/squid/blocked. Группа GG-KV-GROUP1 получает полный доступ ко всем файлам.
acl inet_access0 external ldap_check GG-KV-GROUP0 acl inet_access1 external ldap_check GG-KV-GROUP1 acl block_this_for_ggkvgroup0 url_regex -i "/etc/squid/blocked" http_access deny inet_access0 block_this_for_ggkvgroup0 http_access allow inet_access0 http_access allow inet_access1 ...
[править] Определение политик QoS (delay pools)
Определить ACL
acl ad128 external ldap_check GG-KV-GROUP0 acl ad256 external ldap_check GG-KV-GROUP1 ...
Объявить delay pools
delay_pools 3 delay_class 1 1 delay_class 2 1 ...
Определить принадлежность пользователей к delay pools
delay_access 1 allow ad128 delay_access 1 deny all delay_access 2 allow ad256 delay_access 2 deny all ...
Ограничить пропускную способность
delay_parameters 1 16000/16000 #128Kb на всех delay_parameters 2 32000/32000 #256Kb на всех
[править] Материалы по прокси-серверу Squid на Xgu.ru
- Squid
- Squid и LDAP
- Squid, Kerberos и LDAP
