« LDAP » : différence entre les versions

De Justine's wiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 209 : Ligne 209 :
On peut aussi le faire à distance en ajoutant un hôte avec "-H ldap://mon.hote.tld" par exemple
On peut aussi le faire à distance en ajoutant un hôte avec "-H ldap://mon.hote.tld" par exemple
   
   
= TLS/SSL =
* https://www.golinuxcloud.com/setup-openldap-over-ssl-tls-rocky-linux/
* https://wiki.debian.org/LDAP/OpenLDAPSetup#TLS.2FSSL


Jusqu'à présent, notre serveur LDAP fonctionne en clair. Mais avec LDAPS, on peut faire du SSL. Pour l'exemple, nous allons utiliser un autosigné, mais pour de la production on peut utiliser un certificat let's encrypt, zeroSSL ou autre.
On commence par créer un dossier pour les certifs et donner les droits à l'utilisateur openldap:
<nowiki>
mkdir -p /etc/ldap/ssl/certs
mkdir -p /etc/ldap/ssl/priv
chown -R openldap:openldap /etc/ldap/ssl
</nowiki>


On créée ensuite un autosigné dans notre cas:
<nowiki>
cd /etc/ldap/ssl/priv
openssl genrsa 2048 > ldapserver.key
openssl req -utf8 -new -key ldapserver.key -out ldapserver.csr
cd ../certs
openssl x509 -in ../private/ldapserver.csr -out ldapserver.crt -req -signkey ../private/ldapserver.key -days 3650
#La clef et le certificat doivent ensuite appartenir à openldap:openldap
</nowiki>
== Un mot sur la config ==
L'insertion se fait ensuite via un LDIF avec l'aide de la commande ldapmodify. En effet, Slapd stocke une bonne partie de sa configuration directement dans l'annuaire, sur cn=config (on peut d'ailleurs en extraire le contenu avec slapcat, cf. la section sur les backups.
Pourquoi ? Pour citer [https://www.zytrax.com/books/ldap/ch6/slapd-config.html ma source]
<blockquote> Historically OpenLDAP has been statically configured, that is, to make a change to the configuration the slapd.conf file was modified and slapd stopped and started. In the case of larger users this could take a considerable period of time and had become increasingly unacceptable as an operational method. OpenLDAP version 2.3 introduced an optional new feature whereby configuration may be performed at run-time using a DIT entry called cn=config. The feature is known by a varied and confusing number of terms including on-line configuration (OLC) (our favorite), zero down-time configuration, cn=config and slapd.d configuration. </blockquote>
On trouve donc dans cn=config un tas d'attributs en olc, pour OnLine Configuration.
== Retour sur notre SSL ==
Donc, la modif se fait via un LDIF :
<nowiki>
dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/certs/ldapserver.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/priv/ldapserver.key
</nowiki>
Il s'agit ici de la version pour notre autosigné. Dans le cas d'un vrai certif, on peut avoir une chaîne intermédiaire:
<nowiki>
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/server.key
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/intermediate.pem
</nowiki>
On peut ensuite effectuer la modification avec:
ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
* -Y EXTERNAL : Choix du mécanisme SASL. Ici, signifie que l'authentification est implicite. Pas tout compris; https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer
* -H ldapi:/// : donner une "ldapuri", soit une uri pour ldap... ldapi correspond à /var/run/ldapi, soit un socket Unix. Utilisé uniquement pour cn=config.
* -f ssl.ldif : chemin du fichier.
== Activer le port 636 ==
Il nous reste à activer l'écoute sur le port 636, utilisé par LDAPS. Il faut modifier /etc/default/slapd, et modifier la ligne "SLAPD_SERVICES" pour lui ajouter le ldaps:
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"
On peut aussi réserver les connections en clair en local, par exemple:
SLAPD_SERVICES="ldap://127.0.0.1:389/ ldapi:/// ldaps:///"
Puis restart
systemctl restart slapd
On peut vérifier via openldap que le port sert bien un certificat:
openssl s_client -connect ip.du.ldap:636 -showcerts
== Tester la connection / Faire une recherche ==
=== Autoriser les certificats untrusted et chercher en local ===
On peut vouloir tester localement avec:
ldapsearch -x -b dc=sq,dc=lan -ZZ
Qui renvoie une erreur:
<nowiki>
ldap_start_tls: Connect error (-11)
        additional info: (unknown error code)
</nowiki>
Il faut modifier /etc/slapd/ldap.conf pour ajouter:
TLS_REQCERT never
Ensuite, ça fonctionne.
=== Pareil à distance ===
Pour tester depuis une autre machine:
* S'assurer que le fw de notre serveur LDAP laisse passer la connection sur le port 636/TCP.
* Installer ldap-utils (Debian).
On peut ensuite faire la recherche.
ldapsearch -x -H ldaps://tests.sq.lan -b "dc=sq,dc=lan"
Si le serveur LDAP utiliser un autosigné, on se tape une erreur:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
Il faudrait aller ajouter "TLS_REQCERT" dans /etc/ldap/ldap.conf, mais ça n'existe pas vu qu'on est pas sur un serveur LDAP... Comment faire ?
Il suffit d'utiliser une variable d'environnement avec notre commande
LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://tests.sq.lan -b "dc=sq,dc=lan"
Je récupère ainsi le contenu de l'annuaire. Un annuaire étant normalement public, je me récupère tout le contenu.
= AD =
= AD =
== Faire une recherche LDAP sur un AD ==
== Faire une recherche LDAP sur un AD ==

Version du 17 septembre 2023 à 21:31

LDAP

Sources:

Lightweight Directory Access Protocol. LDAP est un protocole standardisé pour les annuaires; c'est souvent la base de l'IAM (Identity and Authentification Management) au sein d'une organisation. Un annuaire sert à recenser les personnes et les matériels dans un annuaire commun, à un but d'autorisation (à quoi ai-je accès) et d'authentification (suis-je bien qui je prétends être ?).

Il utilise en clair le port 389 et en chiffré le port 636.

Une fois un annuaire LDAP en place, il peut être utilisé à des fins d'authentification sur 99% des applications self-hosted (qu'on parle de LDAP en lui-même ou bien d'Active Directory, qui est sa version Windows). C'est un des piliers centraux d'un système d'informations. Il y aurait beaucoup à dire sur son importance et sur l'importance d'une bonne gestion de l'IAM au sein d'une organisation.

Fonctionnement interne de LDAP

LDAP est une structure en arbre, avec à la base un domaine contenant des OU (Organizational Units) contenant elles-mêmes des objets. Les objets sont appellés "entrées", et sont une collection d'attribut clef-valeur. Chaque entrée est distinguée par son DN pour Distinguished Number, sur le même principe qu'un système de fichiers avec ses chemins.

LDAP dérive de X.500 qui est un système d'annuaires; à l'origine, LDAP était une gateway pour accéder à X.500. Il est désormais intégré directement.


SlapD

Sources:

Slapd est le daemon LDAP par excellence sur Linux. Celui-ci est simple à installer et disponible sur la plupart des distributions; nous sommes ici en Debian (testing, entre la 12 et la 13).

Il se compose d'un daemon (slapd) que l'on va pouvoir configurer et alimenter à l'aide de fichiers LDIF - LDAP Data Interchange Format. Il écoute son port TCP et peux faire du LDAPS avec SSL. Il peut fonctionner en cluster avec slurpd.

Installation et configuration basiques

L'installation se fait normalement:

apt install slapd

Lors de l'installation, celui-ci va nous demander un mot de passe administrateur. Il peut également demander le nom de domaine si celui-ci n'est pas renseigné dans le hostname de la machine. On peut refaire sa configuration de base avec:

dpkg-reconfigure slapd

Voici les réponses que l'on peut donner:

#On veut configurer slapd...
1.Passer la configuration d'OpenLDAP ? non
#Donner notre nom de domaine si il ne le déduit pas
2.Nom de domaine ? example.com
#Pas compris
3.Nom de votre société ? masociété 
#LDAP peut avoir plusieurs backends, hdb est décrit comme 'le backend pour une utilisation normale de slapd'
4.Quelle base de donnée ? hdb 
#Doit-on effacer la base quand la présente config est finie ?
5.Voulez-vous que la base de donnée soit effacée lorsque slapd est purgé ? oui 
#Pareil
6.Supprimer les anciennes bases de données ? oui
7.Mot de passe administrateur ? VotreMotDePasse
8.Confirmer ce mot de passe ? VotreMotDePasse
#LDAPv2 est un vieux vieux protocole
9.Authoriser le protocol LDAPv2 ? non

On peut regénérer un mot de passe admin avec la commande suivante:

sudo slappasswd

Insérer des données

Créer un fichier init.ldif :

#Base de notre arbre : c'est le premier objet.
Les attributs (objectClass, dc etc) sont par défaut, mais on peut créer les notres.
dn: dc=sq,dc=lan
objectClass: dcObject
objectClass: organizationalUnit
dc: sq
ou: Sq Dot Lan

#Une OU pour les personnes
dn: ou=people,dc=sq,dc=lan
objectClass: organizationalUnit
ou: people

#Une OU pour les groupes
dn: ou=groups,dc=sq,dc=lan
objectClass: organizationalUnit
ou: groups

#Je créée un compte utilisateur
dn: uid=justine,ou=people,dc=sq,dc=lan
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
#L'UID est une valeur de base pour identifier une personne et doit être unique
uid: justine
sn: Pelletreau
givenName: Justine
cn: Justine Pelletreau
displayName: Justine Pelletreau
uidNumber: 1000
gidNumber: 10000
gecos: Justine Pelletreay
loginShell: /bin/zsh
homeDirectory: /home/justine
shadowExpire: -1
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax: 999999
shadowLastChange: 10877
mail: justine.pelletreau@squi.fr
postalCode: 77210
l: Avon
o: SqLan
title: System Administrator
initials: JP

#Je créée un groupe
dn: cn=admins,ou=groups,dc=sq,dc=lan
objectClass: posixGroup
cn: admins
gidNumber: 10000
displayName: Example group

Les attributs peuvent être trouvés sur la doc : https://www.openldap.org/doc/admin22/schema.html ou dans diverses listes sur le net : https://www.zytrax.com/books/ldap/ape/#attributes Ils sont définis dans des schémas par défaut (dans /etc/ldap/schema). On peut créer nos propres schémas.

Structure de notre LDAP après insertion de notre fichier LDIF.

Une fois ce fichier écrit, on va devoir effacer l'installation par défaut et entrer nos données à la place:

systemctl stop slapd
sudo rm -rf /var/lib/ldap/*
sudo slapadd -l ~/init.ldif
#On redonne les droits de lecture sur la base
sudo chown -R openldap:openldap /var/lib/ldap
systemctl start slapd

On va ensuite pouvoir faire une recherche afin de vérifier que nos informations sont bien prises en compte à l'aide de ldapsearch (du paquet ldap-utils).

31 root > ldapsearch -xLLL -b "dc=sq,dc=lan" uid=justine sn givenName cn
#Renvoie
dn: uid=justine,ou=people,dc=sq,dc=lan
sn: Pelletreau
givenName: Justine
cn: Justine Pelletreau

Explication de la commande:

  • -x désactive l'authentification
  • -LLL empêche l'affichage des informations LDIF (c'est juste pour raccourcir la réponse)
  • -b "dc=sq,dc=lan" sert à donner le *base DN*, c'est à dire la base à partir de laquelle on va chercher (ici, la racine)
  • uid=justine : je cherche une valeur dont le champ uid est égal à "justine"
  • sn givenName cn : ce sont les valeurs que je veux récupérer

Sauvegarde / Restauration

https://www.vincentliefooghe.net/content/sauvegarde-et-restauration-openldap

La backup se fait simmplement en sauvegardant les données contenues dans le dossier de données de slapd (par défaut /var/lib/ldap) après arrêt de slapd. On peut les restaurer de la même façon en arrêtant slapd, copiant les fichiers, mettre les droits 0600 et la propriété à l'utilisateur openldap et son groupe openldap.

On peut aussi faire une sauvegarde à chaud au format LDIF avec la commande "slapcat" (quel nom bizarre... Mais il sert juste à faire un "cat" de slapd)

slapcat -b "dc=sq,dc=lan" -l backup.ldif

Ici je sauvegarde mon arbre (donné comme Base DN avec le -b) dans le fichier backup.ldif.

Pour la restauration, le principe est le même que lors de notre installation. Cela peut être long sur un gros annuaire. On peut améliorer les perfs avec l'option -q, pour éviter la génération de fichiers de logs et aller plus vite:

slapadd -c -b dc=sq,dc=lan -l Export-Example-com.ldif -q

Ajouter un mot de passe au compte utilisateur

Maintenant que nous avons un compte utilisateur dans notre annuaire, on va pouvoir lui ajouter un mot de passe afin de pouvoir s'authentifier avec ce dernier. Cela passe par la commande ldappasswd.

Depuis le compte admin

Si le compte en question n'as pas encore de mot de passe, on va pouvoir passer par le compte administrateur pour lui en créer un.

ldappasswd -H ldap://127.0.0.1:389 -x -D "cn=admin,dc=sq,dc=lan" -W -S "uid=justine,ou=people,dc=sq,dc=lan"
  • -H : ldapuri - comment se connecter au ldap en question
  • -x : utiliser une authentification simple au lieu de SASL
  • -D : binddn - quel compte utiliser pour se connecter en admin
  • -W : Demander le mot de passe du binddn avec un prompt au lieu de le donner en argument avec -w
  • -S : Demander le nouveau mdp via un prompt au lieu de le donner en argument avec -s
  • On finit avec le dn du compte à modifier.

Depuis le compte en question

On peut aussi se connecter avec le compte en question pour modifier le mot de passe. Par défaut, un serveur LDAP laisse les utilisateurs modifier leur propre mot de passe.

ldappasswd -H ldap://localhost:389 -x -D "uid=justine,ou=people,dc=sq,dc=lan" -W -A -S
Old password: <entrer l'ancien mdp>
Re-enter old password: <encore>
New password: <entrer le nouveau mdp>
Re-enter new password: <encore>
Enter LDAP Password: <entrer l'ancien mdp>

Le seul argument différent de ceux du mode admin est -A, qui sert à prompt pour l'ancien mot de passe.

Tester une connection

On peut ensuite tester une connection avec le compte.

En local:

ldapsearch -x -LLL -D 'uid=justine,ou=people,dc=sq,dc=lan' -W
  • -x : Connection simple
  • -LLL : Raccourcir la sortie en enlevant toutes les infos LDIF
  • -D : bind dn
  • -W : demander le mot de passe

On peut aussi le faire à distance en ajoutant un hôte avec "-H ldap://mon.hote.tld" par exemple

TLS/SSL

Jusqu'à présent, notre serveur LDAP fonctionne en clair. Mais avec LDAPS, on peut faire du SSL. Pour l'exemple, nous allons utiliser un autosigné, mais pour de la production on peut utiliser un certificat let's encrypt, zeroSSL ou autre. On commence par créer un dossier pour les certifs et donner les droits à l'utilisateur openldap:

mkdir -p /etc/ldap/ssl/certs
mkdir -p /etc/ldap/ssl/priv
chown -R openldap:openldap /etc/ldap/ssl

On créée ensuite un autosigné dans notre cas:

cd /etc/ldap/ssl/priv
openssl genrsa 2048 > ldapserver.key
openssl req -utf8 -new -key ldapserver.key -out ldapserver.csr
cd ../certs
openssl x509 -in ../private/ldapserver.csr -out ldapserver.crt -req -signkey ../private/ldapserver.key -days 3650
#La clef et le certificat doivent ensuite appartenir à openldap:openldap

Un mot sur la config

L'insertion se fait ensuite via un LDIF avec l'aide de la commande ldapmodify. En effet, Slapd stocke une bonne partie de sa configuration directement dans l'annuaire, sur cn=config (on peut d'ailleurs en extraire le contenu avec slapcat, cf. la section sur les backups.

Pourquoi ? Pour citer ma source

Historically OpenLDAP has been statically configured, that is, to make a change to the configuration the slapd.conf file was modified and slapd stopped and started. In the case of larger users this could take a considerable period of time and had become increasingly unacceptable as an operational method. OpenLDAP version 2.3 introduced an optional new feature whereby configuration may be performed at run-time using a DIT entry called cn=config. The feature is known by a varied and confusing number of terms including on-line configuration (OLC) (our favorite), zero down-time configuration, cn=config and slapd.d configuration.

On trouve donc dans cn=config un tas d'attributs en olc, pour OnLine Configuration.

Retour sur notre SSL

Donc, la modif se fait via un LDIF :

dn: cn=config
changetype: modify
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/certs/ldapserver.crt
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/priv/ldapserver.key

Il s'agit ici de la version pour notre autosigné. Dans le cas d'un vrai certif, on peut avoir une chaîne intermédiaire:

dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/server.key
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/intermediate.pem

On peut ensuite effectuer la modification avec:

ldapmodify -Y EXTERNAL -H ldapi:/// -f ssl.ldif
  • -Y EXTERNAL : Choix du mécanisme SASL. Ici, signifie que l'authentification est implicite. Pas tout compris; https://en.wikipedia.org/wiki/Simple_Authentication_and_Security_Layer
  • -H ldapi:/// : donner une "ldapuri", soit une uri pour ldap... ldapi correspond à /var/run/ldapi, soit un socket Unix. Utilisé uniquement pour cn=config.
  • -f ssl.ldif : chemin du fichier.

Activer le port 636

Il nous reste à activer l'écoute sur le port 636, utilisé par LDAPS. Il faut modifier /etc/default/slapd, et modifier la ligne "SLAPD_SERVICES" pour lui ajouter le ldaps:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

On peut aussi réserver les connections en clair en local, par exemple:

SLAPD_SERVICES="ldap://127.0.0.1:389/ ldapi:/// ldaps:///"

Puis restart

systemctl restart slapd

On peut vérifier via openldap que le port sert bien un certificat:

openssl s_client -connect ip.du.ldap:636 -showcerts

Tester la connection / Faire une recherche

Autoriser les certificats untrusted et chercher en local

On peut vouloir tester localement avec:

ldapsearch -x -b dc=sq,dc=lan -ZZ

Qui renvoie une erreur:

ldap_start_tls: Connect error (-11)
        additional info: (unknown error code)

Il faut modifier /etc/slapd/ldap.conf pour ajouter:

TLS_REQCERT never

Ensuite, ça fonctionne.

Pareil à distance

Pour tester depuis une autre machine:

  • S'assurer que le fw de notre serveur LDAP laisse passer la connection sur le port 636/TCP.
  • Installer ldap-utils (Debian).

On peut ensuite faire la recherche.

ldapsearch -x -H ldaps://tests.sq.lan -b "dc=sq,dc=lan"

Si le serveur LDAP utiliser un autosigné, on se tape une erreur:

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

Il faudrait aller ajouter "TLS_REQCERT" dans /etc/ldap/ldap.conf, mais ça n'existe pas vu qu'on est pas sur un serveur LDAP... Comment faire ? Il suffit d'utiliser une variable d'environnement avec notre commande

LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://tests.sq.lan -b "dc=sq,dc=lan"

Je récupère ainsi le contenu de l'annuaire. Un annuaire étant normalement public, je me récupère tout le contenu.


Faire une recherche LDAP sur un AD

https://tylersguides.com/guides/search-active-directory-ldapsearch/ <source lang="bash">

  1. Avec TLS

ldapsearch -H ldaps://dc.example.com -x -W -D "user@example.com" -b "dc=example,dc=com" "(sAMAccountName=user)"

  1. Sans TLS

ldapsearch -H ldap://dc.example.com -x -W -D "user@example.com" -b "dc=example,dc=com" "(sAMAccountName=user)" </source>