Forum Linux.debian/ubuntu Le dilemme du moment : Samba 3 ou Samba 4 pour un domaine ?

Posté par .
3
24
mai
2012

Bonjour,
Après plusieurs mois d'étude sur le remplacement d'un Active Directory par un domaine géré par des serveurs Linux, je voulais avoir l'avis des francophones de linuxfr.org.

Nous cherchons à remplacer un domaine géré par un AD Microsoft Windows 2003 par un architecture nous permettant de :
* ne gérer qu'une seule base de données utilisateur
* faire du SSO sur des OS Windows et Linux
* permettre l'authentification des utilisateurs de manière centralisée
* gérer des serveurs de fichiers et d'impression.

Nous sommes presque parvenus à nos fins avec Samba3/OpenLdap/Kerberos(MIT). Le problème restant réside dans la gestion du client kerberos pour windows. De deux choses l'une : soit on passe par samba, et on n'obtient pas de ticket kerberos, car samba 3 ne semble pas à même de dispenser les tickets au clients, soit on lie directement le client windows au royaume Kerberos. Pour cette dernière solution, les client kerberos (qu'ils soient fournis par M$ ou par le MIT) semblent exiger une base d'utilisateur locaux pour "mapper" ceux du royaume vers ces derniers. Gérer une telle base utilisateur sur les clients n'est pas envisageable. Si certains d'entre vous on réussi à contourner ce problème, vos expériences nous intéressent.

Puis finalement, Samba4 est là, en production sur quelques sites dans le monde depuis déjà plusieurs mois. Alors pourquoi pas se lancer dans l'aventure ? Il est simple à mettre en oeuvre, il est un AD, mais donc aussi un serveur kerberos et Ldap, ouverts et disponibles… Il gère nativement Kerberos, peuple le DNS et le serveur Ldap à l'installation, rien de plus agréable. Mais le choix est crucial et on cannait les risques de s'embarquer avec une version en dev. De plus, nous ne sommes pas sûrs d'avoir besoin de l'usine à gaz AD. Mais nous ne voudrions pas rater le train samba4, s'il garde les avantages de la version 3.

Un tel choix pour les 5 à 8 ans à venir, dans une entreprise de plusieurs centaines de postes, nous laisse perplexe. Toute expérience sera la bienvenue. merci d'avance.

Pour ceux qui peuvent être intéressés, notre travail sur samba3/openldap (sans kerberos pour l'instant, peut-être à venir selon le temps dispo.) est disponible ici :
http://www.fondation-misericorde.fr/sites/fondation-misericorde.fr/files/public/admin/20120524-samba-ldap-pdc-and-misc.html

  • # reste sur Microsoft AD

    Posté par . Évalué à 2.

    J'ai réalisé une étude similaire l'année dernière:
    voici quelques infos

    • Samba3 émule un PDC de type WinNT 4.0 et donc c'est normal qu'il n'y ait émission d'un ticket Kerberos.
    • Kerberos ne fournit que l'authentification, tu es obligé dans tous les cas d'avoir un utilisateur (uid) windows quelque part. Tu peux utiliser soit un compte local soit … un compte AD.
    • si tu n'utilises pas le kerberos de AD, mais un autre, attention au effet de bords: par exemple le cache d'authentification ne fonctionne plus (dommage pour les portables windows)
    • Mis à part l'absence de kerberos, un PDC samba3 n'offre pas assez de services selon moi par rapport à AD. Par exemple il manque les GPO.

    Ma conclusion: AD est incontournable pour gérer un parc windows.
    Le choix se limite donc à choisir l'implémentation d'AD
    - celle de Microsoft.
    - celle de samba4.

    Les tests que j'ai fait avec samba4 (alpha14) m'ont convaincu que c'est encore un produit expérimental, et qu'il était beaucoup plus sûr pour l'instant de conserver mes controleurs de domaine win2003.

  • # resara?

    Posté par . Évalué à 2.

    Il y a eu récemment une dépêche sur le projet Resara, basé sur Samba4.

    https://linuxfr.org/news/resara-server-1-1-2

  • # Merci

    Posté par . Évalué à 1.

    Merci pour vos commentaires.
    Je vais y réfléchir et tester samba4 avec quelques utilisateurs en prod.
    J'ai bien vu passer le post sur Resara, mais je préfère me baser sur l'original que sur un package de samba4 contenant une interface.
    A plus

Suivre le flux des commentaires

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