Samba se met enfin en 4.0 et prend en charge les AD

Posté par  (site web personnel, Mastodon) . Édité par labiloute, Benoît Sibaud, Yves Bourguignon, Étienne, detail_pratique, claudex et NeoX. Modéré par claudex. Licence CC By‑SA.
Étiquettes :
44
16
déc.
2012
Samba

Samba, implémentation 100% libre (licence GPLv3) du protocole SMB (Server Message Block), vient de publier sa version 4.0, le tout après une dizaine d'années de développement et 21 versions alpha, une phase bêta depuis le début de l'année et un cycle de releases candidates depuis septembre.
 logo_samba
La grande nouveauté très attendue de cette version majeure est la prise en charge de manière transparente des Active Directory (AD de leur petit nom) de Microsoft. Mais ce n'est pas tout. Au programme :

  • l'implémentation de la version 2.1 du protocole de partage de fichier SMB de Microsoft
  • une première version de la version 3 du même protocole
  • la répartition de charge pour ces protocoles
  • une nouvelle interface de scripting en Python pour les besoins d'automatisation
  • une intégration sécurisée de NTP afin de fournir un horodatage plus précis aux clients Windows.

Le tout s'est fait en étroite collaboration avec les équipes de Microsoft. L'équipe derrière Samba a remercié leurs équipes, notamment sur la mise à disposition d'une documentation officielle et de tests d'interopérabilité qui ont permis le développement de la partie Active Directory.

NdM : merci à Étienne, detail_pratique, NeoX, Yves Bourguignon et labiloute qui ont contribué à cette dépêche dans l'espace de rédaction collaborative.

Sommaire

Samba et l'Active Directory

Alors que la branche 3 de Samba peut assurer la fonction de contrôleur de domaine type NT, Samba 4.0 implémente la partie serveur de l'environnement Active Directory utilisé par Windows 2000 et les versions suivantes. Il est donc maintenant possible de joindre un domaine Samba 4 avec toute version de Windows à partir de Windows NT4, et de profiter des fonctionnalités de l'Active Directory correspondantes.

Afin de fournir un ensemble pleinement compatible, cette version inclut sa propre implémentation de serveur LDAP, un serveur Kerberos, un serveur DNS, un serveur RPC, un serveur NTP ainsi qu'un serveur de fichiers basé sur Samba 3.

L'ensemble fonctionne sous un seul service nommé samba.

Il est donc possible d'utiliser Samba 4 pour mettre à disposition des clients Windows, entre autres, des profils itinérants ou des stratégies de groupes.

Les contraintes de l'AD Samba 4

La compatibilité de Samba 4 avec Active Directory est assurée dans la mesure où :

  • Il n'y a qu'un seul domaine dans la forêt.
  • Il n'y a pas d'approbation inter-forêt (samba4 peut être approuvé par un domaine mais ne peut pas en approuver)
  • Samba est le seul contrôleur de domaine de son domaine.

Ces limites seront levées dans les prochaines versions de samba, notamment avec le support des systèmes de réplications nécessaires au bon fonctionnement des contrôleurs principaux et secondaires.

Installer Samba 4

En attendant les paquetages pour nos distributions préférées, la documentation de Samba 4 propose de télécharger les sources à l'aide de git ou de rsync, puis de compiler l'ensemble de manière traditionnelle.

Administrer Samba 4

De nombreuses tâches peuvent être réalisées avec l'outil « samba-tool », permettant d'administrer et d'automatiser, par exemple, la création de groupes ou d'utilisateurs.

Les consoles d'administration de l'Active Directory comme « dsa.msc » (Utilisateurs et ordinateurs Active Directory), « gpmc.msc » (gestion des stratégies de groupes) ou dnsmgmt.msc (gestion du DNS) peuvent être installées sur une ou des machine(s) cliente connectée(s) au domaine. Ceci permet d'administrer le domaine Samba 4 avec les consoles Microsoft.

La documentation donne les liens vers les sites Microsoft vous permettant de télécharger les consoles pour votre système Microsoft Windows.

Samba 4 et les GPO

Les GPO (Group Policy Object ou stratégies de groupes) sont des fonctions de gestion centralisée de la famille des systèmes d'exploitation Windows. Samba 4 permet de créer des GPO applicables sur l'ensemble des machines de la petite famille.

Comme les contrôleurs de domaine Microsoft, le serveur Samba 4 utilise le partage et l'arborescence SYSVOL, avec des acl étendues afin de mettre les stratégies de groupe à disposition des clients Microsoft.

Note : pour disposer des GPO d'un des systèmes d'exploitation de la famille, il faut avoir installé les consoles d'administration des serveurs correspondantes.

Samba 4 et le DNS

Samba 4 inclut un serveur DNS. Il est toutefois possible d'utiliser un serveur DNS externe. L'équipe Samba 4 préconise alors bind 9.8.0 ou supérieur.

Ce serveur DNS accepte des mises à jour dynamiques et sécurisées des noms de machines de la part des clients ayant joint le domaine.

Samba 4 et NTP

Rien n'est plus sensible dans un domaine Active Directory que la synchronisation du temps. Principalement pour les échanges liés au protocole Kerberos, il est important que les horloges des membres et des serveurs soient parfaitement ajustées.

Dans une infrastructure Active Directory, les réponses aux requêtes des clients NTP se doivent d'être signées. Ce système de sécurité est disponible en utilisant le démon NTP à partir de la version 4.2.6 et le socket de signature Samba4.

L'installation du daemon NTP (>= 4.2.6) aux cotés de Samba 4, permet après quelques lignes de configuration, de maintenir précisément à l'heure les clients Windows comme les clients GNU/Linux, .

Samba 4 et Kerberos

Une des avancées majeures de cette version est le serveur Kerberos inclus (implémentation Heimdal) et sa compatibilité avec les clients Microsoft. Ce serveur Kerberos comprend le support du PAC (Privilege Account Certificate) Windows, une extension du protocole Kerberos jusque là spécifique à l'Active Directory Microsoft.

Il est donc désormais possible d'utiliser l'authentification Kerberos dans un domaine exclusivement Samba, avec les applications supportant ce protocole. Les clients Microsoft Windows comme les clients GNU/Linux (à travers Winbind et les bibliothèques clientes Kerberos) peuvent donc bénéficier de ce système d'authentification. Les avantages peuvent être par exemple, l'utilisation du SSO (Single Sign-On).

Samba 4 et LDAP

Samba 4 comprend un serveur LDAPv3 développé pour l'occasion, dans le respect des standards, bien sûr. Cette implémentation allégée d'un serveur LDAP stocke l'arborescence de l'Active Directory.

Il n'est actuellement pas prévu de pouvoir ajouter ses propres schémas au serveur LDAP interne à samba4. De la même manière, l'utilisation d'un backend LDAP externe est déconseillée par l'équipe de développement, mais toujours possible. Les détails sont disponibles sur le Wiki samba.

Samba 4 n'est pas Samba 3

Bien que Samba 4 fasse suite, dans la numérotation au moins, à Samba 3, ce sont deux projets assez différents, mais pleinement compatibles. Samba 4 se concentre sur la prise en charge d'Active Directory, alors que la vocation de Samba 3 est le share and print, comprenez le partage de fichiers et l'impression centralisée.

La migration depuis Samba 3

Samba 4 contient les outils nécessaires à la migration depuis un contrôleur de domaine samba 3.
Une page du Wiki samba traite du sujet.

Joindre le domaine

Comme le faisait Samba avec Active Directory, il est possible de joindre un domaine Samba 4 avec un serveur de fichiers Samba 3. Ceci permet, par exemple, de dissocier la partie serveur de fichiers de la partie authentification. Ceci permet aussi de joindre un serveur Web, ou simplement une machine GNU/Linux membre du domaine.

Conclusion

Bien qu'il manque encore quelques fonctionnalités essentielles à Samba 4 (essentiellement la prise en charge complète de la réplication), cette version 4.0 (stable) est prête à prendre le pas à tout domaine Microsoft Windows 2000/2003/2008, ou plus timidement, à s'intégrer à celui-ci.

Les expériences fructueuses et la stabilité du logiciel semblent confirmer que même à l'heure de l'authentification dans le Cloud, ces 10 longues années de développement n'ont pas été vaines.

Cette version marque une nouvelle étape dans l'offre de logiciels pour l'entreprise. C'est aussi une évolution majeure en terme d'interopérabilité. L'élément central des systèmes informatiques de nombreuses entreprises, le contrôleur de domaine, n'est plus l'exclusivité de la société de Redmond.

Aller plus loin

  • # Microsoft ?

    Posté par  (site web personnel) . Évalué à 8.

    Le tout s'est fait en étroite collaboration avec les équipes de Microsoft. L'équipe derrière Samba a remercié leurs équipes, notamment sur la mise à disposition d'une documentation officielle et de tests d'interopérabilité qui ont permis le développement de la partie Active Directory.

    Quel est (a été ou sera) l'intérêt pour Microsoft ?

    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

    • [^] # Re: Microsoft ?

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 16 décembre 2012 à 19:46.

      Quel est (a été ou sera) l'intérêt pour Microsoft ?

      C'est parce que les gens de Microsoft sont des gentils et qu'ils aiment favoriser l'interopérabilité ?
      Heuu…non en vrai c'est parce que Microsoft a perdu en 2004 un procès sur l'interopérabilité intenté par l'Union européenne. Ils ont fait appel et ont été condamnés définitivement en 2007. La commission européenne (merci à elle) a donc réussi à forcer Microsoft à divulguer les informations techniques. L'équipe Samba a ainsi pu en profiter pour améliorer la compatibilité de son logiciel.

      Voir : http://www.samba.org/samba/PFIF/ et aussi https://fsfe.org/activities/ms-vs-eu/leaflet-ms-vs-eu.fr.html

      Moralité : Microsoft c'est toujours pas des gentils.

      • [^] # Re: Microsoft ?

        Posté par  . Évalué à 10.

        L'obligation se limite a la doc. Rien ne nous oblige a leur filer nos tests d'interop ou a repondre a leurs questions mais on le fait quand meme…

        • [^] # Re: Microsoft ?

          Posté par  (site web personnel) . Évalué à 7.

          mais on le fait quand même

          merci !

          • [^] # Re: Microsoft ?

            Posté par  (site web personnel) . Évalué à 3.

            tiens, je suis moinsé, aussi peu de monde comprend le 2ème degré ? J'ai oublié d'appeler Albert< à répondre ?

            Pour autant, et Albert< sera d'accord avec moi, ce serait bien qu'un jour Microsoft implémente OOXML dans ses logiciels, histoire que leurs clients puissent relire leurs documents dans la durée, plutôt que de s'appuyer sur OpenOffice.org^WLibreOffice pour un format pérenne (ODF 1.2) et légitimé sans fast track mais dans la durée par l'ISO.

      • [^] # Re: Microsoft ?

        Posté par  (site web personnel) . Évalué à 10. Dernière modification le 17 décembre 2012 à 07:20.

        Spoiler: je suis membre de la 'Samba-Team'

        C'est parce que les gens de Microsoft sont des gentils et qu'ils aiment favoriser l'interopérabilité ?

        Je pense pas que toutes les personnes de Microsoft soient gentilles mais certaines ont compris que c'est un argument de vente que d'avoir des alternatives inter-operables avec leurs produits.

        Heuu…non en vrai c'est parce que Microsoft a perdu en 2004 un procès sur l'interopérabilité intenté par l'Union européenne. Ils ont fait appel et ont été condamnés définitivement en 2007. La commission européenne (merci à elle) a donc réussi à forcer Microsoft à divulguer les informations techniques. L'équipe Samba a ainsi pu en profiter pour améliorer la compatibilité de son logiciel.

        Il faut savoir que les obligations de ce jugement obligeait pas Microsoft à documenter ces protocoles (mais seulement ceux couverts) par le jugement et surtout pas à les rendre librement consultable (c'est la raison pour laquelle la PFIF a été créée).

        Je pense que le résultat de ce jugement à surtout changé le rapport de force entre différents courants et que les partisans d'un peu plus de collaboration avec la communauté open-source ont acquis plus d'influence.

        Moralité : Microsoft c'est toujours pas des gentils.

        Moralité, le monde à changé depuis l'an 2000, il faut arrêter de penser qu'une entreprise est binaire (soit pro, soit anti logiciels libres) je pense qu'au contraire différentes nuances expriment. Dans le cas de Microsoft je pense que la réalité c'est qu'il en y a qui sont farouchement contre l'open-source et d'autres qui pensent que c'est une bonne chose pour Microsoft d'être ouvert.

        Au risque d'enfoncer une porte ouverte, le but d'une entreprise c'est de faire de l'argent et je pense que toutes les entreprises qui font de l'open-source ("les gentils") le font parce que c'est bon pour les affaires en tout premier lieu.

        • [^] # Re: Microsoft ?

          Posté par  . Évalué à 3.

          Au risque d'enfoncer une porte ouverte, le but d'une entreprise c'est de faire de l'argent et je pense que toutes les entreprises qui font de l'open-source ("les gentils") le font parce que c'est bon pour les affaires en tout premier lieu.

          Désolé de verser philosophie, mais j'ai horreur de ce genre d'affirmation, qui plus est présentées comme des totologies (mes excuses de rebondir, car tu le fais sûrement de manière rapide ici, sans vouloir prêter à conséquence)

          Le rôle d'une entreprise est multiple et pas uniquement de faire de l'argent. L'entreprise peut être là pour répondre à des besoins, faire progresser l'offre, assurer un travail à ses salariés. Même pour un libéral, il peut être acceptable de réduire les bénéfices reversé aux actionnaires, a une récompense équivalente à la prise de risque qui a permis l'aventure sociale de l'entreprise.

          Mon propos n'est pas fermé, je veux juste donner des pistes et sortir de la caricature utilitariste ! (oh p*t*n je suis grave pompeux là :-P)

          • [^] # Re: Microsoft ?

            Posté par  (site web personnel) . Évalué à 4.

            Le rôle d'une entreprise est multiple et pas uniquement de faire de l'argent. L'entreprise peut être là pour répondre à des besoins, >faire progresser l'offre, assurer un travail à ses salariés. Même pour un libéral, il peut être acceptable de réduire les bénéfices >reversé aux actionnaires, a une récompense équivalente à la prise de risque qui a permis l'aventure sociale de l'entreprise.
            Je ne suis pas d'accord le but premier d'une entreprise à but lucratif c'est de faire de l'argent, pas forcement à n'importe quel prix et pas forcement pour les actionnaires mais cela reste quand même le but principal.

  • # Changement d'époque !

    Posté par  (site web personnel) . Évalué à 9.

    Microsoft collabore à Samba et fournit les spécifications d'interfaçage… Quel changement !
    Le temps où il fallait faire du reverse-engineering est donc révolu.
    On peut s'en féliciter mais il faut être prudent : Est-ce que toutes les spécifications ont été publiées ? Est-ce que Microsoft ne va pas faire quelques petites modifications sans les publier afin que seules ses solutions fonctionnent bien, juste un peu mieux que les autres ? C'est en cachant quelques API dites à usage interne que Borland a été éliminé car il était ainsi un peu moins performant que Microsoft.

    Une autre hypothèse est que Microsoft sent le vent tourner et est obligé de cohabiter avec les logiciels libres pour ne pas être éliminé. La leçon d'IBM doit rester présente dans les esprits. Un dirigeant d'IBM disait que leur arrogance avait failli leur faire mettre la clef sous la porte.

    Alors où est la vérité ? Peut être un peu des deux ?

    • [^] # Re: Changement d'époque !

      Posté par  (site web personnel) . Évalué à 3.

      Microsoft collabore à Samba et fournit les spécifications d'interfaçage… Quel changement !

      cf mon message au-dessus.

    • [^] # Re: Changement d'époque !

      Posté par  (site web personnel) . Évalué à 6. Dernière modification le 17 décembre 2012 à 07:24.

      Le temps où il fallait faire du reverse-engineering est donc révolu.

      Oui et non, il arrive que les spécifications ne soient pas correctes mais ça reste plus l'exception que la norme de plus la documentation couvre le protocole et un peu le comportement spécifique de chaque version de Windows mais jamais de comment ça se passe à l'intérieur de Windows.
      Parfois sur les choses qui sont de la libre interprétation de l'implémentation (la documentation utilise beaucoup de "SHOULD" pour indiquer ce que l'implémentation devrait faire) on obtient des comportements non documentés et la reverse-engineering est parfois nécessaire pour arriver à comprendre ce qui se passe et ainsi pouvoir discuter plus facilement avec les équipes de Microsoft en charge la documentation.

      On peut s'en féliciter mais il faut être prudent : Est-ce que toutes les spécifications ont été publiées ?

      Toutes les spécifications de tous les protocoles utilisés par Windows ne sont pas à mon avis publiées mais une grosse majorité le sont.
      Cf. http://is.gd/HRP3eu

      Est-ce que Microsoft ne va pas faire quelques petites modifications sans les publier afin que seules ses solutions fonctionnent bien, juste un peu mieux que les autres ? C'est en cachant quelques API dites à usage interne que Borland a été éliminé car il était ainsi un peu moins performant que Microsoft.

      Ca ressemble étrangement à ce que autre entreprise avec un logo en forme de fruit fait sur la plate-forme où il est en monopole…
      Je pense que Microsoft ne devrait plus jouer de trop à ce jeu, car pour l'ensemble des protocoles couverts par le jugement ils sont encore tenu à leurs obligations et donc si ils faisaient ceci sciemment cela pourrait aboutir à des poursuites. Mais plus important cela ruinerait l'effort qu'ils ont entrepris pour apparaître (et être) plus "interoperable friendly".

    • [^] # Re: Changement d'époque !

      Posté par  . Évalué à -3.

      C'est en cachant quelques API dites à usage interne que Borland a été éliminé car il était ainsi un peu moins performant que Microsoft.

      D'un autre cote, tout le code de visual studio est a usage interne, donc je vois pas trop ou est le probleme a utiliser des api privees, connues de seul MS.
      Borland aurait tres bien pu reimplementer le meme code, c'est du soft, pas de la magie noire.

      Sans compter que cette histoire est generalement attribuee a office et excel, pas visual studio.

      Linuxfr, le portail francais du logiciel libre et du neo nazisme.

  • # Samba 4 n'est pas Samba 3

    Posté par  . Évalué à 3.

    Je n'ai pas bien compris ce passage.
    Par exemple si j'ai une machine sous linux qui est connectée dans un réseau AD et que je veux partager des fichiers/répertoires de cette machine à destination des machines sous Windows, est-ce que je dois utiliser Samba 4 ou Samba 3 ?

    • [^] # Re: Samba 4 n'est pas Samba 3

      Posté par  (site web personnel) . Évalué à 3.

      Le projet a pris un retard fou… Du coup, la partie partage de fichier et impression n'est pas finit et samba 4 s'est concentré sur la partie AD. Au final, "Samba 4" est un mix de samba 3 et de samba 4 ;-)

      Bref, les nouvelles briques devraient remplacer les anciennes mais il y a un an ou deux, il a été décidé de sortir les nouvelles briques avec les anciennes afin d'avoir une ensemble cohérent.

    • [^] # Re: Samba 4 n'est pas Samba 3

      Posté par  . Évalué à 3.

      À la base, Samba 4 était une réécriture complète, y compris de la partie partage de fichier, finalement la partie partage de fichier a été reprise de samba 3 mais ça montre bien que le projet se voulait fort différent. Si c'est juste pour du partage de fichier (et qu'il n'y a pas besoin de SMB > 2. Il vaut mieux rester avec Samba 3.

      « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

      • [^] # Re: Samba 4 n'est pas Samba 3

        Posté par  (site web personnel) . Évalué à 1.

        À la base, Samba 4 était une réécriture complète, y compris de la partie partage de fichier, finalement la partie partage de fichier a >été reprise de samba 3 mais ça montre bien que le projet se voulait fort différent.

        Si une nouvelle architecture (NTVFS) étaient bien prévu pour la version 4.0 elle n'a pas été retenue comme implemantation par défaut car entre temps beaucoup de changements introduit par samba4 ont été back-portés au cours des différentes versions 3.x.
        Ce fut le cas de la librairie talloc (http://talloc.samba.org) (pour la gestion hiérarchique de la mémoire), de la génération de code pour les protocoles (CIFS, NETLOGON, LSA, …) du stockage des ACLs NT 100% fidèles à ce qui est spécifié du coté client.

        De ce fait les avantages relatifs aux changements d'implementation (S3FS -> NTVFS) étaient moins important et les inconvénients de la migration eux toujours présent (jeunesse de la solution par rapport à une solution éprouvée et utilisé en production dans des cas très très différents).

        Si c'est juste pour du partage de fichier (et qu'il n'y a pas besoin de SMB > 2. Il vaut mieux rester avec Samba 3.

        Non, avec la mise à dispo de Samba 4.0, la branche 3.6.x passe en mode maintenance et presque aucune amélioration ne sera faite sur cette branche (juste les corrections de bugs).
        Comme indiqué avant, si c'est juste pour un serveur de fichier il suffit de démarrer smbd et potentiellement winbindd.

        • [^] # Re: Samba 4 n'est pas Samba 3

          Posté par  . Évalué à 4.

          Non, avec la mise à dispo de Samba 4.0, la branche 3.6.x passe en mode maintenance et presque aucune amélioration ne sera faite sur cette branche (juste les corrections de bugs).
          Comme indiqué avant, si c'est juste pour un serveur de fichier il suffit de démarrer smbd et potentiellement winbindd.

          Mais la version 4 étant un peu jeune et pas encore dans les paquets officiels de la plupart des distributions, je ne suis pas sûr qu'elle soit quand même conseillée si on a pas besoin des fonctionnalités qu'elle offre.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Samba 4 n'est pas Samba 3

            Posté par  (site web personnel) . Évalué à 3.

            Alors je pense que la version 4.0 est aussi conseillée que la dernière version de la branche 3.6 surtout en ce qui concerne la partie serveur de fichier car:
            - Il y a eu peu de modification de code dans cette partie
            - Chaque commit doit passer une batterie de 1500 tests de bout en bout avant pouvoir être réellement intégré au "master tree git"
            - Il a été testé en condition réelle pendant les betas et les release candidate

            Après si tu dois faire un choix entre la version 3.6.x où les mises à jours de sécurité sont assurées par la distro ou bien avoir à suivre les différentes alertes de sécurités Samba et faire les mises à jours soit même, je te laisse prendre la conclusion qui va bien en terme de facilité de la chose.

            Mais à niveau de support équivalent, il n'y a aucune bonne raison pour rester à la version 3.6.x

    • [^] # Re: Samba 4 n'est pas Samba 3

      Posté par  (site web personnel) . Évalué à 2.

      cela marche déjà très bien avec samba 3

      inclusion d un linux dans l ad
      avec un smb.conf adequat

      net ads join -U

      ensuite le partage des fichiers entres les linuc et windows se fait comme entre les windows et windows
      et avec le sso en plus si on a crée les keytab qui vont bien.

      • [^] # Re: Samba 4 n'est pas Samba 3

        Posté par  . Évalué à 2.

        Je ne dois pas être doué parce que je n'ai jamais réussi … :)
        Tu mets quoi sans le smb.conf ?

        • [^] # Re: Samba 4 n'est pas Samba 3

          Posté par  (site web personnel) . Évalué à 3. 

          [gnumdk@wendy ~]$ cat /etc/samba/smb.conf
[global]

###########
# DOMAINE #
###########
        workgroup = AD
        realm = AD.***-TOULOUSE.FR
        netbios name = wendy
        server string = Debian Linux
        security = ads
        client use spnego = yes
        domain master = no
        local master = no
        preferred master = no
        os level = 0

###########
# WINBIND #
###########
        idmap backend = tdb
        idmap uid = 2000-10000000
        idmap gid = 2000-10000000
        idmap config AD: backend = rid
        idmap config AD: range = 2000-10000000
        template shell = /bin/bash
#       winbind separator = +                                                                                  
        winbind use default domain = yes                                                                       
        winbind enum users = no                                                                                
        winbind enum groups = no                                                                               
        winbind nested groups = yes                                                                            
        map untrusted to domain = no                                                                           
        winbind refresh tickets = yes
        machine password timeout = 0

    • [^] # Re: Samba 4 n'est pas Samba 3

      Posté par  (site web personnel) . Évalué à 3. Dernière modification le 17 décembre 2012 à 13:35.

      J'avoue que cette phrase est bizarre pour moi aussi. Alors certe 3 != 4.
      Mais Samba 4.0 est bien le successeur des version Samba 3, le changement le plus important est l'introduction de la fonctionnalité de contrôleur de domaine AD, qui est implemantée dans le programme samba, et samba une fois démarré propose les services de partage de fichiers CIFS/SMB/SMB2 et les services d'impression réseau.
      Maintenant si le besoin c'est juste un serveur de fichier et/ou d'impréssion membre d'un domaine AD ou bien juste en solitaire alors le programme smbd (et sûrement winbindd et nmbd) doivent être démarrés.

      En tant que contrôleur de domaine, samba s'appuie sur le serveur de fichier smbd pour la prise en charge du partage de fichier.

      Par exemple si j'ai une machine sous linux qui est connectée dans un réseau AD et que je veux partager des fichiers/répertoires de >cette machine à destination des machines sous Windows, est-ce que je dois utiliser Samba 4 ou Samba 3 ?

      Samba 4, mais en démarrant le programme smbd

      Je pense que pour la version 4.1 samba sera le seul programme à démarrer que l'on veuille juste un serveur de fichier ( smbd ) ou un contrôleur de domaine AD ou bien juste la gestion de l'autorisation et de l'identification ( winbindd ).

  • # DC additionnel

    Posté par  . Évalué à 2.

    Sauf erreur de ma part, il me semble que l'on peut avoir Samba4 comme contrôleur de domaine additionnel, et meme faire un mix de contrôleurs windows+samba non ?

  • # Samba 4, DNS et LDAP

    Posté par  . Évalué à -1.

    Samba 4 inclut un serveur DNS. Il est toutefois possible d'utiliser un serveur DNS externe.
    […]
    Samba 4 comprend un serveur LDAPv3 développé pour l'occasion, dans le respect des standards, bien sûr.

    Je ne comprends pas, pourquoi réinventer la roue ? Voilà sans doute ce qui a retardé Samba 4.

    • [^] # Re: Samba 4, DNS et LDAP

      Posté par  (site web personnel) . Évalué à 7.

      Samba 4 inclut un serveur DNS. Il est toutefois possible d'utiliser un serveur DNS externe.
      […]
      Samba 4 comprend un serveur LDAPv3 développé pour l'occasion, dans le respect des standards, bien sûr.

      Je ne comprends pas, pourquoi réinventer la roue ? Voilà sans doute ce qui a retardé Samba 4.

      Quand on ne sait pas le mieux est de se taire de peur de dire des bêtises !

      Les raisons qui ont poussé à la création d'un serveur DNS internes sont :
      - Complexité de configuration de Bind 9.x, avec une liste de versions compatibles bien précises, incompatibilité des configuration entre bind 9.7, 9.8 et 9.9
      - Automatisation des tests de bout en bout sans dépendance avec bind (car tous les développeurs n'ont pas forcement la bonne version de bind installée.
      - Réduction de la mémoire utilisée pour les systèmes types embarqués (beagle board, …)

      Les raisons qui ont poussé à la création du serveur LDAP sont:

      • Absence de support pour les transactions LDAP (indispensable pour la réplication entre 2 contrôleurs)
      • Très fort couplage entre les différents composants (serveur LDAP, serveur Kerberos, gestionnaire des protocoles Netlogon, LSA, …) qui implique qu'un changement réalisé par via un protocole (ie. LDAP) soit instantanément visible dans les autres protocoles (Kerberos, Netlogon)
      • Schema AD spécifique et incompatible pour certain OID

      Les raisons du "retard" sont la complexité des protocoles, si il est facile de faire fonctionner une authentification type AD (la démo a été faite en 2005) il en est moins aisé de faire un serveur qui est suffisamment stable pour que les utilisateurs soient d'accord pour faire fonctionner le cœur du système d'autorisation et d'authentification sur une solution alternative.
      Une raison du "retard" est aussi "où sont vos patches", il y a toujours beaucoup de personnes pour critiquer le retard mais assez peu pour proposer des patches pour corriger les bugs ou bien implementer de nouvelles fonctionnalités.

      • [^] # Re: Samba 4, DNS et LDAP

        Posté par  . Évalué à 1.

        Les raisons qui ont poussé à la création d'un serveur DNS internes sont :
        - Complexité de configuration de Bind 9.x, avec une liste de versions compatibles bien précises, incompatibilité des configuration entre bind 9.7, 9.8 et 9.9

        Bind n'est pas non plus le seul serveur DNS libre, il suffisait d'en prendre un autre comme PowerDNS, MaraDNS, NSD, ou dnsmasq, le choix est vaste, il y en a bien d'autres.

        Je ne vais pas mettre la fameuse image de XKCD sur les standards, mais je n'en pense pas moins.

        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

        • [^] # Re: Samba 4, DNS et LDAP

          Posté par  . Évalué à 10.

          Je ne vais pas mettre la fameuse image de XKCD sur les standards, mais je n'en pense pas moins.

          Et tu fais bien de ne pas la mettre car ça n'aurait pas été pertinent.

          En effet, ils n'ont pas fait un nouveau standard mais bien une nouvelle implémentation d'un standard existant. Et c'est exactement à ça que sert un standard: permettre à chacun de choisir le programme qu'il préfère, et de faire le sien si aucun ne lui convient.

        • [^] # Re: Samba 4, DNS et LDAP

          Posté par  (site web personnel) . Évalué à 3.

          Pour les besoins d'un AD, il faut que le serveur supporte les mises à jours dynamiques signées (principalement TSIG) et un système d'ACL assez puissant et puis qu'ils permette de faire du multi-master.
          Ce qui limite pas mal le choix, ensuite idéalement il devrait pouvoir utiliser les partitions de l'AD ce qui permet de partager avec d'autres implementations (facilite la migration d'un système à l'autre …).
          Pour finir je sais que la personne qui s'est occupé du serveur de DNS a pris contact avec les développeurs de dnsmasq mais ceux-ci n'étaient pas trop intéressés, alors certes c'est open-source donc tu peux forker le code et tout le toutim mais en réalité c'est forcement une super idée.
          En plus il est possible que l'architecture de ce projet ne soit pas tip top (selon tes critères).

          Au final le serveur interne de Samba a été développé en peu de temps (max 2 mois avec principalement un seul développeur) avec très peu de code à proprement parlé car il y a eu réutilisation de beaucoup de "framework" qui avait été développé pour les autres serveurs de samba.

          One last thing, comme disait l'autre, Samba reste un projet opensource où certains contributeurs le font principalement sur leur temps libre parce que c'est "fun", c'est le cas du serveur DNS qui a été fait principalement sur le temps libre de Kai Blin parce que ça lui plaisait de faire ça. Il est pas sûr qu'il aurait utilisé ce temps à faire autre chose de plus "utile" si il n'avait pas passé du temps sur ça.

      • [^] # Re: Samba 4, DNS et LDAP

        Posté par  . Évalué à 4.

        Voilà qui répond à pratiquement toutes les questions que j'avais sur Samba 4 quant à l'intégration de tous ces services. Merci beaucoup. Il m'en reste encore quelques-unes.

        1. 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?

        2. 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? (Je présume que c'est PAC le facteur primordial à l'origine de l'intégration de Kerberos dans Samba 4?)

        3. Je poserais aussi volontiers la version bis de la question ci-dessus à propos de LDAP.

        En tous cas, félicitations à l'équipe Samba et merci pour ce travail colossal. Je pense (j'espère surtout) que cela aura des répercussions positives sur l'adoption préférentielle de Samba pour la libération du parc informatique.

        • [^] # Re: Samba 4, DNS et LDAP

          Posté par  (site web personnel) . Évalué à 4.

          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  . Évalué à 2.

            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.

            J'avoue que je ne comprends pas bien cette partie, notamment sur le fait qu'on puisse bypasser les modules AD ? Par exemple, j'utilise LDAP pour réaliser des modifications sur notre AD Windows (création/suppression/modification d'utilisateurs/groupes/OU), est-ce qu'il faut comprendre que ça n'est pas possible avec Samba4 ? (malheureusement je n'ai pas encore eu l'occasion de tester ça avec Samba4).

          • [^] # Re: Samba 4, DNS et LDAP

            Posté par  . Évalué à 2.

            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, […]
            Je pense qu'on y pense mais pour l'instant rien n'est fait.

            Je comprends que ça n'a pas dû être simple de combiner tout ça. Je ne sais si Dnsmasq reste à l'étude en tout cas ce que j'aime dans ce programme c'est l'extrême simplicité de son interface. Il supporte aussi DBUS mais c'est peut-être un point philosophique sujet à discussion, je le reconnais. Par contre, c'est sans doute la partie “mise à jour du DNS par les postes de travail” qui pourrait causer un peu plus de brainstorming. En tout cas, l'explication de Samba 4 me confirme en quoi un contrôleur de domaine Microsoft est un truc assez complexe et compliqué.

            Je suppose que la question c'est pourquoi pas utiliser Openldap comme serveur LDAP ?,

            En fait, non, pas tout à fait. La question était plutôt de reporter le développement autour de LDAP dans OpenLDAP, comme pour Kerberos. Mais au vu de l'explication je pense comprendre que le couplage LDAP réalisé par Microsoft devrait peut-être rester un cas à part. Un développement particulier de LDAP, adapté à ce cas précis était donc nécessaire. Je pige.

            • 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.

            Effectivement, ça, c'est le genre de cas qui interpelle. D'où l'explication sur la partie transactionnelle à ce niveau je suppose. [Et, entre parenthèses, je suppose aussi que la non-atomicité des opérations sur l'annuaire est sans doute (je prends des précautions, là) une des raisons pour lesquelles Active Directory pourrait se mettre à dérailler.]

            [reprise des fonctionnalités de Kerberos dans MIT] Mais la question c'est quel est exactement le besoin ?

            Simplement pour savoir si le produit Kerberos MIT allait aussi profiter du développement de l'équipe Samba, tant par la pertinence technique (vu que c'est loin d'être le cas pour OpenLDAP) que pour le bénéfice de Kerberos. C'était juste une question de curiosité. La question qui me vient est alors qu'est-ce qui a empêché l'ajout des fonctionnalités nécessaires à Kerberos MIT pour son couplage avec Samba?

            Maintenant, le niveau de complexité de Samba 4 n'a-t'il pas des répercussions sur son applicabilité, c-à-d quant aux raisons qui feront qu'on adopte soit Samba 3 soit Samba 4? Je suppose qu'il existe des circonstances où il vaut mieux adopter Samba 3 que la version 4, exact? Par exemple, dans le cas d'une [petite] entreprise n'ayant pas encore de contrôleur de domaine (ni de messagerie Exchange), il est sans doute plus pratique d'adopter Samba 3, est-ce un raisonnement correct? Est-ce que Samba 4 est plutôt destiné aux entreprises possédant déjà une empreinte Windows importante dans les fonctionnalités des contrôleurs de domaine et qui souhaitent s'en libérer progressivement?

            Il me paraît en tout cas évident que l'équipe Samba n'a pas réinventé la roue mais a produit un travail considérable en tenant compte de ce qui existait déjà et n'était plus à faire. Si j'ai bien compris, tout ce qui a été fait devait être fait de cette manière (Lapalisse était un de mes ancêtres lointains ;-), par exemple la particularisation de LDAP. Les apports à Kerberos par Samba bénéficieront aux produits Kerberos existants et tout ceci est une bonne chose. L'ironie de l'histoire est qu'il aura fallu le développement de Samba par une équipe indépendante pour commencer à comprendre comment Windows fonctionne dans ses entrailles!

      • [^] # Re: Samba 4, DNS et LDAP

        Posté par  . Évalué à 1. Dernière modification le 18 décembre 2012 à 02:48.

        Quand on ne sait pas le mieux est de se taire de peur de dire des bêtises !

        Cette réinvention de la roue me rend perplexe mais merci pour cette remarque déplacée…

        Merci également pour tes explications.

  • # Lien un peu vieux?

    Posté par  (site web personnel) . Évalué à 3.

    Bien qu'il manque encore quelques fonctionnalités essentielles à Samba 4 (essentiellement la prise en charge complète de la >réplication),

    Le lien relatif à cette remarque date de 2005 …, au sein d'un AD il y a deux type de réplications qui ont lieu:

    • Réplication de l'annuaire
    • Réplication des système de fichiers

    La première réplication est implementée depuis 2009 et fonctionne relativement bien, la seconde est toujours en cours de développement et est indispensable pour un bon fonctionnement de Samba dans un environnement mixte (Samba + Windows AD)

    • [^] # Re: Lien un peu vieux?

      Posté par  . Évalué à 1.

      Oui effectivement le lien n'est pas tout neuf. Désolé de la référence un peu moisie.
      Ceci dit le fond est bien celui que tu détaille : la réplication, au moins du SYSVOL et donc des GPO, n'est pas encore prise en charge.

  • # Samba 4, AD 2008 R2, synchronisation utilisateurs + passwd , kerberos 5

    Posté par  . Évalué à -1.

    Bonjour,

    Je suis particulièrement heureux d'apprendre l'existence de samba4 et je félicite tout le monde pour ce fabuleux travail.

    Je ne suis pas un spécialiste linux, mais j'ai quelques questions concernant samba 4 et une AD existantes sous 2008 r2.
    J'expose brièvement mon petit problème.
    Existant:

    samba 3 faisant DC
    un annuaire LDAP sous opendldap
    kerberos 5

    un autre DC sous windows 2008 R2 + AD

    Ce que je veux faire ou plutot ce qu'on me demande de faire:
    supprimer le DC samba
    mettre le DC windows en DC principal
    synchroniser les utilisateurs LDAP (openldap) avec utilisateurs AD windows….le hic c'est la synchronisation des passwords, cause of kerberos 5…

    mon idée serait d'installer samba 4 avec openldap, kerberos 5…
    Pouvez vous me confirmer que je peux faire cohabiter samba 4 avec windows 2008 r2 (du coup la synchronisation des utilisateurs LDAP (openldap) et utilisateurs AD (2008 R2) , ne devrait plus me poser de soucis (si j'ai bien compris!!))?
    dois je laisser mon 2008 R2 comme DC principal et intégrer samba 4 ?

    Je suis un peu perdu dans tout cela…
    est ce que quelqu'un peu me donner quelques tuyaux?

    Merci

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.