☰

Конфигурация LAMP-сервера Kerberos для аутентификации с использованием Windows KDC только для чтения в DMZ

tag-icon • tag-icon apache-2.2 active-directory kerberos dmz domain
Конфигурация LAMP-сервера Kerberos для аутентификации с использованием Windows KDC только для чтения в DMZ

Фон:

У нас есть несколько сетей AD (доменов), которые соединены через VPN и установили доверительные отношения AD. У нас есть внешний веб-сервер, и мы настроилибесшовная аутентификациядля любого пользователя в доверенной сети. Это работает, но наличие VPN на внешнем веб-сервере, не управляемом нашим ИТ-отделом, было сочтено сетевой командой слишком большим риском для безопасности.

У меня нет прав администратора на внутренние сети, но есть полный доступ администратора на веб-серверах.

Хотеть:

Установите такую ​​же бесшовную аутентификацию без VPN, используя контроллер домена только для чтения в DMZ для обработки всех запросов на аутентификацию.

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

  1. У нас есть несколько доменов AD, которым доверяют друг друга и которые соединены через VPN-туннели.
  2. У нас есть DC только для чтения в DMZ, подключенный к основной сети AD.
  3. Внешние веб-серверы LAMP — мы используем один экземпляр для тестирования новой конфигурации.

Выполненные задачи:

  1. Добавлен DC DMZ в файл hosts
  2. Обновлен файл krb5.conf и связан с DMZ DC одиночная область и домен (domain1)
  3. Протестировал аутентификацию в командной строке с помощью kinit (сработало)
  4. Обновлен файл krb5.conf с дополнительными областями и сопоставлениями областей доменов, при этом все домены указывают на DC DMZ.
  5. Протестировал аутентификацию в командной строке с пользователем из одной из дополнительных областей, но она не удалась.

Пример текущих конфигураций

/etc/hosts/ : (я заменил фактический IP-адрес на x и реальные доменные имена из соображений конфиденциальности)

xxx.xxx.xxx.xxx  dc01.domain1.com, dc01.domain2.com, dc01.domain3.com, dc01.domain4.com

/etc/krb5.conf:

[libdefaults]
 default_realm = REALM1.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 clockskew = 12000
 kdc_timesync = 1

[realms]
 REALM1.COM = {
  kdc = dc01.domain1.com
  admin_server= dc01.domain1.com
 }
 REALM2.COM = {
  kdc = dc01.domain2.com
  admin_server= dc01.domain2.com
 }
 REALM3.COM = {
  kdc = dc01.domain3.com
  admin_server= dc01.domain3.com
 }
 REALM4.COM = {
  kdc = dc01.domain4.com
  admin_server= dc01.domain4.com
 }

Проблемы:

DMZ не обрабатывает запросы аутентификации для доверенных доменов. Я не знаю, является ли это результатом конфигурации DC или конфигурации kerberos, поэтому и обращаюсь за помощью.

Потратил несколько часов на изучение других вопросов по serverfault, поиск в Google и чтение руководств, но, похоже, ничто не соответствует нашему сценарию.

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

В ответе Натана С. журнал безопасности показывает запросы на билеты службы Kerberos, подобные этим:

Аудит пройден успешно 14.05.2014 11:05 Microsoft-Windows-Security-Auditing 4769 Операции с билетом службы Kerberos «Был запрошен билет службы Kerberos.

Информация об учетной записи: Имя учетной записи: [email protected] Домен учетной записи: DOMAIN1.COM GUID входа: {C93D9AAC-6968-6C00-83EF-2C2D54E2363B}

Информация об услуге: Имя услуги: RODC01$ Идентификатор услуги: DOMAIN1\RODC01$

Информация о сети: Адрес клиента: ::1 Порт клиента: 0

Дополнительная информация: Параметры тикета: 0x40810000 Тип шифрования тикета: 0x17 Код ошибки: 0x0 Передаваемые службы: -

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

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

Параметры тикетов, типы шифрования и коды ошибок определены в RFC 4120.

К сожалению, выдержка из журнала, отправленная мне, не совпадает с тем временем, когда я пытался пройти аутентификацию, поэтому я не знаю, к чему на самом деле относится эта запись журнала. Я запросил другую выдержку.

Информация Об Учетной Записи:

Имя учетной записи: jameel.rahmaa

Предоставленное имя области: DOMAIN1.COM

ID пользователя: NULL SID

Служебная информация:

Имя сервиса: krbtgt/DOMAIN1.COM

Идентификатор сервиса: NULL SID

Информация о сети:

Адрес клиента: [WEB IP СКРЫТ]

Клиентский порт: 34567

Дополнительная информация:

Варианты билетов: 0x40800000

Код результата: 0x6

Тип шифрования билета: 0xffffffff

Тип предварительной аутентификации: -

Справочная информация:

Имя эмитента сертификата:

Серийный номер сертификата:

Отпечаток сертификата:

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

Типы предварительной аутентификации, параметры билетов, типы шифрования и коды результатов определены в RFC 4120.

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

решение1

0x6. KDC_ERR_C_PRINCIPAL_UNKNOWNвот оно... исследуйте это. Похоже, ваши SPN настроены неправильно или он пытается использовать учетную запись, которая даже не существует. Wireshark — еще один хороший инструмент, который вы можете запустить на веб-сервере, чтобы увидеть, что он получает от DC при выполнении запросов.

Связанный контент