PHP connect via SSH tunnel to LDAP in other network
Asked Answered
V

4

10

I'm developing website for my school. In that school we authenticate users via LDAP, so there was an idea to do the same via school-site. On that site everything is working perfectly, but during developing I need very often to test if such solution works, of not. In order not to commit my changes so often I want to test this site on my local computer, but for connecting with LDAP i want to use ssh tunnel. In school network we have one server through witch we are connecting with inside of our school network. It's address is phoenix.lo5.bielsko.pl. Inside this network we have LDAP server with opened 389 and 636 ports. It's address is auth.lo5. I don't have access to auth.lo5 via SSH, I can only connect with it to get some LDAP entries. So, I've tried to run SSH tunnel by running:

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

Then, I've set in my /etc/hosts that auth.lo5 is pointing to 127.0.0.1. I'm connecting to LDAP in PHP in such a way:

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

But I'm getting error Can't contact LDAP server. I think, that problem might be on phoenix.lo5.bielsko.pl in its SSH daemon config or in arguments passed to ldap_connect() function. Can you tell me, what should I set in sshd_config or in arguments passed to ldap_connect to get it working?

I posted the same question in similar thread, but no one has answered my question.

P.S. In my /etc/ssh/sshd_config I have line AllowTcpForwarding yes

Vizor answered 25/7, 2010 at 13:10 Comment(3)
If you use the LDAP command-line tools, do they work? Try using ldapwhoami -H ldaps://auth.lo5 first - PHP doesn't report as many helpful messages as the command-line LDAP utilities.Lananna
@Borealid, our LDAP server don't allow to bind anonymously, so I've typed ldapwhoami -D cn=lo5-www,ou=services,dc=auth,dc=lo5 -W -H ldaps://auth.lo5 and on phoenix answer is dn:cn=lo5-www,ou=services,dc=auth,dc=lo5, but on my desktop its ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)Vizor
Until the command-line tools work, your SSH tunnel isn't up. Since the command you're using is spot-on (and, honestly, I'm impressed you know how to do this - SSH tunneling is complicated!), I only have one more suggestion. Try using an unprivileged port (higher than 1024) for the local port (as in, ssh -L 9999:auth.lo5.bielsko.pl:636). Also specify a FQDN! Still, test with the command-line tools. And make sure they work from phoenix.lo5 to auth.lo5!Lananna
B
1

If I got it right phoenix.lo5 and auth.lo5 are 2 different machines. If so you have to create a tunnel to the ssh machine, and then send the ldap queries to the right machine.

Your command: ssh -L 636:auth.lo5:636 [email protected] is right if phoenix.lo5.bielsko.pl can resolve auth.lo5 via DNS or /etc/hosts, if not you need to use its internal ip address.

Also if you want to use port 636 on your pc, you need to run your command as superuser (root or with sudo) else you need to use an high port (above 1024) as stated by Borealid

Once the tunnel is up you have to point to localhost to do the queries

Bonnard answered 26/7, 2010 at 18:54 Comment(2)
Of course phoenix and auth are different machines and we use our DNS to resolve its names. I think, addresses aren't real problem here. I've used tcpdump to check if there are real connection through tunnel and if ldapwhoami is sending packets correctly. The result was confusing: local =[tunnel]=> phoenix => auth (LDAP querying) => phoenix =[tunnel]=> local, so I think, that ldapwhoami should give right answer, but I get error ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1). I have sudo on phoenix so ports under 1024 are not problem, I think. Don't you think its weird?Vizor
I'm bumping into this same issue. My current thought is that the SSL handshake is failing. I tried using a local /etc/hosts entry to fake out the hostname, but that hasn't worked out yet.Exponent
E
1

I ran into this same issue. Running with -d1 showed me this error:

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

Could be you're hitting a similar problem.

I was able to fake it out by running:

sudo hostname someserver.mydomain.com

which caused SSL to assume it was talking to the right host.

Exponent answered 13/1, 2015 at 21:43 Comment(0)
O
1

I was also getting the error hostname (mylaptop.local) does not match common name in certificate (*.mydomain.com). However I did not want to edit the hostname of my machine to match that of the LDAP server. Instead I edited the hosts file (etc/hosts on linux) file to add a line that would intercept requests to the LDAP server eg:

127.0.0.1 ldap.server.com

This has the added benefit of not requiring you to change which server name you are trying to connect to in your code, you only need to change the port number if you chose a different port.

October answered 16/9, 2019 at 16:52 Comment(0)
S
0

Try replacing all instances of auth.lo5 with localhost:

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

If that doesn't work, try turning off SSL to see if that works:

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

Suez answered 25/7, 2010 at 15:43 Comment(1)
Both solutions aren't working. I think, it shouldn't be localhost in ssh commands, because LDAP server is reachable for phoenix not by 'localhost' but 'auth.lo5'. 'localhost' points to phoenix. Maybe I have to put something to my client or server ssh-configs?Vizor

© 2022 - 2024 — McMap. All rights reserved.