[Samba] heimdal/AD documentation

[Pascal Levy]

as i promise last week, a incomplete documentation about configuring a trust 
beetween a heimdal kdc and a windows AD domain

really sorry for non-french speakers

of course, i'm very interresting in any feedback...


Pascal



 configuration

- le realm Kerberos est DEMO.LOCAL
- le realm du domaine AD est ad.demo.local

La configuration du KDC lui même ne présente pas de difficulté particulière. 
Nous utilisons un KDC Heimdal sur un serveur FreeBSD 6.2. Le service de nom 
de domaine est utilisé pour localiser les services du KDC, rendant la 
configuration des postes clients minimale (utile surtout pour les postes non 
windows). Les enregistrements spécifiques créés pour Kerberos :

 kerberos        IN      CNAME   ns0

_kerberos._udp      IN  SRV     01 00 88 kerberos
_kerberos._tcp      IN  SRV     01 00 88 kerberos
_kpasswd._udp       IN  SRV     01 00 464 kerberos
_kerberos-adm._tcp  IN  SRV     01 00 749 kerberos
_kerberos           IN  TXT     DEMO.LOCAL

Attention : Kerberos est très sensible à deux choses : la synchronisation 
(nécessité d'utiliser ntp pour synchroniser les horloges des machines 
impliquéees) et la résolution de nom. l'utilisation d'un CNAME pour le 
serveur ne pose pas de problème, mais la résolution inverse (PTR) doit 
absolument être configurée de manière adéquate.

Pour le détail de l'installation du KDC, suivre l'excellent article du 
handbook FreeBSD.
Mise en place de la relation de confiance :

La confiance entre les deux realms Kerberos repose sur un principal partagé 
avec une clef commune.

- côté Windows :
dans Outils d'administrations > Domaines et approbations Active Directory

Sur le domaine AD (ici ad.demo.local) clic droit et propriété, puis onglet 
approbations, cliquer sur nouvelle approbation.

Suivre l'assistant, grosso modo, on peut tout laisser par défaut. Le mot de 
passe choisi est particulièrement important : la sécurité de la relation 
d'approbation repose sur lui... Par contre, il n'aura à être rentré que deux 
fois à la création des clefs et n'a même pas besoin d'être conservé.

- côté Unix :

se connecter à l'application d'administration du realm en faisant par 
exemple :

# kadmin -l

créer la clef de confiance :

kadmin> ank krbtgt/AD.DEMO.LOCAL at DEMO.LOCAL 

... avec le même mot de passe utilisé sous Windows. Un prinicipal suffit ici, 
puisque l'approbation doit être unilatérale. Toute la difficulté consiste 
dans la gestion catastrophique des types de clefs par Windows. Le plus simple 
consiste à laisser Heimdal créer ses clefs avec les types par défaut et à 
supprimer ensuite celles qui sont en trop pour ne laisser que le minimum. Ce 
que supporte les différentes versions successives de Windows 2000 à 2003 
n'est pas très clair. La seule solution raisonnable, à moins d'être sur de 
son fait est de ne laisser que le type des-cbc-crc.

Pour voir le détail d'un principal et les types de clefs qu'il contient :

 kadmin> get krbtgt/AD.DEMO.LOCAL

regarder la dernière ligne :

 Keytypes(salttype[(salt-value)]): des3-cbc-sha1(pw-salt), des-cbc-md5
(pw-salt), des-cbc-md4(pw-salt), des-cbc-crc(pw-salt)

supprimer les types qui nous embêtent (enfin, qui embêtent l'AD...) avec par 
exemple :

  kadmin> del_enctype krbtgt/AD.DEMO.LOCAL des3-cbc-sha1

etc, jusqu'à ne garder plus que

 Keytypes(salttype[(salt-value)]): des-cbc-crc(pw-salt)

 La relation de confiance devrait maintenant être fonctionnelle.
configuration des postes Windows :

Windows devrait savoir (dans certaines versions seulement...) utiliser DNS 
pour retrouver le KDC (enregistrement SRV) mais de toute façon pas le realm 
(enregistrement TXT). Il faut donc intervenir sur chaque machine, à commencer 
par le pdc lui même avec un outil qui se trouve dans les supports tools de 
Windows 2003 serveur, à trouver sur le CD et installer séparément.  Ensuite :

ksetup /addkdc DEMO.LOCAL kerberos.bsg.local

mappage des utilisateurs

Pour que les utilisateurs puissent accéder aux ressources du domaine, l'AD 
doit pouvoir trouver un compte qui corresponde. Il faut réaliser un mappage 
entre les principals Kerberos et les comptes du domaine. Le mappage peut être 
réalisé globalement avec 

ksetup /mapuser * *

ou par utilisateur dans l'interface de gestion des comptes de l'AD. Activer 
les "fonctions avancées" et faire un clic droit sur l'utilisateur et "mappage 
des utilisateurs"

on devrait maintenant pouvoir se logger sur un poste du domaine en utilisant 
le domaine Kerberos...
quelques outils utiles...

sur unix :

acquérir un ticket initial sur un KDC

# kinit principal at REALM

 lister les tickets kerberos avec le détails (notamment les fameux 
enctypes...)

# klist -v

 se connecter sur un partage en utilisant le ticket kerberos :

# smbclient -k //serveur/partage

on peut aussi accèder au ldap du contrôlleur de domaine :

ldapsearch -H ldap://dc.ad.bsg.local  -b "dc=ad,dc=bsg,dc=local" 

 sur Windows :

il faut installer le ressource Kit Windows (à télécharger sur microsoft.com) 
pour utiliser klist.exe et ktray.exe (nom exact ?) qui permettent de voir les 
tickets acquis dans une session Windows.


-- 
Pascal Levy
Ingénieur réseaux & ressources informatiques

Bibliothèque InterUniversitaire Sainte Geneviève
tél. : (33) 1 44 41 97 53
Bibliothèque InterUniversitaire de Langues Orientales
tél. : (33) 1 44 77 95 00

pascal.levy at univ-paris3.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.samba.org/archive/samba/attachments/20081013/34b3e30d/attachment.bin