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

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

0 голосов
/ 13 июня 2009

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

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

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

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

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

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

Ответы [ 2 ]

3 голосов
/ 14 июня 2009

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

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

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

0 голосов
/ 14 июня 2009

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

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

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

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

    tracert a.b.c.d

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

    telnet a.b.c.d 389

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

...