views:

612

answers:

2

I have a django application hosted on webfaction which now has a static/private ip.

Our network in the office is obviously behind a firewall and the AD server is running behind this firewall. From inside the network i can authenticate using python-ldap with the AD's internal IP address and the port 389 and all works well.

When i move this to the hosted webserver i change the ip address and port that has been openend up on our firewall. For simplicity the port we opened up is 389 however the requests to authenticate always timeout. When logged into webfaction and running python from the shell and querying the ipaddress i get webfactional's general ip address rather than my static ip.

Is this whats happening when i try and auth in django? the request comes from the underlying ip address that python is running on rather than the static ip that my firewall is expecting?

Im fairly clueless to all this networking and port mapping so any help would be much appreciated!

Hope that makes sense?

A: 

There are quite a few components between your hosted django application and your internal AD. You will need to test each to see if everything in the pathways between them is correct.

So your AD server is sitting behind your firewall. Your firewall has ip "a.b.c.d" and all traffic to the firewall ip on port 389 is forwarded to the AD server. I would recommend that you change this to a higher more random port on your firewall, btw. Less scans there.

With the shell access you can test to see if you can reach your network. Have your firewall admin check the firewall logs while you try one of the following (or something similar with python) :

  • check the route to your firewall (this might not work if webfaction blocks this, otherwise you will see a list of hosts along which your traffic will pass - if there is a firewall on the route somewhere you will see that your connection is lost there as this is dropped by default on most firewalls):

    tracert a.b.c.d

  • do a telnet to your firewall ip on port 389 (the telnet test will allow your firewall admin to see the connection attempts coming in on port 389 in his log. If those do arrive, that means that external comm should work fine):

    telnet a.b.c.d 389

Similarly, you need to check that your AD server receives these requests (check your logs) and as well can respond to them. Perhaps your AD server is not set up to talk to the firewall ?

Alex Boschmans
+1  A: 

I would recommend against opening the port on the firewall directly to LDAP. Instead I would suggest making an SSH tunnel. This will put the necessary encryptionn around the LDAP traffic. Here is an example.

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

This assumes that the ssh server is running on port 22 of your ldap server, and is accessible from your web host. It will create a tunnel from port 389 on the ldap server to port 2222 on the web host. Then, you configure your django application on the web host to think that the LDAP server is running on localhost port 2222.

Apreche