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@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 -------------- 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