Настройка kerberos-аутентификации для linux

Enabling Kerberos Authentication in Internet Explorer

Let’s consider how to enable Kerberos authentication in Internet Explorer 11.

We remind that since January, 2016, the only officially supported Internet Explorer version is IE11.

Go to Internet Options -> Security -> Local intranet, and click Sites -> Advanced. Add the following entries to the zone:

You can add the sites to this zone using the Group Policy: Computer Configuration -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Site to Zone Assignment. Add an entry with the value 1 for each website. See the example in the article “How to disable Open File security warning on Windows for the files downloaded from the Internet”.

Then go to the Advanced tab and in the Security section, make sure that Enable Integrated Windows Authentication option is checked.

Important. Make sure that websites, for which Kerberos authentication is enabled, are present only in the Local intranet zone. A Kerberos token for the websites included into Trusted sites zone is not sent to the corresponding web server.

Проблема входа в систему

То, что происходит после того, как OAuth 2.0 установил способ доступа к сторонним API, заключается в том, что приложение также требуется регистрировать пользователей у себя. Используя наш пример: HireMe123 нужно, чтобы пользователь MyCalApp мог залогиниться, используя свою учетную запись MyCalApp, даже несмотря на то, что он не был зарегистрирован в HireMe123.

Но, как мы упоминали выше, OAuth 2.0 предназначен только для делегированного доступа. Это не протокол аутентификации. Но это не помешало людям попытаться использовать его и для аутентификации, и это представляет проблему.

Проблемы с использованием токенов доступа для аутентификации

Если HireMe123 предполагает успешный вызов API MyCalApp с токеном доступа, достаточным что бы пользователь считался аутентифицированным, у нас возникают проблемы, поскольку у нас нет способа проверить, был ли выдан токен доступа правильному пользователю.

Например:

Кто-то мог украсть токен доступа у другого пользователя
Маркер доступа мог быть получен от другого клиента (не HireMe123) и введен в HireMe123

Это называется запутанной проблемой делегирования. HireMe123 не знает, откуда взялся этот токен и кому он был выдан. Если мы помним: аутентификация — это проверка того, что пользователь — это тот, кем он себя заявляет. HireMe123 не может знать это из-за того, что он может использовать этот токен доступа для доступа к API.

Service principals and keytabs

First, ensure you have configured krb5.conf on all involved machines.

A kerberos principal has three components, formatted as `primary/instance@REALM`. For user principals, the primary is your username and the instance is omitted or is a role (eg. «admin»): `[email protected]` or `myuser/[email protected]`. For hosts, the primary is «host» and the instance is the server FQDN: `host/[email protected]`. For services, the primary is the service abbreviation and the instance is the FQDN: `nfs/[email protected]`.
The realm can often be omitted, the local computer’s default realm is usually assumed.

With remote kadmin

This is the easier method, but requires you to have configured .

Open kadmin as root (so we can write the keytab) on the client, authenticating with your admin principal:

client# kadmin -p myuser/admin

Authenticating as principal myuser/admin with password.
Password for myuser/[email protected]:
kadmin:

Add a principal for any services you will be using, eg. «host» for SSH authentication or «nfs» for NFS:

kadmin: addprinc -randkey host/kbclient.example.com

WARNING: no policy specified for host/[email protected]; defaulting to no policy
Principal "host/[email protected]" created.

Save each key to the local keytab:

kadmin: ktadd host/kbclient.example.com

Entry for principal host/kbclient.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

Without remote kadmin

Start kadmin on the Kerberos server, using either unix or kerberos authentication:

# kadmin.local

Authenticating as principal root/[email protected] with password.
kadmin.local:

Add a principal for any services you will be using, eg. «host» for SSH authentication or «nfs» for NFS:

kadmin.local: addprinc -randkey host/kbclient.example.com

WARNING: no policy specified for host/[email protected]; defaulting to no policy
Principal "host/[email protected]" created.

Save each key to a new keytab to be transferred to the client:

kadmin.local: ktadd -k kbclient.keytab host/kbclient.example.com

Entry for principal host/kbclient.example.com with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.
Entry for principal host/kbclient.example.com with kvno 2, encryption type aes128-cts-hmac-sha1-96 added to keytab FILE:/etc/krb5.keytab.

Finally, copy from the server to the client using SCP or similar, then put it in place with correct permissions:

# install -b -o root -g root -m 600 kbclient.keytab /etc/krb5.keytab

Finally, delete kbclient.keytab from the server and client.

Настройка LDAP аунтификации для входа в zabbix

За основу взята http://www.ekzorchik.ru/2017/05/configure-zabbix-authentication-through-active-directory/. Настройка на примере взаимодействия с MS Active directory

оф дока https://www.zabbix.com/documentation/3.4/manual/web_interface/frontend_sections/administration/authentication

Обращаю внимание, это только ОДИН из вариантов, такой чтобы не терять УЗ — Admin, есть вариант с правкой кода Login — когда у вас уже заведен пользователь с правами Zabbix Super Admin — оптимально, для тех кто делал эт много раз, для первых вариантов — пойдем по пути переименования админа

Для централизованного управления УЗ, необходимо настроить авторизацию zabbix через LDAP. Способ, в лучших традициях выделания гланд, через ивестное место. Приступим

Настройка почтовой поддержки

Отправляем используя STARTLS, в дальнейшем надо прикрутить TLS

Это мы настроили адрес отправки. Теперь нужно пользователю добавить адрес для получения. Для этого идем в Administration -> Users, выбираем пользователя Admin.

Идем в закладку Media и жмем add.

Указываем почтовый ящик получателя. Жмем Add, затем Update.

Дальше нужно активировать отправку уведомлений по событиям. Для этого идем в Configuration -> Actions и жмем на Disabled, чтобы она стала Enabled.

Все, отправку уведомлений мы настроили, осталось подождать срабатывания триггера, чтобы проверить. Сделаем это позже, когда подключим хост к мониторингу.

На машине с Debian

С помощью ktutil

Этот способ работает если SPN предварительно были созданы и привязаны.

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

apt-get install krb5-kadmin

Запустим ktutil и создадим keytab-файл:

ktutil
ktutil:  addent -password -p HTTP/[email protected] -k 6 -e RC4-HMAC
Password for HTTP/[email protected]: 
ktutil:  wkt squid.keytab
ktutil:  q

С помощью Samba

Для создания keytab-файла с помощью samba, необходима работающая kerberos-аутентификация. При использовании этого метода нет необходимости генерировать и привязывать SPN на контроллере домена. Приведите файл настроек /etc/samba/smb.conf к следующему виду:

realm = DOMG.TESTG
workgroup = DOMG
server string = Samba server on %h (v. %v)
security = ads
dedicated keytab file = /etc/krb5.keytab
kerberos method = dedicated keytab

Введите машину в домен:

net -v ads join DOMG.TESTG -UAdministrator
Using short domain name -- DOMG
Joined 'DOSERVER' to dns domain 'domg.testg'

Проверить ввод в домен можно командой:

net ads testjoin
Join is OK

После этого в домене будет создан аккаунт компьютера к которому можно будет привязать SPN.

Создадим keytab-файл для компьютера:

net ads keytab create -UAdministrator

Добавим в keytab-файл принципала сервиса «HTTP»:

net ads keytab add HTTP -U Administrator
Processing principals to add...

Далее можно поменять права на keytab и отредактировать его утилитой kutil.

С помощью Samba DC

При использовании этого метода kerberos ни при чём, а все действия выполняются на машине с домен-контроллером.

Создадим пользователя, с которым будем связывать создаваемые SPN:

samba-tool user create <someuser>
samba-tool user setexpiry <someuser> --noexpiry

Привяжем к нему SPN (возможно несколько раз для разных сервисов):

samba-tool spn add <service-name>/test.example.com <someuser>

Создадим keytab:

samba-tool domain exportkeytab /tmp/keytab --principal=<service-name>/test.example.com

Данную процедуру необходимо выполнить несколько раз для всех spn, которые требуется поместить в keytab.

Проверка:

klist -ke /tmp/keytab
  Keytab name: FILE:/etc/http.keytab
  KVNO Principal
  ---- --------------------------------------------------------------------------
     1 host/[email protected] (des-cbc-crc) 
     1 host/[email protected] (des-cbc-md5) 
     1 host/[email protected] (arcfour-hmac) 
     1 HTTP/[email protected] (des-cbc-crc) 
     1 HTTP/[email protected] (des-cbc-md5) 
     1 HTTP/[email protected] (arcfour-hmac)

С помощью FreeIPA Client

Для этого способа необходимо ввести машину в домен FreeIPA.

Для генерации keytab-файла используется команда:

ipa-getkeytab -s dc.ipa.server.ru -p HTTP/httpserver.ipa.server.ru -k /etc/http.keytab

Здесь:

— FreeIPA сервер
— SPN
/etc/http.keytab — местоположение создаваемого keytab-файла

Первичная настройка

Сервер

Установить пакеты и создать новый realm

$ sudo apt-get install krb5-kdc krb5-admin-server krb5-pkinit
# В диалогах указать:
# realm = AKTIV-TEST
# домен = aktiv-test.ru
$ sudo krb5_newrealm
# ввести пароль

/etc/krb5.conf

	.aktiv-test.ru = AKTIV-TEST
	aktiv-test.ru = AKTIV-TEST

Создать на сервере нового пользователя

$ sudo kadmin.local
# username = testuser
# password = test
kadmin.local:$ addprinc <username>
# ...
kadmin.local:$ quit

Клиент

Установим pkcs11 модуль

Установим необходимые пакеты и сконфигурируем kerberos

$ sudo apt-get install krb5-user libpam-krb5 libpam-ccreds auth-client-config krb5-pkinit opensc libengine-pkcs11-openssl
# В диалогах указать:
# realm = AKTIV-TEST
# домен = aktiv-test.ru
$ sudo dpkg-reconfigure krb5-config

/etc/krb5.conf

	...
	.aktiv-test.ru = AKTIV-TEST
	aktiv-test.ru = AKTIV-TEST

Kerberos

Данная вкладка предназначена для подключения к по протоколу сетевой аутентификации Kerberos.

Заполните все поля вкладки:
- «Имя компьютера» — задает ;
- «Имя домена» — задает имя домена, в котором ИКС будет как пользователь;
- «DNS-имя контроллера домена» — укажите соответствующее имя;
- «Keytab файл» — предназначено для загрузки .
Загрузите Keytab-файл по кнопке .
Нажмите «Сохранить».

Пример создания Keytab-файла

Имя компьютера — Test, имя домена — test.ru. Для создания Keytab-файла выполните следующие действия на контроллере домена:

Создайте пользователя Test с бессрочным паролем, имя не должно содержать кириллических символов.
Выполните от имени администратора в командной строке:
ktpass -princ HTTP/[email protected] -mapuser «Test» -pass «Aa123456» -crypto All -ptype KRB5_NT_PRINCIPAL -out C:\ics_01.keytab

где:
- -princ HTTP/[email protected] — имя принципала службы ();
- -mapuser «Test» — пользователь, созданный в контроллере домена;
- -pass «Aa123456» — пароль созданного пользователя;
- -out C:\ics_01.keytab — путь до создаваемого Keytab-файла с указанием его имени.

Для удобства команда создания Keytab-файла указана в веб-интерфейсе на вкладке «Kerberos». Она изменяется в соответствии с введенными значениями полей.

Внимание! При интеграции ИКС с LDAP-сервером FreeIPA команда для генерации keytab-файла, подходящего для настройки Kerberos, будет отличаться. Команда также выводится для удобства на вкладке «Kerberos» и изменяется в соответствии с введенными значениями полей

Пример создания Keytab-файла (FreeIPA)

Имя компьютера — Test, имя домена — test.ru, DNS-имя сервера FreeIPA — server.test.ru. Для создания Keytab-файла выполните следующие действия на сервере FreeIPA:

Добавьте узел test c IP-адресом ИКС.
Добавьте службу HTTP c указанием узла test.test.ru.
Выполните команду:
ipa-getkeytab -s server.test.ru -p HTTP/[email protected] -k /tmp/ics_01.keytab

где:
- -s server.test.ru — DNS-имя сервера FreeIPA;
- -p HTTP/[email protected] — имя принципала службы (SPN);
- -k /tmp/ics_01.keytab — путь до создаваемого Keytab-файла с указанием его имени.

В случае удачной настройки ИКС сообщит соответствующую информацию: «А-запись», «PTR-запись», «Попытка авторизации» должны иметь статус Ок».

Если попытка прошла неудачно, ИКС выдаст рекомендации по их устранению.

Внимание! При подключении по протоколу Kerberos имя системы будет изменено на «имя.домен». ИКС должен использовать контроллер домена как единственный , иначе необходимо добавить перенаправление DNS-зоны домена на одного или нескольких контроллеров домена

ИКС должен использовать контроллер домена как единственный , иначе необходимо добавить перенаправление DNS-зоны домена на одного или нескольких контроллеров домена.

Настроить авторизацию на прокси с использованием Kerberos

Укажите в браузере адрес ИКС как имя, под которым ИКС введен в домен (например, test.office1.example.ru). По IP данный тип авторизации работать не будет.
В настройках службы прокси укажите, что нужно использовать тип авторизации Kerberos.

Важно! Если пользователь не прошел Kerberos-авторизацию, ему будет предложено ввести логин и пароль для LDAP-авторизации. При этом если не используется LDAPS (с сертификатом), пароль при LDAP-авторизации будет передаваться в открытом виде

Если Kerberos не настроен, то авторизация в VPN, связанная с Kerberos, будет недоступна.

Настройка прозрачной (Single Sign On) аутентификации в Zabbix (Apache2, krb5-user)

Сначала в файле /etc/hostname укажите FQDN имя сервера, которое должно совпадать с DNS записью в вашем домене, в моём случае это zabbix.domain.local.

В файле /etc/hosts также пропишите FQDN вашего сервера на локальный IP и на IP вашего сервера:

Для корректной работы Kerberos аутентификации необходимо синхронизировать время с контроллером вашего домена. Ставим пакет ntpdate и направляем его на контроллер домена

apt-get install ntp ntpdatentpdate dc.domain.local

Теперь нам нужно сгенерировать keytab файл. Keytab — это файл который содержит SPN и зашифрованные ключи. Keytab используется для аутентификации на различных системах с использованием Kerberos без ввода пароля.

Сгенерировать keytab файл можно на контроллере домена:

Залогиньтесь на контроллер домена и запустите командную строку с правами администратора. Перейдите в директорию C:\
Введите: ktpass -princ HTTP/ -mapuser zabbix_admin -pass STRONGPASS -crypto ALL -ptype KRB5_NT_PRINCIPAL -out zabbix.keytab -setupn –setpass
Скопируйте файл C:\zabbix.keytab на ваш Zabbix сервер в директорию /etc/apache2/.

Установим необходимые пакеты для работы Kerberos и модуль для apache2:

apt install krb5-user libapache2-mod-auth-kerb

Сконфигурируем krb5-user. Правим конфигурационный файл /etc/krb5.cnf:

Подставьте свой домен, в некоторых местах домен написан в заглавном виде – соблюдайте это правило.

Проверяем работу Kerberos аутентификации в Linux:

kinit -kV -p HTTP/zabbix.domain.local –t /etc/apache2/zabbix.keytab

Вы можете столкнуться с ошибкой

В этом случае прежде всего попытайтесь авторизоваться из-под другого пользователя, например, вашей учетной записи^

Если аутентификация пройдет успешно, то значит дело в кейтаб файле. Убедитесь, что вы правильно сгенерировали его. Проверьте корректность команды для создания keytab файла.

Проверьте наличие SPN записи для вашего служебной учетной записи zabbix в AD. В командой строке контролера домена наберите:

Вы должны увидеть подобное сообщение, запись должна быть в формате HTTP/zabbix.domain.local, если записи нет, нужно её добавить.

setspn -a HTTP/zabbix.domain.local zabbix_admin

Также нужно проверить что у пользователя изменилось имя входа на HTTP/zabbix.domain.local.

Если не изменилось, то измените его вручную.

Теперь нужно изменить конфигурационной файл apache2 — /etc/apache2/sites-available/000-default.conf.

Под строчкой ServerName zabbix.domain.local добавьте

Часто встречается ошибка, которая связана с несовпадением KrbServiceName с тем, что прописан в keytab файле, поэтому на время тестирования можно поставить значение Any. После того как всё заработает, впишите валидное название сервиса. Свериться можно через команду klist -le /etc/apache2/zabbix.keytab .

# Настройка kerberos.properties

Создайте файл kerberos.properties в директории {RUNAWFE_JBOSS}/standalone/wfe.custom. Замените в нем имена на настоящие.

# задействовать аутентификацию используя RunaWFE API
api.auth.enabled=true
appName=com.sun.security.jgss.krb5.accept
moduleClassName=com.sun.security.auth.module.Krb5LoginModule
principal={SERVER_SPN}
storeKey=true
useKeyTab=true
keyTab={KEYTAB_PATH}
doNotPrompt=true
# режим отладки аутентификации
debug=true
# задействовать аутентификацию по протоколу HTTP (из веб-интерфейса)
http.auth.enabled=true
jcifs.http.enableNegotiate=true
# режим отладки аутентификации
sun.security.krb5.debug=true
jcifs.spnego.servicePrincipal={SERVER_SPN}
http.auth.preference=Kerberos

Как работает Kerberos?

Проверка подлинности Kerberos состоит из 4 этапов, в зависимости от того, какие компоненты взаимодействуют между собой:

Вход пользователя / клиента: на этом этапе происходит взаимодействие между пользователем и клиентом. Пользователь вводит в клиент свое имя пользователя и пароль. Затем клиент преобразует этот пароль в ключ шифрования, хранящийся локально. Если это завершится правильно, клиент может начать аутентификацию с помощью AS.
Аутентификация клиента / AS: на этом этапе клиент и сервер аутентификации подключаются для аутентификации имени пользователя и проверки того, что они являются частью системы. Затем AS проверяет, что имя пользователя уже задокументировано в системе. В этом случае Клиент и AS обмениваются зашифрованными проверочными сообщениями для проверки друг друга. В конце оба аутентифицируются, соединение устанавливается, и клиент может перейти к аутентификации с помощью службы.
Аутентификация клиента / службы: на этом этапе клиент и сервер должны аутентифицировать друг друга в соответствии с практикой взаимной аутентификации. Клиент и сервер обмениваются зашифрованными проверочными сообщениями, как на предыдущем этапе. Если все это проходит, клиент и служба аутентифицируются, и клиент получает разрешение запросить их службу.
Клиент / запрос службы: наконец, клиент может запросить именованную службу у сервера службы. Затем сервисный сервер проверяет, доступна ли запрошенная услуга. Если да, сервер службы предоставляет услугу клиенту. Поскольку клиент прошел аутентификацию на всех этапах этого процесса, он может продолжать использовать службу до истечения срока действия разрешений.

Пример процесса Kerberos

Каждый из этих этапов состоит из нескольких этапов, но в режиме реального времени процесс происходит очень быстро. Чтобы поместить то, что мы узнали выше, в контекст, давайте рассмотрим пример из реальной жизни.

В начале рабочего дня вы вводите пароль в свой клиент. Пароль аутентифицируется AS, а затем KDC предоставляет вам TGT. В этом билете есть набор ключей от dataScienceкоролевства.

Затем TGT кэшируется на вашем компьютере для дальнейшего использования. Этот доступ позволяет вам использовать любые услуги в dataScienceобласти, например, доступ к покупательскому поведению клиентов.

Затем вы можете получить доступ к этой службе в любое время без необходимости каждый раз аутентифицировать свои разрешения. Однако, если вы попытаетесь получить доступ к любой из служб из financesобласти, вам будет отказано, потому что ваш TGT не имеет ключей к этой области.

В конце рабочего дня срок действия вашего TGT истекает, и вы не сможете снова получить доступ к этим службам, пока не получите новый билет при входе в систему на следующий день.

Configuring Delegated Security for Mozilla Firefox

To configure Firefox to use Windows Integrated Authentication:

1. Open Firefox.

2. In the address bar type about:config

3. You will receive a security warning. To continue, click I’ll be careful, I promise.

4. You will see a list of preferences listed. Find the settings below by browsing through the list or searching for them in the search box. Once you have located each setting, update the value to the following:

Setting	Value
network.automatic-ntlm-auth.trusted-uris	MyIISServer.domain.com
network.automatic-ntlm-auth.allow-proxies	True
network.negotiate-auth.allow-proxies	True

** MyIISServer.domain.com should be the fully qualified name of your IIS server that you are setting up the Windows Integrated Authentication to.

Negotiate authentication is not supported in versions of Firefox prior to 2006.

Сценарий 2. Настройка ограниченного делегирования в учетной записи NetworkService

В этом разделе описывается, как реализовать ограниченное делегирования только для S4U2Proxy или Kerberos при использовании учетной записи NetworkService для прокси-страниц веб-регистрации.

Необязательный шаг: Настройка имени для использования для подключений

Вы можете назначить имя роли веб-регистрации, которую клиенты могут использовать для подключения. Эта конфигурация означает, что входящие запросы не должны знать имя компьютера переднего сервера веб-регистрации или другие сведения о маршрутизации, такие как каноническое имя DNS (CNAME).

Например, предположим, что имя компьютера сервера веб-регистрации — WEBENROLLMAC (в домене Contoso). Вместо входящих подключений необходимо использовать имя ContosoWebEnroll. В этом случае URL-адрес подключения будет следующим:

Это не будет следующим образом:

Чтобы использовать такую конфигурацию, выполните следующие действия:

В файле зоны DNS для домена создайте запись псевдонима или запись имени хозяина, которая сопоповедет новое имя подключения к IP-адресу роли веб-регистрации. Используйте средство Ping для проверки конфигурации маршрутов.

В примере, который был ранее рассмотрен, в файле зоны имеется запись псевдонима, которая сопочает ContosoWebEnroll с IP-адресом роли веб-регистрации.
Настройте новое имя в качестве SPN для переднего сервера веб-регистрации. Для этого выполните следующие действия:
1. В Active Directory пользователи и компьютеры подключаются к домену, а затем выберите Компьютеры.
2. Щелкните правой кнопкой мыши учетную запись компьютера переднего сервера веб-регистрации, а затем выберите свойства.
  
  Примечание
  
  Эта учетная запись также называется «учетная запись машины».
3. Выберите службу Редактор > атрибутовPrincipalName.
4. Введите HTTP/ <ConnectionName> <DomainName.com> , выберите Добавить, а затем выберите ОК.
  
  Примечание
  
  В этой строке это новое имя, которое вы определили, и <ConnectionName> <DomainName> это имя домена.
  В примере строка HTTP/ContosoWebEnroll.contoso.com.

1. Настройка делегирования

Если вы еще не подключены к домену, сделайте это сейчас в Active Directory Пользователи и компьютеры, а затем выберите компьютеры.
Щелкните правой кнопкой мыши учетную запись компьютера переднего сервера веб-регистрации, а затем выберите свойства.

Примечание

Эта учетная запись также называется «учетная запись машины».
Выберите Делегирования, а затем выберите Доверяйте этому компьютеру только для делегирования указанных служб.

Примечание

Если вы можете гарантировать, что клиенты всегда будут использовать проверку подлинности Kerberos при подключении к этому серверу, выберите только Использование Kerberos.
Если некоторые клиенты будут использовать другие методы проверки подлинности, такие как NTLM или проверка подлинности на основе форм, выберите Используйте любой протокол проверки подлинности.

2. Создание и привязка сертификата SSL для веб-регистрации

Чтобы включить страницы веб-регистрации, создайте сертификат домена для веб-сайта и привязывайте его к первому сайту по умолчанию. Для этого выполните следующие действия:

Откройте диспетчер IIS.
В дереве консоли выберите и выберите <HostName_> _Server Certificates в области действий.

Примечание

<HostName> это имя переднего веб-сервера.
В меню Действия выберите Создание сертификата домена.
После создания сертификата выберите веб-сайт по умолчанию и выберите привязки.
Убедитесь, что порт установлен до 443. Затем в сертификате SSL выберите сертификат, созданный на шаге 3. Выберите ОК, чтобы привязать сертификат к порту 443.

Настройка LDAP аутентификации Zabbix в Active Directory

Привязка доменного пользователя к Zabbix

Сначала нужно привязать пользователей домена к Zabbix. Для этого достаточно создать в заббиксе пользователя с таким же логином, как и в домене. Например, если ваш логин (атрибут sAMAccountName) user_5, то и пользователь в Zabbix должен иметь такое же имя входа.

Проделайте это с каждым пользователем, который будет пользоваться Zabbix.

Создание Active Directory учетки для связи Zabbix с доменом

Теперь нужно создать в Active Directory отдельного пользователя, через которого будет выполняться привязка Zabbix к домену. На практике, можно использовать любой доменный аккаунт, но лечше создать выделенный служебный аккаунт. В моём случае это будет zabbix_admin. Для создания пользователя в AD я воспользуюсь PowerShell командой New-ADUser:

New-ADUser -Name «zabbix_admin» -GivenName «zabbix_admin» -Surname «zabbix_admin» -SamAccountName «zabbix_admin» -AccountPassword (Read-Host -AsSecureString «Password:») -DisplayName «zabbix_admin» -Enabled $true

Выполните команду в консоли PowerShell и задайте пароль пользователя. Ваш новый пользователь будет находиться в контейнере Users в корне домена.

Настройка LDAP аутентификации в веб интерфейсе Zabbix

Теперь перенастроим Zabbix на LDAP аутентификацию. В веб-интерфейсе перейдите в Administration -> Authentication, вкладка LDAP settings. Включите опцию Enable LDAP authentication и заполните следующие поля.

Перед завершением настройки, обязательно проверьте валидность ваших настроек, выполнив тестовый логин (кнопка Test). Укажите пользователя (мы завели его в zabbix ранее) и его пароль из AD.

Если тест пройден успешно, то сохраняйте настройки и переключите тип авторизации в Zabbix с Internal на LDAP.

На этом настройка LDAP аутентификации завершена.

Совет. В случае недоступности вашего LDAP сервера, вы не сможете попасть в Zabbix. Чтобы переключиться обратно на внутреннею аутентификацию, зайдите в mysql и выполните команду:

# krb5.ini

Файл не является обязательным, но может влиять на поведение процесса аутентификации.

На сервере и клиентских машинах Windows он может быть расположен в ${windir}/krb5.ini.

Пример файла krb5.ini

 .test.com = TEST.COM
 test.com = TEST.COM

 default_realm = TEST.COM
 kdc_timesync = 1
 ccache_type = 4
 ticket_lifetime = 600
 default_tkt_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
 default_tgs_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1
 permitted_enctypes = des-cbc-md5 des-cbc-crc des3-cbc-sha1

 kdc = CONSOLE

 TEST.COM = {
  kdc = 192.168.0.1
  kdc = 192.168.1.1
  default_domain = test.com
 }

 autologin = true
 forward = true
 forwardable = true
 encrypt = true

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

Данная инструкция сделана в окружении Windows Server2008R2 (контроллер домена), Windows Server2012R2 (RunaWFE Server), Windows7 (RunaWFE client).

В данном разделе регистр может иметь значение, хотя опытным путём было выяснено что логин пользователя, название компьютера сервера и SPN не являются регистрозависимыми.

Настройка squid на проверку подлинности через Kerberos в домене Windows 2008 R2.

Для того чтобы сквид знал, какой кейтаб использовать, ему нужно указать, где он лежит. Для этого нужно создать и заполнить файл /etc/default/squid3 следующим содержимым (задать переменную, хранящую путь к кейтаб файлу, которую читает сквид):

squid ~ # cat /etc/default/squid3
KRB5_KTNAME=/etc/squid3/squid.keytab
export KRB5_KTNAME

Так же, необходимо в squid.conf настроить схему аутентификации, для этого нужно добавить следующие строки:

# указание, какой хелпер использовать с каким SPN
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth -s HTTP/
# сколько параллельных потоков запускать для обслуживания аутентификации клиентов
auth_param negotiate children 10
# указывает поддерживать связь, а не обрывать, когда браузер опрашивает схемы аутентификации
auth_param negotiate keep_alive on

В некоторых конфигурациях в «сети» приводятся примеры без указания параметра -s и SPN, но у меня такая конфигурация не заработала. Так же, не забываем о наличии строк, разрешающим доступ для авторизованных пользователей:

acl lan proxy_auth REQUIRED
http_access allow lan

Примечание: вместо SPN можно использовать значение GSS_C_NO_NAME, в данном случае, squid будет использовать любой (какой? в какой последовательности?) SPN из keytab файла. Строка будет выглядеть так: <…>ate program /usr/lib/squid3/squid_kerb_auth -s GSS_C_NO_NAME(спасибо за дополнение комментатору selivan)

На этом можно считать настойку сквида законченной (не забудте сделать рестарт сквида). Если необходимо пускать не в всех пользователей в интернет, а только избранных, то в acl необходимо указать имя пользователя в том формате, в котором squid распознает пользователя. Этот формат можно посмотреть в логе access.log. Например для нашего случая имя пользователя имеет следующий вид:

1330858897.314 86 10.0.1.48 TCP_MISS/200 491 GET http://www.google-analytics.com/__utm.gif?  DIRECT/173.194.69.113 image/gif
1330858898.296 94 10.0.1.48 TCP_MISS/204 192 GET http://support.google.com/accounts/bin/stats?  DIRECT/173.194.69.100 -

squid ~ # cat /etc/squid3/usersallow


...

squid ~ # grep allow /etc/squid3/squid.conf
acl allowinet proxy_auth "/etc/squid3/usersallow"
http_access allow allowinet

Кроме данного способа, есть возможность предоставить доступ пользователей к интернету на основе членства в доменных группах. Но для данной задачи используется отдельный хелпер и список доступа в формате external_acl и хелпер /usr/lib/squid3/squid_ldap_group. В сети можно найти много примеров. Конфигурацию на основе доменных групп я постараюсь рассмотреть в следующих статьях.