Wednesday, April 10, 2019

CentOS7 (FR) 2 : mise en place de BIND (DNS)

English summary: I prepare a server running CentOS 7.6 for BIND DNS, install BIND and then configure services, zones and resource records. I configure DNS clients in the following blog post.

***

Dans cet article, je prépare un serveur CentOS 7.6 pour l'installation de BIND et ensuite configure services, zones et enregistrements ressource. La configuration des clients DNS se fera dans l'article suivant.

D'abord, notre futur serveur DNS (LX1) a déjà une adresse IP statique (une des exigences pour le rôle), soit :

10.4.4.1

Quant au nom d'hôte, "LX1", nous devons le changer en FQDN. Nous pourrions utiliser un domaine imaginaire tel que "exemple.net" mais, comme j'ai acheté quelques domaines pour mes réseaux d'essai, je me servirai de l'un d'entre eux, machlinkit.biz, pour cette expérience. Nous avons donc :

LX1.machlinkit.biz

Je change donc le nom d'hôte avec cette commande :

hostnamectl set-hostname LX1.machlinkit.biz

Je fais redémarrer le service :

systemctl restart systemd-hostnamed

Je ferme et rouvre ma session.

Et je vois ceci (ce qui est sans doute normal) :



En d'autres mots, l'invite de commande affiche toujours "LX1" plutôt que le FQDN.

Et maintenant, je vais installer et configurer BIND. L'ordre des étapes de la configuration varie selon les différentes sources que j'ai consultées (livres ou en ligne). En gros, je vais suivre cet ordre :
  1. Installer BIND.
  2. Configurer le démarrage du service "named".
  3. Configurer le pare-feu (s'il est activé) pour autoriser les requêtes DNS entrantes.
  4. Editer le fichier named.conf
  5. Définir des zones
  6. Définir des enregistrements ressource.
  7. Changer le propriétaire des fichiers de zone.
  8. Valider la configuration et les zones.


1. Installer BIND

Nous installons BIND avec cette commande :

yum install bind

Certaines sources ajoutent aussi bind-utils alors que d'autres affirment que ces outils sont installés quand nous installons les binaires pour le serveur. Nous verrons.

Quand yum me demande de confirmer que je souhaite vraiment installer les binaires ou importer une clé, je saisis "y" (pour "yes") ou "o" (pour "oui") afin de continuer l'installation.



2. Configurer le démarrage de named

Si j'exécute la commande suivante, je vois que le service named n'apparaît pas, bien que nous venions d'installer BIND :

systemctl list-units --type service

Cette commande n'affiche que les services actifs et nous n'avons pas fait démarrer named ou configuré le service pour qu'il se lance de façon automatique au démarrage.

Remarque : la liste des services est assez longue et je ne mettrai pas les multiples captures d'écran ici.

Si nous voulons afficher tous les services, actifs ou inactifs, nous devons ajouter le paramètre --all :

systemctl list-units --type service --all


Mais cela n'affiche toujours pas named (ceci ne donne rien) :

systemctl list-units --type service --all | grep named


Il faut cette commande-ci pour constater que le service est bien installé mais désactivé :

systemctl list-unit-files | grep named



Ces commandes nous donnent encore une autre perspective :

systemctl is-active named

systemctl is-enabled named



Je vais donc faire démarrer le service avec cette commande :

systemctl start named

L'état change alors et nous avons comme valeur "active" et disabled" respectivement.

Je configure le service pour un démarrage automatique (au démarrage du serveur) avec cette commande :

systemctl enable named


Remarque : cliquez dessus pour agrandir.

Les commandes nous donnent maintenant ces résultats :




Remarque : nous pourrions aussi utiliser cette commande :

systemctl status named


Quoi qu'il en soit, le service named est prêt.



3. Configurer firewalld

Cette étape n'est pas nécessaire si le pare-feu est inactif. J'ai choisi d'activer le pare-feu (et trouvé qu'il l'était déjà) précisément pour apprendre comment le gérer au cas où la politique de l'entreprise serait de toujours activer le pare-feu (et bien que la nécessité d'activer le pare-feu sous Linux fasse l'objet d'un débat).

Au départ, les règles du pare-feu ne tiennent pas compte de l'installation de BIND :

firewall-cmd --state

(Cette commande - en haut - est seulement pour vérifier l'état du pare-feu)

firewall-cmd --list-services


Ainsi, seuls les services ssh et le client dhcpv6 s'affichent.


Comme nous devrions savoir, si nous visons à gérer un serveur DNS, ce dernier utilise le port 53 (TCP et UDP). Nous devons donc exécuter les commandes suivantes, l'une après l'autre, pour configurer notre pare-feu en conséquence :

firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp



Cependant, comme nous pouvons observer en bas de la capture d'écran ci-dessus, rien n'est ajouté pour DNS. C'est parce que nous avons ajouté les ports qu'utilise DNS plutôt que le service lui-même. D'abord, il faut recharger le service firewalld et utiliser une autre commande pour voir les ports ouverts :

firewall-cmd --reload

firewall-cmd --list-all


Remarques : nous pouvons constater dans la capture d'écran ci-dessus que rien ne s'affiche pour DNS (ni service, ni ports) sans relancer le service. Ensuite, le service ne s'affiche toujours pas mais nous voyons l'exception faite pour les ports avec la dernière commande.



4. Editer le fichier named.conf

Les éléments relatifs à BIND se trouvent aux emplacements suivants :
  • /etc/named.conf (c'est le fichier pour la définition des zones).
  • /var/named/ (c'est ici que nous définissons les enregistrements ressource pour chacune de nos zones).
  • /var/log/messages (c'est ici que les journaux se trouvent - ou les "logs").

J'ajoute qu'un fichier modèle se trouve à cet endroit :

/usr/share/doc/bind*/sample/etc/named.conf


La configuration peut se faire de plusieurs manières. Après avoir renommé le fichier named.conf original, nous pouvons copier le fichier modèle vers /etc/ et l'utiliser. Nous pouvons aussi éditer directement le fichier named.conf original, en nous rapportant, le cas échéant, au fichier modèle. C'est cette approche que je vais adopter mais après avoir créé une copie de sauvegarde du fichier original tout de même.

Le fichier named.conf se compose de trois grandes sections : une section pour les "options" DNS du serveur, une section "logging" pour la journalisation et une section "zones" où nous définissons les zones hébergées sur le serveur. D'habitude, il y a au moins deux zones dans la mesure où nous configurons normalement une zone directe et une zone inverse pour chaque domaine.

Il s'agit donc de modifier le fichier avec l'éditeur de texte de votre choix. Je vais utiliser vi et rappelle quelques éléments du mode d'emploi :

  • Au départ, nous sommes en mode "command".
  • Nous passons en mode "insert" en tapant sur la touche "i".
  • Nous sortons du mode "insert" en tapant sur la touche "Esc" (ou l'équivalent sur votre clavier).
  • Nous enregistrons nos modifications en tapant ":wq" (sans les guillemets).

Avant tout, je tiens à créer une copie de sauvegarde de named.conf :

cp /etc/named.conf /etc/named.conf.backup

Cela donne ceci :



Ensuite, j'ouvre le fichier /etc/named.conf avec vi.

Avant les modifications, la section "options" ressemble à ceci :



Et après, nous avons ceci :



La définition des zones se fait dans le même fichier mais je traite cet aspect dans la prochaine section.



5. Définir nos zones

Toujours dans le fichier named.conf, nous devons définir (ou déclarer) les zones pour lesquelles nous voulons résoudre des noms en adresses IP et l'inverse. Dans mon exemple, j'ai une configuration simple où je définis une zone directe et une zone inverse (en anglais, "forward" et "reverse" respectivement). Je me suis inspiré des exemples trouvés en ligne ainsi que de la documentation Red Hat (voir la section "Sources" en bas). Pour une configuration simple, donc, il suffit de faire comme j'ai fait dans la capture d'écran ci-dessous. Encore une fois, il ne s'agit pas d'exécuter des commandes mais de modifier le fichier named.conf avec l'éditeur de texte de votre choix.



Je ne traite pas de la syntaxe des paramètres qu'on voit dans la capture d'écran.Une présentation plus globale de BIND dépasserait du reste le cadre de cet article. Mon seul objectif ici, plus pratique, est de permettre la résolution de noms entre serveurs et clients de mon réseau d'essai. Dans un tel cadre, la configuration plus haut suffit tout à fait.

En revanche, il est crucial de comprendre que chaque fichier désigné par le mot "file" doit bel et bien exister dans le répertoire /var/named. La création de ces fichiers est le sujet de la prochaine section.



6. Définir des enregistrements ressource

Chacun des fichiers qu'on désigne dans la section précédente doit effectivement exister dans le répertoire /var/named. Encore une fois, plusieurs options se présentent à nous. Nous pourrions créer un fichier de toutes pièces, copier un fichier modèle, ou faire une copie de named.localhost. J'ai retenu cette dernière option.

cp localhost.named forward.machlinkit.biz

Remarque : il faut se trouver dans le répertoire /var/named pour faire la copie.

Avant toute modification, nous avons un contenu qui ressemble à ce que nous voyons dans la capture d'écran ci-dessous :



Je n'expliquerai pas chaque modification mais nous devrions avoir un fichier comme celui-ci à la fin :


Remarque : faites attention à mettre un point à la fin de l'enregistrement NS. A mon premier essai, j'ai oublié cela et la validation a échoué (voir plus bas pour la validation de la configuration et des zones).

Nous faisons pareil dans le fichier reverse.machlinkit.biz pour la zone inverse :




7. Changer le propriétaire des fichiers de zone

Après avoir créé nos zones directe et inverse, je lis qu'il faut en changer le propriétaire. Pour l'instant, le propriétaire, c'est root :


Il faut, paraît-il, que le service named en soit le propriétaire, ce que nous accomplissons en exécutant ces commandes :

chown root:named forward.machlinkit.biz
chown root:named reverse.machlinkit.biz



Jusqu'ici, je n'ai pas étudié en détail les permissions et la propriété sous Linux, et en particulier l'obligation (?) de changer le propriétaire de ce type de fichier DNS. En attendant de combler cette lacune un jour, je me contente de confirmer que le propriétaire des fichiers a changé :





8. Valider la configuration et les zones

Je valide ma configuration (dans le fichier /etc/named.conf) avec cette commande :

named-checkconf /etc/named.conf

Si la configuration est bonne, cela ne devrait rien afficher (rien du tout).

J'ai vu aussi exécuter cette commande et si tout est correct, nous devrions voir "loaded serial 0" :

named-checkconf -z /etc/named.conf


Pour les zones, nous utilisons les commandes suivantes :

named-checkzone forward /var/named/forward.machlinkit.biz

named-checkzone reverse /var/named/reverse.machlinkit.biz


Voici une capture d'écran qui montre les résultats que nous devrions voir si tout est configuré comme il faut :



***

Je m'en tiendrai là pour le moment. Nous pourrions aussi faire des vérifications avec nslookup ou dig mais il faudrait installer les "bind-utils" pour cela (non, ces outils n'ont pas été installés avec les binaires BIND). Ce sera pour un autre article. De même, j'aurais voulu montrer certaines erreurs commises lors de ma première tentative et la façon dont je les ai résolues utilisant les commandes de vérification présentées plus haut. Mais une telle analyse aurait sans doute alourdi le texte et j'ai décidé que, si je finis par partager ces détails, ce sera, là aussi, dans un article séparé. Par ailleurs, la configurtion des clients DNS (qui peuvent être serveurs d'ailleurs) sera le sujet de mon prochain article.



Sources

J'ai consulté une multitude de sources en ligne mais la référence essentielle reste la documentation Red Hat sur BIND :

Red Hat Enterprise Linux 7 | Networking Guide | 14.2 BIND

Et en version française :

BIND (FR)

Enfin, j'estime que cette présentation est un bon survol pour quelqu'un qui essaie la mise en place d'un serveur BIND pour la première fois :

How to configure DNS Name Server in Centos7 , Redhat7 (Server and Client Configuration)

Sunday, March 31, 2019

CentOS7 (FR) 1 : configuration de base d'un serveur

English summary: after an interruption of almost one year, I'm going to continue my experiences with CentOS Linux. My approach is slightly different. My objective is to configure a BIND (DNS) server, which is where I stopped my last series of blog posts on Linux. I will configure elements such as the hostname, networking, firewall and security updates with yum.


***


Après presque un an d'interruption, je vais essayer de reprendre mon apprentissage de CentOS (il s'agit, en substance, de la version gratuite de Red Hat Linux, donc moins la marque et surtout moins l'assistance technique).

L'an passé, je me suis heurté à la configuration d'un serveur BIND (DNS) et c'est ce qui a brisé mon élan. Je ne me trouvais pas confronté à un manque de sources mais plutôt à une variété de sources dont j'avais du mal à faire la synthèse des différentes approches.

Aujourd'hui, je recommence par la configuration d'un serveur qui sera un serveur DNS. Je commence par la configuration générale (nom d'hôte, adresse IP, pare-feu, mise à jour avec yum). Ce sera une révision des choses apprises autrefois et peut-être le modèle pour la mise en service d'autres serveurs à l'avenir.

Je ne présente pas l'installation de CentOS dont j'ai simplement accepté les choix par défaut.


***


Nom d'hôte

La première tâche consiste à configurer le nom d'hôte, ce que j'accomplis avec cette commande :

nmcli general hostname LX1

Dans la capture d'écran ci-dessous, vous remarquerez que le changement ne se fait pas tout de suite. Nous sommes toujours "root@localhost". Cette commande ne force pas le changement non plus :

systemctl restart systemd-hostnamed



Il a fallu que je ferme la session en cours et en ouvre une nouvelle pour voir le changement:



Nous pouvons afficher le nom d'hôte avec cette commande :

hostname

Comme cela arrive souvent, c'est en faisant des recherches sur ces commandes que j'ai appris qu'il existe d'autres méthodes de gérer le nom d'hôte.

D'abord, il suffit d'exécuter cette commande pour changer le nom :

hostname LX1

En outre, je découvre qu'une commande de la famille *ctl existe pour les noms d'hôte : hostnamectl. Nous aurions pu changer le nom avec cette commande :

hostnamectl set-hostname LX1

Et nous pouvons afficher le nom d'hôte avec ces commandes qui ont le mérite de montrer beaucoup plus de détails que la simple "hostname" :

hostnamectl

hostnamectl status

Remarque : ces deux commandes sont équivalentes et produisent le même résultat.



Nous pouvons toujours nous contenter de "hostname" si nous préférons la concision.

Remarque : à ma connaissance, il n'est pas obligatoire de commencer par la configuration du nom d'hôte. C'est simplement un choix que j'ai fait.



Paramètres IP

Je configure les paramètres IP avec cette commande :

nmcli conn add con-name NET1 ifname eth0 type ethernet ipv4.method manual ip4 10.4.4.1/8 gw4 10.1.1.3 ipv4.dns 208.67.200.220


Je n'explique pas ici la syntaxe de la commande nmcli et de des paramètres ci-dessus. Je me contente de préciser que la commande crée bien une nouvelle connexion (ou profil) et le chiffre "200" en rouge est une erreur que vous me verrez corriger dans un moment. Il est souvent instructif de présenter ses erreurs et la façon de les résoudre.

Je constate que ma nouvelle connexion (profil) devient active et s'associe au périphérique eth0 :



Je vérifie la connectivité réseau avec ping (tout va bien) :


Si nmcli nous permet de configurer les paramètres réseau sans devoir éditer des fichiers à la main (avec vi ou vim par example), je crois qu'il est utile de rappeler que nous pouvons trouver les fichiers en question à cet emplacement...

/etc/sysconfig/network-scripts



Et que nous pouvons voir les paramètres eux-mêmes dans le fichier portant le nom de la connexion :

cat /etc/sysconfig/network-scripts/ifcfg-NET1




Pare-feu (firewalld)

Je croyais que le pare-feu n'était pas activé par défaut sous Linux et j'allais l'activer quand j'ai remarqué qu'il tourne déjà, comme la sortie de ces commandes l'atteste :


Note: cliquer dessus pour agrandir.




Puis, un pare-feu est-il nécessaire sous Linux ? C'est le sujet de maintes discussions en ligne, par exemple :

https://unix.stackexchange.com/questions/99104/do-i-need-a-special-firewall-on-a-personal-computer

Quoi qu'il en soit, je voulais activer le pare-feu pour apprendre à gérer les règles au cas où je me trouverais dans une entreprise où l'utilisation du pare-feu d'hôte... serait la règle.


Un petit problème...

A cette étape, j'allais installer les mises à jour de sécurité avec yum mais n'arrivais pas à établir un lien avec le dépôt (repository) :



Je confirme encore l'état des éléments réseau :



Y compris l'état du service NetworkManager :



Cela a l'air d'être un problème de résolution de noms (puisque ping réussit à passer).

Je revois mes paramètres DNS et j'ai un doute sur l'adresse IP du serveur OpenDNS que j'ai désigné :



Vérification faite, j'ai mal saisi l'adresse IP qui devrait être plutôt 208.67.220.220. Chemin faisant, je décide d'ajouter l'adresse d'un second serveur DNS, ce qui n'est pas crucial dans mon réseau d'essai mais constitue toujours une bonne pratique dans le monde réel (voir la commande saisie en bas de la capture d'écran ci-dessus).

Cela donne ceci :



Contre toute attente, les choses empirent. Non seulement la résolution de noms continue à échouer mais je perds la connectivité de base. Je ne peux même pas atteindre ma passerelle par défaut :



J'édite même le fichier ifcfg-NET1, observant que le paramètre pour le second serveur DNS se trouve à la fin, et pensant que cette position n'est peut-être pas valable. Rien n'y fait.

Je trouve quelques références à ce problème en ligne, par exemple :

ping - connect: No buffer space available

Je ne vois pas pourquoi il faudrait augmenter des ressources pour ARP et je choisis plutôt de faire redémarrer la machine, ce qui résout le problème. La cause exacte en reste un mystère.



Mettre à jour (yum)

Je mets ci-dessous les commandes que j'ai essayées. En fin de compte, mon installation n'aurait pas eu besoin de mises à jour de sécurité.

Pour voir les "erratas" disponibles, sans les installer, je dois exécuter :

yum updateinfo list available

Aucun résultat - je dois être à jour

Et de même pour ces commandes qui affichent les mises à jour de sécurité (sans les installer) :

yum updateinfo list security all
yum updateinfo list sec

Pour afficher les mises à jour installées :

yum updateinfo list security installed

Si je voulais installer des mises à jour disponibles, j'exécuterais cette commande :

yum update --security -y

Des mises à jour s'affichent mais à la fin je vois : "No packages needed for security; 61 packages available".


Autres remarques

Cette installation est pour un serveur DNS (et peut-être d'autres rôles plus tard). De ce fait, je me contente de l'interface à la ligne de commande et n'ajoute pas d'interface graphique. S'il y avait une interface graphique disponible, nous pourrions la lancer avec cette commande :

systemctl isolate graphical.target

A supposer, bien entendu, qu'une telle interface soit disponible (par exemple, si nous avions installé GNOME ou KDE). Nous pouvons voir le défaut avec cette commande:

systemctl get-default

Et éventuellement faire de l'interface graphique le cas défaut avec celle-ci :

systemctl set-default graphical.target


Saturday, March 23, 2019

Office 365 - migrate Azure AD Connect

In this blog post, I'll be migrating Azure AD Connect (once known as "DirSync") from an older server running Windows 2012 R2 to a newer server running Windows 2016.

The new server is already a member of the domain and been prepared with any prerequisites. In fact, with Windows Server 2016, we only need these two installation files:

The Microsoft Online Services Sign-In Assistant

And the Azure AD Connect installation file iteself

We should end up with two files that look like this:




We can install Azure AD Connect on the new server and simply run the wizard. We do not have to export and import any database. However, there is a risk of changing our configuration if we make different choices on the new server. This is yet another reason to document our configuration(s). In my case, I have both screenshots of each step of the original AD Connect configuration and a screenshot of the current configuration summary.

I will not post the screenshots of the previous installation in addition to the screenshots of the new installation below, but I will present the summary of the current configuration:





In my test environment, I will simply shut off the old server, start the new server and run the configuration wizard. We do have the option to place a server in "staging mode" but I will not use that option here. We could also schedule the switchover to happen on the weekend or at night when (depending on your organization) no changes (or few changes) to the directory are taking place.


I will redocument the new AD Connect installation and observe what is already installed. Nothing so far:



First, I'll install the "Microsoft Online Services Sign-In Assistant". Since I cannot execute the installation file "as administrator", I open the command prompt (as administrator) and then execute the file that way. This may not be necessary here but I've encountered problems in other circumstances (when installing Exchange rollups, for example) because the file cannot be run as administrator in the GUI.




The installation is very simple. We just follow the prompts:




We can now see the program in "Programs and Features":



Then I install "Azure AD Connect" itself (same method):




If the wizard does not start automatically, we can open it by clicking on the Azure AD Connect icon on the desktop:




After agreeing to the license terms, I can consider the "Express Settings" option which will not work for me (so I'll select "Customize"):




At this point, I can refer to my documentation to make the appropriate choices. For example, I will use the same service account to run the AD synchronization service:




Several components are installed (Visual C++, SQL)...




That we can see here:




I use "password hash synchronization" for sign-in:





We enter Azure AD (Microsoft 365) global administrator credentials here:





We have to connect our Active Directory domain. At this step, we only need to "confirm" our local domain (which may be selected already by default). It is only later that we need a domain "verified" in Microsoft 365:




We also designate at this time the account that will be used for periodic synchronization with Azure AD. In my case (since this is a migration), I will use an account created when the wizard was run before (and yes, I intentionally leave the spaces blank):




Now our directory is a "configured directory":





Here, my publicly registered domain name has been added and I select the on-premises attribute "user principal name" to be the user name in Azure AD. I also must chose to continue without matching all UPN suffixes to verified domains (namely mynet.lan):




We can sync all domains and OUs or select a subset (which is my choice):


Note: the actual selection of OUs is not shown above. You have to expand to domain tree structure to make the selections.


I only have one directory so I can select the first option below and then chose a specific attribute or "anchor" to identify the user in Azure AD. I will continue to use the "objectGUID":




In addition to filtering by OU (two steps above), we can also filter by group membership but only direct members (membership in nested groups is ignored): 




One of the lasts steps has to do with "Optional features". I had already opted for password synchronization earlier and will also select "Exchange hybrid deployment" here:




We can now start the actual configuration of Azure AD Connect based on our choices above - and optionally start synchronization when the configuration is complete (my choice below). There is also a "staging mode" option we could use if another AD Connect server was still online (not my case):




Below we can see see that the configuration is complete (and that it is recommended that we enable the AD Recycle Bin - not enabled however in my test environment - as you can see):




We can confirm synchronization is working by logging into our Microsoft 365 tenant and looking at the synchronization status on the Home page:




References, other sources and perspectives

Custom installation of Azure AD Connect

Migrating Azure AD Connect to a New Server (practical365)

In particular, Paul Cunningham presents the "AADConnectConfigDocumenter" tool that may be useful for those who want a more detailed view of their current Azure AD Connect configuration.