bonjour a tous :)
alors voila j'ai mis en place un serveur ldap pour authentification pour des connexions ssh
selon son compte on a droit a ce connecter sur tel ou tel serveur.
Ca marchait bien jusqu'a ce que j'essaye de tout faire fonctionner en tls donc toujours sur le port 389 d'apres ce que j'ai pu voir a droit a gauche.
quand je lance mon serveur ldap (log ldap):
[code]May 26 16:51:00 srvtest3 slapd[11794]: @(#) $OpenLDAP: slapd 2.3.27 (Jun 27 2007 08:48:26) $ brewbuilder@ls20-bc1-13.build.redhat.com:/builddir/bui
ld/BUILD/openldap-2.3.27/openldap-2.3.27/build-servers/servers/slapd
May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server
May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: could not search LDAP server - Server is unavailable
May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server
May 26 16:51:00 srvtest3 slapd[11794]: nss_ldap: could not search LDAP server - Server is unavailable
May 26 16:51:00 srvtest3 slapd[11794]: /etc/openldap/slapd.conf: line 34: rootdn is always granted unlimited privileges.
May 26 16:51:00 srvtest3 slapd[11794]: /etc/openldap/slapd.conf: line 40: rootdn is always granted unlimited privileges.
May 26 16:51:01 srvtest3 slapd[11795]: bdb_db_open: dc=mh,dc=org
May 26 16:51:01 srvtest3 slapd[11795]: slapd starting[/code]
/etc/openldap/ldap.conf :
[code]host 127.0.0.1
port 389
base dc=mh,dc=org
uri ldap://srvtest3.test.org
ldap_version 3
TLS_REQCERT allow[/code]
/etc/ldap.conf
[code]# TLS
ssl start_tls
ssl on
Afin que le client puisse valider l'identitéu serveur, on doit le fournir la cléublique
du CA avec laquelle il pourra éblir que le certificat du serveur a bien é signéar
la clérivéde cette mê CA.
TLS_CACERT /usr/local/ssl/certs/ldap.crt
On demande élement au client de toujours valider l'identitéu serveur.
TLS_REQCERT demand
IP du serveur ldap
host srvtest3.test.org
Le DN de base pour effectuer les recherche
base dc=mh,dc=org
Optimisation de recherche dans la base
scope=one
Pour que le poste demarre meme si le server ldap ne repond pas
bind_policy soft
Version du protocole utilise
ldap_version 3
Port ecoute serveur
port 389
Filtres de validation dun utilisateur
pam_filter objectclass=account
pam_filter host=srvtest3.test.org
Attribut compare avec lindentifiant de connexion de lutilisateur
pam_login_attribute uid
Verification attribut host
pam_check_host_attr yes
DN groupe auquel il faut appartenir pour acces machine locale
pam_groupdn ou=group,dc=mh,dc=org
Definit lattribut dappartenance au groupe
pam_member_attribute member
password envoi serveur
pam_password crypt
Parametres nss-ldap de recherche
nss_base_passwd ou=user,dc=mh,dc=org?sub
nss_base_shadow ou=user,dc=mh,dc=org?sub
nss_base_group ou=group,dc=mh,dc=org?sub
nss_base_hosts ou=machines,dc=mh,dc=org?sub[/code]
quand j'essaye de me connecter en ssh avec un user ldap qui a bien les droit dans l'annuaire il reste bloqué ici :
[code]ssh videl@192.168.2.217
videl@192.168.2.217's password:[/code]
et les log du serveur 192.168.2.217 :
[code]May 26 16:53:40 srvtest3 sshd[11808]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server
May 26 16:53:40 srvtest3 sshd[11808]: nss_ldap: could not search LDAP server - Server is unavailable
May 26 16:53:40 srvtest3 sshd[11808]: Invalid user videl from 192.168.1.111
May 26 16:53:40 srvtest3 sshd[11809]: input_userauth_request: invalid user videl
May 26 16:53:46 srvtest3 sshd[11808]: nss_ldap: failed to bind to LDAP server ldap://srvtest3.test.org: Can't contact LDAP server
May 26 16:53:46 srvtest3 sshd[11808]: nss_ldap: could not search LDAP server - Server is unavailable
May 26 16:53:46 srvtest3 sshd[11808]: pam_unix(sshd:auth): check pass; user unknown
May 26 16:53:46 srvtest3 sshd[11808]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.1.111[/code]
si qqu a deja fait ce genre de chose je veux bien un ptit coup de main :)
merci d'avance
# port TLS LDAP
Posté par NeoX . Évalué à 1.
mais je me trompe peut-etre
[^] # Re: port TLS LDAP
Posté par Obsidian . Évalué à 2.
Oui, enfin en partie.
La man page stipule que l'une des grandes particuliarités du passage de SSL à TLS est l'utilisation (par défaut) du même port de communication.
# LDAP puis TLS puis NSS
Posté par Obsidian . Évalué à 2.
D'autre part, le TLS_CACERT en majuscule est une directive de /etc/openldap/ldap.conf et pas /etc/ldap.conf (une saloperie, ce truc). Ceci dit, on utilise les mêmes directives dans l'autre aussi, mais en minuscules. Je ne sais pas si le parser fait la distinction ou pas.
Enfin, essaie déjà de désactiver LDAP dans le NSS puis lancer une recherche avec ldapsearch -h tonserveurldap -LLL -x -ZZ dn pour voir si le TLS fonctionne bien du côté d'OpenLDAP et de ses outils.
Moi, j'en suis à cette étape aussi. OpenLDAP ok, NSS échoue.
[^] # Re: LDAP puis TLS puis NSS
Posté par zorooo . Évalué à 1.
dans nsswitch.conf ?
[^] # Re: LDAP puis TLS puis NSS
Posté par Obsidian . Évalué à 2.
Quelle distribution utilises-tu au fait ?
[^] # Re: LDAP puis TLS puis NSS
Posté par zorooo . Évalué à 1.
[^] # Re: LDAP puis TLS puis NSS
Posté par Obsidian . Évalué à 2.
[^] # Re: LDAP puis TLS puis NSS
Posté par Obsidian . Évalué à 2.
[^] # Re: LDAP puis TLS puis NSS
Posté par zorooo . Évalué à 1.
ldapsearch -x -H ldaps://127.0.0.1 -D "cn=god,dc=mh,dc=org" -w mypassword -b "dc=mh,dc=org"
tout le contenu de mon annuaire s'affiche
ssl fonctionne mais pas tls visiblement non ?
de bidouiller ldap pour ssl & tls ca ma ouvert deux ports en plus par rapport a ldap simple
22/tcp open ssh
80/tcp open http
389/tcp open ldap
443/tcp open https
636/tcp open ldapssl
[^] # Re: LDAP puis TLS puis NSS
Posté par Obsidian . Évalué à 2.
Essaie d'ajouter l'option -Z à ta commande, pour forcer le TLS, puis -ZZ pour l'obliger à s'arrêter en cas d'échec de l'authentification. Cette étape fonctionne désormais chez moi, mais nsswitch, lui, continue d'échouer sur un timeout.
# cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
Il faut d'abord configurer proprement /etc/ldap.conf et /etc/openldap/ldap.conf, puis veiller a ce que les clients aient accès au certificat de l'autorité racine qui à signé celui du serveur (si pas auto-signé), faire attention au format (.PEM,.CRT,...) et surtout se méfier de host et uri, mutuellement exclusifs. Enfin, il faut se souvenir que le TLS écoute le port 177 par défaut (le SSL Netscape utilisait le 636).
Le piège, c'est que si on spécifie uri ldaps://ldap.serveur.org, le mot-clé est associé au port 636, qui n'est pas ouvert si on fonctionne en start_tls. Moralité, les modules nss_ldap et pam_ldap ne peuvent pas se connecter, alors qu'un ldapsearch -h ldap.serveur.org -ZZ, lui, y arrive très bien parce qu'on ne précise que le nom d'hôte sans le protocole, et que l'on négocie ensuite le TLS manuellement, avec l'option idoine.
Beaucoup de temps perdu, mais ça servira bien.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
tu as quoi dans ton fichier serveur ldap /etc/openldap/ldap.conf ?
moi :
host 127.0.0.1
base dc=mh,dc=org
uri ldap//127.0.0.1/
ldap_version 3
dans mon fichier client : /etc/ldap.conf
# IP du serveur ldap
host 127.0.0.1
#uri ldaps://srvtest3.test.org/
faut remettre l'uri ou pas ? ldap://192.168.2.217:177 ?
dans slapd.conf
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCertificateFile /etc/openldap/cacerts/ldap.crt
#TLSCertificateKeyFile /etc/openldap/cacerts/ldap.key
#TLSCACertificateFile /etc/openldap/cacerts/ldap.crt
# Use the following if client authentication is required
# TLSVerifyClient demand
# ... or not desired at all
# TLSVerifyClient never
reste a savoir ce qui est util ou pas
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
tu as quoi dans ton fichier serveur ldap /etc/openldap/ldap.conf ?
moi :
host 127.0.0.1
base dc=mh,dc=org
uri ldap//127.0.0.1/
ldap_version 3
dans mon fichier client : /etc/ldap.conf
# IP du serveur ldap
host 127.0.0.1
#uri ldaps://srvtest3.test.org/
faut remettre l'uri ou pas ? ldap://192.168.2.217:177 ?
dans slapd.conf
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSCertificateFile /etc/openldap/cacerts/ldap.crt
#TLSCertificateKeyFile /etc/openldap/cacerts/ldap.key
#TLSCACertificateFile /etc/openldap/cacerts/ldap.crt
# Use the following if client authentication is required
# TLSVerifyClient demand
# ... or not desired at all
# TLSVerifyClient never
reste a savoir ce qui est util ou pas
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
extrait :
Note that if the TLS-related directives in slapd.conf are properly configured, TLS will be available over port 389 even without specifying '-h ldaps://' on the slapd command line. In fact, this is the way to make TLS available without making ldaps available.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
Bon, alors en gros :
- Commenter host et garder uri dans /etc/ldap.conf ;
- Utiliser ldap:// et pas ldaps:// dans cet URI (et ne pas oublier le deux-points, non plus) ;
- Ne pas préciser le numéro de port dans l'URI ;
- Passer en mode TLS par le port par défaut (389, donc) avec ssl start_tls;
- tlscacertfile pour préciser le nom de fichier de la CA qui a signé le certificat de ton serveur, pour que le client puisse l'authentifier. Peut-être pas nécessaire si tls_checkpeer no.
Ensuite, côté serveur, donc dans slapd.conf
- il te faut au moins un certificat côté serveur, fût-il autosigné (mais moi j'ai pris le temps de créer une CA puis de créer un certificat propre à LDAP).
TLSCertificateFile /etc/pki/tls/certs/ldap.pemTLSCertificateKeyFile /etc/pki/tls/private/ldap.key
sans oublier de redémarrer :
# /etc/init.d/ldap restart
Ça devrait suffire à faire démarrer le TLS.
Puis :
ldapsearch -x -H ldap://srvtest3.test.org -ZZ '*'
Pour voir si tu peux établir une connexion en TLS avec ton serveur.
Après, c'est la configuration de PAM et NSS.
Bon courage.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
ldap_start_tls: Connect error (-11)
additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[^] # Re: cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
Il y existe TLS_REQCERT pour contourner ce contrôle, mais le mieux reste encore de générer un certificat valide.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
ldap_start_tls: Connect error (-11)
additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
ldap_initialize( ldap://srvtest3.test.org )
ldap_start_tls: Connect error (-11)
additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure
mon /etc/openldap/ldap.conf
#host 127.0.0.1
base dc=mh,dc=org
uri ldap//srvtest3.test.org/
ldap_version 3
TLS_REQCERT allow
#TLS_CACERT /etc/openldap/cacerts/ldap.crt
#TLS_CERT /etc/openldap/cacerts/ldap.crt
#TLS_KEY /etc/openldap/cacerts/ldap.key
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
http://www.labo-linux.org/articles-fr/gestion-centralisee-de(...)
[^] # Re: cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
#TLS_CERT /etc/openldap/cacerts/ldap.crt
#TLS_KEY /etc/openldap/cacerts/ldap.key
S'il y a des # devant tes lignes, c'est qu'elles sont commentées.
Sinon, essaie d'appeler ldapsearch avec -Z au lieu de -ZZ (qui force la validation).
Par contre, je maintiens que le mieux que tu aies à faire est de refaire des certificats au propre.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
il faut ces trois lignes dans le /etc/openldap/ldap.conf ?
tu as suivi quel tuto pour faire tes certificats ?
[^] # Re: cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
Lire les deux pages (« avec l'usine »).
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
il parle d'un fichier mais il donne pas d'exemple
server-cert-sign.cnf
[^] # Re: cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
OpenSSL utilise un fichier de configuration pour connaître les valeurs par défaut de tout ce qu'il y a à mettre dans un certificat. Tu peux passer une bonne partie de ces valeurs sur la ligne de commande, mais elle devient alors kilométrique ... Donc : regarde dans /etc/pki/tls/openssl.cnf. C'est le fichier de configuration d'OpenSSL par défaut. Copie-le dans le répertoire config de la CA que tu as dû créer si tu as suivi le tutoriel en entier.
Édite cette copie et mets-y tes valeurs par défaut. Lis bien chaque option, y compris celle qui sont commentées. Fais ensuite des copies de ce fichier pour chaque type d'opération que tu as l'intention d'effectuer : requête, signature, création du certificat racine ... (en principe, ces deux ou trois-là devraient être suffisants).
Le détail qui change tout : n'oublie pas d'ajouter utf8 = yes dans la section [ req ]. Ou alors passer -utf8 sur la ligne de commande. Autrement, il te génère bien un certif' compatible UTF-8, mais il parse quand même le contenu de ton fichier de conf' en ASCII.
Il faudra donc au minimum préciser le pays (Country - C), l'organisation (O), l'unité organisationelle (OU), et le Common Name (CN), soit le p'tit nom de ton certif' ou de ce qu'il représente. Si tu crées ce certificat pour un serveur, le CN doit obligatoirement contenir le nom de serveur pleinement qualifié (avec le domaine).
De là, première étape (à n'effectuer qu'une seule fois), la création du certificat racine, que tu conserveras précieusement :
1) Génère suffisamment de données aléatoires dans un fichier (ainsi, tu pourras recommencer facilement en cas de pépin). Ça peut être long si tu utilises le générateur de vrais nombres aléatoires. N'oublie pas de provoquer de l'activité disque, réseau, souris et autres pour accélérer cette production.
dd if=/dev/random of=private/.rand bs=1 count=163842) Tu vas créer la clé privée du certificat racine. À conserver en lieu sûr et à ne jamais divulguer ! D'ailleurs, tu vas même la protéger par une passphrase. Choisis-là suffisamment longue pour qu'elle ne soit pas triviale, mais pas trop compliquée non plus car tu la saisiras chaque fois que tu signeras un certificat.
openssl genrsa -aes256 -out private/ca.key -rand private/.rand 4096chmod 400 private/ca.key
3) Crée le certificat racine. On le fait en faisant une requête et en passant -x509 pour qu'il remplissent directement les champs qui en font un certificat à part entière ... en l'autosignant. « req » dit que l'on veut travailler sur des demandes de signature. « new » dit que l'on souhaite en créer une (et pas travailler sur un fichier existant). « root-ca-cert.cnf » est le nom de ton fichier de config. On va le signer avec la clé que tu viens de créer, il faudra donc saisir ta passphrase pour pouvoir utiliser cette clé.
openssl req -new -x509 -days 3650 -config configs/root-ca-cert.cnf -key private/ca.key -out ca.crtEt voila. Tu viens de créer le certificat racine, valable 10 ans, qui signera tous les autres. Il faudra également le communiquer aux différents clients si ce n'est pas automatique. C'est l'équivalent d'un CACert, Thawte ou Verisign. Note que ce certificat est à la racine de ton répertoire CA, et pas dans un de ses sous-répertoires. La clé privée, elle, reste en dessous de private. Sauve bien les deux et ne divulgue jamais la clé, encore une fois.
Deuxième étape, à répéter pour chaque certificat que tu vas créer et signer :
4) Regénère des données aléatoires (moins long cette fois) :
dd if=/dev/random of=private/.rand bs=1 count=40965) Regénère une clé. Sans passphrase cette fois, parce qu'elle ne protège qu'un seul certificat, et qu'il faudrait resaisir cette passphrase à chaque fois que l'on relancerait le serveur qui utilise le certificat qu'elle protège.
openssl genrsa -out private/ldap.key -rand private/.rand 1024chmod 400 private/ldap.key
6) Refais une demande de signature en bonne et due forme, sans « -x509 », cette fois. Je te conseille de choisir comme nom de fichier la valeur que tu donneras à ton OU. De plus, on déposera cette demande dans le répertoire prévu à cet effet, « csr ». Le fichier « server-csr.cnf » est ton fichier de config dédié à la demande de certificats, si ce n'est pas le même.
openssl req -new -out csr/ldap.csr -config server-csr.cnf -key private/ldap.key7) Tu as maintenant un certificat, protégé par une clé secrète, mais pas encore authentifié. On va demander à la CA de signer ce certificat avec le sien. « sign.cnf » est le ficheir de config dédié à la signature. Si tu l'as bien configuré, il contient déjà les noms et emplacements du certificat racine et de sa clé, ce qui t'évite d'avoir à te les palucher à chaque fois sur la ligne de commande.
openssl ca -out certs/ldap.crt -in csr/ldap.csr -config sign.cnfImporte ensuite manuellement le fichier ca.crt dans la liste des autorités de certification de Firefox, par exemple. On ne doit pas te demander de passphrase à ce stade. Il faudra faire de même pour tous les clients sécurisés, style ldapsearch ou autre. Enfin, utilise un certificat signé (pas celui de la CA) par serveur à authentifier.
C'est fastidieux, mais c'est une méthode universelle. Avec çà, fini les certifs auto-signés.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
par contre mes authentification ssh par ldap ne fonctionne plus
tail -f /var/log/secure
nss_ldap: could not search LDAP server - Server is unavailable
et comme je te disai :p
/usr/bin/slapd -4 lance bien mon serveur
mais service ldap start ne le lance pas error :(
May 30 01:13:29 srvtest3 slapd[32529]: nss_ldap: could not search LDAP server - Server is unavailable
May 30 01:13:29 srvtest3 slapd[32529]: nss_ldap: could not search LDAP server - Server is unavailable
May 30 01:13:29 srvtest3 slapd[32529]: /etc/openldap/slapd.conf: line 39: rootdn is always granted unlimited privileges.
May 30 01:13:29 srvtest3 slapd[32529]: /etc/openldap/slapd.conf: line 44: rootdn is always granted unlimited privileges.
May 30 01:13:29 srvtest3 slapd[32529]: main: TLS init def ctx failed: -1
May 30 01:13:29 srvtest3 slapd[32529]: slapd stopped
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
nss_ldap: could not search LDAP server - Server is unavailable
ca vient de mon /etc/ldap.conf ou /etc/openldap/ldap.conf ?
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
nss_ldap: could not search LDAP server - Server is unavailable
ca vient de mon /etc/ldap.conf ou /etc/openldap/ldap.conf ?
[^] # Re: cn=chezmoicamarche,dc=org
Posté par Obsidian . Évalué à 2.
Or, NSSwitch est justement là pour fournir d'autres sources de données, de manière transparente, dont une base LDAP. Donc, ton serveur LDAP se plaint au démarrage parce que le serveur LDAP n'est pas lancé :-)
Pour autant, on s'aperçoit également que ce n'est pas ça qui empêche ton serveur de démarrer.
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
mon nsswitch.conf
passwd: files [SUCCESS=return] ldap
shadow: files [SUCCESS=return] ldap
group: files [SUCCESS=return] ldap
le seul truc dont il a besoin c'est sont user ldap et il est dans "files" et si il trouve son bonheur dans files il va pas voir dans ldap
[^] # Re: cn=chezmoicamarche,dc=org
Posté par zorooo . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.