Service d'annuaire avec LDAP [4]: ​​OpenLDAP (I)

Salut les amis!. Passons aux choses sérieuses, et comme nous le recommandons toujours, lisez les trois articles précédents de la série:

• Service d'annuaire avec LDAP. introduction.
• Service d'annuaire avec LDAP [2]: NTP et dnsmasq.
• Service d'annuaire avec LDAP [3]: Isc-DHCP-Server et Bind9.

DNS, DHCP et NTP sont les services essentiels minimum pour notre annuaire simple basé sur OpenLDAP native, fonctionne correctement sur le Debian 6.0 "Squeeze", ou dans Ubuntu 12.04 LTS "Precise Pangolin".

Exemple de réseau:

Lan: 10.10.10.0/24
Dominio: amigos.cu
Servidor: mildap.amigos.cu
Sistema Operativo Servidor: Debian 6 "Squeeze
Dirección IP del servidor: 10.10.10.15
Cliente 1: debian7.amigos.cu
Cliente 2: raring.amigos.cu
Cliente 3: suse13.amigos.cu
Cliente 4: seven.amigos.cu

Dans la première partie, nous verrons:

• Installation d'OpenLDAP (giflé 2.4.23-7.3)
• Vérifie après l'installation
• Indices à prendre en compte
• Règles de contrôle d'accès aux données
• Génération de certificats TLS dans Squeeze

tandis que dans la deuxième partie, nous continuerons avec:

• Authentification des utilisateurs locaux
• Remplir la base de données
• Gérez la base de données à l'aide des utilitaires de la console
• Résumé à ce jour ...

Installation d'OpenLDAP (giflé 2.4.23-7.3)

Le serveur OpenLDAP est installé à l'aide du package giflé. Il faut également installer le package utilitaires ldap, qui nous fournit des outils côté client, ainsi que les propres utilitaires d'OpenLDAP.

: ~ # aptitude installe slapd ldap-utils

Pendant le processus d'installation, le débconf Il nous demandera le mot de passe de l'administrateur ou de l'utilisateur «admin«. Un certain nombre de dépendances sont également installées; l'utilisateur est créé ouvrirldap; la configuration initiale du serveur est créée ainsi que l'annuaire LDAP.

Dans les versions antérieures d'OpenLDAP, la configuration du démon giflé a été fait entièrement via le fichier /etc/ldap/slapd.conf. Dans la version que nous utilisons et plus tard, la configuration se fait de la même manière giflé, et à cet effet un DIT «Arborescence des informations d'annuaire»Ou l'arborescence des informations de répertoire, séparément.

La méthode de configuration appelée RTC «Configuration en temps réel»Configuration en temps réel, ou comme méthode cn = config, nous permet de configurer dynamiquement le giflé sans nécessiter un redémarrage du service.

La base de données de configuration se compose d'un ensemble de fichiers texte au format FRDI «Format d'échange de données LDAP»Format LDAP pour l'échange de données, situé dans le dossier /etc/ldap/slapd.d.

Pour avoir une idée de l'organisation des dossiers slapd.d, courons:

: ~ # ls -lR /etc/ldap/slapd.d/
/etc/ldap/slapd.d/: total 8 drwxr-x --- 3 openldap openldap 4096 16 février 11:08 cn = config -rw ------- 1 openldap openldap 407 16 février 11:08 cn = config.ldif /etc/ldap/slapd.d/cn=config: total 28 -rw ------- 1 openldap openldap 383 16 février 11:08 cn = module {0} .ldif drwxr-x --- 2 openldap openldap 4096 16 février 11:08 cn = schema -rw ------- 1 openldap openldap 325 16 février 11:08 cn = schema.ldif -rw ------- 1 openldap openldap 343 16 février 11:08 olcBackend = {0} hdb.ldif -rw ------- 1 openldap openldap 472 16 février 11:08 olcDatabase = {0} config.ldif -rw ------- 1 openldap openldap 586 16 février 11:08 olcDatabase = {- 1} frontend.ldif -rw ------- 1 openldap openldap 1012 16 février 11:08 olcDatabase = {1} hdb.ldif /etc/ldap/slapd.d/cn = config / cn = schema: total 40 -rw ------- 1 openldap openldap 15474 16 février 11:08 cn = {0} core.ldif -rw ------- 1 openldap openldap 11308 16 février 11:08 cn = {1} cosine.ldif -rw ------- 1 openldap openldap 6438 16 février 11:08 cn = {2} nis.ldif -rw ------- 1 openldap openldap 2802 16 février 11:08 cn = {3} inetorgperson.ldif

Si nous regardons un peu la sortie précédente, nous voyons que le backend utilisé dans Squeeze est le type de base de données hdb, qui est une variante de bdb "Berkeley Database", et qu'il est entièrement hiérarchique et prend en charge le changement de nom des sous-arbres. Pour en savoir plus sur les possibles Backends qui prend en charge OpenLDAP, visitez http://es.wikipedia.org/wiki/OpenLDAP.

On voit aussi que trois bases de données distinctes sont utilisées, soit une dédiée à la configuration, une autre à L'extrémité avant, et le dernier qui est la base de données hdb en soi.

En outre, giflé est installé par défaut avec les schémas Core, Cosinus, Nis e internaute.

Vérifie après l'installation

Dans un terminal, nous exécutons et lisons calmement les sorties. Nous vérifierons, notamment avec la deuxième commande, la configuration déduite du listage du dossier slapd.d.

: ~ # ldapsearch -Q -LLL -Y EXTERNE -H ldapi: /// -b cn = config | plus: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b cn = config dn
dn: cn = config dn: cn = module {0}, cn = config dn: cn = schema, cn = config dn: cn = {0} core, cn = schema, cn = config dn: cn = {1} cosinus , cn = schema, cn = config dn: cn = {2} nis, cn = schema, cn = config dn: cn = {3} inetorgperson, cn = schema, cn = config dn: olcBackend = {0} hdb, cn = config dn: olcDatabase = {- 1} frontend, cn = config dn: olcDatabase = {0} config, cn = config dn: olcDatabase = {1} hdb, cn = config

Explication de chaque sortie:

• cn = config: Paramètres globaux.
• cn = module {0}, cn = config: Module chargé dynamiquement.
• cn = schéma, cn = config: Contient le codée en dur au niveau des schémas du système.
• cn = {0} core, cn = schema, cn = config: L' codée en dur du schéma du noyau.
• cn = {1} cosinus, cn = schéma, cn = config: Le schéma Cosinus.
• cn = {2} nis, cn = schéma, cn = config: Le schéma Nis.
• cn = {3} inetorgperson, cn = schema, cn = config: Le schéma internaute.
• olcBackend = {0} hdb, cn = config: backend type de stockage de données hdb.
• olcDatabase = {- 1} frontend, cn = config: L'extrémité avant de la base de données et des paramètres par défaut pour les autres bases de données.
• olcDatabase = {0} config, cn = config: base de données de configuration du giflé (cn = config).
• olcDatabase = {1} hdb, cn = config: Notre instance de la base de données (dc = amis, dc = cu)

: ~ # ldapsearch -x -LLL -H ldap: /// -b dc = exemple, dc = com dn
dn: dc = amis, dc = cu dn: cn = admin, dc = amis, dc = cu

• dc = amis, dc = cu: Arborescence des informations du répertoire de base DIT
• cn = admin, dc = amis, dc = cu: Administrateur (rootDN) du DIT déclaré lors de l'installation.

Note: Le suffixe de base dc = amis, dc = cu, l'a pris débconf lors de l'installation de FQDN du serveur mildap.amigos.cu.

Indices à prendre en compte

L'indexation des entrées est effectuée pour améliorer les performances des recherches sur le DIT, avec des critères de filtrage. Les index que nous considérerons sont les minimums recommandés en fonction des attributs déclarés dans les schémas par défaut.

Pour modifier dynamiquement les index de la base de données, nous créons un fichier texte au format FRDI, et plus tard, nous l'ajoutons à la base de données. Nous créons le fichier olcDbIndex.ldif et nous le laissons avec le contenu suivant:

: ~ # nano olcDbIndex.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modifier ajouter: olcDbIndex olcDbIndex: uidNumber eq - ajouter: olcDbIndex olcDbIndex: gidNumber eq - ajouter: olcDbIndex olcDbIndex olcDbIndex: uidNumber eq - ajouter: olcDbIndex olcDbIndex: gidNumber eq - ajouter: olcDbIndex olcDbIndex olcDbIndex: uidNumber eq - ajouter: olcDbIndex olcDbIndex: gidNumber eq - ajouter: olcDbIndex olcDbIndex olcDbIndex: memberShIndex olcDbIndex: olcDbIndex eqdex: login : loginShell eq, pres, sub - addhellShell - add: olcDbIndex olcDbIndex: uid pres, sub, eq - add: olcDbIndex olcDbIndex: cn pres, sub, eq - add: olcDbIndex olcDbIndex: uid pres, sub, eq - add: olcDbIndex olcDbIndex: cn pres, sub, eq - add: olcDbIndex olcDbIndex: sn pres, sub, olcD eqIndex: sn pres, sub, olcDe : givenName, ou pres, eq, sub - add: olcDbIndex olcDbIndex: displayName pres, sub, eq - add: olcDbIndex olcDbIndex: default sub - add: olcDbIndex olcDbIndex: mail eq, subinitial - add: olcDbIndex eqIndex: dcDbIndex

Nous ajoutons les index à la base de données et vérifions la modification:

: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f ./olcDbIndex.ldif

: ~ # ldapsearch -Q -LLL -Y EXTERNAL -H ldapi: /// -b \ cn = config '(olcDatabase = {1} hdb)' olcDbIndex

dn: olcDatabase = {1} hdb, cn = config olcDbIndex: objectClass eq olcDbIndex: uidNumber, gidNumber eq olcDbIndex: memberUid eq, pres, sous olcDbIndex: loginShell eq olcDbIndex: uid pres olc, pres olc cn presq olcDbIndex: sn pres, sub, eq olcDbIndex: givenName, ou pres, eq, sub olcDbIndex: displayName pres, sub, eq olcDbIndex: par défaut sous olcDbIndex: mail eq, sous-initial olcDbIndex: dc eq

Règles de contrôle d'accès aux données

Les règles établies pour que les utilisateurs puissent lire, modifier, ajouter et supprimer des données dans la base de données de l'annuaire sont appelées Contrôle d'accès, tandis que nous appellerons les listes de contrôle d'accès ou «Liste de contrôle d'accès ACL»Aux politiques qui configurent les règles.

Pour savoir lequel ACL ont été déclarés par défaut lors du processus d'installation du giflé, nous exécutons:

: ~ # ldapsearch -Q -LLL -Y EXTERNE -H ldapi: /// -b \
cn = config '(olcDatabase = {1} hdb)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNE -H ldapi: /// -b \
cn = config '(olcDatabase = {- 1} frontend)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNE -H ldapi: /// -b \
cn = config '(olcDatabase = {0} config)' olcAccess

: ~ # ldapsearch -Q -LLL -Y EXTERNE -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Chacune des commandes précédentes nous montrera le ACL que jusqu'à présent nous l'avons déclaré dans notre Directoire. Plus précisément, la dernière commande les montre tous, tandis que les trois premiers nous donnent les règles de contrôle d'accès pour les trois. DIT impliqué dans notre giflé.

Au sujet de ACL et afin de ne pas faire un article beaucoup plus long, nous vous recommandons de lire les pages du manuel homme slapd.access.

Pour garantir l'accès des utilisateurs et administrateurs pour mettre à jour leurs entrées de connexionShell y Geckos, nous ajouterons l'ACL suivante:

## Nous créons le fichier olcAccess.ldif et le laissons avec le contenu suivant: ~ # nano olcAccess.ldif
dn: olcDatabase = {1} hdb, cn = config changetype: modify add: olcAccess olcAccess: {1} to attrs = loginShell, gecos by dn = "cn = admin, dc = friends, dc = cu" write by self write by * lis

## Nous ajoutons l'ACL
: ~ # ldapmodify -Y EXTERNE -H ldapi: /// -f ./olcAccess.ldif

# Nous vérifions les changements
ldapsearch -Q -LLL -Y EXTERNE -H ldapi: /// -b \
cn = config '(olcAccess = *)' olcAccess olcSuffix

Génération de certificats TLS dans Squeeze

Pour avoir une authentification sécurisée avec le serveur OpenLDAP, nous devons le faire via une session cryptée que nous pouvons réaliser en utilisant le TLS «Sécurité de la couche de transport» o Couche de transport sécurisé.

Le serveur OpenLDAP et ses clients peuvent utiliser le cadre TLS pour assurer une protection en matière d'intégrité et de confidentialité, ainsi que pour prendre en charge l'authentification LDAP sécurisée via le mécanisme SASL «Authentification simple et couche de sécurité« Externe.

Les serveurs OpenLDAP modernes favorisent l'utilisation de */ StartTLS /* o Démarrer une couche de transport sécurisé vers le protocole /LDAPS: ///, qui est obsolète. Pour toute question, visitez * Démarrer TLS v. ldaps: // * en http://www.openldap.org/faq/data/cache/605.html

Laissez simplement le fichier installé par défaut / etc / default / slapd avec la déclaration SLAPD_SERVICES = »ldap: /// ldapi: ///», dans le but d'utiliser un canal crypté entre le client et le serveur, et les applications auxiliaires elles-mêmes pour administrer l'OpenLDAP qui sont installés localement.

La méthode décrite ici, basée sur les packages gnutls-bin y SSL-cert il est valable pour Debian 6 "Squeeze" et aussi pour Ubuntu Server 12.04. Pour Debian 7 "Wheezy" une autre méthode basée sur OpenSSL.

La génération des certificats dans Squeeze est effectuée comme suit:

1.- Nous installons les packages nécessaires
: ~ # aptitude installer gnutls-bin ssl-cert

2.- Nous créons la clé primaire pour l'autorité de certification
: ~ # sh -c "certtool --generate-privkey> /etc/ssl/private/cakey.pem"

3.- Nous créons un modèle pour définir le CA (Certificate Authority)
: ~ # nano /etc/ssl/ca.info cn = Amis cubains ca cert_signing_key

4.- Nous créons le certificat CA auto-signé ou auto-signé pour les clients
: ~ # certtool --generate-self-signed \ --load-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/ca.info \ --outfile / etc / ssl / certs / cacert.pem

5.- Nous générons une clé privée pour le serveur
: ~ # certtool --generate-privkey \ --bits 1024 \ --outfile /etc/ssl/private/mildap-key.pem

Note: Remplacer "doux"dans le nom de fichier ci-dessus pour votre propre serveur. Nommer le certificat et la clé, à la fois pour le serveur et pour le service qui l'utilise, nous aide à garder les choses claires.

6.- Nous créons le fichier /etc/ssl/mildap.info avec le contenu suivant:
: ~ # nano /etc/ssl/mildap.info organization = Amis cubains cn = mildap.amigos.cu tls_www_server encryption_key signature_key expiration_days = 3650

Note: Dans le contenu précédent, nous déclarons que le certificat est valable pour une période de 10 ans. Le paramètre doit être ajusté à notre convenance.

7.- Nous créons le certificat de serveur
: ~ # certtool --generate-certificate \ --load-privkey /etc/ssl/private/mildap-key.pem \ --load-ca-certificate /etc/ssl/certs/cacert.pem \ --load- ca-privkey /etc/ssl/private/cakey.pem \ --template /etc/ssl/mildap.info \ --outfile /etc/ssl/certs/mildap-cert.pem

Jusqu'à présent, nous avons généré les fichiers nécessaires, nous n'avons qu'à ajouter au répertoire l'emplacement du certificat auto-signé cacert.pem; celui du certificat de serveur mildap-cert.pem; et la clé privée du serveur mildap-key.pem. Nous devons également ajuster les permissions et le propriétaire des fichiers générés.

: ~ # nano /etc/ssl/certinfo.ldif
dn: cn = config add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem - ajouter: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert.pem - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ssl/certs/mildap-cert. -key.pem

8.- On ajoute: ~ # ldapmodify -Y EXTERNAL -H ldapi: /// -f /etc/ssl/certinfo.ldif

9.- Nous ajustons le propriétaire et les autorisations
: ~ # adduser openldap ssl-cert: ~ # chgrp ssl-cert /etc/ssl/private/mildap-key.pem: ~ # chmod g + r /etc/ssl/private/mildap-key.pem: ~ # chmod ou /etc/ssl/private/mildap-key.pem

Le certificat cacert.pem C'est celui que nous devons copier dans chaque client. Pour que ce certificat soit utilisé sur le serveur lui-même, nous devons le déclarer dans le fichier /etc/ldap/ldap.conf. Pour ce faire, nous modifions le fichier et le laissons avec le contenu suivant:

: ~ # nano /etc/ldap/ldap.conf
BASE dc = amis, dc = cu URI ldap: //mildap.amigos.cu TLS_CACERT /etc/ssl/certs/cacert.pem

Enfin et aussi à titre de vérification, nous redémarrons le service giflé et nous vérifions la sortie du syslog depuis le serveur, pour savoir si le service a été redémarré correctement à l'aide du certificat nouvellement déclaré.

: ~ # redémarrage du service slapd
: ~ # tail / var / log / syslog

Si le service ne redémarre pas correctement ou si nous constatons une erreur grave dans le syslog, ne soyons pas découragés. Nous pouvons essayer de réparer les dégâts ou recommencer. Si nous décidons de repartir de zéro, l'installation du giflé, il n'est pas nécessaire de formater notre serveur.

Pour effacer tout ce que nous avons fait jusqu'à présent pour une raison ou une autre, nous devons désinstaller le package giflé, puis supprimez le dossier / var / lib / ldap. Il faut aussi laisser le fichier dans sa version d'origine /etc/ldap/ldap.conf.

Il est rare que tout fonctionne correctement du premier coup. 🙂

N'oubliez pas que dans le prochain épisode, nous verrons:

• Authentification des utilisateurs locaux
• Remplir la base de données
• Gérez la base de données à l'aide des utilitaires de la console
• Résumé à ce jour ...

A bientôt mes amis !.