Как настроить openvpn сервер и включить аутентификацию через ldap (active directory)

Введение

Мы хотим добиться того, чтобы наши пользователи сохранялись в LDAP, аутентифицировались через LDAP (direct или pam) и чтобы вы имели некоторый инструмент для управления этими всем понятным для человека способом.

Таким образом, мы можем использовать все программное обеспечение, поддерживающее LDAP, или возвратимся к модулю LDAP PAM, который будет действовать как шлюз PAM-> LDAP.

Более подробную информацию о идее LDAP можно найти в Википедии: LDAP wikipedia

Настройка OpenLDAP

OpenLDAP состоит из slapd и slurpd-демона.

Этот способ охватывает один сервер LDAP без репликации, поэтому мы сосредоточимся только на slapd.

Я также предполагаю, что вы установили и инициализировали установку OpenLDAP (в зависимости от системы / распространения).

Если да, перейдем к части конфигурации.

В моей системе (Gentoo) конфигурация OpenLDAP хранится в /etc/openldap, нас интересует файл /etc/openldap/slapd.conf.

Но сначала мы должны сгенерировать пароль для администратора LDAP, чтобы поместить его в файл конфигурации:

Конфигурация выглядит так:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
allow bind_v2
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args
modulepath      /usr/lib/openldap/openldap
access to attrs=userPassword
        by dn="uid=root,ou=People,dc=domain,dc=com" write
        by dn="cn=Manager,dc=domain,dc=com" write
        by anonymous auth
        by self write
        by * none

access to dn.base="" by * read
access to *
         by dn="cn=Manager,dc=domain,dc=com" write
         by * read


database        bdb
suffix          "dc=domain,dc=com"
rootdn          "cn=Manager,dc=domain,dc=com"
rootpw          {MD5}Tk1sMytv5ipjr+Vhcf03JQ==

directory       /var/lib/openldap-data
index   objectClass     eq

Не забудьте изменить суффикс и пути.

Это варианты с некоторыми базовыми ACL, необходимыми для изменения паролей пользователем.

Если вам нужна дополнительная функциональность, прочитайте руководство по OpenLDAP.

Теперь, когда у нас есть надлежащая конфигурация для slapd, мы можем запустить демон:

Пожалуйста, не забудьте сделать что-то подобное в файле конфигурации, отвечающем за аргументы, переданные slapd (путь должен указывать на slapd.sock):

Теперь мы можем проверить, работает ли openldap и работает ли он правильно.

У нас еще нет данных в каталоге, но мы можем попытаться связать их как cn = Manager, dc = domain, dc = com.

Когда вас попросят ввести пароль, вы должны использовать тот, который вы создали (конечно, его текстовая версия :):

Что такое LDAP в Active Directory (Введение)

Т.к. LDAP пока для меня — это маленькая тайна. Расскажу, что знаю… Итак, LDAP — это некий каталог (дословно — lightweight directory access protocol, в переводе — облегчённый протокол доступа к каталогам), который хранит в себе различную информацию в древовидной форме и имеет структуру, на нашем примере (на примере домена AD.LOCAL):

Давайте разберем что к чему… В голове структуры — имя домена (AD.LOCAL), «в подчинении» у домена — отделы (т.н. организационные единицы), у каждого отдела могут быть в подчинении другие отделы. Кроме того, в любой отдел (в том числе и в корневой контейнер — домен) могут входить некие элементы — группы, пользователи, принтеры и др., которые «в себе» могут хранить некоторые настройки — атрибуты объекта (например, у пользователя — пароль, имя, адрес почты и др.).

У каждой записи в LDAP, будь то объект или контейнер с объектами внутри имеется уникальное для всего каталога LDAP имя (т.н. англ. Distinguished Name (DN) — Отличительное имя). Это даже не имя, а путь, характеризующий полный путь к этом этой записи во всей иерархии. Уникальный путь может выглядеть (на примере группы squid), следующим образом: «cn=squid, ou=groups, ou=UNIXs, dc=ad, dc=local». Уникальное имя состоит из одного или нескольких относительных отличительных имен (RDN — англ. Relative Distinguished Name), разделённых запятой. Относительное уникальное имя имеет вид ИмяАтрибута=значение (например cn=squid ). На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами (при этом, в Active Directory имеются некоторые дополнительные ограничения, например, не может быть пользователя с одинаковым именем во всем дереве).

Давайте разберем приведенный путь. Данный путь стОит читать с конца. Он начинается с описания домена, в котором расположен каталог и обозначается как dc=ad, dc=local, здесь — имя dc (оно же Domain Component – компонент доменного имени) задает имя домена, то есть если бы у нас был домен, например subdomain.ad.local, то данный кусок отличительного имени выглядел бы как dc=subdomain, dc=ad, dc=local. Далее описывается ~~структура~~ иерархия контейнеров отделов (они же OU, они же Organization Unit — организационная единица или подразделение), которые представляет собой ou=groups, ou=UNIXs. Это стоит читать так же с конца, то есть в текущем домене есть некий контейнер UNIXs, в котором есть подконтейнер groups. Если бы необходимый нам объект находился в отделе, например, Склады, то текущий кусок DN (Distinguished Name) выглядел бы следующим образом: ou=Склады, ou=groups. Далее мы видим в DN описание конкретной записи (в данном случае — запись — это группа squid). Кусок, DN пути, описывающий группу представляет собой строку cn=squid, где CN — Common Name — общее (относительное) имя (Пользователь, контакт, группа или другой объект, который как правило не имеет дочерних объектов).

Думаю, что общую структуру объяснил понятно. Этого понимания, думаю, будет достаточно для реализации Kerberos LDAP авторизации на основе группы Active Directory.

Установка Spring Security

Для настройки Spring Security, вам для начала нужно добавить некоторые
дополнительные зависимости в вашу сборку.

Для сборки на основе Gradle:

Для сборки на основе Maven:

Эти зависимости добавляют Spring Security и ApacheDS, LDAP сервер с открытым
исходным кодом. С этого момента вы можете использовать Java для настройки
вашей политики безопасности.

подключает необходимые бины для
использования Spring Security.

Вам также нужен LDAP сервер. Spring Security LDAP модуль подключает
встроенный сервер, написанный на чистой Java, которая используется
в этом уроке. Метод настроен так,
что имя пользователя из формы входа помещается в ,
таким образом осуществляется поиск
на LDAP сервере.

Расширенная конфигурация

Здесь в основном объясняется так называемая расширенная конфигурация.Конфигурация, относящаяся к средней группе, для которой требуется определенная концепция групп LDAP. Чтобы облегчить понимание, мы будем использовать реальные примеры, чтобы проиллюстрировать

Если у нас есть три группы overmind, kerrigan и admin, конфигурация будет следующей:

Нам необходимо реализовать интегрированную LDAP-аутентификацию Django и не разрешать пользователям, принадлежащим к группе kerrigan, входить в систему. Если пользователь принадлежит к группе администраторов, вам необходимо установить его как администратора при входе в Django. Следующая конфигурация объяснит, как выполнить это требование.

Конфигурация группы в django-auth-ldap:

Подробное объяснение вышеуказанной конфигурации выглядит следующим образом:

AUTH_LDAP_GROUP_SEARCH： Искать информацию по определенному номеру, иПараметры аналогичны, где ou обычно относится к группе, напримерКаталог группы

AUTH_LDAP_GROUP_TYPE： Тип возвращаемой группы, значение первого атрибута DN группы, например DN группы, Тогда вот

AUTH_LDAP_REQUIRE_GROUP： Установите, каким членам группы разрешено входить в систему. Если мы разрешаем входить в систему только членам группы сверхразума, то это можно установить здесь

AUTH_LDAP_DENY_GROUP： Установите, каким членам группы запрещено входить в систему, если мы не разрешаем членам группы kerrigan входить в систему, вы можете установить это здесь

Когда мы устанавливаем для пользователя принадлежность как к группе сверхразума, так и к группе керриган одновременно, то есть пользователю разрешено входить в систему и настроен отказ от входа, тогда пользователь не может войти в систему на основании отказа войти в систему.

AUTH_LDAP_USER_FLAGS_BY_GROUP： Установите дополнительные атрибуты пользователей Django в соответствии с группой LDAP. Например, мы хотим, чтобы группа администраторов в LDAP имела полномочия суперадминистратора в Django. Помимо ручных настроек в Django, это также можно настроить непосредственно в настройках.

Он будет автоматически предоставлен пользователю, когда пользователь группы администратора войдет в систему.Для свойства установлено значение True

Пока у нас есть полное представление о django-auth-ldap, и мы можем легко сделать это при реальной интеграции проекта. Если у вас есть какие-либо вопросы, вы можете обратиться к моему коду на github.

Using Active Directory

An Active Directory installation may support multiple domains at the
same time. To distinguish users between domains, an identifier called
a User Principle Name (UPN) can be added to a user’s entry in the
directory. This UPN usually takes the form of the user’s account
name, followed by the domain components of the particular domain,
for example somebody@nz.example.com.

You may wish to configure the
module to authenticate users present in any of the domains making up
the Active Directory forest. In this way both
somebody@nz.example.com and someone@au.example.com
can be authenticated using the same query at the same time.

To make this practical, Active Directory supports the concept of
a Global Catalog. This Global Catalog is a read only copy of selected
attributes of all the Active Directory servers within the Active
Directory forest. Querying the Global Catalog allows all the domains
to be queried in a single query, without the query spanning servers
over potentially slow links.

If enabled, the Global Catalog is an independent directory server
that runs on port 3268 (3269 for SSL). To search for a user, do a
subtree search for the attribute userPrincipalName, with
an empty search root, like so:

AuthLDAPBindDN apache@example.com
AuthLDAPBindPassword password
AuthLDAPURL ldap://10.0.0.1:3268/?userPrincipalName?sub

Права, связанные с группами

Основные права

только чтение — права только на чтение заявки в данной группе/очереди
переместить — права на перемещение заявок в эту группу/очередь
создание — права на создание заявок в этой группе/очереди
заметка — права на добавление заметок в заявки в этой группе/очереди
владелец — права на смену владельца заявок в этой группе/очереди
приоритет — права на смену приоритета заявок в этой группе/очереди
чтение/запись — полные права на чтение и запись для заявок в данной группе/очереди

Дополнительные права

отчеты — предоставляет доступ к странице отчетов
перенаправить — право перенаправить/bounce почтовое сообщение (ссылка перенаправить/bounce в ticketZoom)
создать — право составления ответа на заявку
клиент — право изменить клиента для этой заявки
переслать — право пересылать сообщения (с помощью кнопки Переслать)
в ожидании — право перевести заявку в ожидание
телефон — право добавить содержание звонка клиента к заявке в виде сообщения/заметки
ответственный — Право изменить ответственного за заявку

каждый клиент может быть включен в одну или несколько групп, изначально все клиенты входят в группу users
каждая очередь заявок связывается с какой-либо одной из групп
через веб-интерфейс клиент может делать заявки в тех очередях, к которым имеют доступ группы, в которые он включен
при отправке клиентом заявки по электронной почте существует возможность на основании анализа атрибутов письма (например, адреса отправителя или заголовка письма) изменять характеристики заявки, в том числе и очередь, в которую попадет заявка
если клиент позвонил по телефону, агент может завести заявку вручную, выбрав любую из доступных агенту очередей
желательно, чтобы заявка клиента всегда была в очередях, доступных клиенту, иначе он не сможет получить доступ к ней через веб-интерфейс
агенты могут производить действия в заявками в соответствии с правами на очередь, в которой находится заявка

Контекст миграции

Ниже приведены некоторые моменты, которые следует учитывать при переносе локальных установок WLS и Azure AD.

Если у вас уже есть арендатор Azure AD без доменных служб, доступ к которым предоставляется через LDAP, это руководство поможет вам включить возможности LDAP и интегрировать их с WLS.
Если в вашем сценарии используется локальный лес Active Directory, примените решение гибридной идентификации на основе Azure AD. Дополнительные сведения см. в документации по гибридной идентификации.
Если у вас уже есть локальное развертывание доменных служб Active Directory (AD DS), изучите пути миграции, описанные в статье Сравнение самостоятельно управляемых доменных служб Active Directory, Azure Active Directory и управляемых доменных служб Azure Active Directory.
Если вы оптимизируете облако, это руководство поможет вам начать с нуля работу с LDAP в Azure AD DS и WLS.
Полный обзор миграции сервера с помощью WebLogic Server на Виртуальные машины Azure см. в статье Миграция приложений WebLogic в Виртуальные машины Azure.

Настройка Active Directory для использования групп

По умолчанию, в AD запрещено анонимным пользователям получать какую-либо информацию из каталога. Для того, чтобы squid хелпер squid_ldap_group имел право обращаться к каталогу Active Directory и извлекать некую информацию из доменной структуры, необходимо хелперу предоставить некие учетные данные для доступа к LDAP. Для этого я в домене создал учетку с минимально необходимыми правами (членство в группе Domain Users — Пользователи домена) (??? может будет достаточно группы Гости домена…)

Имя учетной записи в моем примере будет adsquid@AD.LOCAL, важно задать настройку запрета смены пароля и отменить ограничение времени действия пароля при создании учетной записи

Для удобства, все группы и учетные записи пользователей и компьютеров использующиеся для интеграции сервисов на Linux в инфраструктуру Kerberos я создаю в контейнере UNIXs в подконтейнерах groups, users, hosts соответственно.

Конечно же, нам необходимо создать (для примера) 2 группы пользователей. 1 — это группа, имеющая доступ в интернет без ограничения доступа (называется squid), 2 — группа, имеющая доступ только к списку избранных сайтов (называется squid-list). Можно создать сколько угодно групп с заданием разных настроек, но для примера будет достаточно 2х.

Изменение профиля пользователя и пароля

Пользователи могут изменить их настройки (имя, почтовый адрес и пароль) используя кнопку «Профиль». Это может потребовать выделения соответствующих привилегий для пользователя, от имени которого DokuWiki работает с AD (этот пользователь указан в настройках и ). При этом изменение пароля доступно только через SSL или TLS соединение. См. раздел LDAP over SSL в документации на библиотеку adLDAP.

Также необходимо помнить, что автоматически создаваемые DokuWiki пароли не удовлетворяют политикам безопасности, использованным по умолчанию в Active Directory. В таком случае либо исправьте соответствующие политики AD, либо выключите функцию «Напомнить пароль» в DokuWiki в настройках config:disableactions.

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

Создадим нового клиента (приложение которое будет получать пользователей из Keycloak). Переходим:

Clients —> Create

Option	Value
Client ID
Access Type
Root URL
Valid Redirect URIs
Admin URL

Так же создадим scope для групп:

Client Scopes —> Create

Option	Value
Template
Name
Full group path

И настроим mapper для них:

Client Scopes —> groups —> Mappers —> Create

Option	Value
Name
Mapper Type
Token Claim Name

Теперь нам нужно включить маппинг груп в нашем client scope:

Clients —> kubernetes —> Client Scopes —> Default Client Scopes

Выбираем groups в Available Client Scopes, нажимаем Add selected

Теперь настроим аутентификацию нашего приложения, переходим:

Clients —> kubernetes

Option	Value
Authorization Enabled

Нажимем save и на этом настройка клиента завершена, теперь на вкладке

Clients —> kubernetes —> Credentials

вы сможете получить Secret который мы будем использовать в дальнейшем.

Конфигурация Nginx

Наконец, можно выполнять настройку веб-сервера. Для удобства будет создана директория, в которой необходимо расположить конфиг для авторизации через AD – так его будет удобно подключать в необходимый контекст. Ну, или разместить по своему усмотрению:

В файле nginx-ldap-auth.conf описан location, в котором настроено:

наименование location – в данном случае /auth
кеширование 200 кода (через пробел можно добавить и другие коды) ответа в течение 10 минут
проксирование запросов на локальный адрес, где слушает nginx-ldap-auth
передача HTTP-заголовков для LDAP

В вышеописанном конфигурационном файле к обычному “location /” добавляется “auth_request /auth;” и после подключается ранее сформированный файл nginx-ldap-auth.conf. Далее остаётся проверить синтаксис и выполнить релоад Nginx:

Исключение для basic auth

Удобным может тот случай, когда для доверенных адресов какую-либо авторизацию на веб-сервере можно вообще убрать – на помощь приходит директива “satisfy any”:

Если пользователь пришёл с адреса из подсети 10.10.1.0/24, то satisfy разрешает доступ, если все () или хотя бы один () из модулей ngx_http_access_module, ngx_http_auth_basic_module, ngx_http_auth_request_module или ngx_http_auth_jwt_module разрешают доступ и в таком случае пароль вводить не понадобится.

Удобно сделать white-лист и подключать его через include:

Подготовка системы

Для корректной работы нашего веб-сервера необходимо:

Задать имя серверу.
Настроить синхронизацию времени.
Настроить брандмауэр.

Рассмотрим настройку по шагам.

1. Имя сервера

В процессе настройки аутентификации через LDAP нам необходимо будет задать в качестве принципала имя нашего сервера:

hostnamectl set-hostname nginx.domain.local

* предполагается, что в нашем случае имя сервера будет nginx.domain.local (домен domain.local).

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

Для работы с LDAP нам необходимо, чтобы время на последнем совпадало с временем на нашем веб-сервере. Самый правильный способ этого добиться — настроить синхронизацию.

Для начала настраиваем временную зону:

timedatectl set-timezone Europe/Moscow

* в данном примере мы задаем зону по московскому времени. Список все доступных зон можно посмотреть командой timedatectl list-timezones.

Устанавливаем утилиту для синхронизации времени, настраиваем ее, разрешаем запуск демона и стартуем его. Набор команд будет зависеть от дистрибутива Linux.

а) если на системе Ubuntu / Debian:

apt-get install chrony

vi /etc/chrony/chrony.conf

…
pool domain.local
# pool …
# pool …
# pool …
…

* в данном примере мы указали в качестве сервера синхронизации любой контроллер домена. Остальные настройки pool необходимо закомментировать.

systemctl enable chrony

systemctl restart chrony

б) если на системе CentOS / Red Hat:

yum install chrony

vi /etc/chrony.conf

…
server domain.local
# server …
# server …
# server …
…

systemctl enable chronyd —now

3. Настройка безопасности

Для корректной работы нашего веб-сервера необходимо открыть порты http и https. Действия будут отличаться в зависимости от используемого брандмауэра.

а) Iptables (как правило, на Ubuntu/Debian или ранних версиях CentOS):

iptables -I INPUT -p tcp —match multiport —dports 80,443 -j ACCEPT

Для сохранения правил устанавливаем iptables-persistent и запускаем утилиту:

apt-get install iptables-persistent

netfilter-persistent save

б) Firewalld (как правило, на поздних версиях CentOS):

firewall-cmd —permanent —add-service=http{,s}

firewall-cmd —reload

Также на системах с активированным SELinux (как правило, )

setenforce 0

sed -i ‘s/^SELINUX=.*/SELINUX=disabled/g’ /etc/selinux/config

Настройка аутентификации на Postfix

Аутентификация на postfix будет выполняться методом dovecot. Для этого устанавливаем его. Заодно, устанавливаем и postfix (на случай, если его нет еще в системе). В зависимости от используемой операционной системы используем разные команды.

а) если используем Ubuntu / Debian:

apt-get update

apt-get install postfix dovecot-imapd dovecot-pop3d

б) если используем CentOS / Red Hat:

yum install postfix dovecot

После установки пакетов, разрешаем автозапуск dovecot и postfix:

systemctl enable postfix dovecot

Открываем на редактирование конфигурационный файл нашего MTA Postfix:

vi /etc/postfix/main.cf

Добавляем строки (или меняем значения):

smtpd_sasl_type = dovecot
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_relay_restrictions =
  permit_mynetworks
  permit_sasl_authenticated
  reject_unauth_destination

* где:

smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации. Командой postconf -a мы можем получить список механизмов аутентификации, которые поддерживаются почтовой системой.
smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL.
smtpd_sasl_path — путь до файла для обмена аутентификационной информацией. Используется для взаимодействия нескольких систем — в нашем примере Postfix + Dovecot.
smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке. В нашем случае:
- permit_mynetworks — разрешить отправку с компьютеров, чьи IP-адреса соответствуют настройке mynetworks.
- permit_sasl_authenticated — разрешить отправку писем тем, кто прошел авторизацию.
- reject_unauth_destination — запретить всем, кто не прошел проверку подлинности.

Проверяем корректность настройки:

postconf > /dev/null

Если команда не вернула ошибок, перезапускаем Postfix:

systemctl restart postfix

Переходим к настройке dovecot — открываем файл:

vi /etc/dovecot/conf.d/10-master.conf

… и приводим опцию service auth к следующему виду:

service auth {
…
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
…
}

* если соответствующей секции unix_listener нет, то ее нужно создать

Обратите внимание, что для обмена аутентификационными данными мы применяем файл /var/spool/postfix/private/auth, который в конфигурационном файле postfix был указан, как private/auth

Отключаем требование ssl для аутентификации (на текущем этапе нам это не нужно):

vi /etc/dovecot/conf.d/10-ssl.conf

Проверяем, чтобы значение ssl не было required:

ssl = yes

* нас устроит оба варианта — yes или no.

Настройки аутентификации приводим к следующему виду:

vi /etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain login

* данные механизмы позволяют передачу данных в открытом виде.

В этом же файле проверяем, что снят комментарий со следующей строки:

!include auth-system.conf.ext

Проверяем корректность настройки dovecot:

doveconf > /dev/null

Если команда ничего не вернула, перезапускаем сервис:

systemctl restart dovecot

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

useradd smtptest

passwd smtptest

Мы настроили простую аутентификацию на сервере SMTP. Для проверки можно воспользоваться любым почтовым клиентом. Пример настройки thunderbird:

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

Мы завершили настройку аутнтификации на postfix при отправке письма. Добавим проверку данных через LDAP.

Настройка Kerberos

Установка пакетов для поддержки аутентификации Kerberos:

1	apt-get install krb5-user libsasl2-modules-gssapi-mit

В ходе установки может появится запрос указать область по-умолчанию для Kerberos, область необходимо его указать в заглавном виде (прим. JAKONDA.LOCAL)

Файл конфигурации Kerberos (/etc/krb5.conf), приводим к виду:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

default_realm = JAKONDA.LOCAL
default_keytab_name = /etc/squid/squid.keytab
dns_lookup_kdc = false
dns_lookup_realm = false
forwardable = true
ticket_lifetime = 24h

JAKONDA.LOCAL = {
kdc = dc1.jakonda.local
default_domain = JAKONDA.LOCAL
admin_server = dc1.jakonda.local
}

.jakonda.local = JAKONDA.LOCAL
jakonda.local = JAKONDA.LOCAL

Соответственно подставляем название своего домена вместо jakonda.local/JAKONDA.LOCAL

Проверка работы Kerberos, выполним авторизацию в Active Directory:

1
2
3
4
5

kinit -kV -p HTTP/squid.jakonda.local

Using default cache: /tmp/krb5cc_0
Using principal: HTTP/squid.jakonda.local@JAKONDA.LOCAL
Authenticated to Kerberos v5

Удаляем полученный билет:

kdestroy

Настройка squid для авторизации на основе членства в доменной группе LDAP

Приступаем к финальному шагу. Для реализации авторизации на основе членства в доменной группе в squid используется внешний acl, т.н. параметр external_acl_type. Общая схема работы примерно следующая:

# задаем external_acl_type для взаимодействия с LDAP
external_acl_type произвольное_имя_ext_acl %LOGIN /путь/к/хелперу/squid_ldap_group -R \
-b "BaseDN" -f "фильтр с переменной %v и %a" -D пользователь_ad@домен -K -W /файл/с/паролем имя_dc
# где переменная %v подставляется за счет указания значения %LOGIN,
#  которое извлекает имя аутентифицированного пользователя
# далее необходимо задать acl, которое будет передавать в переменную %a имя групп
acl имя_acl external произволное_имя_ext_acl передаваемое_название_группы
# далее необходимо с образовавшимся acl работать как с обычным acl,
# то есть задавать какие-то разрешения с помощью соответствующих параметров

Если данную схему наложить на наш домен и нашу задачу, то получится примерно следующий конфиг:

ldap ~ # grep -v ^# /etc/squid3/squid.conf | grep -v ^$
auth_param negotiate program /usr/lib/squid3/squid_kerb_auth
auth_param negotiate children 15
auth_param negotiate keep_alive on
external_acl_type ldap_verify %LOGIN /usr/lib/squid3/squid_ldap_group -R \
-b "dc=ad,dc=local" -f  "(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=groups,ou=UNIXs,dc=ad,dc=local))"\
-D adsquid@ad.local -K -W /etc/squid3/aduser dc.ad.local.
acl manager proto cache_object
acl localhost src 127.0.0.1/32
acl to_localhost dst 127.0.0.0/8 0.0.0.0/32
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl CONNECT method CONNECT
acl localnet src 10.0.0.0/16
acl to_localnet dst 10.0.0.0/16
acl users external ldap_verify squid
acl users-list external ldap_verify squid-list
acl whitelist dstdomain "/etc/squid3/acls/whitelist.acl"
acl allusers proxy_auth REQUIRED
http_access allow manager localhost
http_access allow localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow users
http_access allow users-list whitelist
http_access deny !allusers all
http_access deny all
http_port 10.0.0.10:3129
http_port 127.0.0.1:3129
hierarchy_stoplist cgi-bin ?
coredump_dir /var/spool/squid3
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320

Давайте разберем получившийся конфиг. Как видно, добавился параметр external_acl_type, заставляющий sqiud обращаться к каталогу LDAP, расположенному на контроллере домена dc.ad.local, через хелпер squid_ldap_group. squid_ldap_group ищет пользователей в каталоге, начиная с пути dc=ad,dc=local, авторизованных пользователей, принадлежащих некоторым группам, имена которых (групп) передаются из acl в переменную %a. Как мы видим, у нас пропал параметр -d за ненадобностью и появился параметр -K. Давайте его разберем. Мы , что при ~~Negotiate~~ Kerberos аутентификации имя пользователя у нас получается в виде пользователь@ДОМЕН, а хелпер squid_ldap_group использует имена в формате пользователь (то есть без доменной части). Так вот, ключ -K заставляет squid_ldap_group «обрезать» часть имени @ДОМЕН и корректно сравнивать имя пользователя и группу.

Далее мы видим, что появилось 3 новых acl — users, users-list и whitelist, которые проверяют принадлежность пользователя к группе с именем squid, к группе с именем squid-list и задает белый список сайтов соответственно. При этом, про первые 2 acl было бы понятней сказать, что они передают в external_acl_type с именем ldap_verify имя группы, которой должен принадлежать аутентифицированный пользователь.

Ну и последнее — это появление двух параметров http_access, которые разрешают доступ acl с именем users и acl с именем users-list при доступе этих пользователей к сайтам из acl whitelist. Кроме того, был убран параметр http_access allow allusers, который разрешал доступ всем аутентифицированным пользователям.

На этом в настройке можно поставить точку. Перезапускаем сквид и наши пользователи, которые входят в доменные группы squid и squid-list могут работать в интернете.

Создание класса Application

Метод передает управление вспомогательному классу
, предоставляя
как аргумент его методу. Это говорит Spring о том, чтобы
прочитать аннотацию метаданных из и управлять им
как компонентом в Spring Application Context.

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

Сборка исполняемого JAR

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

Затем вы можете запустить JAR-файл:

Если вы используете Maven, вы можете запустить приложение, используя ,
либо вы можете собрать приложение с и запустить JAR примерно так:

Процедура, описанная выше, создает исполняемый JAR. Вы также можете вместо него
собрать классический WAR-файл.

Operation

There are two phases in granting access to a user. The first
phase is authentication, in which the
authentication provider verifies that the user’s credentials are valid.
This is also called the search/bind phase. The second phase is
authorization, in which determines
if the authenticated user is allowed access to the resource in
question. This is also known as the compare
phase.

registers both an authn_ldap authentication
provider and an authz_ldap authorization handler. The authn_ldap
authentication provider can be enabled through the
directive
using the value. The authz_ldap handler extends the
directive’s authorization types
by adding , and
values.

The Authentication
Phase

During the authentication phase,
searches for an entry in the directory that matches the username
that the HTTP client passes. If a single unique match is found,
then attempts to bind to the
directory server using the DN of the entry plus the password
provided by the HTTP client. Because it does a search, then a
bind, it is often referred to as the search/bind phase. Here are
the steps taken during the search/bind phase.

Generate a search filter by combining the attribute and
filter provided in the directive with
the username passed by the HTTP client.
Search the directory using the generated filter. If the
search does not return exactly one entry, deny or decline
access.
Fetch the distinguished name of the entry retrieved from
the search and attempt to bind to the LDAP server using that
DN and the password passed by the HTTP client. If the bind is
unsuccessful, deny or decline access.

The following directives are used during the search/bind
phase

	Specifies the LDAP server, the base DN, the attribute to use in the search, as well as the extra search filter to use.
	An optional DN to bind with during the search phase.
	An optional password to bind with during the search phase.

The Authorization Phase

During the authorization phase,
attempts to determine if the user is authorized to access the
resource. Many of these checks require
to do a compare operation on the
LDAP server. This is why this phase is often referred to as the
compare phase. accepts the
following
directives to determine if the credentials are acceptable:

Grant access if there is a directive, and the
username in the directive matches the username passed by the
client.
Grant access if there is a directive, and the DN in the directive matches
the DN fetched from the LDAP directory.
Grant access if there is a directive, and
the DN fetched from the LDAP directory (or the username
passed by the client) occurs in the LDAP group or, potentially, in
one of its sub-groups.
Grant access if there is a
directive, and the attribute fetched from the LDAP directory
matches the given value.
Grant access if there is a
directive, and the search filter successfully finds a single user
object that matches the dn of the authenticated user.
otherwise, deny or decline access

Other values may also
be used which may require loading additional authorization modules.

Grant access to all successfully authenticated users if
there is a
directive. (requires )
Grant access if there is a directive, and
has been loaded with the
directive set.
others…

uses the following directives during the
compare phase: