4 – Kerberos

Installons et configurons Kerberos.

sudo aptitude install krb5-kdc krb5-admin-server

Le message d’erreur : « krb5kdc: cannot initialize realm EXEMPLE.LOCAL – see log file for détails » peut apparaître.

C’est normal !

La paquet va automatiquement configurer Kerberos pour utiliser le realm (royaume) adéquat à partir des informations fournies par Dnsmasq. Nous avons simplement à créer la base de données du realm:

sudo krb5_newrealm

Dans un premier temps, le serveur charge des données aléatoires pour chiffrer la base de données Kerberos.

Ca peut être long !

Puis vous devez entrer un mot de passe pour Kerberos (master key). Utilisez de préférence un mot de passe sécurisé (assez long) mais facile à retenir.

Pour configurer Kerberos pour l’utilisation de NFS, nous devons créer un utilisateur admin

sudo kadmin.local

L’outil affiche ce qui suit:

Authenticating as principal root/admin@EXEMPLE.LOCAL with password.
kadmin.local:

Il faut alors taper ceci :

addprinc MonNomDUtilisateur/admin

(Remplacer MonNomDUtilisateur par votre nom )

Entrez un mot de passe et quittez :

WARNING: no policy specified for MonNomDUtilisateur/admin@EXEMPLE.LOCAL; defaulting to no policy
Enter password for principal « MonNomDUtilisateur/admin@EXEMPLE.LOCAL »:
Re-enter password for principal « MonNomDUtilisateur/admin@EXEMPLE.LOCAL »:
Principal « MonNomDUtilisateur/admin@EXEMPLE.LOCAL » created.
kadmin.local: quit

Nous devons donner les droits d’admin à ce nouvel utilisateur. Pour cela il faut modifier la liste des contrôles d’accès de Kerberos (/etc/krb5kdc/kadm5.acl).

sudo nano /etc/krb5kdc/kadm5.acl

Ce fichier devrait contenir :

# This file Is the access control list for krb5 administration.
# When this file is edited run /etc/init.d/krb5-admin-server restart to activate
# One common way to set up Kerberos administration is to allow any principal
# ending in /admin is given full administrative rights.
# To enable this, uncomment the following line:
*/admin *

Il suffit de dé-commenter la dernière ligne pour que tous les utilisateurs /admin principaux aient les droits d’administration.

Pour que Kerberos prenne en compte les modifications, on doit le redémarrer.

sudo service krb5-admin-server restart

Maintenant, nous pouvons vérifier que tous fonctionne correctement :

kinit MonNomDUtilisateur/admin

Entrez le mot de passe de l’utilisateur puis lancer klist:

klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: MonNomDUtilisateur/admin@EXEMPLE.LOCAL
Valid starting Expires Service principal
02/05/11 19:57:24 02/06/11 05:57:24 krbtgt/EXEMPLE.LOCAL@EXEMPLE.LOCAL
renew until 02/06/11 19:57:21

Si l’affichage ressemble à celui ci-dessus, alors félicitations, vous avez un royaume Kerberos fonctionnel !

Pour être sûr que tous les services (samba pour clients Windows, en particulier) puisse utiliser le royaume correctement, il faut ajouter des informations sur le royaume dans le fichier « /etc/krb5.conf » comme ceci :

[libdefaults]
default_realm = EXEMPLE.LOCAL

# The following krb5.conf variables are only for MIT Kerberos.
krb4_config = /etc/krb.conf
krb4_realms = /etc/krb.realms
kdc_timesync = 1
ccache_type = 4
forwardable = true
proxiable = true

# The following encryption type specification will be used by MIT Kerberos
# if uncommented. In general, the defaults in the MIT Kerberos code are
# correct and overriding these specifications only serves to disable new
# encryption types as they are added, creating interoperability problems.
#
# Thie only time when you might need to uncomment these lines and change
# the enctypes is if you have local software that will break on ticket
# caches containing ticket encryption types it doesn’t know about (such as
# old versions of Sun Java).

# default_tgs_enctypes = des3-hmac-sha1
# default_tkt_enctypes = des3-hmac-sha1
# permitted_enctypes = des3-hmac-sha1

# The following libdefaults parameters are only for Heimdal Kerberos.
v4_instance_resolve = false
v4_name_convert = {
host = {
rcmd = host
ftp = ftp
}
plain = {
something = something-else
}
}
fcc-mit-ticketflags = true

[realms]
EXEMPLE.LOCAL = {
kdc = bidule.exemple.local
admin_server = bidule.exemple.local
master_kdc = bidule.exemple.local
default_domain = exemple.local
}

Authentification sur le Server

Bien que nous n’ayons aucun utilisateur dans le domaine, nous allons configurer le serveur afin qu’il accepte les authentifications.

Ce qui va être fait en utilisant SSSD.

sudo aptitude install sssd

SSSD est magique ! Il va se configurer tout seul à partir des informations que nous avons déjà données jusqu’ici.
La seule chose à faire, est de lui dire de ne pas utiliser TLS pour LDAP.
Ce que nous allons faire en modifiant le fichier /etc/sssd/sssd.conf:

sudo nano /etc/sssd/sssd.conf

Modifiez la ligne “ldap_tls_reqcert = demand” par « ldap_tls_reqcert = never »

Il y a un bug non résolu sous Ubuntu, dans certains cas, le script qui génère le fichier /etc/sssd.conf ne fonctionne pas. Si c’est votre cas, il faut configurer sssd.conf manuellement, comme ceci :

sudo nano /etc/sssd/sssd.conf

[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = exemple.local

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/exemple.local]
; Using enumerate = true leads to high load and slow response
enumerate = false
cache_credentials = true

id_provider = ldap
auth_provider = krb5
chpass_provider = krb5

ldap_uri = ldap://ldap.exemple.local
ldap_search_base = dc=exemple,dc=local
ldap_tls_reqcert = never

krb5_kdcip = kerberos.exemple.local
krb5_realm = EXEMPLE.LOCAL
krb5_changepw_principle = kadmin/changepw
krb5_auth_timeout = 15

Pour que sssd démarre correctement, le fichier de configuration ne doit être lisible que par root. Si le fichier existait déjà au moment de l’édition, cette étape n’est pas nécessaire.

sudo chmod 600 /etc/sssd/sssd.conf

Maintenant, vous pouvez redémarrer sssd

sudo service sssd restart

SSH Kerberisé !

Comme les authentifications kerberos fonctionnent, nous allons activer le SSH kerberisé, ainsi, quand les utilisateurs ont ouvert une session sur une machine client, un simple “ssh bidule” va ouvrir une session directement sur le serveur bidule sans demande de mot de passe supplémentaire.

Premièrement, modifiez /etc/ssh/sshd_config et changez GSSAPIAuthentication de « no » à « yes ».
Laissez les autres options Kerberos par défaut.