Introduction

Dans ce 1er article nous verrons ensemble comment nous authentifier sur un serveur Linux en nous appuyant sur le protocole RADIUS (pour Remote Authentification DIal-in User Service, protocole AAA).

Il s’agit plus d’une découverte du « système » PAM (Pluggable Authentication Modules) car son implémentation peut devenir relativement complexe. Il peut notamment permettre la mise en place de diverses stratégies et mécanismes d’authentification comme LDAP, kerberos, lecteur d’empreinte digital etc… PAM fait également office d’API, de librairie… Ce qui ouvre beaucoup de possibilités aux développeurs et différents langages de programmation.

Si vous utilisez déjà un serveur d’annuaire Microsoft pour authentifier vos utilisateurs en entreprise (Active Directory), l’intérêt sera de pouvoir se baser sur ce dernier pour authentifier de la même manière les linuxiens 😉

Cela permet de faciliter la gestion des utilisateurs (une seule base de données), d’augmenter le niveau de sécurité et d’apporter plus de confort à l’utilisateur final.

Nous nous attarderons un peu sur la partie débogage que je trouve intéressante.

Pré-requis

• Un serveur RADIUS opérationnel avec les règles qui vont bien comme FreeRADIUS ou NPS Server de Microsoft
• Un serveur Linux sur une architecture Debian assez récente (Debian 8 ou Ubuntu 16.04 par exemple)
• Un compte utilisateur ayant un accès avec privilèges (via sudo ou root directement)
• Un accès console SSH ou un terminal
• Un éditeur de texte comme vi
• Un accès Internet
• Un serveur Active Directory Microsoft

Installation et configuration du module PAM

Important: Assurez-vous de garder un shell ouvert durant les opérations, afin de vous assurer de toujours avoir la main et de faire un rollback en cas de soucis

Nous installons la librairie RADIUS en premier lieu :

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install libpam-radius-auth

Nous devons ensuite créer les comptes utilisateurs sur le serveur Linux. Ils doivent strictement correspondre au logon name c.-à-d. au champ « sAMAccountName » dans l’annuaire :

sudo useradd -s /bin/bash -m -G sudo admin

A noter que l’on ne créé pas de mot de passe pour cet utilisateur.

On modifie les propriétés du fichier de configuration de la librairie ainsi que les droits associés. Par sécurité, il ne doit appartenir qu’au compte root en lecture/écriture :

sudo chown root /etc/pam_radius_auth.conf
sudo chmod go-rwx /etc/pam_radius_auth.conf

On édite ce fichier de configuration et on ajoute notre serveur RADIUS dans la section adéquate :

sudo vi /etc/pam_radius_auth.conf

# server[:port] shared_secret      timeout (s)
#127.0.0.1      secret             1
[adresse IP du serveur RADIUS] :1812     [secret/mot de passe partagé]    60

Suivant la version de votre serveur RADIUS, vous devrez peut-être mettre le port UDP 1645 à la place de UDP 1812. A noter qu’il est préférable d’augmenter le timeout à 60 secondes, notamment si vous utilisez du 2FA. Pour laisser le temps aux usagers de se connecter si leur connexion n’est pas bonne.

Autorisons maintenant l’authentification par le protocole RADIUS en SSH. Nous allons pour cela éditer le fichier suivant et ajouter la ligne qui commence par « auth… » au tout début, juste avant le ligne « @include common-auth » :

sudo vi /etc/pam.d/sshd

# Standard Un*x authentication.
auth        sufficient     /lib/security/pam_radius_auth.so
@include common-auth

Petite explication sur cette ligne :

auth = permet la vérifier l’identité de l’utilisateur lors de la connexion

sufficient = cela indique que si le test d’authentification réussi (utilisateur existant dans l’annuaire et mot de passe correct), le traitement s’arrête là.

/lib/security/pam_radius_auth.so = chemin vers la librairie utilisée, RADIUS dans notre cas

En effet, ce fichier, et un fichier « PAM » de manière générale,  comprend un séquencement d’opérations qui sont traitées successivement sur conditions (échec ou réussite). Cela représente une « pile » de règles en quelque sorte.

Pour plus de détails et d’explications claires, je vous invite à vous rendre sur ce site : http://debian-facile.org/doc:systeme:pam

A ce stade, un administrateur linux pourra s’authentifier mais il n’aura pas de privilèges. On doit donc éditer le fichier suivant et ajouter la ligne qui commence par « auth… » au tout début, juste avant le ligne « @include common-auth » :

sudo vi /etc/pam.d/sudo

# Standard Un*x authentication.
auth        sufficient     /lib/security/pam_radius_auth.so
@include common-auth

Et enfin, on doit autoriser l’administrateur à changer de compte utilisateur si besoin. Aussi, on va donc éditer le fichier suivant et cette fois on ajoute la ligne qui commence par « auth… » en fin de fichier, juste avant le ligne « @include common-auth » :

sudo vi /etc/pam.d/sudo

# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
auth        sufficient     /lib/security/pam_radius_auth.so
@include common-auth

La partie configuration est terminée. Passons à la phase de test !

Tests et débogage

Si tout va bien, vous devriez pouvoir vous connecter en SSH avec votre compte Active Directory et voir apparaître le prompt :

Last login: Wed Feb 7 14:25:01 2018 from mon_pc.mon_domaine.corp
admin@mon_serveur-01:~$

On vérifie que notre compte a bien les privilèges en appelant une commande non accessible pour un utilisateur sans droit :

admin@mon_serveur-01:~$ sudo ifconfig
[sudo] password for admin:
eth0 Link encap:Ethernet HWaddr 00:50:13:37:05:34
  inet addr:10.66.0.200 Bcast:10.66.0.255 Mask:255.255.255.0
  inet6 addr: fe80::250:56ff:fe85:6ffb/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
  RX packets:109443470 errors:0 dropped:1 overruns:0 frame:0
  TX packets:18550308 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:10289511895 (9.5 GiB) TX bytes:2060556027 (1.9 GiB) 

De la même manière vous devriez être en mesure de passer root et changer d’utilisateur :

admin@mon_serveur-01:~$ sudo su (votre mot de passe)
root@mon_serveur-01:/home/admin#

admin@mon_serveur-01:~$ su root (mot de passe root cette fois)
root@mon_serveur-01:/home/admin#

En cas de soucis, vous avez la possibilité d’activer le mode debug. Pour cela, il faut ajouter le mot clé « debug » comme ici dans le fichier « /etc/pam.d/sshd » (mais applicable dans tout fichier « PAM ») :

auth sufficient /lib/security/pam_radius_auth.so debug

Assurez-vous ensuite que votre serveur log correctement les messages en mode « debug » dans un fichier de logs, qui est le mode le plus bavard.

Si ce n’est pas le cas, ajoutez ce fichier dans le répertoire rsyslog, service installé par défaut normalement (remplaçant de syslog, sinon installez-le avec « sudo apt-get install rsyslog« ) :

sudo vi /etc/rsyslog.d/80-debug.conf

Puis ajoutez ceci dedans :

$template debug-mode,"/var/log/%hostname%-debug.log"
*.* ?debug-mode

Cela aura pour effet de rediriger/d’écrire l’ensemble des messages du serveur dans un fichier qui aura comme nom le nom du serveur: mon_serveur-01-debug.log

Pour que le changement soit pris en compte, il faut relancer le service rsyslog :

sudo systemctl restart rsyslog.service

Ou suivant votre gestionnaire de système :

sudo service rsyslog restart

En enfin, affichez les logs à l’écran en temps réel grâce à la commande tail -f et en filtrant les messages :

tail -f /var/log/mon_serveur-01-debug.log | grep sshd

Ici j’ai rentré un utilisateur qui est inconnu sur le serveur Linux et dans l’Active Directory (j’ai retiré l’horodatage pour une meilleure lecture) :

sshd[31232]: Invalid user le_matou from 192.168.2.200
sshd[31232]: input_userauth_request: invalid user le_matou [preauth]
sshd[31232]: pam_radius_auth: Got user name le_matou
sshd[31232]: pam_radius_auth: Sending RADIUS request code 1
sshd[31232]: pam_radius_auth: Got RADIUS response code 3
sshd[31232]: pam_radius_auth: authentication failed
sshd[31232]: pam_unix(sshd:auth): check pass; user unknown
sshd[31232]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mon_pc.mon_domaine.corp
sshd[31232]: Failed password for invalid user le_matou from 192.168.2.200 port 21962 ssh2
sshd[31232]: Connection closed by 192.168.2.200 [preauth]

On voit que le système détecte d’emblée que le compte utilisateur n’existe pas sur le serveur puis que le serveur RADIUS rejette l’utilisateur.

Un autre cas où cette fois l’utilisateur existe bien sur le serveur Linux (avec un mot de passe) mais pas dans l’Active Directory :

sshd[26457]: pam_radius_auth: Got user name le_matou
sshd[26457]: pam_radius_auth: Sending RADIUS request code 1
sshd[26457]: pam_radius_auth: Got RADIUS response code 3
sshd[26457]: pam_radius_auth: authentication failed
sshd[26457]: Accepted password for le_matou from 192.168.2.200 port 22070 ssh2
sshd[26457]: pam_unix(sshd:session): session opened for user le_matou by (uid=0)

Cela fonctionne mais grâce à l’authentification locale de PAM dans ce cas. Cela pourrait être utile en cas de défaillance ou d’inaccessibilité du ou des serveurs RADIUS configuré(s). Soit vous avez un compte utilisateur de « secours » (que vous conserveriez soigneusement dans votre KeePass 😉 ), soit vos utilisateurs utilisent un mot de passe « de secours », ce que je ne conseille pas.

Côté serveur RADIUS on verra ce type d’événement lors d’un rejet (ici une log d’un serveur NPS de Microsoft, le client utilise un PC sous Windows 10 donc pas de client NAP) :

User:
Security ID: S-1-0-0
Account Name: le_matou
Account Domain: DOMAINE
Fully Qualified Account Name: DOMAINE\le_matou
Client Machine:
 Security ID: S-1-0-0
 Account Name: -
 Fully Qualified Account Name: -
 OS-Version: -
 Called Station Identifier: -
 Calling Station Identifier: mon_serveur-01.mon_domaine.corp

NAS:
 NAS IPv4 Address: 127.0.0.1
 NAS IPv6 Address: -
 NAS Identifier: sshd
 NAS Port-Type: Virtual
 NAS Port: 8206

RADIUS Client:
 Client Friendly Name: SERVER_IN_10.66.0.0/24
 Client IP Address: 10.66.0.200

Authentication Details:
 Connection Request Policy Name: Request SERVER_IN_10.66.0.0/24
 Network Policy Name: -
 Authentication Provider: Windows
 Authentication Server: mon_serveur_RADIUS.mon-domaine.corp
 Authentication Type: PAP
 EAP Type: -
 Account Session Identifier: -
 Logging Results: Accounting information was written to the local log file.
 Reason Code: 16
 Reason: Authentication failed due to a user credentials mismatch. Either the user name provided does not map to an existing user account or the password was incorrect.

Il existe également un petit utilitaire bien pratique développé par FreeRADIUS (je crois) qui s’appelle « radtest ». Il s’installe de cette manière :

sudo apt-get install freeradius-utils

Il suffit ensuite de taper la commande suivante (pensez à vider votre historique bash ensuite avec « history -c ») :

radtest -x -4 "compte utilisateur AD" "mot de passe AD" [addresse ip/fqdn du serveur radius]:1812 0 "secret partagé (mot de passe)"

Suivant la version de votre serveur RADIUS, vous devrez peut-être mettre le port UDP 1645 à la place de UDP 1812.

Voici une trace lorsque le test fonctionne :

Sending Access-Request of id 93 to mon_serveur_RADIUS.mon-domaine.corp port 1812
 User-Name = "admin"
 User-Password = "***********"
 NAS-IP-Address = 127.0.0.1
 NAS-Port = 0
 Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host mon_serveur_RADIUS.mon-domaine.corp port 1812, id=93, length=202
 Marque-Exec-Privilege = 3
 Marque-AVPair = "web-administrative-role=Manager"
 Filter-Id = "Marque:version=1:mgmt=su:policy=SYS_ADMIN_AAA"
 Login-Service = 50
 Service-Type = Administrative-User
 Class = 0x89d4084f00006543102000a0a047900000000789764a6f44df9d01d3993c0951af0700000000000353bd
 MS-Link-Utilization-Threshold = 50
 MS-Link-Drop-Time-Limit = 120

Cela permet notamment de voir les attributs de l’utilisateur.

Important : Une fois le débogage terminé, pensez à commenter (# en début de ligne) les 2 lignes du fichier de configuration rsyslog et relancez le service. Avec le temps, vous risquez d’avoir un TRÈS gros fichier. Sinon, utilisez le service logrotate afin d’archiver et compresser les messages.

Le mot de la fin

Voilà, c’est tout pour cet article. J’espère avoir pu aider ou éclairer quelques personnes 😉

J’ajouterai que par sécurité et redondance, il est préférable d’avoir aux moins 2 serveurs RADIUS configurés. Utile lors des maintenances, ce sera transparent pour les utilisateurs.

Comme indiqué en introduction, il s’agit d’une « simple » introduction. Nous pourrions aller plus loin en gérant le changement de mot de passe, la création automatique des répertoires à la première connexion etc…