Dans cette 2ème partie (Partie 1) nous allons aborder l’aspect client et le contrôle de ces derniers :
- Règles HBAC : Host Based Access Control, Contrôle d’Accès Basé sur l’Hôte, permet de contrôler qui peut se connecter sur quoi depuis où.
- Règles Sudo : Permet de contrôler les droits des utilisateurs à exécuter des commandes avec Sudo.
- Password Policy : Politique de gestions de mots de passe.
Pré-requis :
- 2 vm installées avec Fedora 27 Workstation à jour
- 1 vm Ubuntu 16.04 Desktop et 1 vm Debian Sid (Facultatif)
- 1 connexion internet pour la récupération des paquets freeipa
Note : Le client SSSD met en cache les informations du serveur freeipa, les créations/modifications que vous faites sur le serveur au niveau des règles HBAC et sudo peuvent ne pas être répercutées immédiatement sur vos clients. Pour accélérer le processus pendant vos tests, utilisez la commande suivante :
service sssd stop && rm -fr /var/lib/sss/db/* && service sssd start
1. Ajouter les clients FreeIPA
Comme dans la partie 1, nous ajoutons nos clients avec cette commande, directement en root sur la VM. Avant l’ajout nous vérifions le bon fonctionnement des DNS, il est important d’arriver à résoudre le FQDN du serveur ipa et du client pour que l’opération se passe correctement, le reverse-dns du client est facultatif à ce stade :
[root@fedora1 ~]# dig +short freeipa0.idm.demo.local A
172.16.110.60
[root@fedora1 ~]# dig +short -x 172.16.110.60
freeipa0.idm.demo.local.
[root@fedora1 ~]# dig +short fedora1.idm.demo.local A
192.168.56.15
[root@fedora1 ~]# yum install ipa-client
[root@fedora1 ~]# ipa-client-install -U --domain=idm.demo.local --realm=IDM.DEMO.LOCAL --server=freeipa0.idm.demo.local --mkhomedir -p admin -w MotDePasse2
Même chose sur notre 2ème client, cette fois ci nous nous connecterons à notre domaine via le serveur réplica :
[root@fedora2 ~]# dig +short freeipa1.idm.demo.local A
172.16.110.61
[root@fedora2 ~]# dig +short -x 172.16.110.61
freeipa1.idm.demo.local.
[root@fedora2 ~]# dig +short fedora2.idm.demo.local A
192.168.56.14
[root@fedora2 ~]# yum install ipa-client
[root@fedora2 ~]# ipa-client-install -U --domain=idm.demo.local --realm=IDM.DEMO.LOCAL --server=freeipa1.idm.demo.local --mkhomedir -p admin -w MotDePasse2
Explication des options :
- -U : mode unattended, sans intervention de l’utilisateur (à désactiver en cas de soucis)
- —domain= : domaine à rejoindre
- —realm= : realm à rejoindre
- —server= : serveur à utiliser par le client
- —mkhomedir : créer automatiquement un dossier dans /home quand un nouvel utilisateur se connectera
- -p : utilisateur autorisé à intégrer des hôtes (ici admin)
- -w : mot de passe admin freeipa définit au début
Nos deux clients sont maintenant dans le domaine, nous devrions pouvoir nous connecter sur l’une ou l’autre avec des Utilisateurs FreeIPA :
[root@fedora1 ~]# ssh testuser1@fedora2.idm.demo.local
Password:
Password expired. Change your password now.
Current Password:
New password:
Retype new password:
Creating home directory for testuser1.
[testuser1@fedora2 ~]$
Nous nous sommes connectés depuis la VM fedora1 sur fedora2 avec l’utilisateur du domaine testuser1, notre dossier home a bien été créé.
FreeIPA demande à l’utilisateur de changer son mot de passe lors de sa première utilisation.
2. HBAC : Host Based Access Control, Contrôle d’Accès Basé sur l’Hôte
Si nous avons pu nous connecter sans problème sur fedora2, c’est parce qu’une règle “allow_all” a été créée à l’installation du paquet freeipa-server (–no-hbac-allow à l’installation pour ne pas la créer)
Cette règle nous donne un bon aperçu de comment fonctionne le module HBAC de FreeIPA, chaque règle est composée de 3 variables :
- Who : Qui, cela peut être un utilisateur ou un groupe d’utilisateurs
- Accessing : Quoi, cela peut être un hôte (ordinateur, vm..) ou un groupe d’hôtes
- Via Service : Comment, via quel type de service : ssh, gdm, ftp, cron…
Nous allons créer une nouvelle règle, pour permettre à testuser1 de se connecter sur fedora1 via ssh et une seconde, pour permettre à testuser2 de se connecter à fedora2 via ssh. Une fois fait nous désactiverons la règle allow_all (mais sans la supprimer).
Testons directement depuis un ordinateur qui n’est pas dans le domaine freeipa :
paul@xps ~> ssh testuser1@fedora1.idm.demo.local
Password:
Creating home directory for testuser1.
[testuser1@fedora1 ~]$ exit
logout
Connection to fedora1.idm.demo.local closed.
paul@xps ~> ssh testuser1@fedora2.idm.demo.local
Password:
Connection to fedora2.idm.demo.local closed by remote host.
Connection to fedora2.idm.demo.local closed.
paul@xps ~> ssh testuser2@fedora2.idm.demo.local
Password:
Creating home directory for testuser2.
[testuser2@fedora2 ~]$ exit
logout
Connection to fedora2.idm.demo.local closed.
paul@xps ~> ssh testuser2@fedora1.idm.demo.local
Password:
Connection to fedora1.idm.demo.local closed by remote host.
Connection to fedora1.idm.demo.local closed.
Tout fonctionne comme configuré, testuser1 peut se connecter sur fedora1 et testuser2 peut se connecter sur fedora2. Lors d’une tentative de connexion non autorisée, la connexion est fermée.
En mode graphique, il faudra ajouter l’un de ces services dans notre règle : gdm si vous utilisez l’environnement gnome ou kdm si vous utilisez l’environnement kde.
Dans notre cas avec l’environnement de bureau cinnamon, c’est lightdm qui gère les sessions, et il n’est pas présent par défaut dans les services freeipa ; nous allons donc l’ajouter (Policy -> HBAC -> HBAC Service), nous créons un nouveau service avec un service name “lightdm” et un commentaire “lightdm”, on l’ajoute ensuite dans la liste des services autorisés, la connexion graphique fonctionne correctement.
Si vous avez un doute sur le service à ajouter pour le gestionnaire de session de votre environnement de bureau, vous pouvez sous Fedora repérer ce qui est refusé dans le log “/var/log/secure”
3. Règles Sudo
Par défaut les règles sudo sont vides dans freeipa, un utilisateur du domaine ne pourra donc pas lancer de commandes avec sudo :
paul@xps ~> ssh testuser2@fedora2.idm.demo.local
Password:
Last login: Sun Apr 1 00:02:36 2018
[testuser2@fedora2 ~]$ yum update
Error: This command has to be run under the root user.
[testuser2@fedora2 ~]$ sudo yum update
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for testuser2:
Sorry, try again.
[sudo] password for testuser2:
Sorry, try again.
[sudo] password for testuser2:
sudo: 3 incorrect password attempts
[testuser2@fedora2 ~]$
Nous allons créer une nouvelle règle permettant à testuser2 de lancer la commande yum update avec sudo.
Une règle sudo est composé de 4 variables :
- Who : Qui peut lancer cette commande
- Access this host : Sur quel hôte la commande peut être lancée
- Run Commands (Allow ou Deny) : Quelles commandes peuvent être lancées ou pas
- As Whom : Quels utilisateurs peuvent être utilisés avec sudo
Avant de pouvoir créer notre règle en elle-même nous allons avoir besoin de définir les commandes (Policy -> Sudo -> Sudo Commands). Nous allons ajouter la commande yum, il faudra y indiquer le chemin complet de l’exécutable (/bin/yum) :
Comme nous utilisons une règle HBAC pour contrôler l’accès à la VM fedora2, il faudra ajouter “sudo” dans les services autorisés de la règle (Policy -> HBAC -> HBAC Rules) :
Et maintenant nous pouvons faire notre règle (Policy -> Sudo -> Sudo Rules) :
[testuser2@fedora2 ~]$ sudo yum update
Last metadata expiration check: 0:48:14 ago on Sun Apr 1 00:12:14 2018.
Dependencies resolved.
Nothing to do.
Complete!
[testuser2@fedora2 ~]$
ça fonctionne !
Il est possible de créer des groupes de commandes pour regrouper les commandes par thème (groupe “editeurs” avec vim et emacs par exemple)
4. Clients Ubuntu et Debian
Freeipa-client est disponible sur Ubuntu 14.04 en version 3.3 et 4.3 en 16.04, Debian propose freeipa-client dans sa dernière version (4.6.3) mais uniquement pour Sid (Unstable).
Sous Ubuntu Desktop 16.04, c’est fonctionnel sans problème après installation du paquet freeipa-client
root@ubuntu:~# apt install freeipa-client
root@ubuntu:~# ipa-client-install -U --domain=idm.demo.local --realm=IDM.DEMO.LOCAL --server=freeipa0.idm.demo.local --mkhomedir -p admin -w MotDePasse2
Client hostname: ubuntu.idm.demo.local
[...]
Client configuration complete.
paul@xps ~> ssh testuser2@ubuntu.idm.demo.local
testuser2@ubuntu.idm.demo.local's password:
Welcome to Ubuntu 16.04.4 LTS (GNU/Linux 4.13.0-37-generic x86_64)
$who
testuser2 pts/0
Sous Debian Sid, l’installation des paquets est possible de la même façon qu’ubuntu, joindre le client au domain ipa n’est pas fonctionnel en l’état, certains certificats doivent être pré-installés manuellement :
root@debian:/~# mkdir -p /var/lib/ipa-client/pki/ && scp root@freeipa0.idm.demo.local:/var/lib/ipa-client/pki/kdc-ca-bundle.pem /var/lib/ipa-client/pki/
Une fois la VM de test intégrée au domaine il est possible de se connecter avec un compte FreeIPA.
paul@xps ~> ssh testuser2@debian.idm.demo.local
Password:
Linux debian 4.15.0-2-amd64 #1 SMP Debian 4.15.11-1 (2018-03-20) x86_64
$ who
testuser2 pts/0
5. Politique de mots de passe
FreeIPA permet de gérer la politique de vos mots de passe, par défaut il existe une “global_policy”. Il est possible de créer une politique de mot de passe différente par groupes.
Résumé des options d’une policy :
- Max lifetime (days) : Durée du mot de passe en jours, au delà, il sera demandé à l’utilisateur de changer son mot de passe.
- Min lifetime (hours) : Durée minimale du mot de passe en heures, il s’agit ici d’éviter que l’utilisateur puisse remettre son ancien mot de passe après un ou plusieurs changements consécutifs.
- History Size (number of passwords) : Nombre de mots de passe à garder en historique, permet de forcer les utilisateurs a ne pas réutiliser leurs anciens mots de passe.
- Character classes : Définir le nombre minimal de “classes” ou “types” sur un mot de passe, par exemple, si nous mettons la valeur à 3, il faudra que notre mot de passe comporte des types de 3 catégories, ces catégories incluent :
- lettres en minuscule
- lettres en majuscule
- nombres
- symboles ( ! . – { ?…)
- Min length : Taille minimale du mot de passe.
- Max failures : Nombres d’erreurs avant que le compte ne soit verrouillé.
- Failure reset interval (seconds) : intervalle de temps avant que le compte d’échecs de mot de passe ne soit remis à zéro.
- Lockout duration (seconds) : durée de verrouillage du compte après avoir dépassé le nombre d’échecs autorisés.
C’est tout pour notre partie 2, dans la partie 3 nous aborderons le sujet de la haute-disponibilité et de la gestion de l’automount.
Notre série sur FreeIPA
Si vous ne les avez pas encore lu, retrouvez notre série d’articles sur FreeIPA :
- FreeIPA Partie 1 : Installation du serveur et de son réplica
- FreeIPA Partie 2 : Clients, HBAC, Sudo, Mots de passe
- FreeIPA Partie 3 : Haute-disponibilité, Automount
- FreeIPA Partie 4 : Seconds facteurs d’authentification
- FreeIPA Partie 5 : Trusts Active Directory
- FreeIPA Partie 6 : Trusts Active Directory, mise en pratique
