LDAP su SSL / TLS che funziona per tutto, ma il login su Ubuntu

Ho ottenuto OpenLDAP con SSL che lavora su una casella di prova con un certificato firmato. Posso utilizzare uno strumento LDAP in una casella di Windows per visualizzare LDAP over SSL (port 636). Ma quando eseguo dpkg-reconfigure ldap-auth-config per impostare il mio login locale per utilizzare ldaps, il mio login sotto un nome utente nella directory non funziona. Se cambio la configuration per usare semplicemente ldap (port 389) funziona bene (posso accedere sotto un nome utente nella directory). Quando la sua configuration per ldaps ottiene Auth.log mostra:

 Sep 5 13:48:27 boromir sshd[13453]: pam_ldap: ldap_simple_bind Can't contact LDAP server Sep 5 13:48:27 boromir sshd[13453]: pam_ldap: reconnecting to LDAP server... Sep 5 13:48:27 boromir sshd[13453]: pam_ldap: ldap_simple_bind Can't contact LDAP server 

Fornirò tutto ciò che serve. Non sono sicuro di cosa altro includere.

  • Richiedi TLS su RDP per tutte le connessioni
  • rilevare la crittografia debole e i protocolli obsoleti
  • Imansible disabilitare RC4
  • C'è un equivalente al test SSL SSLLabs per SSL / TLS che non è HTTPS?
  • Se ricevo un certificato firmato per ECDSA, i browser più vecchi saranno in grado di utilizzare RSA?
  • Può nginx utilizzare protocolli diversi per diversi blocchi di server?
  • openvpn, opzione tls-cipher non funzionante, nessuna cifra condivisa
  • Errore OpenVPN: Errore TLS: le chiavi TLS locali / remote non sono sincronizzate:
  • 4 Solutions collect form web for “LDAP su SSL / TLS che funziona per tutto, ma il login su Ubuntu”

    Sospetto che tu utilizzi "ldaps: // server /" per il tuo URI quando hai bisogno di qualcosa come "ldaps: // server: 636 /".

    Senza specificare la port, il suo tentativo di tentare TLS tramite la port 389.

    sshd utilizza la separazione privilegiata e le chroot. Questo potrebbe interagire male con qualcosa nella pila necessaria per triggersre SSL e verificare i certificati.

    Provare a distriggersre PrivilegeSeparation temporaneamente; è una ctriggers idea di eseguire così, ma se risolve il problema allora sai quale area da indagare.

    Beh, è ​​un problema TLS. Basta disabilitare il controllo di slapd sul lato client. TLS_ReqCert è impostato per default su "richiesta" sul client; cambiarlo in "mai". Ciò rende il vostro cliente fiducia dello slapd e, a sua volta, faccia una connessione dopo la stretta di mano di tsl.

    Ciao Anche se il tuo sistema funziona con la port 389 TLS potrebbe ancora essere in su, perché openLDAP potrebbe essere crittografare i dati e l'invio oltre 389. Potresti controllare questo.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.