Аутентификация Python LDAP с удаленного веб-сервера

У меня есть приложение django, размещенное на веб-сайте, которое теперь имеет статический/частный IP-адрес.

Наша сеть в офисе, очевидно, находится за брандмауэром, и сервер AD работает за этим брандмауэром. Изнутри сети я могу аутентифицироваться с помощью python-ldap с внутренним IP-адресом AD и портом 389, и все работает хорошо.

Когда я перемещаю это на размещенный веб-сервер, я меняю IP-адрес и порт, которые были открыты на нашем брандмауэре. Для простоты мы открыли порт 389, однако запросы на аутентификацию всегда истекают. При входе в веб-фракцию и запуске python из оболочки и запросе IP-адреса я получаю общий IP-адрес веб-фракции, а не свой статический IP-адрес.

Это то, что происходит, когда я пытаюсь авторизоваться в django? запрос исходит от базового IP-адреса, на котором работает python, а не от статического IP-адреса, который ожидает мой брандмауэр?

Я довольно невежественен во всей этой сети и сопоставлении портов, поэтому любая помощь будет высоко оценена!

Надеюсь, это имеет смысл?


python active-directory ldap webserver
person Community    schedule 13.06.2009    source источник
comment
Мы очень успешно используем удаленный LDAP и django, поэтому, если он работает локально в режиме разработки, у вас, вероятно, есть проблема с сетью/портом, характерная для вашей установки или веб-фракции.   -  person Jarret Hardie    schedule 13.06.2009

Ответы (2)


arrow_upward
3
arrow_downward

Я бы рекомендовал не открывать порт на брандмауэре напрямую для LDAP. Вместо этого я бы предложил сделать туннель SSH. Это обеспечит необходимое шифрование трафика LDAP. Вот пример.

ssh -N -p 22 username@ldapserver -L 2222/localhost/389

Это предполагает, что сервер ssh работает на порту 22 вашего сервера ldap и доступен с вашего веб-хоста. Он создаст туннель от порта 389 на сервере ldap до порта 2222 на веб-узле. Затем вы настраиваете свое приложение django на веб-узле так, чтобы оно думало, что сервер LDAP работает на локальном порту 2222.

person Apreche    schedule 14.06.2009

arrow_upward
0
arrow_downward

Между вашим размещенным приложением django и вашим внутренним AD есть довольно много компонентов. Вам нужно будет проверить каждый, чтобы убедиться, что все в путях между ними правильно.

Итак, ваш сервер AD находится за вашим брандмауэром. Ваш брандмауэр имеет IP-адрес «a.b.c.d», и весь трафик на IP-адрес брандмауэра через порт 389 перенаправляется на сервер AD. Я бы порекомендовал вам изменить это на более высокий и более случайный порт в вашем брандмауэре, кстати. Там меньше сканов.

С доступом к оболочке вы можете проверить, можете ли вы подключиться к своей сети. Попросите администратора брандмауэра проверить журналы брандмауэра, пока вы пытаетесь выполнить одно из следующих действий (или что-то подобное с python):

  • проверьте маршрут до вашего файрвола (это может не сработать, если вебфракция это заблокирует, иначе вы увидите список хостов, по которым будет проходить ваш трафик - если где-то на маршруте есть фаервол вы увидите что ваше соединение там потеряно как это по умолчанию отбрасывается в большинстве брандмауэров):

    tracert a.b.c.d

  • подключитесь через telnet к вашему IP-адресу брандмауэра на порту 389 (тест telnet позволит вашему администратору брандмауэра увидеть попытки подключения, поступающие через порт 389, в его журнале. Если они прибывают, это означает, что внешняя связь должна работать нормально):

    телнет a.b.c.d 389

Точно так же вам нужно убедиться, что ваш сервер AD получает эти запросы (проверьте свои журналы), а также может отвечать на них. Возможно, ваш сервер AD не настроен для взаимодействия с брандмауэром?

person Alex Boschmans    schedule 13.06.2009