Les applications et utilitaires
1. Cas de l’application de monitoring OP5
De nombreuses applications peuvent également être connectées à un annuaire LDAP permettant ainsi de s’affranchir de l’administration fastidieuse des comptes utilisateurs de l’entreprise. Nous allons prendre le cas d’une application de monitoring OP5 basée sur le monitoring Nagios.
Dans le cas d’OP5, il faut naviguer dans le menu de configuration de l’application en cliquant sur Manage et trouver la section de configuration de l’authentification, menu Configure :
¬
Figure 13-5
Puis, cliquer sur le bouton auth-module :
¬
Figure 13-6
Il faut ensuite lui ajouter un nouveau module en spécifiant l’utilisation du protocole LDAP :
¬
Figure 13-7
Puis une nouvelle boîte de dialogue apparaîtra dans laquelle il faudra remplir les informations habituelles. À noter que les utilisateurs seront récupérés par leur appartenance à la classe d’objet account et l’identifiant utilisé sera leur attribut uid.
¬
Figure 13-8
¬
Lors de la configuration d’une nouvelle application à un annuaire LDAP, il est conseillé de toujours commencer par tester sa configuration en mode non sécurisé car ainsi, en cas de problème, on s’affranchit des problèmes de certificats qui peuvent vraiment être très fastidieux à résoudre.
Il faut ensuite tester... Dans le cas de l’application OP5, il faut procéder comme ci-dessous :
¬
Figure 13-9
Si en rentrant un utilisateur LDAP dans la zone de recherche, ses groupes d’appartenance s’affichent, alors cela signifie que la connexion vers l’annuaire LDAP fonctionne parfaitement.
¬
Figure 13-10
Ceci étant validé, il est possible maintenant de configurer l’accès en LDAPS qui doit toujours être privilégié compte tenu du passage en clair des mots de passe sur le réseau.
Il faut donc reprendre sa configuration pour ainsi changer de port et choisir l’encryption ssl :
¬
Figure 13-11
L’application OP5 se réfère au fichier de configuration /etc/openldap/ldap.conf et à sa directive TLS_CACERTDIR pour trouver les certificats :
TLS_CACERTDIR   /etc/openldap/cacerts 
TLS_REQCERT     allow 
### TLS_CACERT directive doesn’t work for OP5 web gui authentication 
#TLS_CACERT     /etc/openldap/cacerts/DigiCertCA.crt 
URI ldaps://ldap01.exemple.com:636  
ldaps://ldap02.exemple.com:636 
BASE dc=exemple,dc=com
Dans notre cas, nous allons copier notre certificat DigiCertCA.crt dans ce répertoire :
[root@prod-op5-01 cacerts]# cp cacerts /etc/openldap/cacerts 
[root@prod-op5-01 cacerts]# cat DigiCertCA.crt 
-----BEGIN CERTIFICATE----- 
MIIEsTCCA5mgAwIBAgIQBOHnpNxc8vNtwCtCuF0VnzANBgkqhkiG9w0BAQsFADBs 
MqswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3 
... . 
xICaEnL6VpPX/78whQYwvwt/Tv9XBZ0k7YXDK/umdaisLRbvfXknsuvCnQsH6qqF 
0wGjIChBWUMo0oHjqvbsezt3tkBigAVBRQHvFwY+3sAzm2fTYS5yh+Rp/BIAV0Ae 
cPUeybQ= 
-----END CERTIFICATE-----
L’application OP5 étant en fait un serveur Apache, il faut juste s’assurer que l’utilisateur propriétaire de l’instance httpd de l’application OP5 puisse lire le certificat contenu dans le répertoire /etc/openldap/cacerts.
# Set the rights for the ’/etc/openldap/cacerts’ directory 
[root@prod-op5-01 cacerts]#  
[root@prod-op5-01 cacerts]# chown -R root:root cacerts 
[root@prod-op5-01 cacerts]# chmod -R 744 cacerts 
 
[root@prod-op5-01 openldap]# ls -lrt 
total 12 
drwxr-xr-x. 2 root root 4096 Oct 17  2014 certs 
drwxr--r--  2 root root 4096 Jul 27 10:18 cacerts 
-rw-r--r--  1 root root  352 Aug  2 08:13 ldap.conf 
[root@prod-op5-01 openldap]# cd cacerts 
[root@prod-op5-01 cacerts]# ls -lrt 
total 4 
-rwxr--r-- 1 root root 1716 May  9 02:05 DigiCertCA.crt 
lrwxrwxrwx 1 root root   14 Jul 27 10:18 38ae8eda.0 -> DigiCertCA.crt 
[root@prod-op5-01 cacerts]#
Puis redémarrer le service Apache :
service httpd restart
Pour valider le bon fonctionnement il suffira à nouveau d’effectuer le test de connexion précédemment évoqué.
2. Cas du programme sudo
Cette section va aborder un nouveau cas de figure avec l’intégration d’un programme (sudo) à l’annuaire LDAP de démonstration depuis un client Linux en Red Hat 6.
Il faut tout d’abord s’assurer que la version installée est bien compilée avec le support LDAP.
Voici ci-dessous quelques commandes systèmes qui pourront aider à le déterminer.
# Une première méthode : 
[root@test01 ~]# rpm -qa | grep -i sudo 
sudo-1.8.6p3-15.el6.x86_64 
 
[root@test01 ~]# rpm -ql sudo-1.8.6p3-15.el6.x86_64 | grep -i ldap 
/etc/sudo-ldap.conf 
/usr/share/doc/sudo-1.8.6p3/README.LDAP 
/usr/share/doc/sudo-1.8.6p3/schema.OpenLDAP 
/usr/share/man/man5/sudoers.ldap.5.gz 
 
# Une seconde méthode pour plus de précaution : 
[root@test01 ~]# which sudo 
/usr/bin/sudo 
[root@test01 ~]# strings -f /usr/bin/sudo | grep -i ldap 
/usr/bin/sudo: --build=x86_64-redhat-linux-gnu --host=x86_64- 
redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program- 
prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin -- 
sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share -- 
includedir=/usr/include --libdir=/usr/lib64 -- 
libexecdir=/usr/libexec --localstatedir=/var -- 
sharedstatedir=/var/lib --mandir=/usr/share/man -- 
infodir=/usr/share/info --prefix=/usr --sbindir=/usr/sbin 
--libdir=/usr/lib64 --docdir=/usr/share/doc/sudo-1.8.6p3 
--with-logging=syslog --with-logfac=authpriv --with-pam 
--with-pam-login --with-editor=/bin/vi --with-env-editor 
--with-ignore-dot --with-tty-tickets --with-ldap 
--with-ldap-conf-file=/etc/sudo-ldap.conf --with-selinux 
--with-passprompt=[sudo] password for %p: --with-linux-audit 
-with-sssd 
/usr/bin/sudo: ldap
À partir de la distribution Red Hat 6, la prise en charge de la gestion des authentifications sur le système se fait au travers du service "sssd". Il faudra donc lui configurer les informations de connexion à notre annuaire OpenLDAP au travers du fichier /etc/sssd/sssd.conf et aussi spécifier au programme "sudo" d’utiliser le service "sssd" au travers du fichier /etc/nsswitch.conf.
Voici ci-dessous le contenu du fichier etc/sssd/sssd.conf :
[root@test01 ~]# cat /etc/sssd/sssd.conf 
[domain/default] 
autofs_provider = ldap 
cache_credentials = True 
account_cache_expiration = 7 
entry_cache_timeout = 14400 
ldap_search_base = dc=exemple,dc=com 
krb5_realm = EXAMPLE.COM 
krb5_server = kerberos.example.com 
id_provider = ldap 
auth_provider = ldap 
chpass_provider = ldap 
sudo_provider = ldap 
ldap_uri = ldaps://ldap01.exemple.com:636 
ldap_backup_uri = ldaps://ldap02.exemple.com:636 
ldap_default_bind_dn = cn=linux,ou=binds,dc=exemple,dc=com 
ldap_sudo_search_base = ou=sudoers,dc=exemple,dc=com 
enumerate = True 
debug_level = 2 
... 
[sssd] 
services = nss, pam, autofs, sudo 
config_file_version = 2 
domains = default 
... 
[sudo] 
...
Hormis les informations de connexion à l’annuaire OpenLDAP déjà étudié lors de la configuration du client LDAP sur un système Red Hat 6, il est possible d’observer dans la section "sssd", la déclaration du programme "sudo" dans le champ "services" qui précise au service "sssd" avec quel(s) service(s) il doit travailler.
Puis, nous retrouvons plus haut dans le fichier les paramètres : sudo_provider qui déclare au programme "sudo" d’utiliser l’annuaire LDAP et ldap_sudo_search_base qui donne donc la base de recherche des informations du programme "sudo" lorsque celui-ci fera appel à lui.
Il y a aussi un champ dédié au service "sudo", mais les paramètres qu’il contient ne sont pas grandement utiles.
Ensuite, il faut configurer le fichier /etc/nsswitch.conf en ajoutant la ligne suivante à la fin du fichier :
sudoers:        files sss
Cela indique au programme "sudo" de chercher son fichier de configuration localement au travers de la valeur "files" ou bien dans un annuaire en faisant appel au service "sssd" au travers de la valeur sss.
Maintenant, il est possible de tester l’accès aux informations du serveur LDAP en se connectant avec un utilisateur LDAP :
[testuser1@prod01 ~]$ id 
uid=60012(testuser1) gid=60001(gtogldap)  
groups=60001(gtogldap),60002(gtoggsit)
Puis, en tapant la commande sudo -l :
[testuser1@test01 ~]$ sudo -l 
Matching Defaults entries for testuser1 on this host: 
    !visiblepw, always_set_home, env_reset, env_keep="COLORS  
DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", 
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", 
    env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT 
LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER 
LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS 
_XKB_CHARSET 
    XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin, 
ignore_local_sudoers, logfile=/var/log/sudosas.log, insults, 
log_host, log_year, !env_reset 
 
User testuser1 may run the following commands on this host: 
    (root) PASSWD: /usr/bin/su root, /usr/bin/su "", /usr/bin/su -, 
/bin/su root, /bin/su -, /bin/su "", /usr/bin/su ss7,  
/usr/bin/su - ss7, /bin/su ss7, /bin/su - ss7, !ALL 
[testuser1@test01 ~]$
Toutes les commandes système autorisées (ou non) par le programme "sudo" pour votre utilisateur LDAP apparaissent, signalant par là-même que le programme "sudo" du système se connecte à l’annuaire OpenLDAP.
Dans le cas contraire, il faudra activer le mode "debug" du service "sssd" pour réaliser des investigations (avec le paramètre : debug_level).