Kerberos keytab désynchronisé après maintenance Windows Server : le fix en 3 commandes

Tags : kerberos, linux, windows-server, glpi, apache, sysadmin
Durée de lecture : 3 min

Petit mémo à chaud. C’est le genre de panne qui fait perdre une heure si on cherche au mauvais endroit, et 30 secondes à corriger une fois qu’on a compris.

Le contexte

Environnement Windows Server avec Active Directory (MONDOMAINE.LAN), un GLPI sur Linux (glpi.mondomaine.lan) qui fait de l’authentification SSO via mod_auth_gssapi / SPNEGO. Ça tourne sans problème depuis des mois.

Maintenance mensuelle sur les DC : reboots, mises à jour, la routine. Au retour : plus personne ne se logue sur GLPI en SSO. Les utilisateurs tombent sur un prompt d’authentification basique ou un 401 direct.

Le symptôme

Dans les logs Apache, mod_auth_gssapi est catégorique :

HTTP/glpi.mondomaine.lan@MONDOMAINE.LAN kvno 12 not found in keytab; keytab is likely out of date

Traduction : le kvno (Key Version Number) enregistré dans le keytab local ne correspond plus à celui d’Active Directory. AD a incrémenté la version de la clé du compte de service pendant la maintenance, et le keytab Linux est resté sur l’ancienne version.

Le diagnostic

Deux commandes pour confirmer le désync :

# Version stockée dans le keytab local
klist -kte /etc/krb5.keytab

# Version actuelle côté AD
kvno HTTP/glpi.mondomaine.lan@MONDOMAINE.LAN

Si les numéros divergent, c’est bien ça. Le serveur tente de déchiffrer les tickets Kerberos entrants avec une clé périmée — l’échange échoue systématiquement.

Le fix

# 1. Vider le cache Kerberos
kdestroy -A

# 2. Renouveler le TGT depuis le keytab
kinit -kt /etc/krb5.keytab HTTP/glpi.mondomaine.lan@MONDOMAINE.LAN

# 3. Vérifier que le ticket est valide
klist

# 4. Redémarrer Apache
systemctl restart apache2

Retour immédiat du SSO. Durée d’intervention effective : 30 secondes.

Ce qu’il s’est passé exactement

Les mises à jour Windows Server peuvent provoquer une rotation des clés Kerberos sur les comptes de service, notamment lors de certains patchs liés à l’authentification ou d’un redémarrage du KDC. Le kvno est incrémenté côté AD, mais le keytab sur le serveur Linux n’est pas notifié et reste sur l’ancienne version.

Ce n’est pas un bug — c’est le comportement attendu. C’est juste une dépendance opérationnelle à avoir en tête : toute maintenance AD peut casser l’auth Kerberos sur les hôtes Linux joints au domaine.

À retenir

Après une fenêtre de maintenance AD, penser à vérifier les services Linux GSSAPI.
Le symptôme est toujours le même : 401 ou fallback basic auth, avec kvno X not found in keytab dans les logs.
Le fix prend 30 secondes. Le diagnostic aussi, si on sait où regarder.
Si vous avez plusieurs hôtes Linux GSSAPI dans le parc (GLPI, Zabbix, etc.), un playbook Ansible post-maintenance règle le problème de façon systématique. Sujet d’un prochain article.

Environnement : Ubuntu 24.04 / Apache 2.4 / mod_auth_gssapi / Windows Server 2022 AD