Tranquil IT est une société commerciale française qui vend de la prestation autour de Samba 4 AD DC (implémentation libre d'un contrôleur de domaine Microsoft avec un niveau fonctionnel winwin 2008 R2) : formation / transfert de compétences, migration AD / Samba 3 vers Samba 4 AD DC, documentation Samba 4 en libre accès, etc.

Elle développe également WAPT (Windows Apt), un logiciel libre (GPL) de gestion de parc avec inventaire et déploiement de logiciels et de configurations pour winwin, mais j'ai rien à en dire (pour l'instant ?). De quoi remplacer le vieillissant et plus maintenu wpkg ? Je ne sais pas (encore ?).

Nous avons eu recours aux services de cette société pour nous former sur Samba 4 AD DC et préparer une maquette de notre architecture Samba 4 (plusieurs contrôleurs, BIND DLZ + délégation DNS, avitaillement des identités / comptes utilisateur depuis notre OpenLDAP, PRA Samba 4, etc.). Rien à signaler. Nous n'avons pas souscrit à sa prestation de migration, car cette dernière nécessitait un travail d'intégration (scripts, procédures, etc.) sur lequel nous voulions garder la main.

Bref, une petite société commerciale qui fait vivre le logiciel libre.

Des collègues se plaignent que les modifications qu'ils effectuent dans notre IPAM (interface web de gestion des adresses IP et de la conf' DHCP et DNS ‒ quelle IP est utilisée ? À qui est-elle attribuée ? Dans quel VLAN ? Etc. ‒) maison ne deviennent pas effectifs dans le DNS. Un collègue diagnostique l'usage d'un underscore dans le nom d'une machine, caractère qui serait invalide dans le DNS et bloquerait nos serveurs de noms BIND.

Je tique. À l'école Bortzmeyer, on a appris que le DNS impose une seule limitation concernant les noms, c'est leur taille. De plus, de nos jours, l'underscore est utilisé dans plein de noms DNS. DKIM (signature électronique de l'entête des emails afin d'authentifier le domaine d'émission), DANE TLSA (réparer l'énorme faille conceptuelle des certificats x509 utilisés pour authentifier les parties d'un échange chiffré ‒ TLS, par exemple ‒, voir un exemple d'utilisation ici). Jabber (protocole de messagerie instantanée textuelle libre et fédéré). Tous utilisent l'underscore, et ça se passe très bien.

Je regarde le journal de notre serveur DNS (BIND) : « nom-de-machine_a_suppr.mon-organisation.example: bad owner name (check-names) ». C'est donc vrai. Whaaat ?! :O Il y a donc une contradiction entre la théorie et la pratique.

Un essai me montre que, sur un BIND récent (9.10, packagé dans Debian Stretch), on peut ajouter un nom contenant un underscore si son type est SRV ou TXT, mais pas si son type est A ou AAAA. Cela met en exergue un comportement qui va au-delà de la norme, qui est sans doute spécifique à une implémentation.

L'école Bortzmeyer nous a aussi appris qu'il y a une différence entre un nom de machine et un nom de domaine et que les caractères autorisés pour un nom de machine sont beaucoup plus restreints que pour un nom de domaine. Mais… ça ne change rien, BIND manipule bien un nom de domaine, donc il devrait autoriser l'underscore, qui est un caractère valide pour un nom de domaine (mais pas pour un nom de machine).

Il devrait, oui, mais, par défaut, BIND vérifie que les noms associés à un type A ou AAAA respectent la syntaxe d'un nom de machine. L'idée est de dire que, 99 % du temps, l'administrateur voudra associer une IP à un nom de machine, car ce nom sera manipulé par des programmes qui manipulent des noms de machines et l'admin voudra que ça fonctionne. On peut débrayer ce comportement avec les directives de configurations « check-names ».

Un essai avec nsd 4, autre implémentation d'un serveur DNS qui fait autorité, montre aucun problème : il est parfaitement possible d'associer un nom de domaine avec un underscore à une adresse IP.

Si l'on résume : un nom de domaine a bien aucune limite concernant les caractères qui le composent, mais une implémentation de serveur DNS comme une autre, BIND, a fait le choix de bloquer les noms DNS qui ne respectent pas la syntaxe d'un nom de machine (lettres + chiffres + tiret) quand ils sont associés à un type A ou AAAA ou MX. D'après la doc', BIND vérifie également la syntaxe de la valeur d'un nom de domaine (le RDATA) pour les types SOA, NS, MX, SRV et PTR.

Un autre point m'échappe. Avant de pousser en production le fichier de zone généré par notre IPAM, nous utilisons un script de contrôle maison qui se repose, entre autres, sur named-checkzone. Il s'agit d'un outil livré avec BIND. Pourquoi a-t-il rien détecté ?

Le contrôle de la syntaxe des noms a été introduit dans la version 9.2 de BIND 9, mais il n'est pas activé par défaut. Sur les serveurs DNS maîtres, il est activé par défaut depuis la version 9.3.

named-checkzone vérifie la syntaxe des noms à partir de la version 9.3 de BIND 9, mais il se contente d'émettre un avertissement. C'est toujours le cas dans la dernière version stable (9.14).

Donc, forcément… Vu qu'il écrit tout sur stdout, si named-checkzone ne sort pas en erreur, notre script considère que tout est OK et met le fichier de zone en production. Tout s'explique.

Solutions ? Soit débrayer le contrôle de la syntaxe des noms dans la conf' de BIND, soit forcer named-checkzone à sortir en erreur si le contrôle de la syntaxe des noms échoue en utilisant son option -k fail, soit utiliser une autre implémentation de serveur DNS (BIND veut assurer les deux grands services distincts du DNS ‒ serveur qui fait autorité et serveur récursif ‒ + il veut implémenter toutes les fonctionnalités à la mode + il est monolithique = il est plus difficile à sécuriser).

Pour moi, ce contrôle de la syntaxe des noms de domaine est illégitime en cela qu'il n'est pas conforme à la norme, même s'il évite des prises de tête aux administrateurs (mais il en donne à d'autres, comme moi…).

C'est dans ce genre de moments que je me réjouis d'avoir une monoculture de serveurs DNS (d'utiliser que du BIND au sein d'une même architecture) : si l'on avait eu une diversité de serveurs de noms, certains auraient accepté le fichier de zones et d'autres non, ce qui aurait causé quelques instabilités sur le réseau et aurait rendu la mise en exergue du problème compliquée (le diagnostic n'aurait pas changé : un coup de check-soa, on aurait vu un numéro de série différent, on aurait analysé les journaux, etc.).

XiVo est une solution de téléphonie complète en logiciel libre (GPL, LGPL) développée en France. Elle est basée sur l'autocommutateur téléphonique Asterisk (je me suis déjà un peu amusé avec). XiVo propose une surcouche comme une interface web bien foutue et des API (pour changer les droits d'appel ‒ appels nationaux, internationaux, vers des numéros surtaxés, etc. ‒, pour changer le nom d'une ligne, etc.).

XiVo sait faire toute la téléphonie d'entreprise habituelle : appels, interception d'appel, renvoi d'appel (tout ou conditionné), filtrage d'appel (dit patron/secrétaire), files d'attente, messagerie vocale, diffusion d'un message éventuellement conditionné à un calendrier, salon de conférence, etc. Je crois que le seul truc que ça ne fait pas, c'est des rapports de facturation genre agréger la consommation des lignes téléphoniques d'un service afin de faire de la refacturation interne (le service informatique paye l'intégralité de la facture de téléphone et refacture leur consommation aux autres services) et de présenter aux chefs la consommation de leurs sous-fifres sous une forme kikoo-jolie.

Nous utilisons cette solution depuis 5 ans. Nous avons deux machines virtuelles Debian GNU/Linux + XiVo en failover sur deux sites géographiques pour la partie commutation, deux lignes téléphoniques T2 avec deux passerelles T2<>IP XiVo, des téléphones IP, des téléphones analogiques avec des rocades analogiques et des passerelles analogique<>IP Patton et Realtone, des logiciels de téléphonie (softphones) + XiVo client (qui permet des recherches dans l'annuaire, de voir qui nous appelle, de transférer simplement un appel, etc.), et des saloperies automatiques qui nécessitent une ligne de téléphone (ascenseurs, interphones, etc.) soit un total de 850-900 lignes.

L'éditeur de XiVo, Avencall, propose des prestations d'intégration et de support pour tout le périmètre sus-cité, une liste de matériels totalement compatibles (genre un téléphone IP avec les touches de fonction ‒ intercepter l'appel d'une autre ligne, par exemple ‒ fonctionnelles, genre des casques audio avec les boutons de fonction ‒ muet, sourd, etc. ‒ fonctionnels) et de la revente de matos (genre des téléphones IP, des cordons de téléphone, etc.). D'autres prestataires / revendeurs existent sur le marché, mais nous avons été déçu par le précédent.

Merci Seb' d'avoir monté et entretenu tout ça toutes ces années. :)

LDAP Synchronization Connector, LSC, est un logiciel libre (avec des restrictions sur l'usage du nom), programmé en Java et qui mange une configuration en XML, qui permet de synchroniser (créer, modifier, supprimer) le contenu d'un annuaire LDAP (OpenLDAP, Samba 4 AD DC, etc.) depuis tout un tas de sources : un fichier CSV, une base de données, un autre annuaire LDAP, etc.

LSC peut fonctionner selon 3 modes :

• Le mode one-shot / synchrone (lsc -f /etc/lsc -s all) permet de créer un ou des objets / identités à un instant T en étant sûr qu'ils seront créés sans délai (dans le lsc.xml que l'on mettra dans /etc/lsc, il faut créer autant de tâches qu'il y a de comptes utilisateurs à créer) ;
  
  
• En mode démon / asynchrone (lsc -a all), LSC synchronise tous les attributs qu'on lui demande de tous les objets qu'on lui demande de surveiller. LSC fait une comparaison complète de l'annuaire (ou d'une branche) puis, si la source est un LDAP, toutes les 5 secondes, il fait une recherche avec le filtre LDAP « (modifyTimestamp>=<maintenant - 5 secondes>) ». Si des objets ont été modifiés dans la source ces 5 dernières secondes, il synchronise les objets correspondants dans la destination ;
  
  
• Le mode nettoyage (lsc -c all) supprime de la destination tout les objets qui ne sont plus dans la source. Oui, même si tu précises « delete » = « true » dans « conditions » dans « propertiesBasedSyncOptions » dans la définition d'une tâche, LSC ne supprimera pas l'objet tant qu'il tournera en mode démon / asynchrone.

Nous utilisons LSC pour synchroniser un Samba 4 AD DC (implémentation libre d'un contrôleur de domaine winwin) à partir d'un OpenLDAP. Nous avons besoin d'un contrôleur de domaine, notamment pour intégrer les versions récentes de Windows (Samba 3 / domaine NT 4, c'est mort depuis 10 à 15 ans) et pour intégrer pleinement les NAS modernes (CIFS, NFSv4 authentifié, possibilité pour l'utilisateur de restaurer lui-même ses données ‒ onglet « versions précédentes » dans les propriétés d'un fichier/dossier sous winwin ‒, etc.), mais nous n'avons pas encore envie que Samba 4 devienne le cœur de notre système d'information, on veut qu'il reste en périphérie, qu'il s'occupe uniquement des stations de travail winwin. Une comparaison complète, par un seul thread, entre notre OpenLDAP et notre Samba 4 prend environ 7 minutes pour environ 10 000 objets / identités utilisateur.

Info importante : dans l'Active Directory de Microsoft, et Samba 4 respecte cela, le mot de passe d'un utilisateur est en écriture seule quand on y accède par le protocole LDAP. Autrement dit : le mot de passe étant impossible à lire, il est impossible, pour LSC, de le comparer afin de savoir s'il a changé par rapport à la source. Deux solutions : 1) lorsqu'un utilisateur change son mot de passe, on le change dans Samba 4 AD DC avec samba-tool user setpassword ; 2) lorsqu'un utilisateur change son mot de passe, on pourrait le chiffrer et le mettre dans l'attribut Samba 4 « userPasswordEncrypted » puis la synchronisation (mode démon) de LSC déchiffrerait le mot de passe et le mettrait dans le bon attribut Samba 4 (voir la doc' LSC à ce sujet).

Merci à Seb' d'avoir intégré LSC et d'avoir appuyé le choix Samba 4 AD DC (ça m'aurait bien fait chier de payer M$ pour un contrôleur de domaine). :)