Je développe un site web pour mon école. Dans cette école, nous authentifions les utilisateurs via LDAP, il y avait donc une idée de faire la même chose via un site scolaire. Sur ce site, tout fonctionne parfaitement, mais pendant le développement, j'ai besoin très souvent de tester si une telle solution fonctionne, de pas. Afin de ne pas valider mes modifications si souvent, je souhaite tester ce site sur mon ordinateur local, mais pour vous connecter à LDAP, je souhaite utiliser un tunnel SSH. Dans le réseau scolaire, nous avons un serveur à travers la sorcière que nous connectons à l'intérieur de notre réseau scolaire. Il est adresse est alors, j'ai défini dans mon mais je reçois une erreur J'ai posté la même question dans Similar thread , mais personne n'a répondu à ma question. PS Dans mon phoenix.lo5.bielelsko.pl . Dans ce réseau, nous avons le serveur LDAP avec des ports 389 et 636 ouverts. L'adresse est auth.lo5 . Je n'ai pas accès à auth.lo5 via SSH, je ne peux que la connecter à cela pour obtenir des entrées LDAP. Donc, j'ai essayé d'exécuter un tunnel SSH en exécutant: / etc. hôtes que auth.lo5 est pointé vers 127.0.0.1 . Je me connecte à LDAP en PHP de telle manière: ne peut pas contacter LDAP Server . Je pense que ce problème pourrait être sur phoenix.lo5.bielsko.pl dans sa configuration de démon SSH ou dans des arguments passés à ldap_connect () fonction. Pouvez-vous me dire, que dois-je définir dans sshd_config ou dans des arguments passés à ldap_connect pour le faire fonctionner? / etc / ssh / sshd_config J'ai la ligne allowtcpforwarding OUI
4 Réponses :
Essayez de remplacer toutes les instances de Si cela ne fonctionne pas, essayez de désactiver SSL pour voir si cela fonctionne:
auth.lo5 avec localhost:
ssh -l 636: localhost: 636 hfaua@phoenix.lo5.bielsko.pl
et
ldap_connect ('ldaps: // localhost', 636);
ssh -l 389: localhost: 389 hfaua@phoenix.lo5.bielsko.pl
et
ldap_connect ('localhost', 389);
Les deux solutions ne fonctionnent pas. Je pense que cela ne devrait pas être localhost dans les commandes SSH, car LDAP Server est accessible pour Phoenix non par 'localhost' mais 'auth.lo5'. "localhost" pointe vers Phoenix. Peut-être que je dois mettre quelque chose sur mon client ou mon serveur ssh-configs?
Si je l'ai eu droit Phoenix.lo5 et auth.LO5 sont 2 machines différentes. Si vous devez créer un tunnel sur la machine SSH, puis envoyez les requêtes LDAP à la machine à droite.
Votre commande: Également si vous souhaitez utiliser le port 636 sur votre PC, vous devez exécuter votre commande en tant que superutilisateur (root ou sudo) d'autre que vous devez utiliser un port élevé (ci-dessus 1024), comme indiqué par Borealid
Une fois que le tunnel est en place, vous devez indiquer localhost pour faire les requêtes ssh -l 636: auth.lo5: 636 hfaua@phoenix.lo5.bielsko.pl est juste si phoenix.lo5.bielsko.pl peut résoudre auth.lo5 via DNS ou / etc / hosts, sinon vous devez utiliser son adresse IP interne.
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 existe une réelle connexion via tunnel et si ldapwhoami envoie correctement les paquets. Le résultat était déroutant: local = [tunnel] => phoenix => auth (requête LDAP) => phoenix = [tunnel] => local , donc je pense que ldapwhoami devrait donner une bonne réponse, mais je reçois une erreur ldap_sasl_bind (simple): impossible de contacter le serveur LDAP (-1) . J'ai sudo sur phoenix afin que les ports de moins de 1024 ne sont pas un problème, je pense. Tu ne penses pas que c'est bizarre?
Je chante dans ce même problème. Ma pensée actuelle est que la poignée de main SSL échoue. J'ai essayé d'utiliser une entrée locale / etc / hôte pour simuler le nom d'hôte, mais cela n'a pas encore travaillé.
J'ai couru dans ce même problème. Exécution avec pourrait être que vous frappez un problème similaire.
J'ai pu le simuler en courant:
qui a provoqué que SSL suppose qu'il parlait à l'hôte droit. -D1 m'a montré cette erreur:
TLS: nom d'hôte (mylaptop.local) ne correspond pas à un nom commun dans le certificat (* .MyDomain.com).
TLS Reverse Recherche de 'localhost' est 'mylaptop.local', vérifiant si cela correspond au nom commun de certificat
sudo hôtename somreserver.mydomain.com
Je reçois aussi l'erreur ceci a ajouté Avantage de ne pas nécessiter de changer quel nom de serveur vous essayez de vous connecter dans votre code, il vous suffit de modifier le numéro de port si vous avez choisi un autre port. hostname (mylaptop.local) ne correspond pas à un nom commun dans le certificat (* .MyDomain.com) . Cependant, je ne voulais pas modifier le nom d'hôte de ma machine pour correspondre à celle du serveur LDAP. Au lieu de cela, j'ai édité le fichier d'hôtes ( etc / hosts sur linux) pour ajouter une ligne qui intercepterait des demandes d'interception au serveur LDAP, par exemple:
Si vous utilisez les outils de ligne de commande LDAP, fonctionnent-ils? Essayez d'utiliser
ldapwhoami -h ldaps: //auth.lo5 Premier - PHP ne signalez pas autant de messages utiles que les utilitaires LDAP de ligne de commande.@Borealid, notre serveur LDAP ne permet pas de se lier anonymement, donc j'ai dactylographié
ldapwhoami -d cn = lo5-www, ou = services, dc = auth, dc = lo5 -w -h ldaps: // auth.lo5 et sur phoenix réponse estdn: cn = lo5-www, ou = services, dc = auth, dc = lo5 , mais sur mon bureau sonldap_sasl_bind (simple ): Impossible de contacter le serveur LDAP (-1)Jusqu'à ce que les outils de commande de commande fonctionnent, votre tunnel SSH n'est pas debout. Depuis que la commande que vous utilisez est SPOT-ON (et, honnêtement, je suis impressionné vous savez comment faire cela - SSH Tunneling est compliqué!), Je n'ai qu'une autre suggestion. 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 ). Spécifiez également un FQDN! Néanmoins, testez avec les outils de ligne de commande. Et assurez-vous qu'ils travaillent de Phoenix.LO5 à Auth.LO5!