2010-07-25 18 views
8

Sto sviluppando un sito Web per la mia scuola. In quella scuola autenticiamo gli utenti tramite LDAP, quindi c'era un'idea di fare lo stesso tramite il sito della scuola. Su quel sito tutto funziona perfettamente, ma durante lo sviluppo ho bisogno molto spesso di verificare se tale soluzione funziona, di no. Per non impegnare le mie modifiche così spesso voglio testare questo sito sul mio computer locale, ma per collegarmi con LDAP voglio usare ssh tunnel. Nella rete scolastica abbiamo un server attraverso il quale ci stiamo connettendo all'interno della nostra rete scolastica. L'indirizzo è phoenix.lo5.bielsko.pl. All'interno di questa rete abbiamo un server LDAP con porte aperte 389 e 636. Il suo indirizzo è auth.lo5. Non ho accesso a auth.lo5 tramite SSH, posso solo collegarmi con esso per ottenere alcune voci LDAP. Così, ho provato a correre tunnel SSH eseguendo:PHP connettersi tramite il tunnel SSH a LDAP in un'altra rete

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

Poi, ho impostato nel mio /etc/hosts che auth.lo5 sta indicando 127.0.0.1. Sto connessione a LDAP in PHP in modo tale:

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

Ma io sto ottenendo l'errore Can't contact LDAP server. Penso che quel problema potrebbe essere su phoenix.lo5.bielsko.pl nella sua configurazione daemon SSH o negli argomenti passati alla funzione ldap_connect(). Puoi dirmi cosa devo impostare in sshd_config o negli argomenti passati a ldap_connect per farlo funzionare?

ho postato la stessa domanda in similar thread, ma nessuno ha risposto alla mia domanda.

P.S. Nel mio /etc/ssh/sshd_config ho linea AllowTcpForwarding yes

+0

Se si utilizzano gli strumenti da riga di comando LDAP, funzionano? Prova a usare 'ldapwhoami -H ldaps: // auth.lo5' prima - PHP non riporta tanti messaggi utili come i programmi di utilità LDAP da riga di comando. – Borealid

+0

@Borealid, il nostro server LDAP non consente il binding in modo anonimo, quindi ho digitato 'ldapwhoami -D cn = lo5-www, ou = services, dc = auth, dc = lo5 -W -H ldaps: // auth .lo5' e su phoenix la risposta è 'dn: cn = lo5-www, ou = services, dc = auth, dc = lo5', ma sul mio desktop è' ldap_sasl_bind (SEMPLICE): Impossibile contattare il server LDAP (-1) ' – Hfaua

+1

Fino a quando gli strumenti della riga di comando non funzionano, il tunnel SSH non è attivo. Dato che il comando che stai usando è azzeccato (e, onestamente, sono * impressionato * sai come farlo - il tunneling SSH è complicato!), Ho solo un altro suggerimento. Prova a utilizzare una porta non privilegiata (superiore a 1024) per la porta locale (come in, 'ssh -L 9999: auth.lo5.bielsko.pl: 636'). Specifica anche un FQDN! Ancora, prova con gli strumenti da riga di comando. E assicurati che funzionino da phoenix.lo5 a auth.lo5! – Borealid

risposta

0

Provare a sostituire tutte le istanze di auth.lo5 con localhost:

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

Se questo non funziona, provare a disattivare SSL per vedere se funziona:

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

+0

Entrambe le soluzioni non funzionano. Penso che non dovrebbe essere localhost nei comandi ssh, perché il server LDAP è raggiungibile da phoenix non da 'localhost' ma 'auth.lo5'. 'localhost' punta a Phoenix. Forse devo mettere qualcosa al mio client o server ssh-configs? – Hfaua

1

Se ho capito bene phoenix.lo5 e auth.lo5 sono 2 macchine diverse. Se è così, è necessario creare un tunnel per la macchina ssh, quindi inviare le query ldap alla macchina corretta.

Il tuo comando: ssh -L 636:auth.lo5:636 [email protected] è corretto se phoenix.lo5.bielsko.pl può risolvere auth.lo5 tramite DNS o/etc/hosts, se non è necessario utilizzare il suo indirizzo IP interno.

Inoltre, se si desidera utilizzare la porta 636 sul vostro pc, è necessario eseguire il comando come superutente (root o con sudo) altrimenti è necessario utilizzare una porta alta (sopra 1024) come affermato da Borealid

Una volta che il tunnel è attivo si deve puntare a localhost di fare le query

+0

Ovviamente 'phoenix' e' auth' sono macchine diverse e usiamo il nostro DNS per risolvere i suoi nomi. Penso che gli indirizzi non siano un problema reale qui. Ho usato 'tcpdump' per verificare se ci sono collegamenti reali attraverso tunnel e se' ldapwhoami' sta inviando i pacchetti correttamente. Il risultato è stato confuso: 'local = [tunnel] => phoenix => auth (query LDAP) => phoenix = [tunnel] => local', quindi penso che' ldapwhoami' dovrebbe dare la risposta giusta, ma ottengo errore 'ldap_sasl_bind (SEMPLICE): Impossibile contattare il server LDAP (-1)'. Ho sudo su phoenix, quindi le porte sotto i 1024 non sono un problema, penso. Non pensi che sia strano? – Hfaua

+0

Sono imbattuto in questo stesso problema. Il mio attuale pensiero è che l'handshake SSL stia fallendo. Ho provato ad usare una voce locale/etc/hosts per cancellare il nome host, ma non ha ancora funzionato. –

1

mi sono imbattuto in questo stesso problema. Correndo con -d1 mi ha mostrato questo errore:

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

Potrebbe essere si sta colpendo un problema simile.

sono stato in grado di falsificare fuori eseguendo:

sudo hostname someserver.mydomain.com

che ha causato SSL per scontato che stava parlando con l'host destra.

Problemi correlati