Que peut-on faire au niveau du DHCP? D'après ce que je crois savoir, ce sont les machines qui reçoivent leur adresse qui, par >défaut, mettent à jour leurs enregistrements dans le DNS, exact? Personnellement, je considère que BIND + DHCP c'est du (trop) lourd >et je leur préfère DNSmasq, un excellent combiné DHCP + DNS dont le principal avantage est de mettre à jour le DNS sur base du DHCP. Y >a-t'il des pistes à suivre pour Samba 4?
Pour l'instant il y a deux serveurs DNS possible pour Samba 4 et je ne pense pas que DNSmasq soit à l'ordre du jour, avec ISC DHCP est capable de mettre à jour les enregistrements DNS pour les machines à qui il attribue une adresse. Malheureusement ISC utilise un mécanisme de clé partagée pour faire ça et pour l'instant ça ne marche qu'avec Bind (et encore pas sûr que ça marche avec tous les backends), j'avais fait un article sur mon blog il y a quelques temps de cela: http://is.gd/Ox78Iv.
Je pense qu'on y pense mais pour l'instant rien n'est fait.
Peut-on envisager que le service Kerberos intégré dans Samba soit modularisé comme mit-krb5? Ou bien que les améliorations et >personnalisations apportées à ce service soit reprises dans le code de mit-krb5?
La réponse est oui, et c'est même en cours puisque RedHat fournit par défaut MIT comme implementation Kerberos donc pour pouvoir offrir un paquet Samba 4.0 AD pour RHEL il faut qu'il utilise MIT Kerberos comme KDC.
Mais la question c'est quel est exactement le besoin ?
(Je présume que c'est PAC le facteur primordial à >l'origine de l'intégration de Kerberos dans Samba 4?)
Pas vraiment, c'est juste les gens d'heimdal étaient plus ouvert aux changements nécessaire du fait des besoins pour avoir un KDC compatible AD.
Je poserais aussi volontiers la version bis de la question ci-dessus à propos de LDAP.
Je suppose que la question c'est pourquoi pas utiliser Openldap comme serveur LDAP ?, la raison c'est qu'il faudrait ré-écrire plein de modules pour Openldap et il se pose la question de maintient de l'intégrité avec les autres serveurs (Netlogon, LSA, …).
L'autre option c'est d'utiliser Openldap comme backend de stockage, on a essayé mais on ne supporte plus parce que cette solution ne marche pas bien:
- Afin que ça fonctionne il faut que l'instance Openldap soit "privatisé" pour Samba sinon il peut se passer de drôles de choses si quelqu'un fait des modifications directement via LDAP en by-passant les modules spécifiques AD.
- Il faut que Samba parte d'une nouvelle installation, pas moyen de faire une mise à jour d'une installation existante car les schemas AD sont partiellement incompatibles.
[^] # Re: Samba 4, DNS et LDAP
Posté par ekacnet . En réponse à la dépêche Samba se met enfin en 4.0 et prend en charge les AD. Évalué à 4.
Pour l'instant il y a deux serveurs DNS possible pour Samba 4 et je ne pense pas que DNSmasq soit à l'ordre du jour, avec ISC DHCP est capable de mettre à jour les enregistrements DNS pour les machines à qui il attribue une adresse. Malheureusement ISC utilise un mécanisme de clé partagée pour faire ça et pour l'instant ça ne marche qu'avec Bind (et encore pas sûr que ça marche avec tous les backends), j'avais fait un article sur mon blog il y a quelques temps de cela: http://is.gd/Ox78Iv.
Je pense qu'on y pense mais pour l'instant rien n'est fait.
La réponse est oui, et c'est même en cours puisque RedHat fournit par défaut MIT comme implementation Kerberos donc pour pouvoir offrir un paquet Samba 4.0 AD pour RHEL il faut qu'il utilise MIT Kerberos comme KDC.
Mais la question c'est quel est exactement le besoin ?
Pas vraiment, c'est juste les gens d'heimdal étaient plus ouvert aux changements nécessaire du fait des besoins pour avoir un KDC compatible AD.
Je suppose que la question c'est pourquoi pas utiliser Openldap comme serveur LDAP ?, la raison c'est qu'il faudrait ré-écrire plein de modules pour Openldap et il se pose la question de maintient de l'intégrité avec les autres serveurs (Netlogon, LSA, …).
L'autre option c'est d'utiliser Openldap comme backend de stockage, on a essayé mais on ne supporte plus parce que cette solution ne marche pas bien:
- Afin que ça fonctionne il faut que l'instance Openldap soit "privatisé" pour Samba sinon il peut se passer de drôles de choses si quelqu'un fait des modifications directement via LDAP en by-passant les modules spécifiques AD.
- Il faut que Samba parte d'une nouvelle installation, pas moyen de faire une mise à jour d'une installation existante car les schemas AD sont partiellement incompatibles.