Назад | Перейти на главную страницу

Конфигурация kerberos сервера LAMP для аутентификации против Windows KDC только для чтения в dmz

Задний план:

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

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

Хочу:

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

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

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

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

  1. Добавлен DMZ DC в файл hosts
  2. Обновлен файл krb5.conf и связаны одна область и домен (domain1) с DMZ DC.
  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, поэтому я обращаюсь за помощью.

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

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


В ответ на Nathan C журнал безопасности показывает запросы на сервисные билеты Kerberos следующим образом:

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

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

Информация о службе: Имя службы: RODC01 $ ID службы: DOMAIN1 \ RODC01 $

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

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

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

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

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

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


Информация об учетной записи:

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

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

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

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

Имя службы: krbtgt / DOMAIN1.COM

ID услуги: NULL SID

Сетевая информация:

Адрес клиента: [WEB IP HIDDEN]

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

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

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

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

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

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

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

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

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

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

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

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

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

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