Quoi de neuf dans Samba 4 Samba 4, par Adam Tauno Williams (*) En Décembre 2012, le monde du logiciel libre a reçu la première et très attendue version de samba 4. Samba 4.x a été en développement depuis 10 ans. La série Samba 3.x a vu de nombreuses avancées. Ce développement parallèle a conduit à quelque confusions sur la nature de Samba 4. Et quelques distributions proposaient les deux paquets Samba 3 et Samba 4, qui pouvaient être installés en parallèle, avec des degrés divers de succès. Samba 4 est un remplaçant complet et une mise à jour de Samba 3. Il sera sans aucun doute utilisé en parallèle avec des installations existantes de Samba 3.x, mais pas à cause de quelques déficiences dans Samba 4. Dans presque tous les cas Samba 4 peut remplacer directement les versions de Samba 3 maintenues et continue à fonctionner et fournir les mêmes services. Samba 4 n'est pas le contrôleur de domaine Active Directory de Samba, il s'agit plutôt d' une nouvelle version de Samba qui fournit des services nouveaux et améliorés. Par conséquent, je ferai référence à la version actuelle de Samba 4.x dans cet article tout simplement sous le nom de "Samba". Les numéros de version indiquent seulement une version de Samba autre que la version actuelle. Certaines confusions sur ces versions découlent de la longue période de développement qui a été nécessaire pour sortir la nouvelle version. Au fil des ans, plusieurs directions ont été prises et des ajustements ont étés fait dans le projet, y compris des rumeurs sur un fork potentiel. Cependant le projet a fini par trouver sa voie grâce à une méthode permettant d'intégrer les approches divergentes face aux nombreux problèmes techniques qui devaient êtres résolus. Pour comprendre la structure actuelle du logiciel et l'orientation que le projet a pris, il est essentiel de se référer uniquement au matériau courant. L'utilisation d'anciennes documentations ou d'archives de mailing list, en particulier celles qui font références aux versions de Samba 4 "test" et "alpha" sont fortement déconseillées. Les directives de configuration et la syntaxe des commandes ont changés de façon significative. L'aptitude à participer pleinement à un domaine Active Directory (AD) semble être le seul apport, énorme, et c'est ce dont tout le monde veut parler lorsqu'on considère la nouvelle Samba. Cependant l'intégration d'un AD n'est pas la seule amélioration importante que la dernière Samba met sur la table. Je vais parler de la fonctionnalité de l'ad dans un moment, mais je vais évoquer quelques autres changements importants en premier lieu. Un changement important concerne le projet Samba lui-même et la méthode de travail utilisés pour le développement de Samba. Le nouveau processus de validation de l'équipe Samba nécessite que chaque commit soit examiné par deux développeurs. Une fois que la validation est lancée, la suite entière de test est actée sur chaque commit. Ce processus assure un code de bonne qualité et doit intégrer presque toutes les fonctionnalités des versions antérieures avant qu'elles ne soient intégrées dans une nouvelle version. Presque tous les commits sont également suivis en relation avec les entrées de Bugzilla qui incluent des tests régressifs. premier coup d'oeil Après l'installation de Samba, l'administrateur verra quelques changements. Pour les membres de domaine traditionnels, tels que les serveurs de fichiers, le smbd prévu, nmbd et binaires winbind sont présents et doivent continuer à être utilisés pour ces applications. Pour les serveurs qui fournissent des services de contrôle de domaine, Samba s'exécute comme un simple binaire de Samba. Puisque Samba ne supporte pas complètement l'appartenance à un domaine en tant que membre, les démons appropriés doivent êtres démarrés selon le rôle que doit tenir le serveur. Une nouvelle boite à outil Samba est le premier moyen pour contrôler un serveur Samba qui fournit des services de Domaine. La syntaxe est très similaire à celle utilisée par la commande net.
Les outils de la base de données traditionnelle (TDB) ainsi que smbcacls, smbclient, rpclient et d'autres binaires sont toujours fournis comme on peut s'y attendre. Mais si on installe Samba 3.x et 4.x en parallèle sur un seul hôte, l'installation peut être périlleuse. Tout comme la compilation par vos soins d'un Samba sur un hôte qui possède déjà un Samba 3 installé. Si vous faites une installation parallèle des deux versions n'oubliez pas de regarder votre PATH pour s'assurer que vous utilisez les versions appropriées des outils. L'utilisation la plus basique de Samba est tout simplement celle d'un serveur de fichiers dans lequel Samba 4 excelle. Les mécanismes internes du serveur de fichiers sont dorénavant hautement asynchrone, fournissant un débit plus élevé et une meilleure utilisation des ressources du serveur. Une autre amélioration des performances du serveur de fichier est le support des protocoles SMB2.1 et SMB3. Ces versions de Samba de plus haut niveau sont de mieux en mieux supportées sur les clients Microsoft Vista et postérieurs. Les évolutions du protocole SMB fournissent l'encryptage, le support des liens symboliques, la copie sur le serveur et des fonctionnalités de haute disponibilité tels le multipath et le failover. Un serveur de fichiers SMB3 devrait dépasser en performance un serveur de fichiers CIFS plus ancien. Avant de passer au support de Active Directory, notez que votre serveur doit utiliser un système de fichiers moderne supportant bien les attributs étendus. Si vous utilisez un filesystem ext3 ou ext4 sur Linux, vous devez vous assurer que le système de fichiers est monté avec les options user_xattr, acl, barrier = 1. Si un système de fichiers ext3/ext4 est monté sans l'option barrier=1, on ne peut garantir que les bases de données de TDB utilisés par Samba restent cohérentes en cas de crash système. Une base de données TDB cassée peut entrainer la corruption d'un domaine Active Directory. Si vous êtes bloqués sur un système sans un système de fichiers moderne, le wiki Samba a des informations sur une solution de contournement, mais la mise à niveau de l'hôte est une option préférable. Active Directory Dès l'installation ("out of the box"), le support d'active Directory fonctionne. La création d'un domaine Active Directory peut être effectuée en quelques secondes en utilisant les outils Samba. Cette façon interactive de configurer un domaine vous demandera de spécifier votre zone DNS, le nom de domaine et le mode de DNS préféré (Listing 1). Listing 1: Creating a New Active Directory sudo./bin/samba-tool domain provision Realm [EXAMPLE.COM]: Domain [EXAMPLE]: Server Role (dc, member, standalone) [dc]: DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]: DNS forwarder IP address (write 'none' to disable forwarding) [192.168.1.46]: Administrator password: Retype password: Looking up IPv4 addresses... Fixing provision GUIDs A Kerberos configuration suitable for Samba 4 has been generated at /opt/s4/private/krb5.conf Once the above files are installed, your Samba4 server will be ready to use Server Role: active directory domain controller Hostname: workstation NetBIOS Domain: EXAMPLE DNS Domain: EXAMPLE.COM DOMAIN SID: S-1-5-21-1405516098-4140136852-3456372168 Dès lors, quand vous démarrez Samba, vous lancez ensemble les services Kerberos, DNS, LDAP et
Active Directory. Bien que ce processus semble simple, la réalité est que le support Active Directory est aussi compliqué que Active Directory lui-même. Avant de créer un nouveau domaine Active Directory tenu par Samba, l'administrateur doit vraiment apprendre les bases de Active Directory, ce qui sort du cadre de cet article. Et l'intégration du système d'exploitation Unix-like sous-jacente au serveur de domaine Active Directory amène un degré de complexité supplémentaire. Plus important encore, les administrateurs doivent comprendre ce qui suit : - Un domaine Active Directory est un domaine DNS. Le domaine de la sécurité et le DNS sont inextricablement liés bien plus qu'avec les domaines Windows NT 4.0 (NT4). La modification ou la création d'un domaine Active Directory signifie très probablement un changement dans votre architecture ou vos DNS existants. - Un domaine Active Directory est un domaine Kerberos. Une exigence de Kerberos est la synchronisation précise des horloges. Des différences de temps entre serveurs et clients supérieures à quelques minutes par rapport à l'horloge du contrôleur de domaines rendront inopérant certains services de ces serveurs ou de ces clients. Pour les serveurs, cela signifie aussi que les librairies et utilitaires Kerberos utilisés doivent être disponibles et correctement configuré. Le problème le plus commun avec les versions Kerberos est que les contrôleurs de domaine Active Directory peuvent exiger hachage et encryptage qui peuvent ne pas être disponibles avec les anciens clients Kerberos. - Active Directory est un service d'annuaire LDAP avec son propre schéma et son modèle de sécurité. Active Directory est Active Directory, que vous utilisiez un contrôleur de domaine Samba (DC), Windows Server DC, ou un mélange des deux. Les questions sur la liste de diffusion Samba concernant l'utilisation de Samba 4 sont souvent seulement des questions concernant Active Directory. Vous pouvez casser un domaine AD Samba de la même manière que vous pouvez casser tout domaine AD. Le wiki Samba fournit de très bonnes instructions étape par étape sur la création d'un contrôleur de domaine Active Directory. Vous devriez en priorité l'utiliser comme votre documentation. Pour le reste de cet article je vais me concentrer sur quelques-uns des différents pièges et informations qui ne sont pas mises en évidence sur le wiki. Intégration AD Pour obtenir une intégration complète dans Active Directory, Samba lui-même doit être étroitement intégré avec DNS, fournir des services de contrôleur de domaine Kerberos, et fournir un service d'annuaire LDAP conforme à celle attendue par un client Active Directory (figure 1). Figure 1: Active Directory est une collection étroitement intégrée, de services. Avec le précédent support de domaine NT4, Samba était capable de déléguer le traitement de ces fonctions à des services externes tels que BIND, OpenLDAP, et le MIT ou Heimdal Kerberos. À l'exception de BIND pour le DNS, la possibilité d'utiliser du code tiers dans ces rôle n'existe plus. Une pratique courante avec les domaines NT4 Samba était d'utiliser le ldapsam back-end pour gérer les comptes de sécurité du domaine (SAM) en s'appuyant sur une source de données (DSA)
OpenLDAP. Cette capacité n'existe plus. Le service LDAP utilisé dans Samba est maintenant le service LDAP Samba (intégré). Les sites utilisant OpenLDAP doivent, pour migrer vers Active Directory, migrer au moins leur base SAM vers le serveur intégré LDAP Samba. Il en est de même si le site utilise un centre de distribution autonome MIT ou Heimdal clé (KDC), la fonction KDC doit être migré vers l'hôte Samba. Il faudrait faire la même chose si le contrôleur de domaine AD était un serveur Microsoft. Il pourrait sembler que la prise en charge par Samba de toutes ces fonctions est contraire au concept d'ouverture ou de support des standards ; c'est le cas et le projet l'assume. La perte de l'aptitude à utiliser une tierce partie DSA comme OpenLDAP est regrettable, mais fournir un modèle de domaine fiable et cohérent forgé à partir de composants disparates s'est avéré trop difficile. L'un des principaux objectifs de cette version Samba est de fonctionner "out of the box", ce qui signifie que Samba doit prendre en charge tous ces rôles en parallèle. Le principal avantage d'un domaine Active Directory est que tous les composants (par exemple, DNS, LDAP, KDC) sont intégrés et peuvent être étendus sur plusieurs contrôleurs de domaine. Malgré l'inconvénient d'utiliser ces solutions transitoires pour ces services réseaux, Samba fournit maintenant ces mêmes avantages : une intégration étroite et un schéma convenu. Un contrôleur de domaine AD Samba peut se connecter avec des contrôleurs de domaine Samba AD ou avec d'autres contrôleurs de domaine Windows AD. ON peut monter un serveur Samba et le promouvoir au rôle de DC dans votre domaine existant. Ces contrôleurs de domaine répliqueront les informations du domaine, offrant le même niveau de résistance aux crashs que n'importe quel domaine Windows AD DC pourrait fournir... ou presque. Jusqu'à la version 4.0.3, quelques petits problèmes ont été rencontrés : 1. Un contrôleur de domaine AD Samba ne réplique pas complètement quand il est associé avec un contrôleur de domaine Windows AD (en lecture seule). 2. La réplication des informations du DNS ne se fait pas de façon fiable entre les contrôleurs de domaine lorsque vous utilisez le serveur DNS intégré de Samba. 3. Le volume sysvol, qui stocke les politiques GPO, ne réplique pas automatiquement. 4. La délégation de privilège et les ACL avec des objets LDAP fait éprouver des difficultés au début, mais ces problèmes ont été résolus dans la version 4.0.3. 5. D'après mon expérience sur un Samba AD DC, un script spécifié en utilisant le paramètre winshook qui devrait fonctionner de la même manière que sur les versions précédentes, ne semble pas être fonctionnel. [Bug 9651] 6. Les clients Windows se plaignent du fait qu'ils ne peuvent pas désactiver la mise en cache hors ligne sur le partage de profil [Bug 7810] (Ceci est un message non critique et n'affecte pas les opérations). Les questions 2 et 3 sont les plus importants et doivent être abordées lors de l'utilisation d'un contrôleur de domaine AD Samba. Migration vers Samba Si vous avez déjà un domaine Active Directory utilisant des serveurs Microsoft Windows et qu'ils gérer votre DNS, alors le problème de DNS dans son ensemble peut être laissées de côté, sauf si votre intention est de migrer entièrement à Samba. Sinon, vous pouvez utiliser comme alternative l'intégration BIND DLZ, qui permet au DC Samba de gérer un domaine DNS dans BIND et donne à l'administrateur la même capacité à exécuter les notification de mise à jour BIND, le transfert de zone, et ainsi de suite. L'inconvénient de l'intégration BIND DLZ est qu'il ajoute un autre élément à la pile, quoique celui ci est très familier pour la plupart des administrateurs. Lors de la création ou de la migration d'un domaine NT4 vers Samba existant, le serveur DNS intégré sera utilisé par défaut. Ce serveur DNS simple est adéquat pour les petits sites, mais il lui manque beaucoup de la puissance et de la flexibilité de BIND. Pour changer de prise en charge DNS lors de la création ou de la migration d'un domaine, spécifiez l'option --dns-backend = BIND9_DLZ Si un domaine est initialement alimenté parle serveur DNS interne, il peut ensuite être migré vers BIND DLZ à l'aide du script samba_upgradedns ; il vous suffira alors de configurer le module BIND
DLZ. Quelque soit le back-end DNS, le domaine DNS du domaine Active Directory peut être géré avec les outils de gestion de domaine Windows. En fait, c'est le cas avec toutes les fonctionnalités de Samba : Vous pouvez gérer le serveur Samba de la même manière que vous souhaitez gérer un serveur Microsoft Windows via le Microsoft Management Console ( MMC). Les administrateurs familiers du MMC ne sauront pas qu'ils gèrent une plate-forme non-microsoft. Si vous migrez ou alimentez au départ votre domaine en utilisant le serveur DNS intégré -ce qui est la voie la plus simple, et puis décidez que vous avez besoin de la flexibilité supplémentaire fournie par l'intégration de BIND, vous pouvez migrer le DNS du domaine en utilisant le script samba_upgradedns fourni. La principale mise en garde de l'utilisation de l'intégration de BIND est que vous avez besoin d'une version mise à jour de BIND. Bien qu'il soit possible d'obtenir un fonctionnement correct avec BIND 9.7.x, une version de 9.8.x ou supérieure est fortement recommandée. Les fonctions de mises à jour sécurisées et le support pour Kerberos ont vu des évolution rapides de certaines parties de BIND ; être à jour peut vous aider à éviter les maux de tête. Une approche recommandée pour DNS est d'utiliser un domaine séparé ou sous- domaine de la zone DNS d'active Directory. Cela facilite la migration lors de l'ajout d'un Active Directory à un réseau existant. Si votre domaine actuel est example.com et que vos serveurs DNS résolvent les noms dans ce domaine, vous pouvez créer votre nouveau domaine AD comme ad.example.com. Ensuite, vous pouvez configurer vos serveurs DNS existants à déléguer la résolution de ce domaine pour vos serveurs DNS DC. Sur un DC Samba qui est un serveur DNS, vous pouvez ajouter ce qui suit : [global ]... dns transitaire = 192.168.1.46 à la section globale du fichier smb.conf. Si 192.168.1.46 est votre serveur DNS existant, le DC va transmettre toutes les demandes pour les zones autres que les siens à votre serveur DNS existant. Avec la délégation de votre DNS existant et le transfert vers l' AD DNS, vous serez en mesure de fournir une transition en douceur alors que vous fonctionnez sur AD. Si vous commencez avec le DNS interne Samba fourni, une fois que tout fonctionne, vous pouvez alors envisager de migrer vers le back-end BIND DLZ - DNS. Il est beaucoup plus facile d'isoler les problèmes si vous déployez votre domaine étape par étape. La question de la réplication sysvol est plus fastidieux. Dans la réplication sysvol, ce sont les fichiers qui représentent les objets de stratégie de groupe du domaine, ainsi que les scripts de connexion. Ce volume partagé doit être présent sur tous les contrôleurs de domaine accessibles aux clients. Lorsque des modifications sont apportées aux scripts de login ou GPO, ces fichiers doivent être répliqués à partir de l'original vers tous les DC, cette réplication doit être effectuée en utilisant des outils comme rsync et csync. La liste de diffusion archive Samba a un script à cet effet. Les ACL appliquées aux fichiers sur le volume sysvol sont essentiels pour le bon fonctionnement de clients. Si manuellement, ou par tentative de réplication, vous vous retrouvez avec des ACL incorrectes, la boite à outils samba peut être utilisée pour les réinitialiser aux valeurs attendues : samba- outil sysvolreset ntacl Cette commande devrait également être exécutée lorsque Samba est mis à niveau d'une version à l'autre. Heureusement, la réplication du volume sysvol n'a pas besoin de se produire en temps réel. Grâce à des outils tels que rsync ou csync, ce processus peut être effectuée efficacement en tant que tâche planifiée. Une fois que le domaine est alimenté et que le DNS et Kerberos ont été testés, vous pouvez commencer à joindre les postes de travail à votre domaine. Si vous avez migré vers le domaine Active Directory à partir d'un domaine Samba NT, les postes de travail devraient conserver leur appartenance au domaine ; ils passeront Active Directory automatiquement.
Mise à niveau de NT4 vers AD La mise à niveau est presque aussi fluide que d'approvisionner un nouveau domaine. La chose la plus importante à savoir sur une mise à niveau vers Active Directory, c'est qu'il est à sens unique. À partir du moment où un poste de travail rattaché à un domaine NT, voit un domaine AD avec le même SID ou nom NetBIOS, il passe en mode Active Directory, et il ne reviendra jamais à l'utilisation du mode DC sous NT. Par conséquent, vous devez tester la mise à niveau de votre domaine avec soin, isolé de votre réseau de production, ou vous pourriez vous retrouver attaché à une instance de test de votre DC. Les clients validés AD-Microsoft fonctionnent ainsi naturellement et ce n'est pas spécifique à l'usage d'un AD DC Samba. Pour effectuer la mise à niveau, vous pouvez utiliser les outils samba de support de mise à niveau de domaine. L'outil doit avoir accès à une copie du fichier smb.conf utilisé par l'un de vos contrôleurs de domaine, ainsi que des copies des fichiers TDB. Ces fichiers peuvent être transférés sur votre serveur de test, par exemple, via rsync ou scp. Si votre NT4 DC utilise ldapsam, l'hôte d'essai doit également avoir accès à la DSA tel que configuré dans le fichier smb.conf. Le script de migration ne lit que du ldapsam, donc rien dans le NT4 SAM actuel ne sera modifié : samba- outil domaine classicupgrade - dbdir = / tmp / x - utiliser - xattrs = yes \ - realm = Exemple / tmp / x / smb.conf L'option dbdir spécifie l'emplacement des fichiers TDB du contrôleur de domaine NT4, et l'option realm (domaine) spécifie la zone DNS pour le nouveau domaine AD et l'emplacement d'une copie du fichier smb.conf du DC NT4. À condition que votre SAM NT4 soit cohérente, le script de migration devrait migrer tous les utilisateurs, les groupes et les comptes d'ordinateur. Lors de la migration d'un ldapsam, surtout, vous aurez probablement rencontré quelques incohérences (par exemple, noms d'utilisateur en double, SID, ou des groupes disparus ) qui fera l' échec de la migration ; heureusement, les messages d'erreur ont tendance à être auto- explicatif. Si vous migrez depuis une ldapsam qui a existé pendant une longue période, il peut devenir évident de comprendre pourquoi Samba doit gérer tous les services lui-même: le paresseux NT4 DC continuera à fonctionner en dépit de nombreuses incohérences. À supposer que toutes les erreurs soient dues à des problèmes liés à avec votre SAM NT4, résoudre les problèmes à ce niveau-là, puis tenter à nouveau la migration jusqu'à ce qu'elle se termine. Un réel avantage que Samba donne à des sites utilisant encore des domaines NT4 est qu'il fournit un cheminement pour la mise à niveau vers Active Directory. Tous les outils de migration que je connais pour migrer d'un domaine NT4 à un domaine Active Directory ne sont plus disponibles pour les versions actuelles de Windows Server. Les clients Windows actuel ne sauront pas interagir avec un domaine NT4 sans un certain tripatouillage de la base de registre et, même alors, pas complètement. Samba peut au moins fournir un moyen pour ces sites de migrer vers AD en ajoutant des DC Windows et rétrograder le DC Samba, en laissant vivre un domaine Windows tout-ad ; bien que l'on espère que les administrateurs de ces sites reconnaîtront les avantages et la flexibilité des Samba DC et choisir de le garder sous la main. Maintenant que votre AD Samba est en marche, de nombreuses opérations courantes, telles que l'ajout d' un utilisateur, des entrées DNS, peuvent être accomplies avec l'outil samba-tool (Listing 2). Listing 2: Ajout d'un utilisateur with samba-tool samba-tool user add fbaggins --random-password --use-username-as-cn --surname="baggins" --given-name="frodo" --initials=s --mail-address=fbaggins@example.com --company="hobbiton Inc." --script-path=shire.bat --profile-path=\\\\mydc.example.com\\profiles\\ fbaggins --home-drive=f --home-directory=\\\\myfileserver.micore.us\\fbaggins --job-title="goes there and back again"
Vous pouvez aussi lancer MMC sur un client Windows et commencer à gérer votre nom de domaine (figure 2 ). Figure 2: Modification d'un DNS sur un DC Samba via MMC. Une fois en marche, Samba stocke les informations de domaine dans un ensemble de fichiers LDB. interconnectés. Le contenu de la base de données (SAM ) peut être modifiée via samba-tool, via LDAP, ou avec ldbsearch de Samba, ldbmodify, ldbdel, et d'autres commandes correspondantes. Une fois votre domaine actif, vous voudrez peut-être ajouter des informations supplémentaires sur les utilisateurs, tels que des numéros de téléphone. Vous pouvez générer des fichiers LDIF à importer en utilisant LDAP ou outils LDB ou directement via LDAP à l'aide des outils Python qui supportent l'api Kerberos Generic Security Services ( GSSAPI ). Winbind et d'autres services sur des serveurs Samba 3 ou 4, membres de domaine (non DC) fonctionnent simplement comme ils le faisaient auparavant. N'oubliez pas de lancer smbd, nmbd et windbind -sur les serveurs membres, et non pas le démon samba unifié. Maintenance de l'heure Après vous avez intégré les postes de travail au domaine, vous remarquerez que les horloges dérivent. Parfois, vous n'aurez plus d'accès à cause des exigences de synchronisation de temps de Kerberos, et vous devez donc vérifier que les configurations de samba et NTP correspondent et que les deux ont un accès adéquat dans le répertoire spécifié : # Check the configuration of Samba $ testparm --parameter-name="ntp signd socket directory" /opt/s4/var/ntp # Check configuration of NTP $ cat /etc/ntp.conf... ntpsigndsocket /opt/s4/lib/ntp/ restrict default mssntp # Change permissions of target folder $ chown ntp /opt/s4/lib/ntp
Les clients de domaine Microsoft ne synchroniser à votre service de temps NTP standard car ils nécessitent un serveur de temps qui a été signé par un DC, auquel ils ont confiance ; par conséquent, vous devez installer une version du serveur NTP sur vos contrôleurs de domaine qui prend en charge la signature des paquets ( c'est à dire, n'importe quelle version de ntpd après v4.2.6, à condition qu'il ait été construit avec l'option --enable-ntp- SIGND ). La version de NTP livrée avec RHEL6/CentOS6 et Ubuntu 11.04 est trop vieille et ne supporte pas la signature. Une fois que vous disposez d'une version installée adéquate de NTP, vous devez configurer Samba et NTP pour communiquer. Cela se fait par l'intermédiaire d'un filesystem socket. Samba va créer un tel socket, auquel NTP peut soumettre les réponses d'horloge à signer. NTP alors répondre au client avec les réponses signées. L'emplacement par défaut de la socket créée par Samba est <prefix>/var/ntp /, où <prefix> est le préfixe d'installation de votre Samba (compilé ou paquet). On peut aussi spécifier l'emplacement en utilisant la directive ntp signd socket directory dans la section globale du fichier smb.conf. Dans le fichier ntp.conf, ntpsigndsocket est utilisé pour indiquer le même répertoire. L'aspect très déroutant de cette configuration, à la fois dans Samba et NTP, est que ces directives de configuration n'indiquent pas un fichier, ils indiquent un dossier où une filesystem socket nommé socket est créée, puis attendue comme devant être trouvé. Lorsque vous redémarrez samba, vous devriez voir une socket nommée socket dans le répertoire que vous avez spécifié et Samba écoute sur la socket : $ sudo ls -l /opt/s4/var/ntp/socket srwxrwxrwx 1 root root 0 Feb 12 14:42 /opt/s4/var/ntp/socket $ sudo fuser -u /opt/s4/var/ntp/socket /opt/s4/var/ntp/socket: 1124(root) La sortie de l'utilitaire fuser vérifie que le socket créé automatiquement est ouvert par le processus 1124 (samba ). Sur un client Windows, il est essentiel que la commande : w32tm /resync /rediscover se termine avec succès ; vous devriez voir le message The command completed successfully. Si cette commande n'est pas terminée, la signature de temps n'est pas configuré, et vous courrez le risque de dérive d'horloge, et de désactiver ainsi certaines parties de votre domaine. Grâce à la synchronisation de temps, vous avez maintenant un domaine Active Directory entièrement fonctionnel et stable - avec l'aimable autorisation de code sous GPL. Conclusions Samba 4 fait plus que fournir des services de réseau améliorées. Samba 4 s'intègre pleinement avec Active Directory, et vous pouvez migrer un domaine Active Directory vers Samba 4 ou utiliser Samba 4 pour fournir un moyen de mise à niveau fiable de NT4 vers Active Directory. (*) Traduit de http://www.linux-magazine.com/online/features/what-s-new-in-samba-4