Étapes à suivre pour mettre en place une infra Kerberos

La mise en place d’une infrastructure avec une authentification kerberos est toujours complexe et les étapes pour y parvenir peuvent au premier abord apparaitre compliquées.

Ce post a pour but de lister les étapes essentielles pour y parvenir. Il ne s’agit pas de décrire le fonctionnement de ce protocole, mais simplement de me constituer un aide mémoire lorsque j’aurais besoin de monter une infrastructure de tests rapidement.

Prérequis

Kerberos permet la mise en place d’une authentification unique des différents acteurs faisant parti d’un même contexte de nommage DNS. Ce contexte porte le nome de royaume suivant la terminologie du MIT ou de Heimdal, ou domaine (Active Directory ou Samba 4).

Kerberos repose largement sur les protocoles NTP et DNS.

Il est capital de s’assurer que l’ensemble du parc est synchronisé, un écart de plus de 5 minutes fera échouer l’authentification (message clock skew to great lors du kinit).

Il est possible de configurer l’adresse du serveur d’authentification en dur dans le fichier /etc/hosts. Cependant, cette pratique ressemble plus à un mauvais hack et ne passe pas à l’echelle. Il est préférable (c’est ce que font Microsoft ou Samba 4 dans un environnement Active Directory) de se reposer sur le DNS pour fournir l’adresse du serveur d’authentification relative au royaume.

Un champs SRV permet de donner une réponse aux requêtes de type service lorsque le système recherche le service d’authentification

1
2
3
4
5
6

# Configuration dans bind9
_kereros._udp IN SRV 0 0 88 kerberos.huascar.inc

# Vérifier que la résolution directe et la résolution inverse fonctionnent
host kerberos.huascar.inc -> $IP
host $IP -> kerberos.huascar.inc

Installation et configuration

1

aptitude install krb5-admin-server krb5-kdc

Les étapes à suivre ensuite consistent à

• configuration du fichier /etc/krb5.conf
• création du royaume
• sudo krb5_newrealm
• création d’une politique de mots de passe :

1
2
3
4
5

# kadmin.local
> add_policy -minlength 12 -minclasses 4 admin
> add_policy -minlength 15 -minclasses 4 host
> add_policy -minlength 15 -minclasses 4 service
> add_policy -minlength 8  -minclasses 3 user

Il est possible de configurer les utilisateurs destinés à jouer le rôle d’administrateurs dans le fichier /etc/krb5kdc/kadmin5.acl

• */admin * (les utilisateurs de type $CPN/admin ont tous les droits)

Enfin, rajoutons l’utilisateur root du serveur administrateur de kerberos et créons un utilisateur de test

1
2
3
4
5
6
7
8
9

# Sur le serveur kerberos
kadmin.local
> addprinc -policy admin root/admin
> addprinc -policy user test

# Sur un système quelconque ayant connaissance du serveur kerberos
# tester la récupération d'un ticker
$ kinit test
$ klist -> doit normalement lister le TGT

Configuration du service SSH

• Sur le serveur kerberos

Comme n’importe quel client, le service doit s’authentifier sur le service kerberos. Il est nécessaire de créer un ticket qui sera un ticket de service.

1
2
3

kadmin.local
> addprinc -randkey host/server1.huascar.inc
> ktadd # permet l'export de la clef dans un fichier sur le système de fichiers

• Sur le serveur SSH

1
2
3
4

fichier /etc/ssh/sshd_config
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
# KerberosAuthentication no (laisser à no: c'était pour kerberos v4 obsolète)

• Configuration du client SSH

1
2
3
4

fichier /etc/ssh/ssh_config, ou ~/.ssh/config
GSSAPIAuthentication yes
PubkeyAuthentication no
PasswordAuthentication no

• Super documentation qui aide beaucoup
• https://techpubs.spinlocksolutions.com/dklar/kerberos.html

À suivre :

L’authentification est aini basée sur le protocole kerberos, qui stocke les identifiants et les condensats des mots de passe associés dans une base de données locale. Il est préférable d’utiliser comme interface de stockage un annuaire LDAP et ainsi de coupler l’authentification avec la gestion des autorisations. Des ACLs sur des partages réseaux, des espaces restreints sur un wiki, … peuvent ainsi être gérées par l’annuaire LDAP une fois l’utilisateur authentifié avec kerberos.

Également, le protocole kerberos est basé sur une authentification à l’aide de protocoles cryptographiques symétriques. Le point faible restera encore l’utilisateur qui pourra choisir malgré une politique de complexité de mots de passe rigoureuse un authentifiant faible (choisi parmis des mots d’un dictionnaire par exemple). Il est intéressant de protéger l’échange initial de clefs (TGS-req –> TGS-rep) permettant l’obtention d’un TGT à l’aide d’un certificat. Arrivé à ce point, il suffira de stocker celui-ci dans une carte à puce protégée par code PIN.