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/[EMAIL PROTECTED] ... 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
signature.asc
Description: This is a digitally signed message part.
-- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba