[Samba] heimdal/AD documentation

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é dela 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@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@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@univ-paris3.fr

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBI81SjZByZEPQX7ZIRAjl3AKCGT5dNI5d4GFl4OSz9J/fhivDOZgCfYUSB
+JBdSNwwQ2Lc51A+wP38dm4=
=uEgk
-----END PGP SIGNATURE-----

I have no idea what this guide does as I am not a french speaker. Would
it anable AD to authenticate users against LDAP directory?

Andrei
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba