Создание службы 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>
Обратите внимание, что создание учетной записи службы не исправило мою ошибку имени участника-службы даже при выполнении следующей команды:
setspn -A ldap/<Domain_Name> <Domain_Name>/<Service_Account_Name>
simple_bind_s () не требует SPN, sasl_interactive_bind_s () требует SPN
Только добавление имени участника-службы в список имен SPN локальной машины работало для моей службы Python-LDAP с использованием sasl_interactive_bind_s (). Я также должен отметить, что шаг SPN можно пропустить, если я использую simple_bind_s (), но этот метод отправляет учетные данные в открытом тексте, что недопустимо.
Однако я заметил, что запись остается в списке SPN только около минуты, прежде чем исчезнуть? Когда я запускаю команду setspn, ошибок нет, журналы событий полностью пусты, нигде нет дубликатов, проверено с помощью поиска -F по всему лесу на базе dn и ничего. Я добавил и попытался повторно добавить, удалить и переместить имя участника-службы из объекта в объект, чтобы убедиться, что он нигде не скрывается, но когда я добавляю объект куда-либо, а затем пытаюсь повторно добавить его, уведомляет меня о дубликате. Поэтому я очень уверен, что где-то не спрятан дубликат.
Взломать
На данный момент у меня есть запланированное задание, повторно запускающее команду, чтобы сохранить запись в списке, чтобы моя служба работала точно под названием «SPN Hack».
cmd.exe /C "setspn -A ldap/<Domain_Name> <Computer_Name>"
пока я не смогу выяснить, почему SPN удаляется из списка.
Я не являюсь основным администратором этой конкретной AD, может ли администратор запустить службу, которая синхронизирует SPN с другой службой в AD, и не знать об этом? Меня зовут Веб-разработчик, но не для оправдания, а для объяснения моего невежества в вопросах Active Directory. Мне сказали сделать AD основной пользовательской БД, и я много читаю, но я не могу найти нигде, где у людей бывают проблемы с перезаписью или очисткой имени участника-службы, и ни один из Администраторы хорошо знакомы с SPN вне записей SQLServer.
Зачем мне взломать?
Пока что мой хак не вызвал каких-либо проблем для каких-либо пользователей или служб и не вызвал никаких ошибок, поэтому администратор сказал, что он просто запустит его, и я буду продолжать поиск. Но затем я попадаю в опасную ситуацию написания сервиса, реализация которого построена, по сути, на хроне / дрожи cron ... Итак, любая помощь будет принята с благодарностью.
Обновить
После разговора с системным администратором он согласился, что создание службы поверх хака не является решением, поэтому он дал мне разрешение развернуть локальную службу с шифрованием конечной точки, которую я могу использовать для своих целей, результат тот же , Я буду следить за тем, что приводит к очистке SPN. Локальное связывание не является проблемой при использовании Python-LDAP, и локальный сервис уже запущен и работает только через час или около того. К сожалению, я по сути обертываю функциональность, встроенную в LDAP, но мы делаем то, что должны.
