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.

Monday, March 18, 2019

PKI - migration to Windows Server 2016: Part 5 (the end)

At the end of this previous blog post...

PKI: err_cert_common_name_invalid

I mentioned that even after solving the problem of the invalid certificate common name, another error occurred when I attempted to access the web interface of my issuing certification authority (CA). This second error had to do with a "weak signature algorithm", apparently due to the use of SHA1.

In the meantime, I had practiced a CA migration from an old Windows 2008 R2 server to a new 2016 server. In one of my sources, there was an operation that I thought would also solve the "weak signature algorithm" problem. I executed the command but it failed:



In fact, the operation was meant to convert the the CA key from CSP to KSP. Migrating from CSP to KSP and from SHA1 and SHA256 are often associated (in the article I will cite below, for example) but very separate concepts. I finished my blog series on the 2008 R2 to 2016 CA migration thinking I would have more to do and much to my suprise, I see that my issuing CA uses both preferred standards:




This is the article that outlines the possible upgrade scenarios concerning SHA1 and CSP:

Migrate Windows CA from CSP to KSP and from SHA-1 to SHA-256: Part 1


So I have nothing left to do.

Except when I wanted to see if the use of the new standards would eliminate the "weak signature algorithm" error, I realized that I needed to complete one more task before my 2008 R2 to 2016 migration would be complete. When I attempted to access the web interface to request a certificate, I encountered yet another type of error:






This is because I had not configured the Certification Authority Web Enrollment (CAWE) role service, even though I had installed it.

Note: I have simplified my test network by installing CAWE on the CA itself. I have seen recommendations to install it on a separate server. The reader may want to consider this if implementing a real PKI. 

After installation of a new CA (and assuming, of course, that we are using CAWE), we can only access it locally using this URL:

http://localhost/certsrv

To use https, we have to request, install and then bind a certificate to the default website of the CA. We cannot use the certificate exported from the old CA and imported on the new CA. There are different types of certificates and this type of certificate is for signing other certificates (that is what the CA does: it signs the certificates that it issues). It cannot be used to validate the identity of a website. For this, we need to configure a template for a web server certificate, request it, install it and then bind it to the default website on the issuing CA. If we have the CAWE role service on the CA itself, all these operations are executed on the same server.


First step: publish a certificate template suitable for the web server.

We might do this by duplicating the default "web server" certificate template but since I already did this (in other circumstances), I can simply make the template, that I named "Web Server - Certificate Request", available.

In the Certification Authority console, we highlight the "Certificate Templates" folder and in the menu, select "New" and then "Certificate Template to Issue":





We select the template and click on OK:







Second step: create and submit a certificate request

For the request, we can follow the procedure outlined in the "PKI: err_cert_common_name_invalid" blog post, once again:

PKI: err_cert_common_name_invalid

Note: if we create the request in IIS, we cannot indicate a Subject Alternative Name.


I will not repeat the step by step procedure here but will show the part where we must select a Subject Alternative Name (SAN) to resolve the problem presented in the blog post cited above, since the choices are not evident when one makes such a request, possibly for the first time:



When I was creating the request this time, I forgot to use "Advanced Options" and consequently submitted the request directly to the CA rather than submitting it through the web interface where we can also download it once the request is approved. In fact, there is another method for issuing the certificate in circumstances like this (when the CA administrator is making the request).

Note: this is not necessary if the template does not require approval for certificate issuance. 

First, in the Certification Authority console, we issue the certificate (go to the "Pending Requests" folder and once issued, to the "Issued Certificates" folder) and then open the certificate. On the second tab of the certificate properties ("Details"), we click on "Copy to File" and follow the prompts:




Once again, I will not present each step but will confirm that we can simply use the (checked by default) option "DER encoded binary" option: 



We then open the "Certificates" MMC and "Import" the copied file, navigating to the location where we saved it in the previous step (note that in the screenshot below, I had already imported the certificate: "pki-subca"):



Note: yes, I assume here a certain knowledge of Windows server administration (knowing how to open a management console, etc.) and of PKI in general.

Once the certificate is imported into the (local computer) store, we can bind it to the Default Web Site by highlighting the site and clicking on "Bindings" in the Action pane:



Note: we can also right-click on "Default Web Site" and select the "Edit bindings" option in the menu. 

Configure the binding as shown in the screenshot below:




Now the website is accessible even though I am prompted for credentials (probably because of the authentication methods that may need to be modified - I am using Chrome below, which may not recognize "Windows Authentication":




Once I enter my credentials, I can access the website - without encountering any more error messages: