Я постараюсь включить как можно больше деталей, но рассмотрим следующую ситуацию:
Что касается конфиденциальности, допустим, у меня есть инфраструктура Active Directory, подобная следующей:
microsoft.com
и некоторые дочерние домены:
csharp.microsoft.com
vb.microsoft.com
Все учетные записи пользователей хранятся на microsoft.com.
Я начинаю свой код со следующего:
import ldap
ldap.set_option(ldap.OPT_REFERRALS,0)
ldap.set_option(ldap.OPT_X_TLS_REQUIRE_CERT,ldap.OPT_X_TLS_NEVER)
(я знаю, что, вероятно, у меня должен быть сертификат для домена, но что вы можете сделать)
Затем я устанавливаю соединение следующим образом:
conn = ldap.initialize("ldaps://microsoft.com:636")
conn.simple_bind_s("user","pass")
В моем скрипте я ищу учетную запись пользователя и использую следующий поиск:
result_id = conn.search("DC=microsoft,DC=com",
ldap.SCOPE_SUBTREE,
"(&(CN=gates)(!(objectClass=contact)))",
None)
result_type,result_data = conn.result(result_id,0)
Хорошо, отлично, это работает .... большую часть времени.
Когда это работает, я получаю что-то такое:
[("CN=gates,OU=Users,DC=microsoft,DC=com", {'sAMAccountName':['gates']}])
Однако, на первый взгляд кажется, что я получу следующие результаты:
[(None, ['ldaps://csharp.microsoft.com/DC=csharp,DC=microsoft,DC=com'])]
Хотя результат имеет смысл - Гейтс не существует на csharp.microsoft.com, он существует на microsoft.com DC - он все еще очень озадачивает, потому что у меня сложилось впечатление, что использование параметра OPT_REFERRALS в 0 скажет модуль Python LDAP НЕ использовать рефералов.
Чтобы сделать вещи более интересными, я также иногда получаю следующие результаты:
[(None, ['ldaps://ForestDnsZones.microsoft.com/DC=ForestDnsZones,DC=microsoft,DC=com'])]
Итак, мой вопрос - я что-то не так делаю?
Кроме того, было предложено, что если я использую путь поиска, такой как «OU = Users, DC = microsoft, DC = com» вместо простого поиска в корне («DC = microsoft, DC = com»), то Клиентский модуль LDAP не будет пытаться использовать рефералов - это точно?
Редактировать
Проблема оказалась не в LDAP, а в неправильной конфигурации WSGI.
Использование WSGIDaemonProcess решило проблему перекрестного загрязнения, с которой мы столкнулись.