Пропадает запись имени участника службы интеграции LDAP Active Directory 2012?

Создание службы Python для запроса атрибутов AD

Я интегрирую нашу AD с веб-службами, работающими на Python в Linux, используя Python-LDAP через SASL (DIGEST-MD5) для запроса атрибутов пользователя AD 2012 (подразделение, отдел, добавочный номер телефона, электронная почта и т. Д.). После отработки специфических особенностей моей службы и AD 2003 я начал сталкиваться с ошибкой SPN для нашего нового AD 2012, когда digest-uri не соответствовал ни одному SPN на сервере. Я сделал перекрестные ссылки на список SPN для обоих серверов, и они содержат идентичные аналоги друг друга.

Ошибка: digest-uri не соответствует ни одному имени участника-службы LDAP, зарегистрированному для этого сервера.

Исправление?

Это было исправлено запуском:

setspn -A ldap/<Domain_Name> <Computer_Name>

Обратите внимание, что создание учетной записи службы не устранило мою ошибку SPN, даже когда была запущена следующая команда:

setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>

simple_bind_s () не требует SPN, sasl_interactive_bind_s () требует SPN

Для моей службы Python-LDAP с помощью sasl_interactive_bind_s () работало только добавление SPN в список SPN локального компьютера. Я также должен отметить, что шаг SPN можно пропустить, если я использую simple_bind_s (), но этот метод отправляет учетные данные в открытом виде, что недопустимо.

Однако я заметил, что запись остается в списке SPN только около минуты, прежде чем исчезнет? Когда я запускаю команду setspn, ошибок нет, журналы событий полностью пусты, нигде нет дубликатов, проверено с помощью -F поиском по всему лесу по базовому dn и ничего. Я добавил и попытался повторно добавить, удалить и переместить SPN от объекта к объекту, чтобы убедиться, что он нигде не прячется, но когда я добавляю объект в любом месте, а затем пытаюсь повторно добавить, он уведомляет меня о дубликате. Так что я очень уверен, что где-то не спрятан дубликат.

Взлом

На данный момент у меня есть запланированная задача, повторно запускающая команду, чтобы сохранить запись в списке, поэтому моя служба будет работать с соответствующим названием «SPN Hack»

cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"

пока я не выясню, почему SPN убирается из списка.

Я не являюсь основным администратором этой конкретной AD, может ли администратор иметь запущенную службу, которая синхронизирует SPN с другой службы в AD, и не знать об этом? Мое звание - веб-разработчик, не для оправдания, а для объяснения моего незнания в вопросах Active Directory. Мне сказали сделать AD главной пользовательской базой данных, и я много читал, но я не могу найти нигде, где у людей возникает проблема с периодической перезаписью или очисткой SPN и ни одной из администраторы хорошо знакомы с SPN вне записей SQLServer.

Зачем мне взлом?

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

Обновить

После разговора с системным администратором он согласился с тем, что создание службы на основе взлома не является решением, поэтому он дал мне разрешение развернуть локальную службу с шифрованием конечных точек, которую я могу использовать для своих целей, результат тот же . Я буду следить за тем, что заставляет SPN очищаться. Локальные привязки не являются проблемой при использовании Python-LDAP, и локальная служба уже запущена и работает примерно через час. К сожалению, я, по сути, оборачиваю функциональность, встроенную в LDAP, но мы делаем то, что должны.