Kerberos authentication overviewkerberos authentication overview

Что такое 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.

UserAccountControl — атрибут Active Directory

Суммарное значение всех указанных опций хранится в значении атрибута учетной записи UserAccountControl, т.е. вместо, того чтобы хранить все эти опции в разных атрибутах, используется один атрибут Active Directory. Атрибут UserAccountControl представляет собой битовую маску, каждый бит которого является отдельным флагом, отображающим значение одной из указанных опций и может иметь разное значение (вкл или выкл). Соответственно, в зависимости от включенных опций учетной записи, у пользователя будет получаться разное значение атрибута UserAccountControl. Посмотреть текущее значение атрибута можно на вкладке Attribute Editor или с помощью следующей командлета PowerShell Get-ADUser:

В этом примере значение атрибута 0x10202 (в десятичном представлении 66050). Что означают эти числа?

Ниже представлена таблица доступных флагов учетных записей в AD. Каждый из флагов соответствует определённому биту атрибута UserAccountControl, а значение UserAccountControl равно сумме всех флагов.

Флаг	Значение в HEX	Десятичное значение
SCRIPT (Запуск сценария входа)	0x0001	1
ACCOUNTDISABLE (Учетная запись отключена)	0x0002	2
HOMEDIR_REQUIRED (Требуется домашняя папка)	0x0008	8
LOCKOUT (Учетная запись заблокирована)	0x0010	16
PASSWD_NOTREQD (Пароль не требуется)	0x0020	32
PASSWD_CANT_CHANGE (Запретить смену пароля пользователем)	0x0040	64
ENCRYPTED_TEXT_PWD_ALLOWED (Хранить пароль, используя обратимое шифрование)	0x0080	128
TEMP_DUPLICATE_ACCOUNT (учетная запись пользователя, чья основная учетная запись хранится в другом домене)	0x0100	256
NORMAL_ACCOUNT (Учетная запись по умолчанию. Обычная активная учетная запись)	0x0200	512
INTERDOMAIN_TRUST_ACCOUNT	0x0800	2048
WORKSTATION_TRUST_ACCOUNT	0x1000	4096
SERVER_TRUST_ACCOUNT	0x2000	8192
DONT_EXPIRE_PASSWORD (Срок действия пароля не ограничен)	0x10000	65536
MNS_LOGON_ACCOUNT	0x20000	131072
SMARTCARD_REQUIRED (Для интерактивного входа в сеть нужна смарт-карта)	0x40000	262144
TRUSTED_FOR_DELEGATION	0x80000	524288
NOT_DELEGATED	0x100000	1048576
USE_DES_KEY_ONLY	0x200000	2097152
DONT_REQ_PREAUTH (Не требуется предварительная проверка подлинности Kerberos)	0x400000	4194304
PASSWORD_EXPIRED (Срок действия пароля пользователя истек)	0x800000	8388608
TRUSTED_TO_AUTH_FOR_DELEGATION	0x1000000	16777216
PARTIAL_SECRETS_ACCOUNT	0x04000000	67108864

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

Соответственно, значение userAccountControl из моего примера (66050) получилось следующим образом:

Для обычной заблокированной учетной записи значение userAccountControl будет равно 514:

Значения UserAccountControl по-умолчанию для типовых объектов домена:

• Обычный пользователь : 0x200 (512)
• Контроллер домена : 0x82000 (532480)
• Рабочая станция/сервер: 0x1000 (4096)

С помощью фильтров можно выбирать из AD объекты, с определённым значением атрибута useraccountcontrol. Например, для вывода всех активных (нормальных учетных записей):

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

Список аккаунтов, у которых не ограничен срок действия пароля:

Сложить нужные биты из таблицы и выбрать объекты AD можно с помощью следующих команд:

Apache[править]

1. epmi apache2-mod_auth_kerb
2. a2enmod auth_krb5 && serv httpd2 reload

положил тикет с SPN

добавил такие настройки:

      AuthType Kerberos
      AuthName "Please enter your login and password for ETERSOFT.RU"
      KrbMethodNegotiate on
      KrbMethodK5Passwd on
      KrbServiceName HTTP/time.office.etersoft.ru@ETERSOFT.RU
      KrbAuthRealms ETERSOFT.RU
      Krb5Keytab /etc/krb5.time.office.keytab
      #KrbLocalUserMapping On

другой вариант:

1. epmi apache2-mod_auth_gssapi
2. a2enmod auth_gssapi && serv httpd2 reload

 AuthType GSSAPI
 AuthName "WebDAV Login"
 GssapiBasicAuth On
 GssapiCredStore keytab:/etc/apache2/http.keytab

 require valid-user
 RequestHeader set REMOTE-USER %{REMOTE_USER}s

kinit / klist / kdestroy[править]

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

Получить билет:

$ kinit 

В настроенной системе достаточно просто kinit, а указание полной формы типа kinit user@EXAMPLE.COM позволяет получить тикет в системе сразу после установки epmi /usr/bin/kinit.

Удалить полученные билеты из кэша:

$ kdestroy

Просмотреть полученные билеты:

$ klist

Для отладки получения билета удобно использовать

$ export KRB5_TRACE=/dev/stdout

Если машина находится в другой сети, то потребуется ручное указание REALM и соответствия его домену в /etc/krb5.conf:

default_realm = EXAMPLE.COM
...

 EXAMPLE.COM = {
  default_domain = example.com
 }

Связь хелпера squid_ldap_group с Active Directory

Нижеприведенная команда была сгруппирована из различных источников в сети, поэтому некоторые параметры останутся без четкого описания (как это не печально…).

Рассмотрим пример установки тестовой связи хелпера squid_ldap_group с каталогом LDAP AD:

ldap ~ # /usr/lib/squid3/squid_ldap_group -R -d -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 -W /etc/squid3/aduser dc
test squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=test)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
OK
test@AD.LOCAL squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=test@AD.LOCAL)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
ERR
AD\test squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=AD\5ctest)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
ERR
ivanov squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=ivanov)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
ERR

Давайте рассмотрим, что мы накуралесили в данной команде (все параметры описаны из man  squid_ldap_group):

-R

дословно — do not follow referrals. Как переводится — не знаю Работает и без нее. Но, говорят снижает нагрузку на AD.

 -d

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

-b

это базовое отличительное имя нашего дерева каталогов (т.н. BaseDN). Базовое, то есть от этой ветки будет производиться поиск пользователей в LDAP. Допустим, если бы все наши авторизуемые пользователи находились бы в контейнере OU Юристы, то можно было бы задать значение этого ключа  -b «ou=Юристы, ou=groups,dc=ad,dc=local», тем самым снизив нагрузку на LDAP. Т.к. авторизуемые пользователи у меня разбросаны по всей структуре дерева, то в примере я указываю производить поиск от корня дерева  -b «dc=ad,dc=local»

-f

задает некий фильтр поиска необходимой нам группы (memberOf=cn=%a), которая расположена по пути ou=groups,ou=UNIXs,dc=ad,dc=local. В данном фильтре переменная %v заменяется именем пользователя (без указания домена @AD.LOCAL или AD\), а переменная %a заменяется запрашиваемой группой. Т.к. в LDAP я почти ноль, поэтому толкового объяснения данному фильтру не даю… Соответственно, если у вас группа (принадлежность к которой необходимо проверять) расположена в каком-нибудь контейнере linux в домене primer.domen.local, то данный фильтр будет иметь вид:  -f  «(&(objectclass=user)(sAMAccountName=%v)(memberOf=cn=%a,ou=linux,dc=primer,dc=domen,dc=local))».

-D

задает имя пользователя, от которого происходит подключение к каталогу AD.

-W

указывает путь к файлу, который хранит пароль к учетной записи из параметра -D. На данный файл необходимо назначить владельца — пользователя под которым работает squid (обычно это proxy) и задать права доступа на чтение только для владельца.

dc

задает DNS имя сервера LDAP. Здесь можно указать вместо DNS имени — IP адрес.

Далее в листинге я пытаюсь проверить соответствие доменного пользователя test доменной группе squid-list, в которую он действительно входит. При этом, я пытаюсь указать имя пользователя в различных форматах. Как видно, хелпер  squid_ldap_group корректно принимает имя только без указания доменной части. О чем нам говорит строка:

test squid-list
Connected OK
group filter '(&(objectclass=user)(sAMAccountName=test)(memberOf=cn=squid-list,ou=groups,ou=UNIXs,dc=ad,dc=local))', searchbase 'dc=ad,dc=local'
OK

Последней попыткой я пытаюсь проверить принадлежность пользователя ivanov к указанной группе squid-list, при этом, реально ivanov в данную группу не входит. Соответственно, неудачные попытки нам возвращают значение ERR.

Если на данном шаге удалось связать хелпер с AD и при правильном вводе пользователя и группы, в которую он входит, происходит корректный ответ хелпера — ОК, значит дело движется в правильном направлении и можно приступить к настройке squid. В противном же случае — необходимо разобраться в причинах проблем.

Настройка пользовательских компьютеров

На пользовательском компьютере использовать команду:

pam-auth-update

В файле  /etc/nsswitch.conf добавить слово winbind параметры password и group:

Чтобы пользователи AD после аутентификации могли менять свой пароль из командной строкив файле /etc/pam.d/common-password из строки убрать слово 

Предупреждение: Использование контроллера домена как файлового сервера

Несмотря на то, что Samba в режиме AD DC может предоставлять услуги разделения файлов так же, как и в любом другом режиме применения, разработчкики Samba не рекомендуют использовать DC как файловый север по следующим причинам:

• Для всех организаций, за исключением самых маленьких, наличие более, чем одного DC, является реально хорошим способом резервирования, повышающим безопасность обновлений;
• Отсутствие сложных данных и влияния на другие сервисы позволяет обновлять DC совместно с ОС хоста каждые год или два;
• Обновления могут выполняться путем установки новых версий, или внесения изменений, которые лучше проверены в Samba, что позволяет получить новые возможности, избежав множества рисков, связанных с повреждением данных;
• Необходимость модернизации DC и файлового сервера наступает в разные моменты. Потребность в новых возможностях DC и файлового сервера возникает в разные моментв времени. В то время, как AD DC стремительно развивается, приобретая новые возможности, файловый сервер, после более 20 лет, гораздо более консервативен;
• mandatory smb signing is enforced on the DC.

Если вы изучаете возможность использовать Samba DC как файловый сервер, рассмотрите вместо этого возможность использовать на DC виртуальную машину VM, содержащую отдельного участника домена.

Если вы вынуждены использовать Samba DC как файловый сервер, помните, что виртуальная файловая система (virtual file system, VFS) позволяет настраивать разделяемые ресурсы только со списками управления доступом access (control lists, ACL) Windows.Разделяемые ресурсы с ACL POSIX на Samba DC не поддерживаются, и не работают.

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

Подробности см.:

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

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

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

Минимальное содержимое таких файлов с конфигурациями виртуальных хостов выглядит следующим образом:

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

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

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

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

vi /etc/squid/squid.conf

В разделе с 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:

vi /etc/squid/denysite

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

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

squid -k reconfigure

Настройка squid на Kerberos аутентификацию

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

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
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 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 allusers
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

Конечно же, кроме squid.conf у нас должен быть настроен /etc/krb5.conf  и другие необходимые конфиги и, конечно же, Active Directory согласно статье.

Исходные данные

Конфигурация сети следующая:

• Локальная подсеть — 10.0.0.0/16
• IP контроллера домена — 10.0.0.1
• Имя домена — ad.local
• Имя контроллера домена — dc.ad.local
• IP хоста со squid — 10.0.0.10

Kerberos Golden Tickets

Один из способов сохранить доступ к системе — сформировать Golden Ticket: пароль учетной записи не будет изменен при тех же условиях, при которых может быть изменен пароль администратора.

Golden Ticket — это поддельные билеты для выдачи билетов, также называемые аутентификационными билетами (они же TGT). Если посмотреть на схему аутентификации Kerberos в случае Golden Ticket, то можно заметить, что подлинность Kerberos не проверяется (AS-REQ и AS-REP с контроллером домена). Так как Golden Ticket является поддельным TGT, он отправляется контроллеру домена как часть TGS-REQ для получения билета TGS.

Схема аутентификации Kerberos c Golden Ticket

Золотой билет Kerberos — действительный билет Kerberos TGT, поскольку он зашифрован и подписан доменной учетной записью Kerberos (). А так как TGT зашифрован хешем пароля и может быть расшифрован любой службой KDC в домене, то билет и воспринимается как реальный. Для того чтобы сделать Golden Ticket, нам необходимо знать следующее:

1. SPN домена.
2. SID домена.
3. NTLM-хеш доменной учетной записи .
4. Имя пользователя, под которым будет работать оператор (даже если такого пользователя не существует).

Так как имя пользователя может быть любым, остается найти три недостающих компонента. Название и SID домена можно узнать с помощью PowerShell-команды .

SID и имя домена

Теперь нужно получить NTLM-хеш учетной записи . Сделать это можно как удаленно, так и с помощью mimikatz. С использованием mimikatz у оператора есть выбор: выполнить атаку DCSync, используя базу Security Account Managers (SAM), или задействовать модуль sekurlsa.

Получаем хеши с помощью mimikatz, используя атаку DCSync

Получаем хеши с помощью mimikatz, используя базу SAM

Получаем хеши с помощью mimikatz, используя модуль sekurlsa

Удаленная атака выполняется также с использованием DCSync или при наличии открытой сессии .

Получение хешей с помощью secretsdump

Существует два варианта использования : при помощи и (для второго нужно загрузить модуль kiwi).

Получение хешей с помощью meterpreter hashdumpПолучение хешей с помощью meterpreter dcsync_ntlm

С помощью полученной информации можно создать и применить Golden Ticket. Сделаем это тремя способами: используя mimikatz, удаленно с помощью и с использованием .

Ticketer

Первым делом следует создать билет. Для этого используем скрипт из пакета (напомню, что имя пользователя можно выдумать любое).

Создание Golden Ticket с помощью ticketer

В текущей директории создан билет . Экспортируем его.

Теперь подключимся с помощью из того же пакета .

Подключаемся к хосту, используя Golden Ticket

Получаем удаленное управление с правами .

Mimikatz

Создадим поддельный золотой билет с помощью mimikatz.

Создание Golden Ticket с помощью mimikatz

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

Теперь, выполнив команду , наблюдаем кешированный Golden Ticket.

Создание Golden Ticket с помощью mimikatz 

Meterpreter

Для работы с будем использовать модуль kiwi. Первым делом создадим Golden Ticket.

Создание Golden Ticket с помощью meterpreter

Теперь применим его.

Применение Golden Ticket с помощью meterpreter

И проверим, что билет успешно загружен.

Загруженный Golden Ticket

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

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

Kerberos (MIT)

FILE Main Kerberos config file

libdefaults
   default_realm = EXAMPLE.CO.UK
   forwardable = true
   proxiable = true
   default_keytab_name = FILE:/etc/krb5.keytab

Do not create the file /etc/krb5.keytab — Samba may give an error if it can’t create the keytab file.

The following command will grab a Kerberos ticket for the currently logged in user. <user> can actually be any valid Kerberized user account, if omitted then the current Unix username is used. If the default realm is already specified in krb5.conf then it can be also be omitted.

If the realm is already set and the ticket is for a username that matches the Unix user then simply run kinit and enter a password.

It is not always possible to use supplementary groups with some daemons eg Squid. The following will add additional ACLs to the Kerberos keytab file file to allow the processes to read the keytab. This assumes that you have ACL support on the system. If not then you will need some other method of allowing the daemons to access the single keytab. Failing that you will have to create separate keytabs for each application and get them set up manually — web search for that. Only do this bit after getting Samba to create the file, otherwise you may get errors.

file: etc/krb5.keytab
owner: root
group: root 
user::rwx
user:squid:r--
user:apache:r--
group::r--
mask::r--
other::---

Настройка авторизации

Если не настроена авторизация через Kerberos, по умолчанию для всех ресурсов будет использоваться авторизация через , при этом будет использоваться пользовательская БД, прописанная в настройках ОС. Логин и пароль пользователя будут передаваться от пользователя к серверу в открытом виде с использованием метода аутентификации . Для корректного функционирования авторизации через пользователю, от которого работает web-сервер (по умолчанию — ), необходимо выдать права на чтение информации из БД пользователей и сведений о метках безопасности. Например, добавить права на чтение файла

и права на чтение каталога :