2010-07-25 5 views
8

Je développe un site web pour mon école. Dans cette école, nous authentifions les utilisateurs via LDAP, donc il y avait une idée de faire la même chose via le site de l'école. Sur ce site, tout fonctionne parfaitement, mais en cours de développement j'ai souvent besoin de tester si une telle solution fonctionne, ou non. Afin de ne pas commettre mes changements si souvent je veux tester ce site sur mon ordinateur local, mais pour la connexion avec LDAP je veux utiliser le tunnel ssh. Dans le réseau scolaire, nous avons un serveur à travers lequel nous nous connectons avec l'intérieur de notre réseau scolaire. C'est l'adresse phoenix.lo5.bielsko.pl. À l'intérieur de ce réseau, nous avons un serveur LDAP avec 389 et 636 ports ouverts. C'est l'adresse auth.lo5. Je n'ai pas accès à auth.lo5 via SSH, je ne peux me connecter qu'avec lui pour obtenir des entrées LDAP. Alors, je l'ai essayé de courir le tunnel SSH en exécutant:PHP se connecter via un tunnel SSH à LDAP dans un autre réseau

ssh -L 636:auth.lo5:636 [email protected] 

Ensuite, je l'ai mis dans mon /etc/hosts que auth.lo5 pointe vers 127.0.0.1. Je me connecte à LDAP en PHP de telle manière:

ldap_connect('ldaps://auth.lo5', 636); 

Mais je reçois une erreur Can't contact LDAP server. Je pense que ce problème peut être sur phoenix.lo5.bielsko.pl dans sa configuration de démon SSH ou dans les arguments passés à la fonction ldap_connect(). Pouvez-vous me dire, que dois-je définir dans sshd_config ou dans les arguments passés à ldap_connect pour le faire fonctionner?

J'ai posté la même question dans similar thread, mais personne n'a répondu à ma question.

P.S. Dans mon /etc/ssh/sshd_config je ligne AllowTcpForwarding yes

+0

Si vous utilisez les outils de ligne de commande LDAP, fonctionnent-ils? Essayez d'abord d'utiliser 'ldapwhoami -H ldaps: // auth.lo5' - PHP ne signale pas autant de messages utiles que les utilitaires LDAP en ligne de commande. – Borealid

+0

@Borealid, notre serveur LDAP ne permet pas de lier anonymement, donc j'ai tapé 'ldapwhoami -D cn = lo5-www, ou = services, dc = auth, dc = lo5 -W -H ldaps: // auth .lo5' et sur phoenix la réponse est 'dn: cn = lo5-www, ou = services, dc = auth, dc = lo5', mais sur mon bureau son' ldap_sasl_bind (SIMPLE): Impossible de contacter le serveur LDAP (-1) ' – Hfaua

+1

Jusqu'à ce que les outils de ligne de commande fonctionnent, votre tunnel SSH n'est pas en place. Puisque la commande que vous utilisez est sur place (et, honnêtement, je suis * impressionné * vous savez comment faire cela - le tunnelage SSH est compliqué!), Je n'ai qu'une suggestion de plus. Essayez d'utiliser un port non privilégié (supérieur à 1024) pour le port local (comme dans 'ssh -L 9999: auth.lo5.bielsko.pl: 636'). Indiquez également un FQDN! Encore, testez avec les outils de ligne de commande. Et assurez-vous qu'ils travaillent de phoenix.lo5 à auth.lo5! – Borealid

Répondre

0

Essayez de remplacer toutes les instances de auth.lo5 avec localhost:

ssh -L 636:localhost:636 [email protected] et ldap_connect('ldaps://localhost', 636);

Si cela ne fonctionne pas, essayez de désactiver SSL pour voir si cela fonctionne:

ssh -L 389:localhost:389 [email protected] et ldap_connect('localhost', 389);

+0

Les deux solutions ne fonctionnent pas. Je pense que ça ne devrait pas être localhost dans les commandes ssh, car le serveur LDAP est accessible pour phoenix non par 'localhost' mais 'auth.lo5'. 'localhost' pointe vers le phénix. Peut-être que je dois mettre quelque chose à mon client ou serveur ssh-configs? – Hfaua

1

Si je comprends bien phoenix.lo5 et auth.lo5 sont 2 machines différentes. Si c'est le cas, vous devez créer un tunnel vers la machine ssh, puis envoyer les requêtes LDAP à la bonne machine.

Votre commande: ssh -L 636:auth.lo5:636 [email protected] est correcte si phoenix.lo5.bielsko.pl peut résoudre auth.lo5 via DNS ou/etc/hosts, sinon vous devez utiliser son adresse IP interne.

Aussi, si vous souhaitez utiliser le port 636 sur votre PC, vous devez exécuter votre commande en tant que super-utilisateur (root ou avec sudo) que vous devez utiliser un port élevé (supérieur à 1024) comme indiqué par Borealid

Une fois que le tunnel est en place, vous devez pointer vers localhost pour faire les requêtes

+0

Bien sûr 'phoenix' et' auth' sont des machines différentes et nous utilisons notre DNS pour résoudre ses noms. Je pense que les adresses ne sont pas un vrai problème ici. J'ai utilisé 'tcpdump' pour vérifier s'il y a une vraie connexion via le tunnel et si' ldapwhoami' envoie des paquets correctement. Le résultat était confus: 'local = [tunnel] => phoenix => auth (interrogation LDAP) => phoenix = [tunnel] => local', donc je pense que' ldapwhoami' devrait donner une bonne réponse, mais j'ai une erreur 'ldap_sasl_bind (SIMPLE): impossible de contacter le serveur LDAP (-1)'. J'ai sudo sur 'Phoenix 'donc les ports de moins de 1024 ne sont pas un problème, je pense. Tu ne trouves pas que c'est bizarre? – Hfaua

+0

Je me heurte à ce même problème. Ma pensée actuelle est que la négociation SSL échoue. J'ai essayé d'utiliser une entrée locale/etc/hosts pour simuler le nom d'hôte, mais cela n'a pas encore fonctionné. –

1

J'ai rencontré ce même problème. Courir avec -d1 m'a montré cette erreur:

TLS: hostname (mylaptop.local) does not match common name in certificate (*.mydomain.com). TLS reverse lookup of 'localhost' is 'mylaptop.local', checking if that matches the certificate common name

Peut-être vous frappez un problème similaire.

j'ai pu truquer en lançant:

sudo hostname someserver.mydomain.com

qui a causé SSL à supposer qu'il parlait à l'hôte droit.

Questions connexes