Le Cahier-02: NethServer et migration de LDAP vers Active Directory du “cours NethServer-301” décrit le remplacement du Fournisseur des comptes LDAP par celui d'Active Directory.

1. Installer Samba 4 Active Directory sur un Serveur NethServer.
2. Utiliser la méthode de changement de mot de passe par Question/Réponse, de l'utilitaire Self Service Password, afin que les utilisateurs puissent changer, eux-mêmes, le nouveau mot de passe octroyé par l'installation d'Active Directory.

Pour ce document, nous utiliserons la machine virtuelle du Cahier-301-01 RSAT (Remote Server Administration Tools) du “Cours NethServer-301”.

Les procédures sont exactement les mêmes pour un Serveur NethServer physique directement branché ou non à l'Internet.

Le Cours NethServer-101, se voulant une base solide pour la création d'un site de Commerce en ligne, comprend plusieurs cahiers:

1. Cahier-01: → Les bases de Linux.
2. Cahier-02: → Installation et configuration des logiciels prérequis sur le poste de travail.
3. Cahier-03: → Création d'un Serveur NethServer virtuel.
4. Cahier-04: → Serveur NethServer LOCAL & Let's Encrypt.
5. Cahier-05: → FAI, modem VDSL, domaine FQDN¹⁾ et Serveur NethServer physique.
6. Cahier-06: → Installation de WordPress.
7. Cahier-07: → Installation de l'extension de sécurité Wordfence.
8. Cahier-08: → WooCommerce, comptes chez Stripe et PayPal pour les paiements en ligne.
9. Cahier-09: → Sauvegarde/restauration ou migration d'un site avec l'extension Duplicator.
10. Cahier-10: → Serveur mandataire inversé.
11. Cahier-11: → Sauvegarde/restauration avec BackupPC.

Le Cours NethServer-201 décrit l'installation et la configuration d'applications sur un Serveur NethServer.

1. Cahier-201-01: → Dolibarr.
2. Cahier-201-02: → Odoo-12.
3. Cahier-201-03: → MediaWiki.
4. Cahier-201-04: → DokuWiki.
5. Cahier-201-05: → Moodle.
6. Cahier-201-06: → Proxmox.
7. Cahier-201-07: → Flectra.
8. Cahier-201-08: → Self Service Password.

Le Cours NethServer-301 décrit l'annuaire Active Directory roulant sur un Serveur NethServer.

1. Cahier-301-01: → RSAT (Remote Server Administration Tools).
2. Cahier-301-02: → NethServer et migration de LDAP vers Active Directory.
3. Cahier-301-03: → Active Directory & Self Service Password.
4. Cahier-301-04: → Active Directory & jonction de stations.

Tous les logiciels nécessaires sont du domaine public ou LIBRE sous licence GPL; ils ne coûtent pas un sou. Le seul achat nécessaire est l'obtention d'un nom de domaine au prix initial de $15 CAD et son renouvellement annuel d'environ $30 CAD.

Après avoir suivi le Cours NethServer-101, vous posséderez un site de Commerce en ligne fiable et hautement sécuritaire. De plus, vous pourrez utiliser un clone de votre site, sur un Serveur NethServer virtuel roulant sur votre poste de travail, pour tester de nouvelles extensions et applications sans compromettre la sécurité ou l'intégrité de votre site en ligne.

* Les captures d'écrans ne sont que des références.
** Les informations écrites ont préséance sur celles retrouvées dans les captures d'écrans. Veillez vous référer aux différents tableaux lorsque ceux-ci sont présents.
*** Une capture d'écran avec une accentuation en magenta indique qu'il faut remplacer cette distinction par vos propres paramètres ou implique un choix laissé à votre appréciation.

Manipulation, truc ou ruse pour se tirer d'embarras.
Une recommandation ou astuce.
Une note.
Une étape, note ou procédure à surveiller.
Paragraphe non complété ou non vérifié.
Danger pour la sécurité du système.

Toutes les commandes à la console ou à travers PuTTY sont précédées d'une invite qui est toujours présente.

[root@dorgee ~]# ping 10.10.10.75 -c1

PING 10.10.10.75 (10.10.10.75) 56(84) bytes of data.
64 bytes from 10.10.10.75: icmp_seq=1 ttl=64 time=1.63 ms

--- 10.10.10.75 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.639/1.639/1.639/0.000 ms
[root@dorgee ~]#

Commande à exécuter si ce n'est déjà fait.

Commande indiquée à titre d'information seulement.

Le Serveur NethServer-7.6.1810 est un dérivé de la distribution Linux CentOS et est équivalent à CentOS-7.6.1810.

1. Serveur passerelle pour les connexions à l'Internet.
2. Serveur DHCP pour tout le réseau LOCAL 192.168.1.0/24.

Serveur virtuel LOCAL sous VirtualBox Version 6.0.4 r128413 (Qt5.6.2).

Windows-8.1, on utilisera ce poste de travail comme station d'administration pour tout ce document.

Ne modifiez pas les fichiers avec des éditeurs de documents tels Notepad, TextEdit ou autres qui ajoutent une marque d'ordre d'octets (byte order marks) aux fichiers et qui casse le programme PHP. Utilisez plutôt un éditeur de code tel vi, vim, Notepad++, ou Atom. Ces éditeurs gèrent l'encodage des fichiers de manière appropriée; ils peuvent aussi être utilisés pour réparer les fichiers précédemment cassés par les autres éditeurs de documents.

Voir le Cahier-02: Installations & configurations des logiciels prérequis du “Cours NethServer-101” pour l'installation et la configuration de cet éditeur.

Référence: https://notepad-plus-plus.org/.

Notepad++ est un éditeur de code source qui prend en charge plusieurs langages. Ce logiciel, codé en C++ avec STL et win32 api, a pour vocation de fournir un éditeur de code source de taille réduite mais très performant. En optimisant de nombreuses fonctions, tout en conservant une facilité d’utilisation et une certaine convivialité, Notepad++ contribue à la limitation des émissions de dioxyde de carbone dans le monde; en effet, en réduisant l’utilisation du CPU, la consommation d’énergie des ordinateurs chute considérablement, en conséquence de quoi, la terre est plus verte.

Site de téléchargement: https://notepad-plus-plus.org/downloads/.

Guide pratique (1er août 2013): http://nliautaud.developpez.com/tutoriels/web/notepadplusplus-guide-pratique/.
Aide-mémoire des principales commande: https://drive.google.com/file/d/0B86nuTd5nMTKaENHcmliUC1kdnc/edit.

Lorsque nous voulons utiliser Active Directory comme fournisseur des comptes sur un Serveur NethServer, il nous faut désinstaller le fournisseur LDAP avant l'installation du fournisseur Active Directory.

Lors d'une désinstallation du fournisseur LDAP, une liste d'utilisateurs et de groupes au format TSV est transférée respectivement dans /var/lib/nethserver/backup/users.tsv et dans /var/lib/nethserver/backup/groups.tsv. Si nous réinstallons LDAP comme fournisseur des comptes, il récupérera les comptes et les groupes depuis ces fichiers de sauvegarde.

Lors d'une installation d'Active Directory comme fournisseur des comptes, celui-ci ne récupère pas les comptes et les groupes depuis les fichiers TSV; il crée seulement deux nouveaux comptes: admin et administrator et un nouveau groupe domain admins contenant ces deux nouveaux comptes.

Une fois Active Directory installé, nous pouvons importer les comptes depuis les fichiers TSV, mais AD n'incorpore pas les anciens mots de passe des usagers, il en crée de nouveaux.

Après l'importation des comptes, si nous avons seulement quelques anciens utilisateurs, nous pouvons changer leur mot de passe individuellement, mais si nous avons plusieurs centaines, voire des milliers de comptes, changer leur mot de passe individuellement n'est tout simplement pas très pratique.

De plus, si nous leur envoyons un courriel avec leur nouveau mot de passe, les anciens utilisateurs ne pourront pas accéder à leur compte de messagerie, car ils ne connaissent pas leur nouveau mot de passe pour se connecter.

Dans le Cahier-201-08: NethServer & Self Service Password du “Cours NethServer-201”, nous avons configuré SSP pour qu'un utilisateur puisse changer son mot de passe en répondant à une question préalablement choisie et à laquelle il a déjà répondu sans devoir fournir son ancien mot de passe.

Lorsque nous récupérerons les anciens comptes, Active Directory récupérera la question et la réponse des utilisateurs si cette réponse n'est pas chiffrée.

Après l'installation d'Active Directory, un ancien utilisateur pourra alors se rendre à la page de Self Service Password: fournir seulement son nom d'usager, choisir sa question, donner sa réponse et enfin entrer puis confirmer son nouveau mot de passe. Si la réponse est exactement la même que celle entrée précédemment, SSP changera le mot de passe, crée par Active Directory, par le nouveau mot de passe que l'utilisateur vient de spécifier.

L'administrateur système de NethServer doit obligatoirement exiger, de tous les utilisateurs, d'utiliser la page de Self Service Password (https://www.micronator-dev.org/ssp) afin de choisir une question et de fournir une réponse personnelle avant l'installation d'Active Directory.

La réponse peut être bidon et très longue en autant qu'elle soit exactement toujours la même.
Lors d'un changement de mot de passe par réponse à une question, la réponse donnée n'est pas analysée par SSP; il compare seulement la question et la réponse avec celles préalablement fournies avant la demande de changement de mot de passe.

On répète ce chapitre pour ceux qui n'auraient pas accès au Cahier-03: NethServer Virtuel du “Cours NethServer-101”.

Voir le chapitre À savoir du Cahier-03: NethServer Virtuel.

Voir le Cahier-03: Création d'un Serveur NethServer virtuel du “Cours NethServer-101”.

Pour un serveur virtuel de test, prendre un minimum de 8 Go dynamiquement alloué pour le disque principal.

Avant de commencer quoi que ce soit, il est toujours préférable de mettre à jour le Serveur NethServer.

Il est fortement recommandé d'installer Fail2ban et ClamAV pour mieux sécuriser notre futur système. L'installation de ces logiciels est décrite dans le Cahier-03: NethServer Virtuel du “Cours NethServer-101”.

Pour l'installation d'un certificat Let's Encrypt, consulter le Cahier-04: NethServer LOCAL & Certificat Let's Encrypt du “Cours NethServer-101”.

Plus d'informations.

Onglet Sécurité → Afficher le certificat.

- Le certificat a été émis par Let's Encrypt Authority X3.
- On clique l'onglet Détails.

- On clique Nom alternatif du sujet du certificat.
- Tous les CNAME sont présents.
- Fermer toutes les fenêtres.

Le certificat Let's Encrypt est à jour et fonctionne correctement.

Il faut activer Javascript et les témoins (cookies).
Depuis le poste de travail, sur le réseau LOCAL 10.10.10.0/24, on accède à l'interface Web Nethserver http://10.10.10.75:980.

Lorsque vous parvenez à l'URL, vous serez invité à entrer votre nom d’utilisateur (qui est obligatoirement root) et le mot de passe donné au cours du processus d’installation. Entrez ce justificatif et cliquez sur Login afin d’être amené à l'interface Web Nethserver. L’écran du gestionnaire s’affiche.

Le cadenas est vert, car nous avons un certificat émis par une autorité de certification reconnue.

Si vous avez de la difficulté à vous connecter, vidanger le cache DNS du poste de travail et celui du navigateur Firefox.

- Sur le poste de travail, ouvrir un écran de commandes.
- ifconfig /flushdns.

Historique → Supprimer l'historique ré­cent… → tout → Effacer maintenant.

Configuration → Fournisseur des comptes.

LDAP local est notre fournisseur de comptes.

Configuration → DNS → onglet Hôtes.

Le FQDN du serveur: micronator-dev.org est bien ce qu'il devrait être; micronator-101.ddns.net provient du Cahier-03: NethServer Virtuel du “Cours NethServer-101”, on peut le supprimer pour ce document.

Configuration → Nom du serveur.

Sécurité → SSH.

Sécurité → TLS policy.

Configuration → FTP → onglet Configurer.

Le FTP ne doit pas être activé.

Configuration → Réseau → onglet Serveur DNS.

Le serveur DNS secondaire peut être 8.8.8.8 ou 1.1.1.1; le dernier étant plus rapide.

Les paramètres du serveur sont définis correctement et on peut utiliser PuTTY pour s'y loguer.

Voir PuTTY dans le Cahier-02 : Installations & configurations des logiciels prérequis du “Cours NethServer-101” pour vous familiariser avec ce logiciel de connexion..

On se logue en tant que l'utilisateur root.

login as: root
root@10.10.10.75's password:  mot-de-passe-de-root
Last login: Sat Oct 19 15:58:02 2019 from 10.10.10.81

************ Welcome to NethServer ************

This is a NethServer installation.

Before editing configuration files, be aware
of the automatic events and templates system.


          http://docs.nethserver.org

***********************************************
[root@tchana ~]#

On vérifie les adresses IP du serveur.

[root@tchana ~]# ifconfig

enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.10.75  netmask 255.255.255.0  broadcast 10.10.10.255
        inet6 fe80::a00:27ff:fedf:9e60  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:df:9e:60  txqueuelen 1000  (Ethernet)
        RX packets 1237  bytes 147855 (144.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1471  bytes 1350638 (1.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp0s8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.75  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::a00:27ff:fe50:453a  prefixlen 64  scopeid 0x20<link>
        ether 08:00:27:50:45:3a  txqueuelen 1000  (Ethernet)
        RX packets 3789  bytes 1613677 (1.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4134  bytes 371155 (362.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 392  bytes 42659 (41.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 392  bytes 42659 (41.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@tchana ~]#

On vérifie que le pare-feu Fail2ban soit installé.

[root@tchana ~]# rpm -qa | grep -i fail2ban

fail2ban-firewalld-0.9.7-1.el7.noarch
fail2ban-server-0.9.7-1.el7.noarch
fail2ban-0.9.7-1.el7.noarch
fail2ban-sendmail-0.9.7-1.el7.noarch
fail2ban-shorewall-0.9.7-1.el7.noarch
nethserver-fail2ban-1.1.10-1.ns7.noarch
[root@tchana ~]#

On vérifie que Fail2ban roule sur le serveur.

[root@tchana ~]# ps aux | grep -i fail2ban

root      2305  2.0  0.5 1746708 20008 ?       Sl   14:36   0:07 /usr/bin/python2 -s /usr/bin/fail2ban-server -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -x -b
root      2969  0.0  0.0 112708   984 pts/0    S+   14:42   0:00 grep --color=auto -i fail2ban
[root@tchana ~]#

Par défaut ClamAV est installé, mais partiellement, et s'occupe seulement du balayage des courriels.

Dans le Cahier-03 : Création d'un Serveur NethServer virtuel du “Cours NethServer-101”, nous avons installé ClamAV qui s'occupe aussi du balayage du système de fichiers.

On vérifie que l'antivirus ClamAV pour le système de fichiers soit installé.

[root@tchana ~]# rpm -qa | grep -i clamav

clamav-filesystem-0.101.4-1.el7.noarch
clamav-lib-0.101.4-1.el7.x86_64
clamav-0.101.4-1.el7.x86_64
clamav-update-0.101.4-1.el7.x86_64
clamav-unofficial-sigs-5.6.2-7.el7.noarch
[root@tchana ~]#

Configuration → Scanner Antivirus → onglet Clamscan.

ClamAV lancera un balayage complet du système à 01h00.

Gestion → Utilisateurs et groupes → onglet Utilisateurs.

L'utilisateur michelandre a été créé dans le Cahier-03 : Création d'un Serveur NethServer virtuel du “Cours NethServer-101”.

Les utilisateurs toto et titi ont été créés dans le Cahier-201-08 : NethServer & Self Service Password du “Cours NethServer-201”.

Le groupe grp-utilisateurs a été créé dans le Cahier-201-08 : NethServer & Self Service Password du “Cours NethServer-201”.

Il contient deux membres: toto et titi.

On vérifie les répertoires personnels.

[root@tchana ~]# ls -ls /var/lib/nethserver/home

total 0
0 drwx------ 2 michelandre@micronator-dev.org locals@micronator-dev.org 83 20 oct.  18:02 michelandre
0 drwx------ 2 titi@micronator-dev.org        locals@micronator-dev.org 83 20 oct.  18:02 titi
0 drwx------ 2 toto@micronator-dev.org        locals@micronator-dev.org 83 20 oct.  18:01 toto
[root@tchana ~]#

On vérifie les répertoires des courriels.

[root@tchana ~]# ls -ls /var/lib/nethserver/vmail

total 4
0 drwx------ 3 vmail vmail 21 19 avril  2019 admin@micronator-dev.org
0 drwx------ 3 vmail vmail 21 19 avril  2019 michelandre@micronator-dev.org
0 drwx------ 3 vmail vmail 21  8 janv.  2019 root
4 -rw------- 1 vmail vmail 73 14 oct.  11:35 shared-mailboxes.db
0 drwx------ 3 vmail vmail 21 14 oct.  17:20 titi@micronator-dev.org
0 drwx------ 3 vmail vmail 21 14 oct.  17:19 toto@micronator-dev.org
0 drwx------ 3 vmail vmail 21  8 janv.  2019 vmail
0 drwx------ 3 vmail vmail 21 19 avril  2019 vmail@micronator-dev.org
[root@tchana ~]#

Configuration → Réseau → cartes réseau VERT et ROUGE et onglet Serveurs DNS.

Quel est le PHP par défaut?

[root@tchana ~]# which php

/opt/remi/php72/root/usr/bin/php
[root@tchana ~]#

Quelle est sa version?

[root@tchana ~]# php --version

PHP 7.2.24 (cli) (built: Oct 22 2019 11:28:13) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.2.24, Copyright (c) 1999-2018, by Zend Technologies
[root@tchana ~]#

MemoryLimit.

[root@tchana ~]# cat /etc/opt/remi/php72/php.ini | grep -i Memory_Limit

memory_limit                           = 250M
[root@tchana ~]#

PostMaxSize.

[root@tchana ~]# cat /etc/opt/remi/php72/php.ini | grep -i post_max_size

post_max_size                          = 100M
[root@tchana ~]#

UploadMaxFilesize.

[root@tchana ~]# cat /etc/opt/remi/php72/php.ini | grep -i upload_max_filesize

upload_max_filesize                    = 75M

Comme on le voit ci-dessus, les grandeurs maximales pour PHP-7.2 sont maintenant de: MemoryLimit (250M) > PostMaxSize (100M) > UploadMaxFilesize (75M).

On vérifie la configuration de PHP-7.2.

[root@tchana ~]# config show php72

php72=configuration
    AllowUrlFopen=Off
    ExposePhp=0
    MaxExecutionTime=30
    MaxFileUpload=20
    MaxInputTime=60
    MemoryLimit=250
    PostMaxSize=100
    UploadMaxFilesize=75
[root@tchana ~]#

Si on utilise une machine virtuelle, il faut absolument que les cartes réseau aient le Mode promiscuité à Tout autoriser.

À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

L'administrateur du Serveur NethServer doit obligatoirement exiger, de tous les usagers, d'utiliser la page de Self Service Password (https://www.micronator-dev.org/ssp) afin de choisir une question et de fournir une réponse personnelle avant l'installation d'Active Directory comme Fournisseur des comptes.

De plus, tous les utilisateurs doivent s'être connectés au moins une fois à Webmail afin que leur répertoire de messagerie soit créé, sinon ces utilisateurs ne seront pas transférés dans Active Directory.

1. Parce que LDAP et Active Directory n'utilisent pas le même algorithme de chiffrement, on ne peut pas chiffrer la Question/Réponse de Self Service Password.
2. Parce que tout le monde peut afficher les paramètres d'un utilisateur avec la commande ldapsearch:

[toto@micronator-dev.org@tchana ~]$ ldapsearch -Y EXTERNAL | grep -e "#" -e info:

...
# titi, People, directory.nh
info: {voiture} Honda
...
[toto@micronator-dev.org@tchana ~]$

1. Parce que nous n'avons pas trouvé de cas où la commande ldapsearch était absolument requise.

Pour ces raisons, l'administrateur du Serveur NethServer peut restreindre la commande ldapsearch à l'utilisateur root uniquement avant d'exiger d'utiliser la page de Self Service Password afin de choisir une Question/Réponse avant l'installation d'Active Directory.

[root@tchana ~]# chmod 700 /usr/bin/ldapsearch

[root@tchana ~]#

On vérifie.

[root@tchana ~]# ls -ls /usr/bin/ldapsearch

84 -rwx------ 1 root root 85928 29 janv.  2019 /usr/bin/ldapsearch
[root@tchana ~]#

On cherche le nombre d'utilisateurs dans notre annuaire LDAP.

[root@tchana ~]# ldapsearch -Y EXTERNAL  -b dc=directory,dc=nh "uid=*" uid | grep uid: | wc -l

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
4
[root@tchana ~]#

Nous avons 4 utilisateurs.

On peut afficher leur identifiant.

[root@tchana ~]# ldapsearch -Y EXTERNAL  -b ou=People,dc=directory,dc=nh "uid=*" uid | grep uid:

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
uid: admin
uid: michelandre
uid: toto
uid: titi
[root@tchana ~]#

On vérifie le nombre de réponses. Elles sont stockées dans l'attribut info.

[root@tchana ~]# ldapsearch -Y EXTERNAL | grep "info:" | wc -l

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
2
[root@tchana ~]#

Nous avons 2 utilisateurs qui ont une réponse à une question.

L'utilisateur admin n'a pas de Question/Réponse, car il ne peut changer son mot de passe avec Self Service Password.
Il existe donc un utilisateur qui n'a pas utilisé SSP pour se choisir une Question/Réponse.

On vérifie quels sont nos usagers qui ont choisi, ou non, une Question/Réponse.

[root@tchana ~]# ldapsearch -Y EXTERNAL | grep -e "# " -e info:

...
# admin, People, directory.nh
# domain admins, Groups, directory.nh
# michelandre, People, directory.nh
info: {voiture}MG
# toto, People, directory.nh
info: {voiture}Honda
# titi, People, directory.nh
# grp-utilisateurs, Groups, directory.nh
# search result
# numResponses: 13
# numEntries: 12
[root@tchana ~]#

On voit que seul l'utilisateur titi n'a pas de Question/Réponse. L'administrateur système communique avec titi pour exiger de choisir une Question/Réponse, car son mot de passe ne sera plus valide (après l'installation d'Active Directory).

Avertissement Si vous copiez ce script depuis le PDF de ce cahier, les en-têtes et les pieds de page sont aussi inclus dans la copie. Il faut coller le script dans NotePad++ et enlever les en-têtes et pieds de page.

Prendre tout le contenu de l'encadré pour le script /root/exportation-qestion-reponse.sh.

#!/bin/bash

# Script qui estraie tous les utilisateurs de LDAP et qui on une réponse à une question
# qu'ils peuvent utiliser pour changer leur mot de passe sans devoir à fournir leur mot de
# passe original et en utilisant SSP - Self Service Password.
# À la fin du script, le fichier exportation.ldif contient tous les enregistrements pour une
# importation de la réponse de chaque utilisateur dans Active Directory.
# Michel-André: 2019-11-10_21h32 HNE
# 2019-11-11_11h54 Ajout des (\") parce que micronator-dev contien un (-).
# 2019-12-20_16h11 Il faut que tous les utilisateurs se soient logués, au moins une fois,
# avec Webmail afin de créer leur répertoire de messagerie électronique, sinon ils
# ne seront pas exportés avec ce script.

## Fonction pour l'entrée des données de l'utilsateur dans le fichier LDIF
ad-toto () {
    # Le premier paramètre est le nom de l'usager qui est passé avec l'appel de
    # la fonction
    USAGER_LDAP=$1
    
    # Recherche et isolation de tous les paramètres de l'usager dans LADP 
    ldapsearch -Y EXTERNAL | grep "uid: $USAGER_LDAP" -A100 -B5 > utilisateurs.txt ; awk -v RS= '1; NR == 1 { exit }' utilisateurs.txt > $USAGER_LDAP.txt

    # Isolation de la ligne contenant le paramètre de la Question et remplacememsnt
    # de "info" par "comment" qui est requis par AD
    COMMENTAIRE=`cat $USAGER_LDAP.txt | grep "info:" | sed -e 's/info/comment/g' `
    
    # Isolation du nom de l'usager
    NOM_USAGER=`cat $USAGER_LDAP.txt | grep "uid: " | sed -e 's/uid\: //g' `
    
    # Assemblage du DN de l'usager
    # Il faut mettre des guillemets (") avec un (\) devant comme "Escape character"
    # parce que micronator-dev contient un (-).
    DN="dn: cn=$NOM_USAGER,cn=Users,dc=ad,dc=\"micronator-dev\",dc=org"

    # Création de chaque ligne pour le fichier LDIF d'exportation
    LIGNE1="$DN"
    LIGNE2="changetype: modify"
    # À la ligne-3, on ajoute (add) le paramètre "comment"
    LIGNE3="add: comment"
    LIGNE4="$COMMENTAIRE"

    # Si l'usager n'a pas une Question à son actif, la fonction retourne.
    # Surtout utilisé pour rejeter "admin" et "Administrator".
    # Si l'usager n'a pas de "Question" une ligne en ROUGE est affichée.
    if [ -z "$COMMENTAIRE"  ]
        then
        echo -e "\e[31mL'ussager $NOM_USAGER n'a pas de question...\n\e[0m"
        rm -rf $USAGER_LDAP.txt
        return
    fi
    
    # Écriture des lignes pour cet usager dans le fichier LDIP.
    echo -e $LIGNE1 >> exportation.ldif 2>&1
    echo -e $LIGNE2 >> exportation.ldif 2>&1
    echo -e $LIGNE3 >> exportation.ldif 2>&1
    echo -e "$LIGNE4\n" >> exportation.ldif 2>&1
    rm -rf $USAGER_LDAP.txt
}
## Fin de la fonction "ad-toto"

## Début du script
# On se rend dans le dossier des répertoires de messagerie
cd /var/lib/nethserver/vmail

# On extraie le nom de tous les utilisateurs depuis LDAP
getent passwd * | cut -f6 -d: | cut -f6 -d/ > /root/temp.txt

# On retourne dans le répertoire personnel de "root"
cd /root

# On supprime les lignes vide dans le fichier /root/temp.txt
sed -i '/^$/d' /root/temp.txt

# On débute avec un nouveau fichier LDIF
rm -rf exportation.ldif
touch /root/exportation.ldif

# Boucle pour l'insertion des paramètres à changer pour chaque utilisateur
while read p; do
    # Appel de la fonctio ad-toto
    ad-toto "$p"
done < /root/temp.txt

# Nettoyage final
# Suppression des fichiers intermédiaires.
# Mettre en commentaire les lignes ci-dessous pour déverminer ce script.
rm -rf utilisateurs.txt
rm -rf $USAGER_LDAP.txt
rm -rf temp.txt

# On indique que le script est terminé.
echo -e "\e[31mLe script est terminé.\n\e[0m"

# FIN DU SCRIPT exportation-qestion-reponse.sh

On téléverse le fichier exportation-qestion-reponse.sh dans le répertoire /root du Serveur NethServer.

On ajuste les droits du fichier.

[root@tchana ~]# chmod 700 exportation-qestion-reponse.sh

[root@tchana ~]#

On vérifie.

[root@tchana ~]# ls -als exportation-qestion-reponse.sh

4 -rwx------ 1 root root 3391  1 déc.  09:46 exportation-qestion-reponse.sh
[root@tchana ~]#

On lance le script.

[root@tchana ~]# /root/exportation-qestion-reponse.sh

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
Le script est terminé.

[root@tchana ~]#

Si un utilisateur n'a pas de Question/Réponse, lors du lancement de la commande, une ligne en rouge l'affichera. Ci-dessous, la ligne L'ussager admin n'a pas de question… sera en rouge.

[root@tchana ~]# /root/exportation-qestion-reponse.sh

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
L'ussager admin n'a pas de question...

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
Le script est terminé.

[root@tchana ~]#

Il est normal que l'utilisateur admin n'ait pas de Question/Réponse, car il ne peut modifier son mot de passe avec Self Service Password.

[root@tchana ~]# cat /root/exportation.ldif

dn: cn=michelandre,cn=Users,dc=ad,dc="micronator-dev",dc=org
changetype: modify
add: comment
comment: {voiture}MG

dn: cn=titi,cn=Users,dc=ad,dc="micronator-dev",dc=org
changetype: modify
add: comment
comment: {saison}Un printemps doux

dn: cn=toto,cn=Users,dc=ad,dc="micronator-dev",dc=org
changetype: modify
add: comment
comment: {voiture}Honda

[root@tchana ~]#

Remarquez la réponse de l'utilisateur titi. Elle est longue et contient plusieurs mots.

Référence: http://fr.wikipedia.org/wiki/Domaine_%28Microsoft%29.

Chez Microsoft, un domaine est une entité logique vue comme une enveloppe étiquetée. Il reflète le plus souvent une organisation hiérarchique dans une entreprise. Par exemple, le domaine “COMPTA” désigne l'ensemble des machines réseau (stations, imprimantes, etc..) du service Comptabilité, et les comptes utilisateurs qui sont autorisés à s'y connecter.

Le domaine permet à l'administrateur système de gérer plus efficacement les utilisateurs des stations déployées au sein de l'entreprise, car toutes ces informations sont centralisées dans une même base de données.

Cette base de données est stockée sur des serveurs particuliers (Windows Server NT4, 2000, 2003), appelés Contrôleurs de Domaine (Domain Controller).

Référence: http://www.questcequecest.com/quest-ce-quun-domaine-windows/. (Ce lien n'est plus valide.)

Dans un groupe de travail Windows, l’accès à un ordinateur exige une authentification par rapport à la base des comptes de l’ordinateur. Cette base est stockée dans un fichier intitulé SAM (Security Account Manager).

Si le groupe de travail est constitué de 10 ordinateurs avec un utilisateur par ordinateur et que tous les utilisateurs doivent accéder à tous les ordinateurs, l’administrateur doit créer 100 comptes au total. C’est d’autant plus lourd que l’opération doit être renouvelée partiellement lors de la perte d’un mot de passe.

Pour remédier à cette lourdeur, Microsoft propose d’utiliser un PDC (Primary Domain Controller). Un PDC centralise la base des comptes dans un fichier intitulé NTDS.DIT. Cette base des comptes contient, entre autres informations, les comptes des ordinateurs qui font partie du domaine et les comptes des utilisateurs qui sont membres de ce domaine.

Référence: https://msdn.microsoft.com/fr-fr/library/cc779648%28v=ws.10%29.aspx.

Les contrôleurs de domaine stockent les données et gèrent les interactions entre l'utilisateur et le domaine, y compris les processus d'ouverture de session, l'authentification et les recherches dans l'annuaire. Si vous envisagez d'utiliser ce serveur pour fournir le service d'annuaire Active Directory aux utilisateurs et aux ordinateurs du réseau, configurez-le en tant que Contrôleur de Domaine.

Dans le rôle de Contrôleur primaire de Domaine, un Serveur NethServer fonctionne tel un contrôleur de domaine de style Windows NT4, fournissant: une authentification client/utilisateur, les services WINS, la gestion des profils d'utilisateurs Windows et les services d'impression.

Il est fortement recommandé de mettre à jour le Serveur NethServer avant l'installation d'un module important.

On supprime le fournisseur des comptes actuel - LDAP.

Configuration → Fournisseur des comptes → Uninstall.

Uninstall.

On vérifie la présence des fichiers des exportation.

root@tchana ~]# ls -ls /var/lib/nethserver/backup/*.tsv

4 -rw-r--r-- 1 root root  59 28 nov.  17:30 /var/lib/nethserver/backup/groups.tsv
4 -rw-r--r-- 1 root root 110 28 nov.  17:30 /var/lib/nethserver/backup/users.tsv
[root@tchana ~]#

On affiche le fichier d'exportation des utilisateurs.

[root@tchana ~]# cat /var/lib/nethserver/backup/users.tsv

titi    Titi Deuxième   OEHv_W55
admin   admin   _1rbzdJS
michelandre     Michel-Andre    C7_zj6Bs
toto    Tot Premier     b8ga_J0p
[root@tchana ~]#

On affiche le fichier d'exportation des groupes.

[root@tchana ~]# cat /var/lib/nethserver/backup/groups.tsv

grp-utilisateurs        titi    toto
domain admins   admin   michelandre
[root@tchana ~]#

Référence: https://support.microsoft.com/en-ca/help/909264/naming-conventions-in-active-directory-for-computers-domains-sites-and

Les noms de domaine NetBIOS peuvent contenir tous les caractères alphanumériques à l'exception des caractères étendus répertoriés dans la section Caractères interdits. Les noms peuvent contenir un point, mais ils ne peuvent pas commencer par un point.

Les noms NetBIOS des ordinateurs ne peuvent pas contenir les caractères suivants:

1. barre oblique inverse (\)
2. barre oblique (/)
3. deux points (:)
4. astérisque (*)
5. point d'interrogation (?)
6. Guillemet (“)
7. caractère plus petit que (<)
8. caractère plus grand que (>)
9. barre verticale (|)

Les noms peuvent contenir un point (.). Cependant, le nom ne peut pas commencer par un point. L'utilisation de noms non-DNS avec des points est autorisée dans Microsoft Windows NT. Toutefois, les points ne doivent pas être utilisés dans les domaines Active Directory. Si vous mettez à niveau un domaine dont le nom NetBIOS contient un point, modifiez le nom en migrant le domaine vers une nouvelle structure de domaine. N'utilisez pas de points dans les nouveaux noms de domaine NetBIOS.

Avec Windows 2000 et les versions ultérieures de Windows, les ordinateurs membres d'un domaine Active Directory ne peuvent pas avoir des noms entièrement composés de caractères numériques. Cette restriction est due aux restrictions DNS.

15 caractères.
Remarque: le 16ème caractère est réservé pour identifier la fonctionnalité installée sur le périphérique réseau enregistré.

Les noms DNS ne peuvent contenir que des caractères alphabétiques (A à Z), des caractères numériques (0 à 9), le signe moins (-) et le point (.). Les caractères de point ne sont autorisés que lorsqu'ils sont utilisés pour délimiter les composants des noms de style de domaine.

Dans le système de noms de domaine Windows 2000 et dans le système DNS Microsoft Windows Server 2003, l’utilisation des caractères Unicode est prise en charge. Les autres implémentations de DNS ne prennent pas en charge les caractères Unicode. Évitez les caractères Unicode si les requêtes sont transmises à des serveurs qui utilisent des implémentations DNS non-Microsoft.

Les noms de domaine DNS ne peuvent pas contenir les caractères suivants:

1. virgule (,)
2. tilde (~)
3. deux points (:)
4. point d'exclamation (!)
5. arobase (@)
6. signe numérique (#)
7. signe dollar ($)
8. pour cent (%)
9. caret (^)
10. esperluette (&)
11. apostrophe (')
12. point (.)
13. parenthèses (())
14. accolades ({})
15. souligner (_)
16. espace blanc (vide)

Le trait de soulignement a un rôle spécial, car il est autorisé pour le premier caractère des enregistrements SRV par la définition RFC, mais les serveurs DNS les plus récents peuvent également le permettre n'importe où dans un nom.

Lors de la promotion d'un nouveau domaine, vous recevez un avertissement indiquant qu'un caractère de soulignement peut entraîner des problèmes avec certains serveurs DNS, mais il vous permet de créer le domaine.

1. Tous les caractères conservent leur casse, à l'exception des caractères ASCII.
2. Le premier caractère doit être alphabétique ou numérique.
3. Le dernier caractère ne doit pas être un signe moins ou un point.

2 caractères.

255 caractères.

La longueur maximale du nom d'hôte et du nom de domaine complet (FQDN) est de 63 octets par étiquette et de 255 caractères par FQDN. Ce dernier est basé sur la longueur de chemin maximale possible avec un nom de domaine Active Directory avec les chemins nécessaires dans SYSVOL, ce qui doit respecter la limite de 260 caractères MAX_PATH.

Un exemple de chemin dans SYSVOL contient: \\<FQDN nom du domaine>\sysvol\<FQDN nom du domaine>\policies\{<policy GUID>}\[usager|machine]\<chemin spécifique au CSE>. Le “chemin spécifique au CSE” peut contenir des entrées d'utilisateur telles que le nom du fichier de script d'ouverture de session. Par conséquent, il peut également atteindre une longueur importante.

Le nom de domaine FQDN AD apparaît deux fois dans le chemin d'accès, car la longueur d'un nom de domaine FQDN AD est limitée à 64 caractères.

[root@tchana ~]# yum install -y  nethserver-rh-php72-php-fpm  php72-php-ldap  php-mbstring  php-mcrypt

...
Le paquet php72-php-ldap-7.2.24-1.el7.remi.x86_64 est déjà installé dans sa dernière version
Le paquet php-mbstring-5.4.16-46.el7.x86_64 est déjà installé dans sa dernière version
...
Résumé de la transaction
============================================================================================
Installation   2 Paquets (+10 Paquets en dépendance)

Taille totale des téléchargements : 6.9 M
Taille d'installation : 23 M
...
Installé :
  nethserver-rh-php72-php-fpm.noarch 0:1.0.0-1.ns7     php-mcrypt.x86_64 0:5.4.16-9.el7

Dépendances installées :
  rh-php72.x86_64 0:1-2.el7                      rh-php72-php-cli.x86_64 0:7.2.10-3.el7
  rh-php72-php-common.x86_64 0:7.2.10-3.el7      rh-php72-php-fpm.x86_64 0:7.2.10-3.el7
  rh-php72-php-json.x86_64 0:7.2.10-3.el7        rh-php72-php-pear.noarch 1:1.10.5-1.el7
  rh-php72-php-process.x86_64 0:7.2.10-3.el7     rh-php72-php-xml.x86_64 0:7.2.10-3.el7
  rh-php72-php-zip.x86_64 0:7.2.10-3.el7         rh-php72-runtime.x86_64 0:1-2.el7

Terminé !
[root@tchana ~]#

Référence: https://community.nethserver.org/t/howto-install-nethserver-as-samba-ad-domain-controller-v0-2/9076.

Configuration → Fournisseur des comptes → Active Directory.

- Créer un nouveau domaine.
- Prend plusieurs minutes, être patient!

- On entre les informations demandées.
- CREATE DOMAIN.

Peut prendre un certain temps (minutes)…

- On vérifie les informations utilisées.
- Activer l'utilisateur admin.

Pour activer le compte admin, définissez un mot de passe. Pensez également à activer le shell si l'utilisateur admin doit accéder au nouveau gestionnaire de serveur.

L'utilisateur admin de NethServer a changé de nom: de admin à admin@micronator-dev.org.

De plus, un nouvel administrateur a été créé: administrator@micronator-dev.org / Administrator.

- Onglet Utilisateurs.
- Changer le mot de passe.

- On donne un mot de passe robuste.
- SOUMETTRE.

Ci-contre. on doit activer le shell si l'utilisateur Administrator doit accéder au nouveau gestionnaire de serveur.

Si on active Remote shell (SSH), il faut cliquer SOUMETTRE avant de faire quoi que ce soit d'autre.

On répète la procédure pour l'utilisateur admin.

Les utilisateurs et les groupes ont été exportés dans les fichiers TSV lors de la suppression de LDAP comme fournisseur des comptes tels que vérifiés à la section Vérification de l'exportation des utilisateurs/groupes .

Le répertoire /usr/share/doc/nethserver-sssd-<ver>/scripts/ contient des scripts pour importer les utilisateurs, les groupes et les comptes de messagerie dans AD:

[root@tchana ~]# ls -als /usr/share/doc/nethserver-sssd-1.4.8/scripts/

total 20
0 drwxr-xr-x 2 root root  114 19 avril  2019 .
0 drwxr-xr-x 3 root root   54 19 avril  2019 ..
4 -rwxr-xr-x 1 root root 1322  4 mars   2019 delete_users
4 -rwxr-xr-x 1 root root 1125  4 mars   2019 fix_migration_home
4 -rwxr-xr-x 1 root root 2119  4 mars   2019 import_emails
4 -rwxr-xr-x 1 root root 1398  4 mars   2019 import_groups
4 -rwxr-xr-x 1 root root 2049  4 mars   2019 import_users
[root@tchana ~]#

Dans LDAP, nous n'avions seulement que quatre utilisateurs - admin, michelandre, toto et titi.

On importe les anciens utilisateurs.

[root@tchana ~]# /usr/share/doc/nethserver-sssd-1.4.8/scripts/import_users /var/lib/nethserver/backup/users.tsv

[INFO] imported titi as titi@micronator-dev.org
[ERROR] Account `admin` user-create event failed.
[INFO] imported michelandre as michelandre@micronator-dev.org
[INFO] imported toto as toto@micronator-dev.org
[root@tchana ~]#

Il est normal que l'importation de l'utilisateur admin donne une erreur, car cet utilisateur existe déjà dans AD.

On importe les groupes qui étaient présents dans LDAP et qui on été sauvegardés lors de sa suppression.

[root@tchana ~]# /usr/share/doc/nethserver-sssd-1.4.8/scripts/import_groups /var/lib/nethserver/backup/groups.tsv

[INFO] imported 'grp-utilisateurs' with members 'titi toto'
[ERROR] Account `domain admins` group-create event failed.
[root@tchana ~]#

Il est normal que l'importation du groupe domain admins donne une erreur, car il existe déjà dans AD.
Un erreur pourrait aussi survenir si nous avons un nom de groupe qui est identique à un nom d'utilisateur, car dans Active Directory, il ne peut y avoir un utilisateur et un groupe ayant le même nom.

On vérifie.

Gestion → Utilisateurs et groupes → onglet Groupes → vis-à-vis grp-utilisateurs@micronator-dev.org → Éditer.

Le groupe domain admins a été recréé par AD et il y a insérer l'utilisateur admin qu'il a aussi recréé.

Les autres utilisateurs qui étaient déjà présents dans le groupe domain admins n'y sont pas importés, il faut les remettre dans ce groupe (michelandre dans notre cas).

Gestion → Utilisateurs et groupes → onglet Groupes. L'utilisateur michelandre n'est plus inclus dans le groupe.

- On ré-insère l'utilisateur michelandre dans le grou­pe domain admins.
- SOUMETTRE.

Le répertoire des courriels d'un utilisateur n'est jamais supprimé, même lorsqu'on supprime un utilisateur, car il faut toujours le supprimer manuellement, sinon il le sera au bout d'une année après la suppression de l'utilisateur.

Comme on le voit ci-dessous, les répertoires des courriels des utilisateurs n'ont pas été modifiés par l'ajout d'AD.

[root@tchana ~]# ls -als /var/lib/nethserver/vmail

total 4
0 drwx------   9 vmail vmail 222 17 oct.  11:39 .
0 drwxr-xr-x. 12 root  root  155 19 avril  2019 ..
0 drwx------   3 vmail vmail  21 19 avril  2019 admin@micronator-dev.org
0 drwx------   3 vmail vmail  21 19 avril  2019 michelandre@micronator-dev.org
0 drwx------   3 vmail vmail  21  8 janv.  2019 root
4 -rw-------   1 vmail vmail  73 17 oct.  11:25 shared-mailboxes.db
0 drwx------   3 vmail vmail  21 17 oct.  11:25 titi@micronator-dev.org
0 drwx------   3 vmail vmail  21 17 oct.  11:24 toto@micronator-dev.org
0 drwx------   3 vmail vmail  21  8 janv.  2019 vmail
0 drwx------   3 vmail vmail  21 19 avril  2019 vmail@micronator-dev.org
[root@tchana ~]#

Si, à la section Installation d'Active Directory comme fournisseur des comptes , nous avions choisi un nom de domaine autre que l'original dans LDAP lors de l'ajout d'AD, l'installation aurait créé un nouveau répertoire pour admin: admin@FQDNnouveauDomaine.

Avec un changement de nom de domaine, après avoir importé les utilisateurs et les groupes dans AD, nous devons importer les répertoires de courriels pour qu'ils indiquent le nouveau nom du domaine AD.

Avant de procéder, nous recommandons fortement de faire une sauvegarde, car en cas d'échec…

Avant l'installation d'AD.

[root@tchana ~]# ls -als /var/lib/nethserver/home

total 0
0 drwxr-xr-x.  5 root                           root                       49 Oct 20 18:02 .
0 drwxr-xr-x. 12 root                           root                      155 Apr 19  2019 ..
0 drwx------   2 michelandre@micronator-dev.org locals@micronator-dev.org  83 Oct 20 18:02 michelandre
0 drwx------   2 titi@micronator-dev.org        locals@micronator-dev.org  83 Oct 20 18:02 titi
0 drwx------   2 toto@micronator-dev.org        locals@micronator-dev.org  83 Oct 20 18:01 toto
[root@tchana ~]#

Après l'installation d'AD.

[root@tchana ~]# ls -als /var/lib/nethserver/home

total 0
0 drwxr-xr-x.  5 root root  49 16 nov.  13:54 .
0 drwxr-xr-x. 12 root root 155 19 avril  2019 ..
0 drwx------   2 1001 1000  83 16 nov.  13:54 michelandre
0 drwx------   2 1003 1000  83 17 oct.  11:32 titi
0 drwx------   2 1002 1000  83 17 oct.  11:32 toto
[root@tchana ~]#

Comme on le voit ci-dessus, l'installation d'AD a changé les propriétaire:groupe des répertoires personnels.

L'utilisateur admin ne s'étant jamais connecté à la console du serveur, il n'a pas encore de répertoire personnel.
On se substitue à l'utilisateur admin pour voir ce qui se passera.

[root@tchana ~]# su - admin 

Creating home directory for admin@micronator-dev.org.  
[admin@micronator-dev.org@tchana ~]$

Le système affiche qu'il a créé le répertoire personnel de l'utilisateur admin.

On revient à l'utilisateur root.

[admin@micronator-dev.org@tchana ~]$ exit

déconnexion
[root@tchana ~]#

On affiche les répertoires personnels.

[root@tchana ~]# ls -als /var/lib/nethserver/home

total 0
0 drwxr-xr-x.  6 root                     root                             62 28 nov.  18:04 .
0 drwxr-xr-x. 12 root                     root                            155 19 avril  2019 ..
0 drwx------   2 admin@micronator-dev.org domain users@micronator-dev.org  83 28 nov.  18:06 admin
0 drwx------   2                     1001                            1000  83 16 nov.  13:54 michelandre
0 drwx------   2                     1003                            1000  83 17 oct.  11:32 titi
0 drwx------   2                     1002                            1000  83 17 oct.  11:32 toto
[root@tchana ~]#

Le système a créé le répertoire personnel de l'utilisateur admin et lui a attribué les bons propriétaire:groupe.

On doit ré-ajuster les propriétaire:groupe des répertoires personnels.
On se rend dans le dossier des répertoires personnels.

[root@tchana ~]# cd /var/lib/nethserver/home/

[root@tchana home]#

On vérifie les chemins des répertoire personnels contenus dans AD.

[root@tchana home]# getent passwd * | cut -f6 -d:

/var/lib/nethserver/home/admin
/var/lib/nethserver/home/michelandre
/var/lib/nethserver/home/titi
/var/lib/nethserver/home/toto
[root@tchana home]#

On affiche tous les utilisateurs.

[root@tchana home]# getent passwd * | cut -f6 -d: | cut -f6 -d/

admin
michelandre
titi
toto
[root@tchana home]#

L'utilisateur root retourne dans son répertoire personnel.

[root@tchana home]# cd

[root@tchana ~]#

Vu les commandes ci-dessus, nous avons assez d'informations pour créer un script bash pour ajuster les propriétaire:groupe.

Prendre tout le contenu de l'encadré pour la commande.

cat > /root/dir.sh <<'EOT'
#!/bin/bash

# Mettre le script dans: /root/
# chmod +x /root/dir.sh
# Exécuter: /root/dir.dh

cd /var/lib/nethserver/home/

getent passwd * | cut -f6 -d: | cut -f6 -d/ > temp.txt

while read p; do
  chown -R $p@micronator-dev.org:"domain users@micronator-dev.org" $p
done <temp.txt

rm -rf temp.txt

EOT

On rend le script exécutable par root seulement.

[root@tchana ~]# chmod 700 /root/dir.sh

[root@tchana ~]#

On vérifie.

[root@tchana ~]# ls -als dir.sh

4 -rwx------ 1 root root 302 28 nov.  18:10 dir.sh
[root@tchana ~]#

On lance la commande d'ajustement des propriétaire:groupe.

[root@tchana ~]# /root/dir.sh

[root@tchana ~]#

On vérifie le résultat.

[root@tchana ~]# ls -als /var/lib/nethserver/home/

total 0
0 drwxr-xr-x.  6 root                           root                             62 28 nov.  18:11 .
0 drwxr-xr-x. 12 root                           root                            155 19 avril  2019 ..
0 drwx------   2 admin@micronator-dev.org       domain users@micronator-dev.org  83 28 nov.  18:06 admin
0 drwx------   2 michelandre@micronator-dev.org domain users@micronator-dev.org  83 16 nov.  13:54 michelandre
0 drwx------   2 titi@micronator-dev.org        domain users@micronator-dev.org  83 17 oct.  11:32 titi
0 drwx------   2 toto@micronator-dev.org        domain users@micronator-dev.org  83 17 oct.  11:32 toto
[root@tchana ~]#

Si ce n'est déjà fait, on édite l'utilisateur toto afin de lui permettre de se connecter à l'aide de PuTTY.

On se substitue à l'utilisateur toto pour voir si tout se passera bien

[root@tchana ~]# su - toto

[toto@micronator-dev.org@tchana ~]$

Aucune erreur.

On affiche dans quel répertoire se trouve l'utilisateur toto.

[toto@micronator-dev.org@tchana ~]$ pwd

/var/lib/nethserver/home/toto
[toto@micronator-dev.org@tchana ~]$

L'utilisateur toto est correctement situé dans son répertoire personnel.

On affiche le contenu de son répertoire personnel.

[toto@micronator-dev.org@tchana ~]$ ls -als

total 16
0 drwx------  2 toto@micronator-dev.org domain users@micronator-dev.org  83 17 oct.  11:32 .
0 drwxr-xr-x. 6 root                    root                             62 28 nov.  18:11 ..
4 -rw-------  1 toto@micronator-dev.org domain users@micronator-dev.org 245 28 nov.  17:15 .bash_history
4 -rw-------  1 toto@micronator-dev.org domain users@micronator-dev.org  18 17 oct.  11:32 .bash_logout
4 -rw-------  1 toto@micronator-dev.org domain users@micronator-dev.org 193 17 oct.  11:32 .bash_profile
4 -rw-------  1 toto@micronator-dev.org domain users@micronator-dev.org 231 17 oct.  11:32 .bashrc
[toto@micronator-dev.org@tchana ~]$

Il peut voir tout le contenu de son répertoire personnel. Tous ses anciens fichiers sont là.

On retourne à l'utilisateur root.

[toto@micronator-dev.org@tchana ~]$ exit

déconnexion
[root@tchana ~]#

Aucune erreur, tout s'est bien passé.

L'ajout d'AD comme fournisseur des comptes signifie que la page DNS du Serveur NethServer NE SERA PAS UTILISÉE!
L'adresse IP du serveur DNS que nous allons distribuer aux clients DOIT ÊTRE celle du conteneur AD, c.-à-d. 10.10.10.76: l'adresse IP donnée à la section Installation d'Active Directory comme fournisseur des comptes .

On s'assure de la bonne configuration de la carte réseau de la station à joindre à Active Directory.

- Clac sur l'icône réseau.
- Ouvrir le Centre Réseau et partage.

Modifier les paramètres de la carte.

Double-cliquer sur l'icône de la carte réseau.

Détails…

- On s'assure de la bonne configuration de la carte.
- Fermer.

Fermer toutes les fenêtres.

[root@tchana ~]# account-provider-test dump

{
   "BindDN" : "ldapservice@AD.MICRONATOR-DEV.ORG",
   "LdapURI" : "ldaps://nsdc-tchana.ad.micronator-dev.org",
   "DiscoverDcType" : "ldapuri",
   "StartTls" : "",
   "port" : 636,
   "host" : "nsdc-tchana.ad.micronator-dev.org",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "dc=ad,dc=micronator-dev,dc=org",
   "GroupDN" : "dc=ad,dc=micronator-dev,dc=org",
   "BindPassword" : "OwSvR7Cg_9XbT28w",
   "BaseDN" : "dc=ad,dc=micronator-dev,dc=org",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Dmicronator-dev%2Cdc%3Dorg"
}
[root@tchana ~]#

À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

Nous ajustons Self Service Password pour qu'il fonctionne sous Active Directory en se référant au Cahier-03: Self Service Password & Active Directory du “Cours NethServe-301”.

À ce stade-ci, on peut prendre un instantané de la machine virtuelle afin de pouvoir y revenir en cas d'une future erreur de manipulation.

Si ce n'est déjà fait, il faut maintenant ajuster la configuration de Self Service Password pour l'adapter à Active Directory.
Veillez consulter le Cahier-03: Self Service Password & Active Directory du “Cours NethServe-301” et plus particulièrement, les manipulations du chapitre Self Service Password & Active Directory.

On doit copier le fichier /root/exportation.ldif, créé en format LDIF au paragraphe Fichier d'exportation LDIF créé par le script , contenant les Question/Réponse des utilisateurs dans le répertoire: /var/lib/machines/nsdc/var/lib/samba/private/.

On copie le fichier /root/exportation.ldif tout en le renommant file.ldif.

[root@tchana ~]# cp /root/exportation.ldif /var/lib/machines/nsdc/var/lib/samba/private/file.ldif

[root@tchana ~]#

On vérifie.

[root@tchana ~]# ls -ls /var/lib/machines/nsdc/var/lib/samba/private/file.ldif

4 -rw-r--r-- 1 root root 337  1 déc.  10:08 exportation.ldif
[root@tchana ~]#

Référence: https://wiki.nethserver.org/doku.php?id=howto:useful_commands#modify_the_samba4_ad_settings

On importe les Question/Réponse.

[root@tchana ~]# /usr/bin/systemd-run -M nsdc                \
                         -q                                  \
                         -t /usr/bin/ldbmodify               \
                         -H /var/lib/samba/private/sam.ldb   \
                         /var/lib/samba/private/file.ldif

Modified 3 records successfully
[root@tchana ~]#

Les Question/Réponse de nos trois utilisateurs ont été importés dans Active Directory.

Pour la sécurité, on supprime le fichier file.ldif, car il n'est plus utile.

[root@tchana ~]# rm -rf  /var/lib/machines/nsdc/var/lib/samba/private/file.ldif

[root@tchana ~]#

On vérifie.

[root@tchana ~]# ls -als /var/lib/machines/nsdc/var/lib/samba/private/file.ldif

ls: impossible d'accéder à /var/lib/machines/nsdc/var/lib/samba/private/file.ldif: Aucun fichier ou dossier de ce type
[root@tchana ~]#

Vu que l'utilisateur toto ne connaît pas le nouveau mot de passe qu'Active Directory lui a octroyé, il doit utiliser la méthode de changement de mot de passe par réponse à sa question préalablement choisie. Il se rend donc à la page https://www.micronator-dev.org/ssp et clique Question afin de pouvoir changer son mot de passe.

- L'utilisateur toto entre son identifiant,
- choisit sa question,
- entre sa réponse,
- entre son nouveau mot de passe,
- le confirme,
- répond au reCaptcha
- et clique Envoyer.

L'opération a réussi.

Pour vérifier son nouveau mot de passe, l'utilisateur toto se connecte à Webmail en allant à: https://www.micronator-dev.org/webmail.

L'utilisateur toto entre sont identifiant et son nouveau mot de passe → Connexion.

Le nouveau mot de passe de l'utilisateur toto a bien été changé et il est fonctionnel.

Tous les autres utilisateurs exécutent les mêmes manipulations que celles utilisées par toto pour changer leur mot de passe.

<html>

</html>

Il nous faut ajuster le certificat Let's Encrypt afin d'y inclure le nom et les CNAME de notre domaine Active Directory.

Affichage des CNAME + FQDN de notre domaine. Le nom tchana est celui de notre Serveur NethServer.

[root@tchana ~]# account-provider-test dump

{
   "BindDN" : "ldapservice@AD.MICRONATOR-DEV.ORG",
   "LdapURI" : "ldaps://nsdc-tchana.ad.micronator-dev.org",
   "DiscoverDcType" : "ldapuri",
   "StartTls" : "",
   "port" : 636,
   "host" : "nsdc-tchana.ad.micronator-dev.org",
   "isAD" : "1",
   "isLdap" : "",
   "UserDN" : "dc=ad,dc=micronator-dev,dc=org",
   "GroupDN" : "dc=ad,dc=micronator-dev,dc=org",
   "BindPassword" : "OwSvR7Cg_9XbT28w",
   "BaseDN" : "dc=ad,dc=micronator-dev,dc=org",
   "LdapUriDn" : "ldap:///dc%3Dad%2Cdc%3Dmicronator-dev%2Cdc%3Dorg"
}
[root@tchana ~]#

Pour un serveur directement branché à l'Internet, il faut ajouter les trois enregistrements CNAME: ad, nscd-tchana.ad et adserver.ad chez le régistraire de notre nom de domaine.
Ici, nous utilisons cloudflare.com comme notre régistraire de domaine.

Pour plus de détails, voir le chapitre Régistraire de domaines dans le Cahier-05: VDSL, FQDN, Internet et NethServer du “Cours NethServer-101”.

Voir aussi le chapitre Certificat pour un domaine LOCAL dans le Cahier-04: NethServer LOCAL & Certificat Let's Encrypt du “Cours NethServer-101”.

Voir le chapitre Certificat pour un domaine LOCAL dans le Cahier-04: NethServer LOCAL & Certificat Let's Encrypt du “Cours NethServer-101”.

Pour la demande du certificat Let's Encrypt. il faut ajouter les trois enregistrements CNAME: ad, nscd.tchana.ad et adserver.ad.

[root@tchana ~]# /root/.acme.sh/acme.sh                                             \
                      --issue                                                       \
                      --dns dns_cf                                                  \
                      -d micronator-dev.org                                         \
                      -d www.micronator-dev.org                                     \
                      -d mail.micronator-dev.org                                    \
                      -d wpad.micronator-dev.org                                    \
                      -d ad.micronator-dev.org                                      \
                      -d nscd-tchana.ad.micronator-dev.org                          \
                      -d adserver.ad.micronator-dev.org                             \
                      --cert-file /etc/pki/tls/certs/cert.pem                       \
                      --ca-file /etc/pki/tls/certs/chain.pem                        \
                      --key-file /etc/pki/tls/private/privkey.pem                   \
                      --reloadcmd "/sbin/e-smith/signal-event certificate-update"   \
                      --test

...
[sam. déc.  7 12:02:55 EST 2019] Your cert is in  /root/.acme.sh/micronator-dev.org/micronator-dev.org.cer
[sam. déc.  7 12:02:55 EST 2019] Your cert key is in  /root/.acme.sh/micronator-dev.org/micronator-dev.org.key
[sam. déc.  7 12:02:55 EST 2019] The intermediate CA cert is in  /root/.acme.sh/micronator-dev.org/ca.cer
[sam. déc.  7 12:02:55 EST 2019] And the full chain certs is there:  /root/.acme.sh/micronator-dev.org/fullchain.cer
[sam. déc.  7 12:02:55 EST 2019] Installing cert to:/etc/pki/tls/certs/cert.pem
[sam. déc.  7 12:02:55 EST 2019] Installing CA to:/etc/pki/tls/certs/chain.pem
[sam. déc.  7 12:02:55 EST 2019] Installing key to:/etc/pki/tls/private/privkey.pem
[sam. déc.  7 12:02:55 EST 2019] Run reload cmd: /sbin/e-smith/signal-event certificate-update
[sam. déc.  7 12:02:59 EST 2019] Reload success
[root@tchana ~]#

La demande d'un certificat de test est réussie, on peut demander un certificat officiel.
Vu que le certificat de test est valide pour une période de 90 jours, on remplace le paramètre –test par –force afin de “forcer” le renouvellement.

[root@tchana ~]# /root/.acme.sh/acme.sh                                             \
                      --issue                                                       \
                      --dns dns_cf                                                  \
                      -d micronator-dev.org                                         \
                      -d www.micronator-dev.org                                     \
                      -d mail.micronator-dev.org                                    \
                      -d wpad.micronator-dev.org                                    \
                      -d ad.micronator-dev.org                                      \
                      -d nscd-tchana.ad.micronator-dev.org                          \
                      -d adserver.ad.micronator-dev.org                             \
                      --cert-file /etc/pki/tls/certs/cert.pem                       \
                      --ca-file /etc/pki/tls/certs/chain.pem                        \
                      --key-file /etc/pki/tls/private/privkey.pem                   \
                      --reloadcmd "/sbin/e-smith/signal-event certificate-update"   \
                      --force

...
[sam. déc.  7 12:17:12 EST 2019] Your cert is in  /root/.acme.sh/micronator-dev.org/micronator-dev.org.cer
[sam. déc.  7 12:17:12 EST 2019] Your cert key is in  /root/.acme.sh/micronator-dev.org/micronator-dev.org.key
[sam. déc.  7 12:17:12 EST 2019] The intermediate CA cert is in  /root/.acme.sh/micronator-dev.org/ca.cer
[sam. déc.  7 12:17:12 EST 2019] And the full chain certs is there:  /root/.acme.sh/micronator-dev.org/fullchain.cer
[sam. déc.  7 12:17:12 EST 2019] Installing cert to:/etc/pki/tls/certs/cert.pem
[sam. déc.  7 12:17:12 EST 2019] Installing CA to:/etc/pki/tls/certs/chain.pem
[sam. déc.  7 12:17:12 EST 2019] Installing key to:/etc/pki/tls/private/privkey.pem
[sam. déc.  7 12:17:12 EST 2019] Run reload cmd: /sbin/e-smith/signal-event certificate-update
[sam. déc.  7 12:17:15 EST 2019] Reload success
[root@tchana ~]#

Certificat publique.

[root@tchana ~]# ls -als /etc/pki/tls/certs/cert.pem

4 -rw-r--r-- 1 root root 2143  7 déc.  12:17 /etc/pki/tls/certs/cert.pem
[root@tchana ~]#

Chaîne de certification.

[root@tchana ~]# ls -als /etc/pki/tls/certs/chain.pem

4 -rw-r--r-- 1 root root 1648  7 déc.  12:17 /etc/pki/tls/certs/chain.pem
[root@tchana ~]#

Clé privée.

[root@tchana ~]# ls -als /etc/pki/tls/private/privkey.pem

4 -rw------- 1 root root 1679  7 déc.  12:17 /etc/pki/tls/private/privkey.pem
[root@tchana ~]#

On se rend à https://www.micronator-dev.org.

Il n'est pas nécessaire d'ajouter une exception pour le certificat car, il a été émis par une autorité de certification reconnue. Le cadenas est vert.

On clique le cadenas pour afficher les informations de la connexion puis, on clique l'icône >.

Plus d'informations.

Afficher le certificat.

Tous nos CNAME sont présents.

À chaque jour, une tâche cron vérifie le nombre de jours restant pour la validité.

[root@tchana ~]# crontab -l

56 0 * * * "/root/.acme.sh"/acme.sh --cron --home "/root/.acme.sh" > /dev/null
[root@tchana ~]#

Le renouvellement se fera automatiquement lorsqu'il ne restera que 30 jours de validité.

<html>

</html>

Référence: https://dev-notes.eu/2017/01/apache-directives-in-config-vs-htaccess/
Référence: http://httpd.apache.org/docs/current/howto/htaccess.html#page-header.

• Pour un serveur branché directement à l'Internet, lors d'une demande d'un certificat à Let's Encrypt, ce dernier doit pouvoir accéder au répertoire .well-known et à son sous-répertoire acme-challenge.

• On peut faire la demande de certificat à la page de l'interface Web: Configuration → Certificat du serveur → on déroule le menu et on choisit Requête de certificat Let's Encrypt.

• Pour plus de détails, voir le Cahier-05: NethServer-101, Cahier-05: VDSL, FQDN, Internet et NethServer du Cours “NethServer-101”.

Pour ce genre de serveur, nous devons créer un fichier /etc/httpd/conf.d/z_well-known.conf pour indiquer à Apache de rendre accessibles le répertoire .well-known et son sous-répertoire acme-challenge.

Prendre tout le contenu de l'encadré pour la commande.

cat > /etc/httpd/conf.d/z_well-known.conf <<'EOT'
Alias "/.well-known/acme-challenge/" "/var/www/html/.well-known/acme-challenge/"
<Directory "/var/www/html/.well-known/acme-challenge/">
   Require all granted
   Options -Indexes +FollowSymLinks
   AllowOverride All
</Directory>

EOT

On vérifie.

[root@tchana ~]# ls -als /etc/httpd/conf.d/z_well-known.conf

4 -rw-r--r-- 1 root root 231  7 déc.  13:46 /etc/httpd/conf.d/z_well-known.conf
[root@tchana ~]#

On affiche le contenu du fichier.

[root@tchana ~]# cat /etc/httpd/conf.d/z_well-known.conf

Alias "/.well-known/acme-challenge/" "/var/www/html/.well-known/acme-challenge/"
<Directory "/var/www/html/.well-known/acme-challenge/">
   Require all granted
   Options -Indexes +FollowSymLinks
   AllowOverride All
</Directory>

[root@tchana ~]#

Il n'y a pas de ligne vide au dessus de Alias… Ci-dessus, Nous en avons inséré une afin de faciliter la copie de la commande.

On vérifie si le nom du fichier /etc/httpd/conf/z_well-known.conf est déjà inclus dans le fichier d'inclusion de la sauvegarde des données: /etc/backup-data.d/custom.include, sinon on l'insère.

Prendre tout le contenu de l'encadré pour la commande.

NouvelleInclusion="/etc/httpd/conf/z_well-known.conf"
if grep -Fxq "$NouvelleInclusion" /etc/backup-data.d/custom.include
then
    # L'entrée a été trouvée dans custom.include
    echo -e "\nLe fichier custom.include contient déjà l'entrée:\n$NouvelleInclusion \n"
else
    # L'entrée n'a pas été trouvée dans custom.include
    echo -e "$NouvelleInclusion" >> /etc/backup-data.d/custom.include
    echo -e "\nL'entrée: $NouvelleInclusion a été ajoutée\n"
fi

On vérifie.

[root@tchana ~]# cat /etc/backup-data.d/custom.include | grep z_well-known.conf

/etc/httpd/conf/z_well-known.conf
[root@tchana ~]#

Ci-dessus, il n'y a pas de ligne vide avant /etc/httpd/conf/z_well-known.conf. Nous en avons inséré une afin de faciliter la copie de la commande.

On redémarre le démon Apache afin qu'il relise ses fichiers de configuration.

[root@tchana ~]# systemctl restart httpd

[root@tchana ~]#

Seulement pour un Serveur NethServer branché directement à l'Internet.
Le certificat sera émis pour le nom du premier FQDN entré.

Configuration → Certificat du serveur → on déroule le menu → Requête de certificat Let's Encrypt.

- On entre notre adresse courriel.
- On entre tous nos CNAME + FQDN.
- REQUÊTE DE CERTIFICAT LET'S ENCRYPT.

Les captures d'écran ci-dessous ont été prise d'un autre Serveur NethServer, mais elles reflètent exactement la marche à suivre pour définir le certificat émis par Let's Encrypt comme certificat par défaut.

On désigne le nouveau certificat émis par Let's Encrypt en tant que celui qui sera utilisé par défaut, car c'est le certificat standard auto-signé qui l'est encore comme le démontre le crochet de la colonne Défaut de la capture d'écran ci-dessous.

- On déroule le menu à l'extrême droite de la ligne du certificat Let's Encrypt.
- Set as default.

CONFIRM.

C'est le certificat Let's Encrypt qui sera maintenant utilisé par défaut.

Pour plus de détails, voir le chapitre Certificat Let's Encrypt dans le Cahier-05: VDSL, FQDN, Internet et NethServer du “Cours NethServer-101”.

Les exemples de ce chapitre proviennent de la section Appendices du Cahier-201-04: DokuWiki du “Cours NethServer-201”.

Ligne originale dans le fichier /etc/default/grub.

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/lv_root rd.lvm.lv=VolGroup/lv_swap nodmraid rhgb quiet"

Après avoir enlevé le paramètre rhgb.

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=VolGroup/lv_root rd.lvm.lv=VolGroup/lv_swap nodmraid quiet"

On signale le changement en régénérant le fichier de configuration.

[root@tchana ~]# grub2-mkconfig -o /boot/grub2/grub.cfg

Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-957.5.1.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-957.5.1.el7.x86_64.img
Found linux image: /boot/vmlinuz-3.10.0-957.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-957.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-8ee070fd1a7a4e8daf17a7dae9f85ac1
Found initrd image: /boot/initramfs-0-rescue-8ee070fd1a7a4e8daf17a7dae9f85ac1.img
done
[root@tchana ~]#

Au prochain réamorçage, le nouveau fichier grub sera effectif.

et y ajouter la ligne suivante: config['default_host'] = '127.0.0.1';.

Par contre, si nous modifions directement ce fichier, le prochain ré-amorçage écrasera la modification lorsque le serveur assemblera les gabarits de configuration du système.

Il nous faut donc créer un gabarit personnalisé et y insérer la nouvelle ligne de configuration. Ainsi, lors de l'assemblage des gabarits, le serveur incorporera le gabarit personnalisé au gabarit standard de configuration de PHP.

Création du répertoire pour le gabarit personnalisé.

[root@tchana ~]# mkdir -p /etc/e-smith/templates-custom/etc/roundcubemail/config.inc.php

[root@tchana ~]#

On crée le fichier 91CacherNomDuServeur et on y insère la ligne de configuration.

Prendre tout le contenu de l'encadré pour la commande.

cat > /etc/e-smith/templates-custom/etc/roundcubemail/config.inc.php/91CacherNomDuServeur <<'EOT'

$config['default_host'] = '127.0.0.1';

EOT

On vérifie.

[root@tchana ~]# cat /etc/e-smith/templates-custom/etc/roundcubemail/config.inc.php/91CacherNomDuServeur

$config['default_host'] = '127.0.0.1';
[root@tchana ~]#

Il n'y a pas de ligne vide avant $config… Nous en avons inséré une pour faciliter la copie de la commande.

On signale le changement.

[root@tchana ~]# expand-template /etc/roundcubemail/config.inc.php

[root@tchana ~]#

On redémarre le démon httpd.

[root@tchana ~]# systemctl restart httpd

[root@tchana ~]#

On vérifie si le nom du répertoire /etc/e-smith/templates-custom/etc/roundcubemail/ est déjà présent dans le fichier d'inclusion de la sauvegarde des données: /etc/backup-data.d/custom.include, sinon on l'insère.

Prendre tout le contenu de l'encadré pour la commande.

NouvelleInclusion="/etc/e-smith/templates-custom/etc/roundcubemail/"
if grep -Fxq "$NouvelleInclusion" /etc/backup-data.d/custom.include
then
    # L'entrée a été trouvée dans custom.include
    echo -e "\nLe fichier custom.include contient déjà l'entrée:\n$NouvelleInclusion \n"
else
    # L'entrée n'a pas été trouvée dans custom.include
    echo -e "$NouvelleInclusion" >> /etc/backup-data.d/custom.include
    echo -e "\nL'entrée: $NouvelleInclusion a été ajoutée\n"
fi

On vérifie.

[root@tchana ~]# cat /etc/backup-data.d/custom.include |  grep roundcube

/etc/e-smith/templates-custom/etc/roundcubemail/
[root@tchana ~]#

Ci-dessus, il n'y a pas de ligne vide avant /etc/e-smith/templates-custom/etc/roundcubemail/. Nous en avons inséré une afin de faciliter la copie de la commande.

On affiche les langues offertes à la console du serveur.

  [root@tchana ~]# localectl list-locales | grep fr_
  
  fr_BE
  fr_BE.iso88591
  fr_BE.iso885915@euro
  fr_BE.utf8
  fr_BE@euro
  fr_CA
  fr_CA.iso88591
  fr_CA.utf8
  fr_CH
  fr_CH.iso88591
  fr_CH.utf8
  fr_FR
  fr_FR.iso88591
  fr_FR.iso885915@euro
  fr_FR.utf8
  fr_FR@euro
  fr_LU
  fr_LU.iso88591
  fr_LU.iso885915@euro
  fr_LU.utf8
  fr_LU@euro
  [root@tchana ~]#

On ajuste la langue désirée pour l'affichage. On choisit fr_FR.utf8, car ce choix affectera aussi celui de la traduction pour l'interface Web. Pour l'instant, la traduction fr_FR est plus avancé que celle de fr_CA.

  [root@tchana ~]# localectl set-locale LANG=fr_FR.utf8
  
  [root@tchana ~]#

Dorénavant, la page de connexion offrira Français (France) comme langue par défaut au lieu de English (United States) si nous avons installé le module Langue Française.

On pourra vérifier, après le prochain redémarrage, en lançant la commande ci-dessous.

  [root@tchana ~]# ls -als toto
  
  ls: impossible d'accéder à toto: Aucun fichier ou dossier de ce type
  [root@tchana ~]#

On change la langue de l'interface.

Administration → Software center (peut prendre un certain temps) → on coche French language.

ADD.

APPLY CHANGES.

Le RPM nethserver-lang-fr s'installe.

Reload page.

On se déconnecte/reconnecte pour activer la traduction française.

- Par défaut, Français (France) est affiché.
- LOGIN.

On affiche les différentes mappes de clavier²⁾ “ca” disponibles.

[root@tchana ~]# localectl list-keymaps | grep ca

ca
ca-eng
ca-fr-dvorak
ca-fr-legacy
ca-multi
ca-multix
dvorak-ca-fr
es-cat
ph-capewell-dvorak
ph-capewell-qwerf2k6
[root@tchana ~]#

On active le clavier ca-multi.

[root@tchana ~]# localectl set-keymap ca-multi

[root@tchana ~]#

On vérifie.

[root@tchana ~]# localectl

   System Locale: LANG=fr_FR.UTF-8
       VC Keymap: ca-multi
      X11 Layout: us
[root@tchana ~]#

Référence: http://docs.nethserver.org/en/v7/access.html#session-timeouts.
Par défaut (à partir de NethServer 7.5.1804), une session de gestion du serveur se termine après 60 minutes d'inactivité (délai d'inactivité) et expire 8 heures après la connexion (durée de vie de la session).

La commande ci-dessous définit 2 heures de délai d'inactivité et 16 heures de durée de vie de la session maximale. Le temps est exprimé en secondes.

[root@tchana ~]# config setprop httpd-admin MaxSessionIdleTime 7200 MaxSessionLifeTime 57600

[root@tchana ~]#

Désactivation des délais.

[root@tchana ~]# config setprop httpd-admin MaxSessionIdleTime '' MaxSessionLifeTime ''

[root@tchana ~]#

Les nouvelles valeurs de délais affecteront les nouvelles sessions. Ils ne changent aucune session active.

Pour le fuseau horaire, il existe un fichier pour Montréal.

[root@tchana ~]# ls -ls /usr/share/zoneinfo/America/ -> grep Montreal

 4 -rw-r--r--  3 root root 3477  1 avril 08:27 Montreal
[root@tchana ~]#

On affiche le fuseau horaire actuel.

[root@tchana ~]# ls -l /etc/localtime

lrwxrwxrwx 1 root root 37 19 mai   23:48 /etc/localtime -> ../usr/share/zoneinfo/America/Toronto
[root@tchana ~]#

On change le fuseau horaire pour celui de Montréal.

[root@tchana ~]# timedatectl set-timezone America/Montreal

[root@tchana ~]#

On vérifie.

[root@tchana ~]# ls -l /etc/localtime

lrwxrwxrwx 1 root root 38 22 mai   14:02 /etc/localtime -> ../usr/share/zoneinfo/America/Montreal
[root@tchana ~]#

Voilà! Le fuseau horaire Montréal est récupéré…

Un certificat émis par l'autorité de certification Let's Encrypt vous permettra de chiffrer les connexions de votre serveur avec une clé TLS/SSL reconnue mondialement. Les utilisateurs pourront utiliser https.

Référence: https://fr.wikipedia.org/wiki/Let's_Encrypt.
Let's Encrypt est une autorité de certification (CA) lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d'un mécanisme automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l'installation et le renouvellement des certificats pour la sécurisation des sites Internet.

On examine le certificat émis par Let's Encrypt pour notre serveur dorgee.micronator-101.org qui est directement branché à l'Internet.

Si la demande de certificat a fonctionnée sans erreur, essayez de vous connecter à la page de l'interface Web du Serveur NethServer. Le certificat devrait incorporer tous les noms d'hôtes que vous avez inclus et être valide pour les quatre-vingt-dix prochains jours.

On se connecte à l'interface Web: https://www.micronator-101.org:980.

- Le cadenas est vert.
- On se logue.

- On clique le cadenas.
- On clique l'icône ”>“.

Plus d'informations.

- Onglet Sécurité.
- Afficher le certificat.

- Onglet Détails.
- Émis pour micronator-101.org
- Émis par Let's Encrypt Authority X3
- On voit la date de début et de fin.

- Validité → Pas après.
- Le certificat est valide pour 90 jours.

- Nom alternatif du sujet du certificat.
- Tous nos CNAME choisis lors de la demande du certificat sont affichés.
- Fermer toutes les fenêtres du certificat.

Vérification par Qualsys SSLLabs

Seulement pour un serveur directement branché à l'Internet.
Une fois que vous avez obtenu votre certificat, testez-le en vous rendant chez Qualsys SSLLabs, https://www.ssllabs.com/ssltest/.
Soumettez le nom FQDN de votre domaine pour vérifier que le certificat fonctionne correctement.

Hostname:
micronator-101.org → Submit.

- Overall Rating → A.
- Certificate → 100%.

Changement du mot de passe de root

Référence: https://www.rootusers.com/how-to-reset-root-user-password-in-centos-rhel-7/.
Réinitialiser le mot de passe de root est normalement une tâche simple si vous êtes déjà connecté avec les privilèges de root. Toutefois, si vous oubliez le mot de passe et devez le changer, les choses deviennent un peu plus difficiles.
Le processus a changé de la version 6 de CentOS/RHEL (Red Hat Enterprise Linux) à la version 7. Auparavant, vous démarriez en mode mono-utilisateur, puis changiez le mot de passe en tant qu'utilisateur root. À partir de la version 7, les modes équivalents sont: mode de secours et mode d’urgence. Cependant, ces modes d'opération nécessitent le mot de passe de root avant de pouvoir faire quoi que ce soit. Cette section va vous guider dans le nouveau processus pour changer le mot de passe perdu de root. Cette procédure sera exécutée à la console du système Linux, assurez-vous donc que vous y avez accès avant de commencer.
Comme pour toutes les tâches de maintenance du système, assurez-vous de disposer d'une sauvegarde/instantané du système avant de poursuivre.

Si votre système Linux est en cours d'exécution, redémarrez-le. S'il ne roule pas, démarrez-le.

Pour CentOS 7, le menu de démarrage vous laissera 5 secondes pour sélectionner le noyau du système d’exploitation à démarrer. Ces 5 secondes sont importantes, car elles permettent aux administrateurs de sélectionner différents noyaux ou d’éditer les paramètres du noyau existant avant le démarrage.

Dans le menu de démarrage, appuyez sur e pour modifier le noyau existant tel qu'indiqué ci-dessous.

Dans les options de grub, recherchez la ligne qui commence par linux16 et allez à la fin. Entrez rd.break à la fin de cette ligne tel qu'indiqué ci-dessous.

rd.break

Appuyez sur [Ctrl] + [x] pour démarrer avec ces options qui vous amèneront à l'invite initramfs avec un shell root.

À ce stade, le système de fichiers racine est monté en mode lecture seule (ro) dans le répertoire /sysroot et doit être remonté avec les autorisations de lecture/écriture (rw) pour que nous puissions réellement apporter certaines modifications. Ceci est réalisé avec la commande mount -o remount,rw /sysroot.

switch_root:/# mount -o  remount,rw  /sysroot

switch_root:/#

Une fois le système de fichiers remonté, changez-le en une prison chroot afin que le répertoire /sysroot soit utilisé comme racine du système de fichiers. Ceci est nécessaire pour que toutes les commandes que nous exécuterons se rapportent à /sysroot. La commande à lancer est chroot /sysroot.

switch_root:/# chroot /sysroot

sh-4.2#

À partir d'ici, le mot de passe de root peut être réinitialisé à l’aide de la commande passwd.

sh-4.2# passwd

Changing password for user root.
New password: Nouveau-mot-de-passe-de-root
Retype new passwd: Nouveau-mot-de-passe-de-root
passwd: all authentification tokens updated successfully.
sh-4.2#

Si vous n'utilisiez pas SELinux, vous pourriez redémarrer à ce stade et tout irait bien. Cependant, par défaut, CentOS/RHEL-7 active SELinux. Nous devons donc corriger le contexte du fichier /etc/shadow. En effet, lorsque la commande passwd est exécutée, elle crée un nouveau fichier /etc/shadow. SELinux n'étant pas en cours d'exécution dans ce mode, le fichier est créé sans aucun contexte SELinux, ce qui peut entraîner des problèmes lors du redémarrage.

On crée le fichier /.autorelabel à l’aide de touch.

sh-4.2# touch /.autorelabel

sh-4.2#

La création de ce fichier effectuera automatiquement un ré-étiquetage de tous les fichiers au prochain démarrage. Notez que cela peut prendre un certain temps en fonction de la quantité de fichiers que vous avez. Peut prendre environ 2 minutes pour un serveur CentOS-7 ordinaire.

On quitte l'environnement chroot.

sh-4.2# exit

exit
sh-4.2#

On quitte le shell racine initramfs (peut prendre un certain temps, être patient…). Le serveur s'amorce.

sh-4.2# exit

logout
...

Vérification

À la console du serveur, vous devriez pouvoir vous connecter et utiliser le système avec le nouveau mot de passe que vous avez créé.

ERROR Failed to send host log message

Cette erreur s'affiche seulement lors de l'amorçage d'un serveur roulant sous VirtualBox.

- On arrête le Serveur NethServer.
- À l'écran VirtualBox, on sélectionne la machine → État actuel → Configuration.

Au retour, on amorce le Serveur NethServer et le message ne s'affichera plus.

Affichage → onglet Écran → Contrôleur graphique → on change pour VboxVGA → OK.

Martian source

Si dans le fichier journal /var/log/messages, vous voyez plusieurs lignes telles que ci-dessous, c'est que l'IP de la passerelle du réseau vert de la carte enp0s3 ou les Serveurs DNS ne sont corrects.

...IPv4: martian source 192.168.1.1...
...IPv4: martian source 192.168.1.1...
...IPv4: martian source 192.168.1.1...

Passerelle du réseau de la carte enp0s3

On trouve notre passerelle en lançant un traceroute vers google.com.

[root@dorgee ~]# traceroute google.com

traceroute to google.com (172.217.165.14), 30 hops max, 60 byte packets
 1  lo0-0-lns03-tor.teksavvy.com (206.248.155.139)  10.367 ms  11.449 ms  11.487 ms
 2  ae0-2150-bdr01-tor.teksavvy.com (69.196.136.172)  11.523 ms  11.793 ms  11.826 ms
 3  72.14.212.134 (72.14.212.134)  11.868 ms  12.430 ms  12.306 ms
 4  74.125.244.161 (74.125.244.161)  12.736 ms 74.125.244.145 (74.125.244.145)  14.002 ms 74.125.244.161 (74.125.244.161)  13.174 ms
 5  216.239.40.255 (216.239.40.255)  13.577 ms  13.923 ms 216.239.41.175 (216.239.41.175)  13.923 ms
 6  yyz12s06-in-f14.1e100.net (172.217.165.14)  13.020 ms  12.009 ms  11.291 ms
[root@dorgee ~]#

L'adresse IP de la ligne #1 est 206.248.155.139 et elle est donc la passerelle utilisée par notre connexion.

Configuration → Réseau → Périphérique enp0s3 → Éditer.

On change l'IP de la passerelle pour l'IP du rôle LAN (vert) / enp0s3 → 206.248.155.139.

SOUMETTRE.

Serveurs DNS

Référence: https://korben.info/1-1-1-1-ou-9-9-9-9-ou-8-8-8-8-quel-dns-choisir.html.
… Le DNS de Cloudflare est un excellent DNS, car il est le plus rapide, mais aussi parce qu'ils ont pris les devants et s'engagent à ne pas revendre les données, et ne conservent pas les logs au-delà de 24h…
Le principal avantage bien sûr, c'est que contrairement au DNS de Google qui permet de mieux vous profiler pour vous balancer de la pub, on sait que Cloudflare ne trempe pas là dedans. Cela reste une boîte américaine, donc c'est évidemment à prendre avec toutes les précautions d'usage…

Référence: pour 8.8.8.8 - https://www.dnsperf.com/dns-resolver/google.

Autre référence: comparaison mondiale des performances de différents DNS: https://medium.com/@nykolas.z/dns-resolvers-performance-compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5.

Référence: pour ci-dessous 1.1.1.1 - https://www.dnsperf.com/#!dns-resolvers.

Configuration → Réseau → Serveurs DNS.

On ajuste les DNS Primaire et Secondaire.

Le serveur DNS primaire 1.1.1.1 est le plus rapide et le plus utilisée de tout l'Internet.

Le serveur DNS secondaire 206.248.182.3 est le défaut de notre FAI.

Soumettre.

Si votre FAI filtre l'adresse 1.1.1.1, prendre 8.8.8.8 ou une de celles citées dans la référence https://medium.com/@nykolas.z/dns-resolvers-performance-compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5.

Introduction à l'éditeur vi

Référence: http://www.iro.umontreal.ca/~dift3830/vi.html. (Dernière consultation, le 30 mai 2016. Novembre 2018, ce lien n'est plus fonctionnel.)

vi est un éditeur de texte très puissant. Sa convivialité par contre lui fait défaut. Ceci dit, il est toujours utile d'en connaître les rudiments, car son omniprésence est presque garantie sur les systèmes modernes.

La documentation de vi étant très abondante, on se limitera pour cette démo aux commandes les plus usuelles.

Tout d'abord l'invocation. On peut invoquer vi à partir du shell de plusieurs façons dont en voici quelques-unes:

- vi: → ouvre vi avec un contenu vide. - vi nom_de_fichier: → ouvre un fichier et l'affiche à l'écran. - vi +nom_de_fichier: → ouvre un fichier et positionne le curseur à la fin de celui-ci.

Dès son invocation, vi se met en mode commande, dans ce mode il est possible d'entrer les commandes qui seront vues plus bas. Si on tape une commande susceptible de modifier un texte (insertion d'un caractère par exemple), vi bascule en mode édition; dans ce mode tout caractère tapé sera considéré comme faisant partie du texte, tandis que les caractères saisis en mode commande, seront eux interprétés comme étant des commandes et ne seront jamais rajoutés au texte.

Afin de basculer du mode édition au mode commande il suffit de presser la touche [Échap].

Nous allons commencer par invoquer vi à partir du shell en tapant:

vi

Ce qui devrait donner l'affichage ci-contre:

vi est déjà en mode commande, pour le faire passer en mode édition, on tape la commande i (insert) qui nous permet d'insérer du texte.

i

Après avoir tapé le texte suivant:

vi est un éditeur de texte très
 
utile pour la communauté des 
administrateurs.

On obtient l'affichage ci-contre.

Après cela, on pourrait passer en mode commande par simple pression sur la touche [Échap].

Une fois en mode commande, on voudrait par exemple, éliminer la ligne blanche qui se trouve juste après la première. Pour ce faire, on positionne le curseur a la hauteur de la 2e ligne et on tape dd.

Ceci aura pour effet de supprimer la ligne.

Si on est satisfait, il ne nous reste plus qu'à sauvegarder le document sous le nom texte1.txt à l'aide de la commande suivante:

:w texte1.txt

(Pour les sauvegardes ultérieures, il n'est pas nécessaire d'ajouter le nom du fichier).

Afin de quitter vi il suffit de taper la commande:

:q texte1.txt

Les commandes abondent dans vi, on n'en citera que quelques-unes.

Principales commandes de vi
Commande	Effets
i (insert)	Insère un texte sur le curseur
I	Insère au début de la ligne
a (append)	Insère après le curseur
A	Insère à la fin de la ligne
Les flèches	pour les déplacements
Ctrl-F (forward)	Défiler d'un écran vers le bas
Ctrl-B (backward)	Défiler d'un écran vers le haut
nG (goto)	va à la nième ligne dans le texte
G	Va à la fin du texte
x	Effacer le caractère courant
dd	Effacer la ligne courante
D	Effacer depuis la position du curseur jusqu'à la fin de la ligne
db (DeleteBegining)	Effacer depuis la position courante jusqu'au début de la ligne
/chaîne	rechercher la chaîne 'chaîne' dans le texte, on peut taper 'n' pour voir les autres occurrences
:w fichier	copie le texte courant sur le disque sous le nom fichier
:wq (write & quit)	écrit le fichier sur le disque et quitte vi.
:q!	Quitter sans sauvegarder.
:set nu	Affiche le numérotage des lignes.

Victoire totale, hissons la bannière de la victoire.

---

Crédits

© 2019 RF-232
Auteur: Michel-André.
Remerciement: Tous les contributeurs GNU/GPL.
Intégré par: Michel-André Robillard CLP
Contact: michelandre at micronator.org

Répertoire de ce document: E:\000_DocPourRF232_general\RF-232_NethServer-301\RF-232_Cours_NethServer-301-02_ActiveDirectory_2019-12-24_11h59.odt.

Historique des modifications:

Version	Date	Commentaire	Auteur
0.0.1	2019-10-02	Début.	M.-A. Robillard
12345678901			12345678901

<html><hr style=“width:50%; margin: 0 auto;”></html>

AVIS DE NON-RESPONSABILITÉ

Ce document est uniquement destiné à informer. Les informations, ainsi que les contenus et fonctionnalités de ce do­cument sont fournis sans engagement et peuvent être modifiés à tout moment. RF‑232 n'offre aucune garantie quant à l'actualité, la conformité, l'exhaustivité, la qualité et la durabilité des informations, contenus et fonctionnalités de ce document. L'accès et l'utilisation de ce document se font sous la seule responsabilité du lecteur ou de l'utilisateur.

RF‑232 ne peut être tenu pour responsable de dommages de quelque nature que ce soit, y compris des dommages di­rects ou indirects, ainsi que des dommages consécutifs résultant de l'accès ou de l'utilisation de ce document ou de son contenu.

Chaque internaute doit prendre toutes les mesures appropriées (mettre à jour régulièrement son logiciel antivirus, ne pas ouvrir des documents suspects de source douteuse ou non connue) de façon à protéger le contenu de son ordina­teur de la contamination d'éventuels virus circulant sur la Toile.

Toute reproduction interdite Vous reconnaissez et acceptez que tout le contenu de ce document, incluant mais sans s’y limiter, le texte et les images, sont protégés par le droit d’auteur, les marques de commerce, les marques de service, les brevets, les secrets industriels et les autres droits de propriété intellectuelle. Sauf autorisation expresse de RF-232, vous acceptez de ne pas vendre, délivrer une licence, louer, modifier, distribuer, copier, reproduire, transmettre, afficher publiquement, exécuter en public, publier, adapter, éditer ou créer d’oeuvres dérivées de ce document et de son contenu.

Avertissement

Bien que nous utilisions ici un vocabulaire issu des techniques informatiques, nous ne prétendons nullement à la précision technique de tous nos propos dans ce domaine.

¹⁾

FQDN: Dans le DNS, un Fully Qualified Domain Name (FQDN, ou nom de domaine complètement qualifié) est un nom de domaine qui révèle la position absolue d'un nœud dans l'arborescence DNS en indiquant tous les domaines de niveau supérieur jusqu'à la racine. On parle également de domaine absolu, par opposition aux domaines relatifs. Par convention, le FQDN est ponctué par un point final.
Référence: https://fr.wikipedia.org/wiki/Fully_qualified_domain_name.

²⁾

Table de mappe de clavier: n.f. Disposition des touches d'un clavier.
Référence: http://www.granddictionnaire.com/ficheOqlf.aspx?Id_Fiche=18050861#eng.