Blog de ILINFO

Trucs et astuces

Blog ILINFO Active DIrectory MIIS LDAP ADAM PCA PRA BCP DRP

Log in

Problème restauration des comptes associés aux keytab

by Emmanuel Dreux avril 10, 2009 21:26

Contexte:

Un administrateur a mis en place une solution de SSO pour que des utilisateurs d'un domaine Active Directory puissent s'authentifer en Kerberos auprès d'applications JAVA ou aurpès d'applications hébergées sur des machines Unix ou Linux.

Dans ce contexte, des comptes SSO ont été crées dans l'Active Directory.
Il s'agit de comptes de service pour lesquels un keytab a été généré à l'aide de la commande Ktpass.exe (ktpass -princ 'value' -mappuser domain\svcaccount etc.)

Lors de l'éxécution de la commande, le mot de passe du compte de service est modifié et la clé de chiffrement contenue dans le keytab est dérivée du mot de passe.

Un numéro de version du mot de passe appelé kvno est également stocké dans le keytab. Il doit correspondre au numéro de version contenu dans les tickets générés par les KDC. Le KDC récupère le numéro de version depuis l'attribut msDS-KeyVersionNumber. Cet attribut msDS-KeyVersionNumber est un attribut construit (constructed attribute) dont la valeur est égale à une metadonnée de l'attribut UnicodePwd.

 

Problème:

Lors d'une restauration autoritaire (authoritative restore), la métadonnée de l'attribut UnicodePwd est incrémentée de 100 000.

Celà a une double conséquence:

1.  le msDS-KeyVersionNumber (= kvno) est également incrémenté de 100 000 et ne correspond donc plus au numéro de version stocké dans le keytab. En d'autres termes, celà invalide le keytab existant qu'il faut alors regénérer.

2. Le kvno est originellement codé sur 8 bit et accepte des valeus de 0 à 255. Les valeurs supérieures sont alors mal perçues selon les implémentations kerberos. L'implémentation MIT par exemple accepte des kvno > 255 alors que l'implémentation de Vintela (Quest) ne les accepte pas.

Dans un cas de PRA (plan de reprise d'activité, DRP en anglais), où il faut procéder à une restauration autoritaire d'annuaire, il faut alors regénérer tous les keytab des comptes SSO Kerberos Unix et les réinstaller dans chaque application. Si la stack kerberos n'accepte pas les kvno > 255, il faut alors supprimer tous les comptes SSO et les recréer.

 

Contournements:

Vintella accepte des keytab avec un kvno à -1 et dans ce cas ignore si les numéros de version ne correspondent pas (ce n'est pas applicable pour l'implémentation MIT).

Il est donc possible d'éditer les fichiers keytab existants avec un éditeur héxadécimal et de forcer la valeur kvno à FF.

Il est également possible de générer un keytab avec la valeur kvno à -1, pour cela utiliser l'option de ktpass /kvno 255.

 Finalement, il est possible de forcer l'active directory à revenir à la mode Windows 2000 c'est à dire ne jamais incrémenter le  msDS-KeyVersionNumber et lui forcer la valeur à 1 systématiquement.

Pour celà, il faut modifier au niveau de la forêt dans la partition configuration l'attribut dsheuristics.

voir http://support.microsoft.com/kb/870987/en-us

 

Demande de fix :

Une demande de fix (CDCR = Critical Design Change Request) a été formulée auprès de Microsoft.

Ce billet sera mis à jour lorsqu'un statut final sera apporté par Microsoft.

Actuellement noté 5.0 par 1 personne(s)

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: , , , ,

Active Directory | SSO

Partenaires
Assurez votre plan de continuit� d'activit� avec BCPAnywhere
Votre poste de travail partout dans le monde.

Mig6 votre solution de migration de vos postes de travail vers Windows 7
Migrez de XP vers Windows 7 avec Mig6.

Auteur

Freelance, Indépendant, expert Active Directory, Domaine et Sécurité.

Expert MIIS, ILM, FIM 2010,Kerberos, NTLM, SSL, PKI et chiffrement.