Проблема с интеграцией LDAP в iTop ITSM CMDB

Всем привет,

Я работаю с iTop ITSM CMDB и столкнулся с проблемой при попытке настроить интеграцию LDAP с нашим Active Directory. Моя цель — разрешить пользователям аутентифицироваться напрямую с использованием их учетных данных AD.

В логах появляется следующая ошибка:

| Ошибка   |       | ldap_authentication: запись не найдена с запросом '(&(sAMAccountName=test_user))', base_dn = 'DC=domain,DC=com'. Пользователь не найден в LDAP. | IssueLog |

Я проверил следующее:

  • LDAP-сервер активен и принимает соединения.
  • Файл config-itop.php настроен с правильным доменом и учетными данными.
  • Запрос кажется правильной формы, но совпадений в дереве LDAP не найдено.

Дополнительные моменты:

  • Я не использую порт 636 для LDAPS.

Кому-нибудь встречалась эта проблема раньше или знаете, как ее решить? Буду очень признателен за помощь или руководство по корректировке моей конфигурации для правильной аутентификации пользователей в iTop.

Заранее спасибо.

На мой взгляд, нужно включить подпись для продолжения использования незашищенного LDAP (389). По моему мнению, для безопасности рекомендуется сделать доступ к LDAPS (636). Тогда подпись не потребуется. Это правильное решение.

Я понимаю рекомендацию перейти на LDAPS (636) для безопасной связи, и я согласен, что это лучший и безопасный вариант. Однако в моей текущей среде LDAPS еще не настроен. Я скоро приступлю к его настройке. В настоящее время я не использую подпись на порту 389, так как использую HTTP для LDAP.

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

Может кто-то создал “прокси” на Windows для обнародования старых простых соединений??? (он должен запускаться где-то, где подпись делается для реальной проксированной части)

Большое спасибо за информацию! Я уже давно борюсь с этой проблемой, и ваше объяснение было очень полезным. Насколько я понимаю, лучше использовать безопасный порт с подписью.

Однако у меня остается вопрос: будет ли внутренний CA хорошо работать для настройки LDAPS, или мне понадобится публичный сертификат?

Тема подписания такова, что Microsoft делает так, чтобы им не пришлось “чинить” свои собственные системы. Их внутренние системы широко используют 389, и им не хочется иметь дело со сложностью SSL и сертификатами. Это стандартная практика, и так они справляются с использованием протоколов без шифрования (много такого в мире MS, не только LDAP 389). 636 LDAPS, несмотря на ложную информацию, является безопасным и подходит для неприкосновенных вещей, чтобы продолжать использовать LDAP для поиска и аутентификации без подписи. Пока Microsoft не уничтожит Active Directory… что, кстати, уже “на подходе”. Тогда все будут жаловаться, что это всё, что знают и ожидают большинство в мире Windows. У Microsoft есть ответы, но вам не понравится их решения.

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

Весь мир считает, что CA всех взломали (FUD — страх, неопределенность и сомнения для получения выгоды), и посылает сообщение о том, что все SSL-сертификаты скомпрометированы (это FUD). Выдача сертификатов — крупный бизнес. Запуск собственного CA с долгим сроком действия и сертификацией — это способ заработать деньги на важнейших людях. Может, это и политика/жадность. И, конечно, как единственно правильный ответ, предлагают перейти в облако Microsoft и использовать “современную аутентификацию”, которая зачастую требует платить Microsoft.

Подробнее (просто потому что)

Идея Microsoft — избавиться от паролей. Но они еще не готовы, так как устоявшиеся протоколы, такие как файловое и печатное обслуживание, все еще используют NTLMv2 и пароли (это лишь пример, RDP тоже). В прошлом (сейчас) пароли позволяли неучастникам домена получать доступ. Даже если использовалась учетная запись домена, она не проходила через билеты (Kerberos). Сейчас они пытаются создать Kerberos-облако, которое сначала обеспечивает доверие (любишь Microsoft — платишь), а потом “что угодно” как иностранный кандидат может получить “билет” для доверия. Это Leveraging the fact that we love Microsoft and are paying for cloud services… кстати, да, очень связаны с интернетом.

Мир без паролей есть и вне Microsoft, просто Microsoft обычно не хочет использовать эти технологии в своих проприетарных решениях (чтобы зарабатывать деньги).

Microsoft живет в мире “больших корпораций”, где каждая компания хочет зарабатывать много денег. Кто-то должен быть королем, и это хочет Microsoft. Всё это работает (они уже на этом пути).

Больше, чем хотелось бы знать. Готовьтесь к миру с очень высокой задержкой, полностью зависимому от интернета и облака Microsoft.

Я не знаю этого продукта в частности, но обычно при использовании LDAPS с внутренним CA нужно либо отключить проверку сертификата (худшее решение), либо настроить SSL-библиотеки клиента доверять сертификату CA (как зависит от программного обеспечения: keystone для Java, доверие системных CA на Windows и Linux, и так далее).

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

Я уже работаю над настройкой собственного внутреннего CA для доверия и попытки использовать LDAPS. Думаю, это более стабильное, надежное решение на данный момент, и оно дает больше гибкости, не будучи полностью перетянутым в облако. Это в процессе, но я надеюсь, что это поможет управлять сложностью и обеспечить больше контроля.

Это (внутренний CA) то, что мы делаем. Мы делаем “больше” — добавляем Subject Alt Names, чтобы подключить все LDAPS через 4 контроллера домена (2 локально, 2 в дата-центре) под балансировщик.

Спасибо за помощь. Сейчас я завершаю настройку моего внутреннего CA для установки его на сайт iTop, но у меня есть вопрос: достаточно ли включить HTTPS, или нужно что-то еще настроить, потому что я считаю, что iTop также требует TLS? Нужно ли просто указать путь к сертификату или есть что-то еще?

Ну, раскрывать пароли по сети — это никогда не хорошая идея. Так что я бы сказал “да”, стоит зашифровать интерфейсы, используемые для передачи паролей от клиентов. Но… технически, я бы не подумал, что это обязательно. Просто учтите, что любой начинающий хакер сможет украсть ваши пароли, если вы этого не сделаете.

И сегодня, хотя есть идиоты, большинство успешных атак начинаются изнутри вашей сети, а не потому, что кто-то бродит по периметру. Проще вынудить “незрелого” сотрудника сделать что-то злоумышленное, чтобы установить первый контакт для дальнейшего взлома.