Authentification LDAP Python depuis le serveur Web distant

Question

J'ai une application django hébergée sur webfaction qui a maintenant une adresse IP statique/privée.

Notre réseau dans le bureau est évidemment derrière un pare-feu et le serveur AD est en cours d'exécution derrière ce pare-feu. De l'intérieur du réseau je peux m'authentifier en utilisant python-ldap avec l'adresse IP interne de l'AD et le port 389 et tout fonctionne bien. Lorsque je déplace cela vers le serveur web hébergé, je change l'adresse IP et le port qui a été ouvert sur notre pare-feu. Par souci de simplicité, le port que nous avons ouvert est 389, mais les demandes d'authentification sont toujours expirées. Une fois connecté à webfaction et en exécutant python à partir du shell et en interrogeant l'adresse ip, j'obtiens l'adresse IP générale de webfactional plutôt que mon IP statique.

Est-ce que c'est ce qui se passe quand j'essaie et auth en django? La requête provient de l'adresse IP sous-jacente sur laquelle python s'exécute plutôt que de l'adresse IP statique attendue par mon pare-feu?

Je suis assez désemparé à tout ce réseau et la cartographie des ports, donc toute aide serait très appréciée!

Espérons que cela a du sens?

Answer 1

Il existe un certain nombre de composants entre votre application django hébergée et votre AD interne. Vous devrez tester chacun pour voir si tout dans les voies entre eux est correct.

Votre serveur AD se trouve donc derrière votre pare-feu. Votre pare-feu a l'adresse IP "a.b.c.d" et tout le trafic vers l'adresse IP du pare-feu sur le port 389 est transmis au serveur AD. Je recommanderais que vous changiez ceci à un plus haut port plus aléatoire sur votre mur à l'épreuve du feu, btw. Moins de scans là-bas.

Avec l'accès au shell, vous pouvez tester si vous pouvez atteindre votre réseau. Demandez à votre administrateur de pare-feu, consultez les journaux du pare-feu pendant que vous essayez une des options suivantes (ou quelque chose de similaire avec python):

• vérifier l'itinéraire à votre pare-feu (ce qui ne fonctionne pas si les blocs de webfaction, sinon vous verrez une liste d'hôtes le long de laquelle votre trafic passera - si un pare-feu sur la route quelque part, vous verrez que votre connexion y est perdue car cela est abandonné par défaut sur la plupart des pare-feu):

  tracert abcd

• effectuez un telnet sur votre pare-feu IP sur le port 389 (le test Telnet autorisera votre pare-feu admin pour voir les tentatives de connexion arrivant sur le port 389 dans son journal. Si ceux-ci n'arrivent, cela signifie que comm externe devrait fonctionner correctement):

  telnet ABCD 389

De même, vous devez vérifier que votre serveur AD reçoit ces demandes (vérifiez vos journaux) et ainsi peut y répondre. Peut-être votre serveur AD n'est pas configuré pour parler au pare-feu?

Answer 2

Je recommande d'ouvrir le port sur le pare-feu directement à LDAP. Au lieu de cela, je suggère de faire un tunnel SSH. Cela mettra le chiffrement nécessaire autour du trafic LDAP. Voici un exemple.

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

Cela suppose que le serveur ssh est en cours d'exécution sur le port 22 de votre serveur ldap, et est accessible depuis votre hébergeur.Il créera un tunnel entre le port 389 sur le serveur LDAP et le port 2222 sur l'hôte Web. Ensuite, vous configurez votre application django sur l'hôte Web pour penser que le serveur LDAP est en cours d'exécution sur le port localhost 2222.