FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Hier — 17 juin 2021Flux principal

Comment personnaliser le Prompt de son environnement PowerShell ?

17 juin 2021 à 11:00

I. Présentation

Les linuxiens vous le diront, customiser son environnement, le nom de son terminal, son prompt, c'est utile / indispensable (rayer la mention inutile).

Non seulement on s'approprie les outils mis à notre disposition, mais en plus cela nous permet d'afficher des informations utiles et de les garder à l'oeil, de gagner du temps, et le tout en apprenant comment notre terminal fonctionne.

Et vous êtes nombreux à l'ignorer, mais PowerShell vous offre également cette possibilité.

Dans cet article, je vais vous montrer comment personnaliser votre environnement PowerShell, notamment :

  • Comment renommer la fenêtre de son terminal manuellement
  • Comment le faire automatiquement
  • Comment modifier le prompt par défaut (un peu tristounet et austère)
  • Et enfin, je vais vous montrer quelles sont les modifications que j'utilise au quotidien dans mon environnement PowerShell.

Allez, c'est parti !

II. Prérequis

  • PowerShell version 5.1 ou +.

A noter que pour ce tutoriel, j’ai utilisé PowerShell version 7 sur une distribution Ubuntu. Juste pour vous montrer que oui, c'est possible, et que oui PowerShell 7 (ou PowerShell Core) ça fonctionne plutôt (très) bien sous Linux.

III. Modifier le titre de sa fenêtre terminal PowerShell

En PowerShell, pour interagir avec notre terminal, et donc le customiser, il faut passer par la variable $host.

Note : La commande Get-Host fonctionne également, et vous retourne la valeur de $host.

On peut voir que $host contient un certain nombre de propriétés, dont UI à laquelle nous allons nous intéresser maintenant.

PowerShell $host

La propriété UI est en fait un objet de type System.Management.Automation.Internal.Host.InternalHostUserInterface.

On va donc aller voir ce que contient cet objet :

$host.UI

On peut alors voir que $host.UI contient un nouvel objet, dénommé RawUI. On continue donc notre investigation en effectuant :

$host.UI.RawUI

On obtient alors une liste de propriétés liées à notre terminal, dont une plus particulièrement nous intéresse : WindowTitle.

Elle contient actuellement une chaîne de caractères : "PowerShell", qui est actuellement le nom donné à notre fenêtre. Logiquement, si on change cette chaîne de caractères, on change donc le nom du terminal.

Testons ça de suite.

Pour renommer la fenêtre PowerShell, il nous suffit donc de donner une nouvelle valeur à cette propriété WindowTitle, comme ceci :

$host.UI.RawUI.WindowTitle = "Test"

Et voilà le résultat : notre fenêtre est renommée et s'appelle maintenant "Test".

Note : de la même manière, vous pouvez modifier la couleur de la police d’écriture, du fond, la taille de votre fenêtre, et ainsi de suite. N’ayez pas peur d’expérimenter à ce stade. Si vous vous trompez, les changements ne sont pas persistants, il vous suffit donc d'ouvrir un nouveau terminal et de recommencer.

Allons un peu plus loin. Vous vous en doutiez sûrement, mais il est tout à fait possible de passer des variables dans le titre.

Par exemple j’ai créé une variable $t, qui contient la chaîne de caractères suivante : <3

Si je reprends la commande précédente, je vais donc passer la variable dans le nom du titre de cette manière :

$host.UI.RawUI.WindowTitle = "I $t IT-Connect"

Ma fenêtre est donc renommée en "I <3 IT-Connect".

Plutôt pratique pour afficher l’état d’avancement d’une migration dans un terminal ou pour se repérer dans de multiples fenêtres.

Ok, autre exemple.

Que se passe t-il si je tape la commande suivante dans mon terminal ?

$host.UI.RawUI.WindowTitle = "PS >> User: Thibault >> Current DIR: $((Get-Location).Path)"

Et bien la commande (Get-Location).Path va s’exécuter, et le résultat va s’afficher directement dans la fenêtre de mon terminal. Autrement dit ma fenêtre PowerShell va être renommée avec le nom du répertoire dans lequel je me trouve actuellement.

Seul problème, si je change de répertoire cela ne se met pas à jour automatiquement. Et c’est normal, puisque jusqu’à maintenant j’ai exécuté des commandes one shot.

Donc dans la logique actuelle, si je veux mettre à jour le nom de ma fenêtre à chaque fois que je change de répertoire, je dois donc relancer la même commande, encore et encore, après chaque opération.

Vous en conviendrez, ce n'est absolument pas pratique et viable sur le long terme?

Alors comment automatiser ça ? Via une fonction que l’on va enregistrer dans le profil utilisateur.

IV. Création d'un profil utilisateur personnalisé pour PowerShell

Première chose : avant de modifier ce profil, il nous faut déjà savoir où celui-ci est stocké. Pour cela rien de plus simple, il vous suffit d’accéder au contenu de la variable $profile. A une nuance près : il existe plusieurs profils utilisateurs sous PowerShell. Nous allons nous intéresser dans notre cas au profile CurrentUserAllHosts :

$profile.CurrentUserAllHosts

Note : pour tout comprendre sur les différents profils PowerShell, je vous redirige sur cet excellent article de Microsoft, en anglais : https://devblogs.microsoft.com/scripting/understanding-the-six-powershell-profiles/

Dans mon cas, mon fichier de profil PowerShell est stocké à l’endroit suivant :

/home/thibault/.config/powershell/profile.ps1

Pour rappel, j’utilise PowerShell 7 sur une distribution Ubuntu pour ce tutoriel, votre profil sera donc stocké à un autre endroit sur Windows.

Mais surprise, si j’essaye de modifier ce fichier, il n’existe pas. Pourquoi ? Car nous n’utilisons pas de profil PowerShell personnalisé pour le moment.

On va donc commencer par créer ce fichier (chemin à adapter, en particulier sous Windows) et le dossier "powershell" qui le conient :

New-Item -Path /home/thibault/.config/ -ItemType Directory -Name powershell
New-Item -Path /home/thibault/.config/powershell -ItemType File -Name profile.ps1

Créer profil PowerShell personnalisé

Bien ! Maintenant que notre fichier profil est créé, on va l’ouvrir avec notre éditeur préféré. Dans mon cas, j’utilise VsCode, donc logiquement je vais taper la commande suivante :

code /home/thibault/.config/powershell/profile.ps1

On va maintenant pouvoir commencer la personnalisation de notre environnement. Commençons par ajouter la fonction suivante :

$CurrentUser= (Get-ChildItem Env:\USERNAME).Value
function Prompt {
$host.UI.RawUI.WindowTitle = "PS >> User: $CurrentUser >> Current DIR: $((Get-Location).Path)"
Return " "
}

Il nous reste maintenant qu'à fermer notre terminal, puis à le rouvrir pour tester ce que l'on vient de coder. Le profil personnalisé est alors chargé, et notre fonction s’exécutera à chaque fois que l’on effectuera une nouvelle commande PowerShell.

Je me déplace dans le répertoire /Repos, le nom de la fenêtre change :

PowerShell : nom de la fenêtre égal au répertoire courant
PowerShell : nom de la fenêtre égal au répertoire courant

Je change à nouveau de répertoire pour aller dans /home, le nom de la fenêtre change à nouveau :

Bon, par contre vous avez remarqué un énoooorme souci sur les captures d’écran : c’est que le prompt a tout bonnement disparu !

Pourquoi ? Car dans notre fonction Prompt, on n’a strictement rien indiqué sur quoi afficher dans le prompt : celui-ci est donc vide. On va s’atteler à changer ça.

V. Modification du prompt PowerShell

Par défaut, PowerShell affiche PS <répertoire-courant> > en tant que prompt. Dans mon cas, cela donne :

PS /home/thibault >

On va donc rouvrir notre fichier de profil PowerShell, et modifier notre fonction Prompt pour recréer ce prompt par défaut :

code /home/thibault/.config/powershell/profile.ps1

Puis, on va ajouter au début de notre fonction Prompt les 3 lignes suivantes :

Write-Host -NoNewLine "PS "
Write-Host -NoNewLine $((Get-Location).Path)
Write-Host -NoNewLine ">"

Et oui, ça ne fonctionne absolument pas comme Linux où on stocke dans une variable $PS1 le contenu du prompt. Ici, on l’écrit à l’écran, tout simplement.

A noter qu’on utilise ici le paramètre -NoNewLine, qui nous permet de tout écrire sur la même ligne, et donc de générer le prompt. Autrement, chaque itération de Write-Host ferait par défaut un saut à la ligne, ce qui n’est pas vraiment ce qu'on attend d'un prompt.

On sauvegarde alors notre fichier profil, et comme tout à l’heure on lance un nouveau terminal PowerShell pour observer le résultat.

C’est tout de suite mieux !

Allez, un dernier pour la route, on va encore modifier notre prompt, cette fois pour y ajouter :

  • L’heure
  • Le nombre de répertoires / fichiers dans le présent dossier
  • Un peu de couleurs pour égayer tout ça

Ce qui nous donne :

function Prompt {
  Write-Host -NoNewLine "[" -ForegroundColor Yellow
  Write-Host -NoNewLine (Get-Date -Format HH:mm:ss) -ForegroundColor White
  Write-Host -NoNewLine "]" -ForegroundColor Yellow
  Write-Host -NoNewLine $((Get-Location).Path) -ForegroundColor White
  Write-Host -NoNewLine " | " -ForegroundColor Yellow
  Write-Host -NoNewLine (Get-ChildItem -Path (Get-Location)).Count -ForegroundColor White
  Write-Host -NoNewLine " >" -ForegroundColor Red
  $host.UI.RawUI.WindowTitle = "PS >> User: $CurrentUser >> Current DIR: $((Get-Location).Path)"
  Return " "
}

Allez, je vous explique tout ça :

  • (Get-Date -Format HH:mm:ss) nous donne l’heure au format 24 heures (les 2 H majuscules). Si vous formatez la date au format hh:mm:ss, vous obtiendrez l’affichage de l’heure au format 12 heures, version US.
  • $((Get-Location).Path) donne le répertoire actuel de travail, comme on l’a vu précédemment.
  • Enfin, (Get-ChildItem -Path (Get-Location)).Count compte le nombre de sous-dossiers et de fichiers présents dans le répertoire de travail actuel.
  • Le paramètre -ForegroundColor quant à lui permet de modifier la couleur de la police d’écriture.

Note : Si vous souhaitez modifier la couleur de fond, vous utiliserez -BackgroundColor

Voyons ce que ça donne une fois le terminal PowerShell relancé :

Plutôt sympa, non ? Il n’y a plus qu’à laisser parler votre créativité.

VI. Mes préférences persos

De mon côté, j’aime avoir à portée de main des infos utiles, histoire de gagner du temps.

Voici les infos que je juge utile au quotidien, et qui apparaissent dans mon shell PowerShell :

  1. Si j’ai ouvert PowerShell en tant qu’administrateur, la mention Elevated apparaît dans le prompt.
  2. Le nom de l’utilisateur courant. Toujours pratique, notamment quand on jongle entre les utilisateurs.
  3. Le hostname de la machine.
  4. Le répertoire courant. Je n’affiche pas le chemin UNC dans son intégralité, mais juste le nom du répertoire courant.
  5. La branche Git sur laquelle je me trouve, si le répertoire est tracké par Git.
  6. L’ID de la commande par rapport à l’historique
  7. Le temps d’exécution de la dernière commande
  8. Enfin, dans le nom de ma fenêtre, j’affiche le chemin d’accès complet au répertoire courant. Dans quelques cas particuliers, notamment lorsque j’ai plusieurs scripts de migration qui tournent en parallèle, je renomme la fenêtre avec le nom du script, ou son contexte d’exécution. Par exemple : « Migration Floirac ».

Si vous êtes curieux, voici ce que ça donne sous Linux.

Et en utilisant le même profil sur PowerShell 7 sur mon PC Windows, on obtient ceci :

Et ceci côté Windows PowerShell version 5.1 :

Le comportement est légèrement différent sous Windows, car oui dans mon profil je teste si PowerShell tourne sous Linux, MacOS, ou Windows, et mon prompt évolue en fonction de cela.

Pour voir en détail à quoi ressemble ma fonction Prompt dans mon profil PowerShell, rendez-vous sur mon espace Github.

Maintenant c'est à vous de jouer et de laisser parler votre créativité. Un seul mot d'ordre : dites adieu au prompt austère par défaut de PowerShell !

The post Comment personnaliser le Prompt de son environnement PowerShell ? first appeared on IT-Connect.
À partir d’avant-hierFlux principal

Comment imposer des prérequis dans ses scripts PowerShell ?

16 juin 2021 à 13:00

I. Présentation

Vous commencez à avoir une belle collection de scripts PowerShell, mais vous ne savez jamais comment les lancer ? Pour celui-ci, faut-il avoir les droits administrateur ? Faut-il le lancer en tant qu’utilisateur classique ? Doit-on le lancer dans Windows PowerShell version 5.1, ou plutôt dans PowerShell 7 ? Et côté modules, que faut-il installer sur la machine avant de lancer ce script ?

Si vous vous posez ces questions à chaque fois que vous souhaitez lancer un script, alors cet article est pour vous.

Car vous ne le savez peut-être pas, mais il est tout à fait possible d’imposer des prérequis à respecter dans un script PowerShell, sous peine de quoi le script refusera de se lancer, car les prérequis ne sont pas respectés.

Plus besoin d’ouvrir le script dans un éditeur et de le parcourir pour vérifier quels sont les prérequis en fonction des commandes inscrites.

II. Prérequis

  • Windows PowerShell version 5.1 ou PowerShell 7

III. L’instruction Requires en PowerShell

A. Quelques exemples

Certains d’entre vous ont contourné le problème en ajoutant dans un commentaire en début de script que celui-ci doit être lancé en tant qu’administrateur. D’autres font un test en début de script pour vérifier si la session PowerShell est une session de type administrateur ou non.

Mais ces solutions ne sont pas viables : l'une oblige à modifier le script et consulter les commentaires systématiquement avant de le lancer, l'autre est plutôt lourde à coder et en fonction de votre environnement (notamment pour PowerShell Core sur des machines autres que Windows), votre code pourrait ne pas fonctionner.

Il y a pourtant bien plus simple : l’instruction Requires.

Il s’agit d’une instruction très simple, qui demande à PowerShell de vérifier avant toute exécution du script les prérequis listés :

  • La version minimum de PowerShell à utiliser
  • Les modules qui doivent être préalablement installés, ainsi que leur version
  • L’édition de PowerShell (Desktop ou Core) à utiliser
  • Une session PowerShell ouverte en tant qu’administrateur

L’un de ces prérequis n’est pas respecté ? Le script refuse de se lancer. Par exemple, j’ai ici ajouté une instruction demandant à être administrateur, mais j’ai lancé mon script en tant qu’utilisateur.

PowerShell #Requires

Autre exemple : cette fois, j’ai indiqué que le prérequis était de lancer le script sur une édition Desktop. Autrement dit, il ne peut se lancer que sur Windows PowerShell.

Pour le vérifier, j’ai tenté de lancer le script sur PowerShell édition Core (version 7), et sur Windows PowerShell (édition Desktop, version 5.1). Et voici le résultat :

B. Comment ça marche ?

Concrètement, comment ça marche ? Vous allez voir, c’est d’une simplicité enfantine.

Il vous suffit d’ajouter l’instruction #Requires dans votre script, suivi du paramètre choisi.

Si vous avez plusieurs prérequis différents à respecter, par exemple lancer un script en tant qu’administrateur tout en utilisant PowerShell version 5.1 minimum, il vous faudra mettre chaque instruction sur une ligne séparée. Et ... C’est tout !

Vous pouvez glisser cette instruction n’importe où dans votre script, mais je vous conseille pour des raisons de maintenabilité de l’ajouter au début. Avant toute exécution de votre script, PowerShell va chercher si une instruction #Requires est présente, et si c’est le cas, va vérifier que les prérequis sont bien respectés.

Note : Veillez bien à respecter le # avant le Requires. Bien que le dièse est habituellement utilisé pour ajouter des commentaires, cette instruction ne fonctionnera pas sans. Voyez ça comme un commentaire spécial.

IV. Les paramètres de #Requires en PowerShell

Vous pouvez utiliser les paramètres suivants avec l’instruction Requires :

A. -Version

Ce paramètre sert à spécifier la version minimum de PowerShell à respecter afin de pouvoir lancer le script. Vous pouvez indiquer une version majeure (par exemple 5), ou une version mineure, par exemple 5.1.

#Requires -Version 5.1

PowerShell devra être à minima en version 5.1 pour lancer ce script.

#Requires -Version 7

PowerShell devra être à minima en version 7 afin d'exécuter ce script.

B. -PSEdition

Ce paramètre sert à spécifier l'édition de PowerShell à respecter. Pour rappel, si vous utilisez PowerShell en version 5.1, ou via Windows PowerShell (la version préinstallée sur votre OS), vous êtes en édition Desktop. Si vous utilisez PowerShell en version 7, ou sur un Linux / MacOS, vous êtes en version Core.

#Requires -PSEdition Desktop

Impose l'utilisation de Windows PowerShell pour lancer le script.

#Requires -PSEdition Core

Impose l'utilisation de PowerShell en version Core. A privilégier pour les scripts cross-platform.

Note : Vous pouvez coupler ce paramètre avec le paramètre -Version afin d'avoir un contrôle plus fin sur vos prérequis.

C. -RunAsAdministrator

Sans nul doute le paramètre qui vous servira le plus souvent, et qui vous permet d'imposer qu'une session soit lancée en tant qu'administrateur pour que le script s'exécute.

#Requires -RunAsAdministrator

D. -PSSnapin

Ce paramètre sert à préciser les snap-ins requis pour l'exécution du script. Vous pouvez également indiquer, sur la même ligne (et de manière optionnelle) la version du snap-in à utiliser.

#Requires -PSSnapin DiskSnapin -Version 1.2

Note : Pour tout savoir sur les snapins, rendez-vous ici.

E. -Modules

Ce paramètre sert à spécifier les modules devant être installés sur votre machine préalablement avant l'exécution du script. Le module est absent ? Le script refuse de s'exécuter.

Optionnellement, vous pouvez préciser la version minimum, la version exacte ou la version maximum à utiliser pour ce module. Petite précision d'importance : vous ne pouvez utiliser qu'un seul de ces paramètres à la fois, à vous donc de choisir celui qui se rapproche le plus de ce que vous souhaitez faire.

Voici quelques exemples :

#Requires -Modules ActiveDirectory

➡ Le module ActiveDirectory doit être installé.

#Requires -Modules ActiveDirectory, AzureAD

➡ Les modules ActiveDirectory & AzureAD doivent être préalablement installés.

#Requires -Modules @{ModuleName= "AzureRM.Netcore" ; ModuleVersion= "0.12.0"}

➡ Le module AzureRM.Netcore doit être présent minimum en version 0.12.0.

#Requires -Modules @{ModuleName= "AzureRM.Netcore" ; RequiredVersion= "0.12.0"}

➡ Le module AzureRM.Netcore doit être présent exactement en version 0.12.0.

#Requires -Modules @{ModuleName= "AzureRM.Netcore" ; MaximumVersion= "0.12.0"}

➡ Le module AzureRM.Netcore doit être présent et au maximum en version 0.12.0.

Note : Si l'on souhaite préciser la version du module à utiliser, on passe cette information en plus du nom dans une hashtable : la notation @{}

Vous l’aurez compris, plus besoin de vous lancer dans des tests compliqués en début de script pour vérifier les modules installés ou non, si la session est une session administrateur, etc.

Avec l’instruction Requires, vous allez littéralement vous simplifier la vie !

The post Comment imposer des prérequis dans ses scripts PowerShell ? first appeared on IT-Connect.

Linux : comment renommer son terminal ?

9 juin 2021 à 13:00

I. Présentation

Je ne sais pas vous, mais perso j’ai souvent plusieurs terminaux d’ouverts, chacun avec sa propre thématique : bash, zsh, tutoriel en cours, PowerShell (oui, je sais, PowerShell sous Linux, allez-y, huez-moi :D).

Et question d’organisation, j’aime bien que chacun porte un nom évocateur. C’est simple, on ne cherche pas 3 heures la bonne fenêtre : on sait d'un coup d’œil où on se trouve.

Sauf que voilà : l’application terminal par défaut d’Ubuntu Gnome ne le permet pas / plus. On peut customiser son arrière-plan, même mettre un GIF animé (la classe!), mais renommer sa fenêtre ? Non pas possible.

Et comme je refuse de m’avouer vaincu, laissez-moi vous donner ma petite astuce pour résoudre ça. Vous l'aurez compris, dans ce tutoriel, je vais répondre à la question suivante : comment renommer son terminal sous Linux ?

II. Prérequis

  • Terminal bash (Distribution Linux ou WSL)

 

III. Utiliser le terminal Mate

La première option serait de changer de terminal. On peut installer Terminal Mate sous Ubuntu, qui permet nativement de renommer sa fenêtre.

Pour l’installer :

sudo apt install mate-terminal -y

Note : Le -y vous permet d'éviter de donner votre confirmation avant installation des paquets.

Comme vous pouvez le constater, c’est on ne peut plus simple : Cliquez sur le menu Terminal, puis sur Modifier le titre. Et ça marche !

Je ne comprends d'ailleurs toujours pas pourquoi sur Gnome cette fonctionnalité pourtant bien pratique (indispensable même) a tout bonnement disparu du terminal. Si quelqu’un a une explication, je suis preneur.

Maintenant, laissez-moi vous avouer quelque chose : j’adore utiliser mon terminal avec une petite touche de transparence. C’est pratique quand vous passez votre temps à switcher entre la doc et le terminal sur le laptop, et puis ça peut impressionner vos voisins dans le train :D.

Et le truc, c’est que je n’ai jamais réussi à faire fonctionner correctement la transparence correctement avec le terminal Mate : c’est soirée disco, ça clignote de partout, ça pique les yeux et surtout c'est inutilisable. Et ça, ce n'est juste pas envisageable.

Je suis donc revenu à mon terminal Gnome par défaut, et la problématique reste entière. Du coup, je me suis orienté vers la seconde solution : créer une fonction custom dans mon profil bash.

IV. Fonction custom pour changer le nom du terminal

J’ai donc créé une fonction de quelques lignes qui me permet de changer facilement et rapidement le nom de mon terminal. Et pour que cela soit persistant, j’ai ajouté cette fonction dans mon profil utilisateur. Comment ?

En modifiant le fichier /home/<user>/.bashrc :

vim ~/.bashrc

Puis j'ai ajouté dans ce fichier les lignes suivantes pour créer la fonction set-title :

#  Fonction pour changer le titre de la fenêtre terminal
function set-title() {
  if [[ -z "$ORIG" ]]; then
  ORIG=$PS1
  fi
  TITLE="\[\e]2;$*\a\]"
  PS1=${ORIG}${TITLE}
}

Testons ça dans un nouveau terminal, en tapant set-title, suivi d’une chaîne de caractère :

set-title Coucou
set-title Ceci est un super titre

Comme vous pouvez le voir, non seulement ça fonctionne, mais en plus ça prend en compte les espaces :

Maintenant un peu d’explication :

  • La variable $PS1 est une variable d’environnement et correspond à votre environnement bash sous Linux.
  • $* correspond à l’ensemble des arguments saisis. Autrement dit, via $* on capture tout ce qui est saisi après l'appel de notre fonction, donc après set-title.

Bien. Si on déroule notre fonction étape par étape, voici ce que ça donne :

  • On commence par récupérer le contenu de la variable $PS1 et on le stocke dans $ORIG, au cas où.
  • On crée ensuite une nouvelle variable $TITLE avec les entrées saisies au clavier (tout ce qu'il y a après le set-title), puis on réécrit le contenu de $PS1, en y injectant $ORIG (le prompt actuel donc), + $TITLE (le nom de la fenêtre).

Et là vous me demandez pourquoi ça marche. Comment ça se fait que la magie opère ?

Regardons plus en détail la variable TITLE, que l’on pourrait décomposer en trois sections :

  • [\e]2;
  • $*
  • \a

On a déjà vu ce que faisait le $*. Quand aux deux autres sections, elles sont interprétées par le driver du terminal. En voyant le code [\e]2; passer, votre terminal sait qu’il va ajouter tout ce qu’il y a entre ça et le \a dans le titre du terminal.

Plutôt sympa, non ?

V. Conclusion

En l'état, il vous faudra exécuter cette fonction à chaque fois que vous souhaiterez changer le nom du terminal, la modification ne s'effectue pas automatiquement.

On verra d'ailleurs dans un futur article comment faire pour mettre à jour automatiquement le titre du terminal, par exemple pour afficher le nom du répertoire courant.

N'hésitez pas à me dire en commentaires si vous souhaitez voir d'autres customisations de l'environnement bash.

The post Linux : comment renommer son terminal ? first appeared on IT-Connect.

Créer un lien symbolique sous PowerShell

3 juin 2021 à 10:30

I. Présentation

Dans ce tutoriel, nous allons apprendre à créer un lien symbolique avec PowerShell, sur une machine Windows.

Chez les linuxiens, cela se gère par la commande ln -s. Mais il n'existe pas une commande dédiée en PowerShell, c'est un peu plus subtil que ça... Mais en même temps logique.

Vous allez voir 😉

Il faut savoir qu'il existe la commande native "mklink" qui permet de créer un lien symbolique sous Windows. Néanmoins, nous ne sommes pas à l'abri que cette commande historique disparaisse : il est préférable de savoir le faire avec Powershell.

II. Prérequis

  • Windows PowerShell version 5.1, ou PowerShell Core version 7+

III. À quoi ça sert un lien symbolique ?

Qu'est-ce que c'est que cette bête-là ? Et puis d'abord à quoi ça sert ?

Un lien symbolique, c'est un peu comme un raccourci sur votre bureau. Il s'agit d'un fichier un peu spécial qui pointe vers un autre fichier.

Concrètement, le fichier "lien symbolique" ne contient aucune donnée du fichier cible.

À noter que je parle de fichiers depuis tout à l'heure, mais on peut faire un lien symbolique aussi bien vers un répertoire qu'un fichier, que ceux-ci soient locaux à notre machine, ou accessibles à distance, sur un partage DFS par exemple.

Vous souhaitez un exemple concret d'utilisation ?

Ok, c'est parti 🙂

Sur mon PC Windows, j'utilise aussi bien Windows PowerShell (version 5.1) que PowerShell Core (version 7).

Il s'agit bien de deux versions de PowerShell différente et à ce titre, les fichiers de profils personnalisés sont différents.

Sauf que personnellement, je n'ai pas envie de gérer deux fichiers sur mon système : 1 seul profil est bien suffisant.

Du coup, j'ai stocké mon fichier profile.ps1 dans un répertoire sur ma machine, puis j'ai créé deux liens symboliques (1 pour Windows PowerShell, et 1 pour PowerShell 7) afin de pointer sur le même fichier.

Toujours dans la même logique, si je veux avoir le même environnement customisé sur les serveurs distants sur lesquels je me connecte, je peux créer un lien symbolique vers le dossier partagé sur lequel j'ai stocké ce profil, par exemple.

Un autre cas d'utilisation...

Dernier cas d'utilisation assez courant, si vous trackez vos fichiers de configuration via Git, vous pouvez mettre tous vos fichiers de configuration applicatifs dans un seul répertoire, par exemple Repos\Config.

Il vous reste ensuite pour chaque application à créer les liens symboliques pointant vers les fichiers de configuration stockés dans ce répertoire.

Plutôt pratique, pour deux raisons :

  1. Vous ne suivez qu'un dépôt Git. Vous appliquez ainsi le principe du Keep it easy.
  2. Vos liens symboliques pointant vers le dépôt Git, dès que vous mettrez celui-ci à jour, vos applications prendront immédiatement en compte les nouveaux fichiers de configuration. Plus d'opération de copier/coller manuelle à prévoir.

 

IV. Créer un lien symbolique sous PowerShell

Reprenons le cas concret du profil PowerShell. Pour savoir où ce profil est stocké, tapez la commande :

$profile.CurrentUserAllHosts

Dans mon cas, ayant lancé cette commande sous PowerShell 7, mon fichier profil est stocké à cet endroit :

C:\Users\Thibault\Documents\PowerShell\profile.ps1

Je me déplace donc dans mon dossier C:\Users\Thibault\Documents\, puis je vais vérifier si le dossier PowerShell existe :

Test-Path ./PowerShell

La réponse étant false, je vais créer ce dossier, ce qui me permettra par la suite de créer mon lien symbolique :

New-Item -ItemType Directory -Name PowerShell

Mais plutôt que de créer un fichier classique profile.ps1, nous allons cette fois créer le fameux lien symbolique, pointant sur le "vrai" fichier de configuration profile.ps1, stocké dans mon dépôt Git.

Comment ? Également via la commande New-Item. Et oui ! Cette même commande que l'on utilise pour créer nouveaux répertoires et nouveaux fichiers.

Note : Il vous faudra les droits d'administration pour créer un nouveau lien symbolique.

On va donc réutiliser la commande New-ItemType en indiquant cette fois comme ItemType un SymbolicLink :

New-Item -ItemType SymbolicLink -Path .\PowerShell\profile.ps1 -Target E:\Repos\config\PowerShell\profile.ps1
  • Le paramètre -Path indique ici le nom du lien symbolique à créer. PowerShell attendant un fichier nommé profile.ps1 pour contenir mon environnement custom, je vais donc nommer comme cela mon lien symbolique.
  • Le paramètre -Target indique le fichier cible sur lequel mon lien symbolique va pointer.

 

Si on vérifie le contenu du dossier PowerShell, on va effectivement voir un nouveau lien symbolique, qui va s'afficher de la manière suivante : <nom-du-lien-symbolique> -> <cible>

Lien symbolique PowerShell
Exemple d'un lien symbolique créé avec PowerShell

Et voilà, votre lien symbolique est créé.

Si vous ne me croyez pas, allez-y, il vous suffit de modifier le fichier cible pour que la modification soit prise en compte par votre application.

Fini les repository Git multipliés à outrance, vous pourrez maintenant centraliser tous vos fichiers de configuration sur un seul et même répertoire.

Elle n’est pas belle la vie ?

The post Créer un lien symbolique sous PowerShell first appeared on IT-Connect.

Docker : résoudre l’erreur permission denied while connect to daemon socket

2 juin 2021 à 10:30

I. Présentation

J’ai récemment réinstallé mon laptop avec la dernière version d’Ubuntu, et après avoir réinstallé mes outils fétiches, je souhaitais tester rapidement un nouveau container qui me faisait de l'œil via docker. Je lance donc le classique « docker run container:latest », et là : c'est le drame...

Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.40/containers/json: dial unix /var/run/docker.sock: connect: permission denied

Bim ! Erreur dans ta face.

Il me semblait pourtant avoir tout bien fait lors de la réinstallation de docker. Mais apparemment non : j'ai dû louper quelque chose. C'est parti donc pour une séance d'investigation.

Et si vous ne faites pas attention lors de l’installation, ou si vous mettez à jour vos packages régulièrement, il y a des chances que ça vous arrive à vous aussi.

Laissez-moi vous expliquer comment régler ça.

II. Prérequis

  • Une distribution Linux d’installé ou dispo sous WSL (le fameux sous-système Linux pour Windows). Personnellement, j'utilise Ubuntu 20.04 pour ce tuto.
  • Docker installé

 

III. Un problème de droits… Manifestement

Revenons à notre erreur, plutôt explicite : il me manquerait des droits pour accéder à docker lorsque j’exécute une commande telle que docker pull ou docker run.

Alors, par où commencer ?

Et bien, lorsqu'il s'installe, docker est censé créer un groupe « docker » sur votre système Linux. Commencez par vérifier que ce groupe est bien présent :

cat /etc/group

On peut voir ici que non seulement le groupe docker est présent, mais qu'il contient également un utilisateur : thibault.

Pour vous en convaincre, j'ai créé un nouvel utilisateur "test", et l'ai ajouté au groupe docker.

Si je relance ma commande cat, on voit maintenant que mon groupe docker contient deux utilisateurs : thibault et test.

Si votre utilisateur n'est pas un membre du groupe, ajoutez-le sans attendre via la commande :

sudo usermod -aG docker <user>

Car oui, vous voulez être dans ce groupe, afin de pouvoir lancer sans sudo les commandes docker.

On va ensuite vérifier votre dossier .docker dans votre home directory, qui contient les paramètres docker, et notamment vos custom settings.

S’il est présent, vous allez le supprimer.

NOTE : pas de panique, votre dossier .docker va se recréer automatiquement. Vous perdrez cependant vos custom settings si vous en aviez : pensez donc à faire une copie de ce dossier afin de les conserver.

Bien, maintenant que ce dossier est supprimé, nous allons tester à nouveau de lancer un container, par exemple en effectuant :

docker run hello-world

Pour l'explication, on demande ici à docker de lancer un container qui s'appelle hello-world. Si l'image n'est pas présente sur notre machine, docker va alors télécharger l'image à partir du repository Docker hub.

Qu'est-ce que ce container hello-world ? Il s'agit d'un container minimaliste qui ne va faire qu'une seule chose : se démarrer et écrire "Hello world" dans votre terminal. Rien de plus. Mais c'est pratique pour tester le bon fonctionnement de docker.

Si à la suite de cette opération vous rencontrez l’erreur suivante, c’est presque fini.

WARNING: Error loading config file: /home/user/.docker/config.json -stat /home/user/.docker/config.json: permission denied

Il vous suffit alors de taper les commandes suivantes pour modifier les droits d’accès et le propriétaire du dossier .docker, et le tour est joué :

sudo chown "$USER":"$USER" /home/"$USER"/.docker -R

sudo chmod g+rwx "$HOME/.docker" -R

Malgré cela, votre docker est toujours récalcitrant ?

Redémarrez-le en effectuant un :

sudo systemctl restart docker

Enfin, si malgré ces opérations docker ne veut toujours rien savoir, il reste une dernière étape : changer les droits du fichier /var/run/docker.sock :

sudo chmod 666 /var/run/docker.sock

Redémarrez à nouveau docker, et profitez enfin de ce container magique qu'est hello-world :

docker run hello-world

Votre docker est maintenant fonctionnel, et vous devriez obtenir le résultat suivant :

Et voilà, investigation clôturée, coupable appréhendé.

Il ne vous reste plus qu'à tester vos containers préférés sous docker.

The post Docker : résoudre l’erreur permission denied while connect to daemon socket first appeared on IT-Connect.

Comment manipuler une API en PowerShell ?

31 mai 2021 à 13:00

I. Présentation

Aujourd'hui, les API pullulent littéralement sur Internet. Vous en utilisez même parfois sans vous en rendre compte. Les applications web modernes sont découpées en microservices autonomes, plus simples à développer et maintenir. Et devinez comment ces microservices dialoguent entre eux ?

Bingo ! Via les API.

C'est d'ailleurs ce qui permet à des outils tels que Zapier ou Integromat de coupler des applications entre elles.

Dans cet article, nous allons nous concentrer sur une API simple, afin de voir comment manipuler les appels aux API, et la gestion des données en retour en PowerShell.

Et pour ça, j'ai sélectionné l'API du site motdepasse.xyz, qui vous permet de générer des mots de passe en blocs, selon vos critères de complexité. Prêt à manipuler une API avec PowerShell ? Alors allons-y...

II. Prérequis

Pour suivre cet article, vous pourrez aussi bien utiliser PowerShell 5.1 (Windows PowerShell, également appelée version Desktop), ou alors PowerShell version 7 (également appelé PowerShell Core).

III. Comment fonctionne l'API de motdepasse.xyz ?

L'API de motdepasse.xyz accepte un certain nombre de paramètres dans l'URI à envoyer, que voici :

Je vous laisse consulter la documentation de l'API pour savoir à quoi correspondent plus en détail ces paramètres.

Concrètement, on appelle l'API via l'URL suivante :

https://api.motdepasse.xyz/create/?

On passe ensuite après le ? les paramètres choisis, ce qui peut par exemple donner :

https://api.motdepasse.xyz/create/?include_lowercase&password_length=12&quantity=1

 

IV. Appeler l'API en PowerShell

Comme on vient de le voir, pour dialoguer avec une API, il est nécessaire de passer un certain nombre de paramètres dans l'URL envoyée au serveur web.

Pour cela, on utilise en PowerShell Invoke-RestMethod, qui est un équivalent de Curl sous Linux.

Comme il n'y a rien de mieux qu'une démonstration par l'exemple, on va contacter l'API de motdepasse.xyz pour lui demander :

  • De générer 1 mot de passe de 12 caractères, uniquement avec des minuscules
  • De générer 3 mots de passe de 12 caractères chacun, contenant minuscules et chiffres
Invoke-RestMethod -Uri "https://api.motdepasse.xyz/create/?include_lowercase&password_length=12&quantity=1"

Invoke-RestMethod -Uri "https://api.motdepasse.xyz/create/?include_lowercase&include_digits&password_length=12&quantity=3"

Le serveur web nous renvoie les informations demandées au format JSON. Heureusement pour nous, PowerShell est suffisamment intelligent pour transformer cette réponse en objet, facilement manipulable.

On peut voir sur la capture d'écran que l'API nous renvoie :

  • Les mots de passe générés sous forme de tableau
  • La date et l'heure à laquelle la réponse est envoyée
  • La version actuelle de l'API
  • La dernière date de modification de cette API

PowerShell Invoke-RestMethod

Afin d'exploiter plus facilement les données envoyées, on va stocker le retour de l'API dans une variable, puis on va afficher uniquement le contenu de la propriété passwords de cette variable :

$var = Invoke-RestMethod -Uri "https://api.motdepasse.xyz/create/?include_lowercase&password_length=12&quantity=2"

$var.passwords
Note : Vous pouvez bien sûr naviguer dans les différents mots de passe générés comme dans un tableau classique PowerShell. Le premier mot de passe est accessible via $var.passwords[0], le second via $var.passwords[1], etc...

A ce stade, vous êtes déjà en capacité de générer vous-même et à la demande de nouveaux mots de passe utilisateurs. Mais en fonction des besoins (caractères spéciaux ou non, chiffres, majuscules, etc) vous êtes obligés de modifier manuellement l'URL avant d'envoyer votre appel API.

Pas terrible pour intégrer ça tel quel dans un script. Non ?

V. Fonction PowerShell avancée

Je ne sais pas vous, mais moi j'adore automatiser tout ce qu'il est possible d'automatiser. Et dans notre cas, j'ai cherché à voir comment automatiser la génération de l'URL envoyée à l'API en fonction des besoins.

J'ai codé une fonction qui permet de faire tout ça : vous lui passez en paramètre ce que vous attendez, l'URL est générée, l'API est contactée, et PAF! ça fait des chocapics.

Voyez plutôt :

PowerShell API

On va détailler tout ça ensemble, et comme d'habitude vous pourrez retrouver ce script sur mon espace Github.

A. Déclaration de la fonction

Premièrement, on déclare la fonction, comme d'habitude en respectant les verbes autorisés officiellement pour nommer la fonction.

On déclare également 5 paramètres, qui vous permettront en fonction de ce que vous choisissez de personnaliser l'appel à l'API :

  • Length : la taille du mot de passe. C'est obligatoire. Sinon comment l'API pourrait vous générer un mot de passe ? 😉
  • Quantity : Si vous ne précisez pas de quantité, la fonction demandera à l'API de générer un seul et unique mot de passe.
  • Digits, Uppercase, et SpecialCharacters sont déclarés comme des switchs et ne sont pas obligatoires. Par défaut donc, le mot de passe généré contiendra uniquement des minuscules.

Note : un paramètre de type switch fonctionne presque comme un booléen. Vous appelez la fonction avec -Digits, le switch a donc la valeur $true, et mon code derrière en tiendra compte. Vous ne mettez pas le paramètre, cela sera considéré comme un $false.

Pour le moment, voici notre fonction :

Function Invoke-ApiMotdepassexyz {
    [CmdletBinding()]
    Param (
        [Parameter(Mandatory=$true)][int]$Length,
        [Parameter(Mandatory=$false)][int]$Quantity=1,
        [Parameter(Mandatory=$false)][switch]$Digits,
        [Parameter(Mandatory=$false)][switch]$Uppercase,
        [Parameter(Mandatory=$false)][switch]$SpecialCharacters
    )

B. Construction de l'URI

On va maintenant construire l'URI à envoyer à l'API en fonction des paramètres que l'on passe ou non lorsqu'on appelle notre fonction.

On vérifie tout d'abord que la longueur demandée est comprise entre 4 et 512 caractères, et que le nombre de mots de passe à générer est compris entre 1 et 30, afin de se conformer à la documentation API.

On construit ensuite l'URI en fonction des différents paramètres.

Begin {
        #Building Uri
        if (!(($Length -ge 4) -and ($Length -le 512))) {
            Write-Error "Password length should be between 4 and 512 characters"
            break
        }
        if (!(($Quantity -ge 1) -and ($Quantity -le 30))) {
            Write-Error "Quantity should be between 1 and 30 passwords to generate."
            break
        }
        $Uri = "https://api.motdepasse.xyz/create/?include_lowercase&password_length=$Length&quantity=$Quantity"
            if ($Digits) {
                $Uri += "&include_digits"
            }
            if ($Uppercase) {
                $Uri += "&include_uppercase"
            }
            if ($SpecialCharacters) {
                $Uri += "&include_special_characters"
            }
        $Passwords = @()
    }

Pour générer un mot de passe de 12 caractères, comprenant minuscules, chiffres et caractères spéciaux, cela nous donnera donc l'URI suivante: https://api.motdepasse.xyz/create/?include_lowercase&password_length=12&quantity=1&include_special_characters&include_digits

C. Appel API + Récupération du résultat

Dans le bloc Process{}, on appelle notre API en lui envoyant l'URI précédemment construite, et on catche toute exception qui pourrait se passer afin de la logguer dans la console PowerShell.

Enfin, dans le bloc End{}, on ne garde que les mots de passe générés, que l'on insère dans un tableau, avant de le renvoyer pour qu'il puisse être utilisé ultérieurement dans un script.

Process {
        Try {
            $ApiResult = Invoke-RestMethod -Uri $Uri
        }
        Catch {
            Write-Outut $_.Exception
            Break
        }
    }
    End {
        For($i=0;$i -lt $Length;$i++) {
            $Passwords += $ApiResult.passwords[$i]
        }
        Return $Passwords
    }

 

D. Fonction complète

Il ne vous reste plus qu'à appeler la fonction dans un script, par exemple de la manière suivante :

$array= Invoke-ApiMotdepassexyz -Length 15 -Quantity 5 -Digits -SpecialCharacters -Uppercase

Vous demandez donc à générer 5 mots de passe de 15 caractères chacun, contenant minuscules, majuscules, chiffres et caractères spéciaux.

Ces mots de passe sont générés puis stockés dans un tableau nommé $array, que vous pourrez réutiliser à votre guise.

Voici la fonction complète :

Function Invoke-ApiMotdepassexyz {
    [CmdletBinding()]
    Param (
        [Parameter(Mandatory=$true)][int]$Length,
        [Parameter(Mandatory=$false)][int]$Quantity=1,
        [Parameter(Mandatory=$false)][switch]$Digits,
        [Parameter(Mandatory=$false)][switch]$Uppercase,
        [Parameter(Mandatory=$false)][switch]$SpecialCharacters
    )
    Begin {
        #Building Uri
        if (!(($Length -ge 4) -and ($Length -le 512))) {
            Write-Error "Password length should be between 4 and 512 characters"
            break
        }
        if (!(($Quantity -ge 1) -and ($Quantity -le 30))) {
            Write-Error "Quantity should be between 1 and 30 passwords to generate."
            break
        }
        $Uri = "https://api.motdepasse.xyz/create/?include_lowercase&password_length=$Length&quantity=$Quantity"
            if ($Digits) {
                $Uri += "&include_digits"
            }
            if ($Uppercase) {
                $Uri += "&include_uppercase"
            }
            if ($SpecialCharacters) {
                $Uri += "&include_special_characters"
            }
        $Passwords = @()
    }
    Process {
        Try {
            $ApiResult = Invoke-RestMethod -Uri $Uri
        }
        Catch {
            Write-Outut $_.Exception
            Break
        }
    }
    End {
        For($i=0;$i -lt $Length;$i++) {
            $Passwords += $ApiResult.passwords[$i]
        }
        Return $Passwords
    }
}

VI. Conclusion

Vous savez maintenant manipuler des APIs simples via PowerShell, et en prime vous avez découvert comment générer de manière automatique de nouveaux mots de passe pour vos utilisateurs.

Elle n’est pas belle la vie ? 😉

➡ Si vous souhaitez générer des mots de passe complexes en PowerShell sans utiliser un API, lisez cet article : comment générer des mots de passe avec PowerShell ?

The post Comment manipuler une API en PowerShell ? first appeared on IT-Connect.

Quelle convention de nommage utiliser pour ses serveurs ?

27 mai 2021 à 10:45

I. Présentation

Établir une convention de nommage afin de donner un petit nom à chacun de ses serveurs, c’est à la fois très simple à expliquer et compliquer à maîtriser.

Tout le monde comprend l’intérêt de nommer des serveurs plutôt que de retenir leur adresse IP. C’est d’ailleurs le principe de la technologie DNS, qui est au cœur d’Internet.

Mais à vouloir être trop créatif ou à vouloir mettre trop d’informations, on peut très vite s’y perdre, et la gestion de nos serveurs peut vite ressembler à un casse-tête.

Du coup, je vous vois venir, vous allez me demander comment faire pour choisir une convention pratique, facile et efficace afin de nommer vos serveurs.

Parce que soyons honnête deux minutes, avoir un serveur qui s’appelle Astérix ou SRVWEB112, c’est bien, mais quand on se pose pour la huitième fois de la journée la question du rôle précis de ce serveur (production ? test ? développement ? Et hébergement de quelle application web au juste ?), c’est qu’il est temps de faire quelque chose. 😉

II. Les serveurs ne sont plus ce qu’ils étaient

À une époque pas si lointaine que ça, les serveurs étaient physiques. On pouvait les toucher, les aligner physiquement sur des étagères dans nos salles serveurs.

C’était quelque chose de concret. Et puis la virtualisation et le cloud sont arrivés, et le monde a changé.

Mais à l’époque, lorsqu’on achetait un nouveau serveur, c’était une machine physique qui allait occuper de la place dans notre salle serveur. Ça n’arrivait pas tous les jours. Et on gardait nos serveurs parfois pendant 10 ans.

Ça a changé depuis maintenant plusieurs années. Avec l’avènement du cloud et de la virtualisation (et maintenant des containers), on peut littéralement créer de nouveaux serveurs en moins de 60 secondes, et ce de manière entièrement automatisée.

On est passé de la gestion d’une dizaine de serveurs physiques à la gestion de centaines de serveurs et containers virtuels.

Là où on configurait notre système d’information dans la durée, on monte maintenant parfois des serveurs pour quelques minutes ou heures afin de tester une application.

Et notre manière de les nommer doit évoluer afin de s’adapter à cette nouvelle réalité.

III. L’art de nommer ses serveurs

Le nom d’un serveur est un choix des plus importants pour un sysadmin, d’autant plus qu’il l’utilisera derrière au quotidien.

Sondez votre entourage si vous ne me croyez pas : si vous trouvez quelqu’un qui utilise les IPv4 et les IPv6 au lieu des hostname des serveurs, je veux bien manger ma casquette. 😊

Trêve de plaisanterie, chacun y va de sa manière pour nommer ses serveurs. Il n’y a pas de bonne ou de mauvaise manière de nommer un serveur, à partir du moment où vous êtes capables de retrouver vos petits sans vous plonger dans une documentation de 500 pages.

Voici un tour d’horizon des conventions de nommage les plus répandues. Personnellement, je suis un adepte de la méthode du berger.

A. Laisser parler sa créativité

Si vous aimez les noms de serveurs évocateurs, vous êtes servi, et c’est probablement la méthode à privilégier.

Je me souviens d’entreprises et de sysadmin qui avaient choisi des conventions de nommage originales :

  • Chaque serveur portait le nom d’un personnage du Seigneur des anneaux : Gandalf pour le serveur de fichiers par exemple.
  • Les serveurs Linux avaient tous un nom se terminant en -us : Sinus, Cosinus, Proximus, etc
  • Noms de serveurs inspirés des héros et dieux de la mythologie grecque, romaine, etc.

Le souci, c’est que dès que vous multipliez les serveurs, ça devient compliqué de se souvenir du rôle d’Astérix par rapport à Hercule. Du coup, ça vous oblige régulièrement à consulter votre documentation pour vous rappeler exactement de qui fait quoi.

Par contre l’avantage, c’est qu’un attaquant ne peut pas déduire le rôle d'un serveur à partir de son nom.

Personnellement, je ne vous conseille pas d’utiliser cette méthode, car vous pouvez vite vous mélanger les pinceaux, mais après tout, un nom de héros est toujours plus évocateur qu’un classique SRVFIC01.

B. La méthode itérative

Lorsqu’on a commencé à multiplier les serveurs (un rôle = un serveur virtuel), on a essayé d’attribuer des noms plus évocateurs à nos serveurs.

Sont donc apparus les SRVAD01, SRVFIC03, SRVWEB112, etc.

Le nom est certes évocateur et vous permet d’identifier rapidement qui fait quoi, mais si je vous demande quelle est la différence entre SRVWEB87 et SRVWEB112, vous allez bien vous creuser les méninges.

Ok, ce sont deux serveurs web. Mais tournent-ils sous Windows / IIS ? sous Linux / Apache ? Et pour quelle application ? Mystère...

Autre problème que cette méthode amène : Vous migrez SRVFIC01 et SRVFIC02 sur 2 nouveaux serveurs : SRVFIC03 et SRVFIC04. Puis vous supprimez les deux premiers, car ils sont vieillissants.

Pour un petit parc d’une cinquantaine de serveurs, c’est assez simple à suivre, mais pour un parc de serveurs conséquent, vous vous demanderez toujours s’il existe 4 serveurs de fichiers, ou seulement 2. Et si vous devez en ajouter un nouveau, faut-il l'appeler SRVFIC05, ou peut-on réutiliser SRVFIC01 ? À première vue si le serveur n'existe plus, on est tenté de dire que c'est OK. Mais peut-être y a-t-il des redirections DNS de SRVFIC01 vers SRVFIC03.

Bref, c'est mieux que la méthode précédente, mais je ne pense pas que cela soit viable sur le long terme, ou dans le cas d'une infrastructure multi cloud scalable.

C. La méthode préfixe - suffixe

Un nom du style SRVWEB112 permet de donner une information sur le rôle du serveur. Mais on est toujours dans le flou en ce qui concerne l’environnement du serveur, ainsi que sa localisation.

On utilise donc couramment des préfixes ou des suffixes pour cela. Par exemple :

  • P pour un serveur de Production
  • D pour un serveur de Développement
  • T pour un serveur de Test

On choisit aussi souvent un préfixe de 3 lettres pour indiquer la localisation du serveur : utile lorsque nos serveurs sont éparpillés sur plusieurs sites ou datacenters. Par exemple, on pourrait choisir PAR pour indiquer que le serveur est hébergé à Paris, ou BDX pour indiquer qu’il se trouve à Bordeaux.

PARPSRVWEB04
BDXTSRVFIC02

Cela permet de donner beaucoup d’informations dans le nom de votre serveur, ce qui est toujours un plus quand vous devez administrer un gros parc de serveurs, ou par exemple un parc de serveurs multi-clients. Cependant, ça implique d’avoir un document décrivant avec exactitude les différents sigles utilisés. Et l’inconvénient majeur, c’est bien sûr qu’en cas d’attaque informatique, vous transmettez de précieuses informations à votre attaquant, via le nom du serveur.

Mais personnellement, je pense que le risque en vaut quand même la chandelle.

D. La méthode du berger

Pourquoi la méthode du berger ? Car on va considérer nos serveurs comme on considère un troupeau de moutons.

On a tendance à avoir aujourd’hui de plus en plus de machines, et on démultiplie les environnements : Production, Dev, Test, Préprod, Qualification, etc...

Et contrairement à il y a quelques années, nos serveurs ont pour certains une durée de vie éphémère : parfois de l’ordre de quelques minutes, le temps de tester une nouvelle fonctionnalité avant déploiement en production.

Pour des questions de haute disponibilité, on a aussi aujourd’hui nos serveurs qui sont éparpillés chez différents providers / hébergeurs, ce qu'on appelle le multi cloud : Azure, AWS, GCP, Digital Ocean, Cloud privé, etc, ce qui complexifie la gestion.

Dans ce contexte là, pour savoir où se trouve réellement SRVVWEB112 et quel est son rôle, pas le choix, vous devrez vous taper les 500 pages de documentation interne, en priant pour qu’elle soit à jour.

On a donc une nouvelle méthode de nommage qui a vu le jour : on regroupe ainsi nos serveurs par cluster indépendant, qui correspondent à des applications.

Par exemple, pour faire tourner mon site web, disons que j’ai les serveurs suivants :

  • 2 serveurs web
  • 1 serveur de cache
  • 2 serveurs base de données

Ces serveurs vont donc appartenir au cluster applicatif « webprod ».

Et comme ils sont potentiellement hébergés aux quatre coins du monde, je vais indiquer dans leur hostname leur localisation, ainsi que le nom du provider chez qui ils sont, ce qui nous donnera :

<cluster-applicatif>-<rôle><id>-<localisation-datacenter>-<provider>.<domaine>

Dans notre cas, pour un serveur web hébergé chez AWS dans le datacenter de Paris, cela pourrait donner :

Webprod-web1-par-aws.mondomaine.com

L’avantage de cette méthode, c’est qu’elle est scalable, vous pouvez donc rapidement déployer de nouveaux serveurs pour un nouveau cluster applicatif, sans vous demander s’il s’agit du serveur web 97 ou 113.

Le second avantage que j’y vois, c’est que si vous déplacez un serveur de cluster applicatif, vous faites évoluer nécessairement son nom. Alors certes, ça demande des manipulations supplémentaires, mais vous êtes certain que le nom du serveur reflète bien son rôle actuel.

IV. Comment construire sa convention de nommage

Peu importe la manière de nommer vos serveurs, vous devrez rédiger une convention de nommage, et faire en sorte qu’elle soit partagée et connue de tous dans l’équipe.

Prenons le cas de la méthode du berger. Vous souhaitez passer le plus d’informations possible dans le hostname de votre serveur, et pour éviter les noms à rallonge, vous allez devoir utiliser des sigles.

Votre convention viendra donc expliquer quels sigles choisir.

  • Pour le rôle du serveur, vous pouvez partir sur 2 ou 3 lettres. Par exemple DC pour Domain Controller, DB pour base de données, ou FIC pour serveur de fichiers.
  • Pour la localisation physique du serveur (et donc du datacenter) 2 ou 3 lettres peuvent également correspondre : BDX pour Bordeaux, PAR pour Paris.
  • Si vous souhaitez faire apparaître le cloud provider, utiliser 3 lettres peut également être intéressant : AZU pour Azure, AWS, GCP, DIO pour Digital Ocean, etc
  • L’environnement (production, test, dev, préprod) est également important. Personnellement, je le code sur 1 lettre.
  • Le type de serveur : physique, virtuel, container, etc.
  • Vous pouvez également ajouter le code du pays (US, FR), la localisation de bâtiments

Note : vous pouvez aller encore plus loin et appliquer cette convention de nommage à tout équipement se connectant à votre système d’information : PC, smartphone, système de visioconférence, copieur, imprimante, objets connectés, etc, et identifier chaque type de terminal via un code dans le nom.

V. Conclusion

Nommer ses serveurs est un art, et il n’y a pas de bonne ou de mauvaise manière de faire : il faut trouver ce qui vous convient à vous et à votre équipe.

Personnellement, je fais le choix d’utiliser pour mes nouvelles machines la méthode du berger, afin d’organiser mes serveurs par cluster applicatif. J’y glisse également la localisation physique du serveur, ainsi que le nom du provider chez qui ce serveur se trouve actuellement, et s’il s’agit d’un serveur de production ou non.

Alors oui, ça fait des noms à rallonge, ça fait beaucoup d’informations qui peuvent être visibles dans le cas d’une attaque, mais c’est un gain de temps non négligeable au quotidien.

Quant aux attaques informatiques, que mon serveur s’appelle SRVPRODFIC01 ou Goldorak, si c’est une passoire il se fera trouer à coup sûr.

The post Quelle convention de nommage utiliser pour ses serveurs ? first appeared on IT-Connect.

PowerShell – Comment générer un mot de passe aléatoire ?

20 mai 2021 à 11:00

I. Présentation

Créer des comptes Active Directory pour les nouveaux collaborateurs arrivant dans l’entreprise, c’est l’une des tâches les plus courantes et les plus répétitives qui soit.

C’est d’ailleurs l’une des premières tâches que vous automatisez.

Et la même question revient à chaque fois : comment faire pour automatiser la création d’un mot de passe aléatoire en PowerShell ?

Je vois souvent dans vos scripts deux cas de figure :

  • Le premier : mettre un mot de passe par défaut en « Password1 », à changer à la première connexion
  • Le second : Générer un mot de passe dans une application telle que Keepass ou motdepasse.xyz, puis le copier/coller dans le terminal PowerShell, pour finaliser la création du compte Active Directory.

Et bien, vous allez maintenant pouvoir utiliser un troisième cas de figure : une fonction vous permettant de générer un mot de passe aléatoire conforme à votre politique de sécurité.

🎥 Disponible au format vidéo :

II. Prérequis

Un seul et unique prérequis à respecter :

  • PowerShell version 5.1 ou +

III. La méthode .NET

La première possibilité (et celle qui demande le moins de lignes de code), c’est d’utiliser une méthode existante en .NET.

Pour cela, ajoutez dans votre script les commandes suivantes :

Add-Type -AssemblyName 'System.Web'
[System.Web.Security.Membership]::GeneratePassword($Length, $SpecialCharacters)

Il vous suffit de remplacer la variable $Length par le nombre de caractères à respecter, et la variable $SpecialCharacters par le nombre minimal de caractères spéciaux à respecter.

Par exemple, pour générer un mot de passe de 10 caractères, avec un minimum de 2 caractères non alphanumériques, il vous faut taper :

[System.Web.Security.Membership]::GeneratePassword(10, 2)

Mais cette méthode comprend un inconvénient majeur : vous pouvez vous retrouver avec des mots de passe à plus de 2 caractères spéciaux, certains avec uniquement des minuscules, etc. Ce qui fait qu’on peut se retrouver avec des mots de passe ne respectant pas la politique de mot de passe de l’entreprise, ou alors qui la respecte, mais qui sont tellement difficile à taper pour l’utilisateur que vous allez vous retrouver très rapidement à le changer dans l’Active Directory.

Voici quelques exemples :

IV. Créer sa propre fonction PowerShell

Du coup face à ces deux problématiques majeures, j’ai créé une fonction PowerShell pour générer un nouveau mot de passe aléatoire pour un utilisateur, tout en :

  • Pouvant choisir la taille du mot de passe, le nombre de majuscules à mettre, le nombre de chiffres ainsi que le nombre de caractères spéciaux
  • Respectant la politique de mot de passe de l’entreprise

Copier un code qui fonctionne c’est top, notamment pour vous dépanner d’un coup dur. Mais comprendre ce qu’on a copié, et pourquoi ça fonctionne, c’est mieux. Décomposons donc ensemble la fonction que l'on va créer.

A. Explications

On commence par déclarer notre fonction.

J’ai nommé la fonction New-RandomPassword afin de respecter la convention de nommage en PowerShell, qui est Verbe-Nom.

function New-RandomPassword {
    [CmdletBinding()]
    Param()
    Begin {}
    Process {}
    End {}
}

Bien, on a maintenant un squelette vide, qu’il va falloir remplir.

Commençons par lui indiquer quels sont les paramètres de la fonction. Autrement dit, quelles sont les options que l’on va pouvoir lui passer lorsqu’on y fera appel.

Nous avons besoin de 4 paramètres, afin de pouvoir générer un mot de passe aléatoire qui colle parfaitement à votre politique de sécurité / à vos besoins spécifiques :

  • La taille du mot de passe en nombre de caractères
  • Le nombre de majuscules
  • Le nombre de chiffres
  • Le nombre de caractères spéciaux (non-alphanumériques)

Ces 4 paramètres sont de type [int] : ils n'accepteront qu’un chiffre comme valeur.

On va également considérer que le premier paramètre, la taille du mot de passe, est obligatoire (mandatory). Sans cela, on ne sait pas quelle taille générer, et donc quel mot de passe générer.

Les autres paramètres sont optionnels, et ont tous une valeur par défaut de 1 (que vous pouvez bien sûr changer).

Donc si vous appelez la fonction avec la commande :

New-RandomPassword -Length 10

Vous générez en fait un mot de passe de 10 caractères, contenant 1 majuscule, 1 chiffre, et 1 caractère non-alphanumérique.

Si vous souhaitez faire varier le nombre de majuscules, de chiffres, ou de caractères spéciaux, vous pouvez alors appeler la fonction comme ceci :

New-RandomPassword -Length 10 -Uppercase 2 -Digits 3 -SpecialCharacters 3

Bien. Si l’on traduit donc maintenant cela en PowerShell, voici comment nous allons déclarer nos paramètres :

function New-RandomPassword {
    [CmdletBinding()]
    Param
    (
        [Parameter(Mandatory=$true)][int]$Length,
        [Parameter(Mandatory=$false)][int]$Uppercase=1,
        [Parameter(Mandatory=$false)][int]$Digits=1,
        [Parameter(Mandatory=$false)][int]$SpecialCharacters=1
    )
}

Note : Il n’est pas obligatoire d’écrire (Mandatory=$false) pour déclarer qu’un paramètre est optionnel, mais je le fais systématiquement pour faciliter la lecture.

À l’intérieur de notre fonction, nous avons déclaré au-dessus trois sections :

Begin {}
Process {}
End {}

Ce n’est pas obligatoire non plus, mais on considère cela comme une bonne pratique.

  • La section Begin{} va vous servir généralement à initialiser les variables nécessaires pour votre fonction, ou à vérifier par exemple que les paramètres saisis correspondent bien à ce que vous attendez.
  • La section Process{} contient le cœur de votre fonction : la majorité de votre code se trouvera donc ici.
  • La section End{} contient généralement les retours utilisateurs, si vous voulez renvoyer à l’utilisateur un mot de passe aléatoirement généré par exemple, ou alors les déconnexions bases de données, etc.

Commençons par la section Begin{}.

Maintenant que nous connaissons la taille du mot de passe ($Length), le nombre de majuscules ($Uppercase), le nombre de chiffres ($Digits), ainsi que le nombre de caractères spéciaux ($SpecialCharacters), on peut donc calculer le nombre de minuscules que le mot de passe devra comporter. Ce qui nous donne :

Begin {
        $Lowercase = $Length - $SpecialCharacters - $Uppercase - $Digits
    }

On va également déclarer 3 tableaux, contenant les caractères minuscules, majuscules et spéciaux que l’on souhaite voir apparaître dans le mot de passe.

Begin {
        $Lowercase = $Length - $SpecialCharacters - $Uppercase - $Digits
        $ArrayLowerCharacters = @('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z')
        $ArrayUpperCharacters = @('A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z')
        $ArraySpecialCharacters = @('_','*','$','%','#','?','!','-')
    }

Note : L’avantage de le faire de cette manière est que cela vous laisse toute latitude pour enlever certains caractères, parmi ceux disponibles pour le mot de passe.

Il est maintenant temps de passer à la section Process{} de la fonction, là où la magie opère.

On va créer une nouvelle variable de type [string], $NewPassword, et choisir aléatoirement des lettres minuscules, selon la valeur de $Lowercase. On utilise pour cela la commande Get-Random à laquelle on passe via un pipeline le tableau de lettres minuscules que l’on a précédemment créé : $LowerCharacters.

On répète ensuite cela pour les chiffres, puis les majuscules, puis les caractères spéciaux.

Process {
[string]$NewPassword = $ArrayLowerCharacters | Get-Random -Count $Lowercase
            $NewPassword += 0..9 | Get-Random -Count $Digits
            $NewPassword += $ArrayUpperCharacters | Get-Random -Count $Uppercase
            $NewPassword += $ArraySpecialCharacters | Get-Random -Count $SpecialCharacters
}

Note : 0..9 indique une suite de chiffre continue de 0 à 9. La commande 0..9 | Get-Random -Count $Digits demande donc à PowerShell de choisir aléatoirement X chiffres entre 0 et 9.

Cette méthode a toutefois deux inconvénients :

  • Le premier, c’est qu’entre chaque caractère, on se retrouve avec un espace. Votre mot de passe « Password1 » est donc : « P a s s w o r d 1 ». C’est donc inutilisable en l’état.
  • Le second, c’est que votre mot de passe est actuellement de la forme : abc22ABC%. On a donc choisi aléatoirement des caractères, mais leur placement dans la chaîne de caractères est prévisible : ce n’est pas ce que l’on cherche. Il va donc falloir retravailler cela.

Pour répondre au premier inconvénient, on va utiliser la méthode Replace qui fonctionne très bien pour les chaînes de caractères. Dans notre cas, on cherche à remplacer les espaces par rien, donc à éliminer les espaces.

$NewPassword = $NewPassword.Replace(' ','')

Il nous reste maintenant à traiter le second inconvénient : mélanger de manière aléatoire les caractères que l’on a retenus.

Pour cela, on va transformer la chaîne de caractères en tableau, puis mélanger les caractères entre eux, avant de retransformer le résultat en chaîne de caractères.

$characterArray = $NewPassword.ToCharArray()  
$scrambledStringArray = $characterArray | Get-Random -Count $characterArray.Length     
$NewRandomPassword = -join $scrambledStringArray

Le plus gros est fait, mais si vous vous arrêtez là, votre fonction marche, un mot de passe aléatoire est bien créé, mais à aucun moment vous ne le verrez puisqu’on n’a pas demandé explicitement à la fonction de vous retourner la valeur du mot de passe.

Il nous reste donc à modifier la section End{} pour retourner le mot de passe.

End {
  Return $NewRandomPassword
}

Vous voici maintenant avec une fonction de génération de mot de passe aléatoire, le tout en PowerShell !

Testons enfin notre fonction, en générant un mot de passe de 15 caractères, dont 3 majuscules, 2 chiffres, et 2 caractères spéciaux :

New-RandomPassword -Length 15 -Uppercase 3 -Digits 2 -SpecialCharacters 2

Contrairement à tout à l’heure, on peut voir que les mots de passe ont bien tous 2 caractères spéciaux, et non pas un minimum de 2. Et ça fait toute la différence !

 

B. La fonction en action

Si vous souhaitez tester cette fonction, voici sans plus attendre le code à recopier dans votre script :

function New-RandomPassword {
    [CmdletBinding()]
    Param
    (
        [Parameter(Mandatory=$true)][int]$Length,
        [Parameter(Mandatory=$false)][int]$Uppercase=1,
        [Parameter(Mandatory=$false)][int]$Digits=1,
        [Parameter(Mandatory=$false)][int]$SpecialCharacters=1
    )
    Begin {
        $Lowercase = $Length - $SpecialCharacters - $Uppercase - $Digits
        $ArrayLowerCharacters = @('a','b','c','d','e','f','g','h','i','j','k','l','m','n','o','p','q','r','s','t','u','v','w','x','y','z')
        $ArrayUpperCharacters = @('A','B','C','D','E','F','G','H','I','J','K','L','M','N','O','P','Q','R','S','T','U','V','W','X','Y','Z')
        $ArraySpecialCharacters = @('_','*','$','%','#','?','!','-')
    }
    Process {
            [string]$NewPassword = $ArrayLowerCharacters | Get-Random -Count $Lowercase
            $NewPassword += 0..9 | Get-Random -Count $Digits
            $NewPassword += $ArrayUpperCharacters | Get-Random -Count $Uppercase
            $NewPassword += $ArraySpecialCharacters | Get-Random -Count $SpecialCharacters

            $NewPassword = $NewPassword.Replace(' ','')

            $characterArray = $NewPassword.ToCharArray()  
            $scrambledStringArray = $characterArray | Get-Random -Count $characterArray.Length    
            $NewRandomPassword = -join $scrambledStringArray
    }
    End {
            Return $NewRandomPassword
    }
}

N’oubliez pas que pour utiliser cette fonction, vous devrez l’appeler dans votre script de la manière suivante :

New-RandomPassword -Length $Length -Uppercase $Uppercase -Digits $Digits -SpecialCharacters $SpecialCharacters
  • $Length correspond à la taille de votre mot de passe
  • $Uppercase correspond au nombre de majuscules
  • $Digits correspond au nombre de chiffres
  • $SpecialCharacters correspond au nombre de caractères non-alphanumériques

En l’état, ce code est fonctionnel, mais si on souhaite bien faire les choses, il faudrait encore ajouter des commentaires, si possible visible via la commande Get-Help, ainsi que des contrôles d'erreur.

Pour voir à quoi cela ressemble, faites un tour sur ma page Github, vous pourrez alors récupérer cette fonction avancée avec les commentaires, ainsi que les contrôles d'erreurs.

➡Script - New-RandomPassword.ps1

V. Conclusion

Vous savez maintenant ce qu’il vous reste à ajouter dans vos scripts PowerShell pour automatiser la création d’un utilisateur, et générer un mot de passe aléatoire qui respecte la politique de sécurité de l’entreprise, tout en étant relativement simple à saisir pour l’utilisateur.

The post PowerShell – Comment générer un mot de passe aléatoire ? first appeared on IT-Connect.

Office 365 : comment améliorer la délivrabilité et la sécurité de vos e-mails ?

18 mai 2021 à 13:00

I. Présentation

Que ce soit avec Office 365 et Exchange Online, ou une autre solution de messagerie, lorsque l'on parle d'e-mails, il y a deux termes qui reviennent encore et encore, constamment : sécurité et délivrabilité.

En tant qu’administrateur infrastructure, on souhaite éviter autant que possible de recevoir les mails de type spam, phishing, contenant des pièces jointes frauduleuses. Alors on met en place des filtres anti-phishing, antispam. On cherche aussi à sécuriser les e-mails au départ de notre serveur de messagerie, et faire en sorte qu’ils soient sains. Et puis on souhaite enfin s’assurer que nos mails passent les filtres de sécurité des serveurs de messagerie distants sans encombre, et arrivent directement dans la boîte mail du destinataire, sans passer par la case spam.

Avec Office 365, il y a plusieurs manières (complémentaires) d’arriver à nos fins. L’une d’entre elles est de passer par le trio gagnant des enregistrements DNS : « SPF », « DKIM » et « DMARC ».

II. Prérequis

III. Pourquoi l’enregistrement SPF n’est pas suffisant ?

Bon, je vous vois venir, vous allez me dire que lorsque vous configurez un nouveau domaine dans Office 365, vous devez obligatoirement configurer un enregistrement SPF dans votre zone DNS, et que cet enregistrement sert déjà à améliorer la sécurité et la délivrabilité de vos mails. Alors, à quoi bon s’embêter avec DKIM et DMARC ?

On va la faire courte : SPF est bien entendu nécessaire, mais n’est absolument pas suffisant. C’est là que DKIM et DMARC entrent en jeu.

Je vous explique.

A. SPF – Comment ça marche ?

SPF (ou Sender Policy Framework) est une norme adoptée à l’international qui permet de réduire les spams au niveau de votre serveur.

Concrètement, l’enregistrement SPF sert à authentifier l’expéditeur d’un courrier électronique. Cela permet de vérifier que le serveur qui envoie un mail à partir d’une adresse mail en @mondomaine.com est bien un serveur légitime.

Le nom de domaine de l’émetteur est extrait de l’en-tête du mail reçu (« MAIL FROM : »), et une requête DNS est émise sur ce domaine pour connaître la liste des serveurs de messagerie légitimes qui peuvent émettre des mails pour ce domaine précis. On compare alors cette liste de serveurs à l’adresse IP du serveur qui a émis le message.

Par exemple dans mon cas, comme mes domaines sont configurés sur Office 365, seuls les serveurs Exchange Online du tenant Office 365 sont autorisés à envoyer des mails à mon nom.

Du coup, si jamais quelqu’un essaye de se faire passer pour moi en envoyant un mail en mon nom, son serveur ne sera pas reconnu comme légitime et le mail pourra donc être classifié comme mail frauduleux / spam.

SPF est donc devenu un indispensable pour :

  • Augmenter la délivrabilité globale de ses mails
  • Se défendre contre l’usurpation d’identité de domaine, ainsi que l’usurpation d’adresse électronique (mail)

Cependant, SPF ne sait pas gérer les transferts de mail, et c’est là que les enregistrements DKIM entrent en jeu.

B. SPF – Les bonnes pratiques

L’enregistrement SPF est un enregistrement dans votre zone DNS publique de type TXT qui contient la liste des serveurs de messagerie autorisés à envoyer un mail pour votre domaine.

Voici une bonne pratique à respecter en toute circonstance : incluez toujours vos serveurs sous la forme server.mondomaine.com, ne listez pas les adresses IP une par une.

A. Vérifier la configuration SPF

Vous pouvez vérifier la validité de votre enregistrement SPF en utilisant cet outil gratuit.

Renseignez dans le champ votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Vous obtiendrez alors un résultat complet de l’analyse de votre enregistrement SPF.

Dans mon cas, ma configuration SPF est validée, et le serveur spf.protection.outlook.com (correspondant à Office 365) est bien celui qui est déclaré. Tout est parfait! 🙂

 

IV. Comprendre et configurer DKIM

A. DKIM – Comment ça marche ?

DKIM est un acronyme pour Domain Keys Identified Mail. Cette technologie permet d’envoyer un message chiffré, et de s’assurer que celui-ci n’a subi aucune altération durant sa transition entre le serveur émetteur et le serveur récepteur.

Rassurez-vous, le contenu du mail n’est pas chiffré, et votre destinataire pourra continuer à lire le message sans vous demander de clé de déchiffrement.

Au moment où vous envoyez votre mail, le serveur émetteur le chiffre via sa clé DKIM privée. Le serveur récepteur va lui vérifier la clé DKIM publique (l’enregistrement DKIM de votre zone DNS), et comparer celle-ci avec ce qu’il a reçu. Si le test est concluant, alors le serveur émetteur est bien qui il prétend être, l’identité de l’émetteur est prouvée et le mail peut donc être délivré dans la boîte mail du destinataire.

DKIM permet donc de s’affranchir des attaques de type « man in the middle ».

Note : Cette signature DKIM se gère dans l’en-tête du mail envoyé. Cela est donc transparent pour l’utilisateur final. Comme cette signature reste dans l’en-tête, cela permet de continuer à certifier l’exactitude du mail initial si celui-ci est transféré à une tierce personne.

 

B. Pourquoi DKIM est aujourd’hui indispensable ?

Je vous conseille fortement de mettre en place DKIM en plus de vos enregistrements SPF. Pourquoi ?

Parce que DKIM prouve que le contenu du mail ainsi que les en-têtes n’ont subi aucune altération : le mail est donc authentique et légitime : personne ne l'a envoyé à votre place, et le serveur de messagerie distant est maintenant en capacité de le vérifier.

C. Configuration de DKIM pour votre domaine

Tout d’abord, ouvrez une console PowerShell et commencez par vous connecter à votre serveur Exchange Online :

Import-Module ExchangeOnlineManagement

Connect-ExchangeOnline

Avant de commencer, vérifions ensemble que mondomaine.com soit bien déclaré comme un nom de domaine utilisable par Exchange :

Get-AcceptedDomain

Vous devriez voir mondomaine.com dans la liste.

Nous allons ensuite initialiser la configuration DKIM de notre nom de domaine mondomaine.com :

New-DkimSigningConfig -DomainName mondomaine.com -Enabled $false

 

Note : Vous pouvez utiliser le paramètre -Keysize 2048 dans la commande précédente, pour forcer la taille de votre clé DKIM à 2048 bits. Pas de panique toutefois, si vous ne l'avez pas fait, vous pourrez toujours y apporter des modifications plus tard en production.

Bien. Maintenant, il nous reste à générer les enregistrements DNS « DKIM » que nous devrons ajouter dans notre zone DNS publique.

Pour cela, tapez la commande :

Get-DkimSigningConfig -Identity mondomaine.com | Format-List Selector1CNAME, Selector2CNAME

Dans mon cas, je vais donc devoir créer 2 enregistrements CNAME sur ma zone DNS :

Prenons 30 secondes pour analyser la structure des enregistrements selector1 et selector2 à créer. Ces deux enregistrements se composent comme suit :

selector<id>-<domaine>-<extension>._domainkey.<tenantOffice365>.onmicrosoft.com

Pour le domaine mondomaine.com, cela donnerait donc :

  • selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com
  • selector2-mondomaine-com._domainkey.mondomaine.onmicrosoft.com

Il ne nous reste plus qu'à créer ces deux enregistrements CNAME dans notre zone DNS avec le paramétrage suivant :

  • Nom : selector1._domainkey & selector2._domainkey
  • TTL : 3 600 secondes

Note : Pensez bien à ajouter un point (.) à la fin du nom de domaine, pour indiquer que vous souhaitez pointer vers selector1-mondomaine-com._domainkey.mondomaine.onmicrosoft.com (domaine externe).

 

Attendez maintenant quelques secondes, le temps que votre zone DNS se réplique, puis lancez la commande suivante afin d’activer l’utilisation de DKIM pour mondomaine.com.

Set-DkimSigningConfig -Identity mondomaine.com -Enabled $true

Note : Si vous obtenez une erreur, soit une faute s’est glissée dans votre enregistrement DNS de type CNAME (pensez à bien vérifier le point final), soit vous n’avez pas attendu assez longtemps pour que la réplication de votre zone DNS soit effectuée.

D. Vérifier la configuration DKIM

Pour vérifier la bonne configuration de DKIM sur votre domaine, je vous conseille d’utiliser ce lien.

Renseignez l’un des 2 sélecteurs configurés, ainsi que votre nom de domaine, puis cliquez sur le bouton « Valider DNS ».

Note : Ne saisissez que selector1, l'outil va compléter automatiquement le reste de l'enregistrement DNS. Si vous saisissez selector1._domainkey, le test échouera.

Vous pouvez donc voir que dans mon cas l’enregistrement DKIM du sélecteur 1 est valide.

Note : Pensez bien à refaire cette étape pour chacun des sélecteurs DKIM configurés pour votre domaine.

Vous pouvez également, lorsque vous êtes connectés à votre serveur Exchange en PowerShell, exécuter la commande suivante :

Get-DkimSigningConfig -Identity mondomaine.com

Je n'obtiens pas d'erreur, mon domaine est donc correctement configuré avec DKIM.

V. Comprendre & configurer DMARC

A. DMARC – Comment ça marche ?

DMARC est un acronyme pour Domain-based Message Authentication, Reporting, and Conformance. DMARC utilise SPF et DKIM pour authentifier les expéditeurs d’emails, et fournit une protection supplémentaire.

En effet, SPF et DKIM permettent d’authentifier un expéditeur (ou non). Mais ils ne donnent aucune indication sur la conduite à tenir dans le cas d’une usurpation d’identité avérée.

C’est là que DMARC entre en jeu : lorsqu’on configure cet enregistrement DNS, on lui indique une politique à tenir. Cela permet au serveur de messagerie de savoir quoi faire de ces mails : faut-il les rejeter ? les mettre en quarantaine ? Ne rien faire mais l’historiser ?

A vous de le décider, et ça se passe dans DMARC.

B. Configuration de DMARC pour votre domaine

Afin de configurer DMARC pour votre domaine, il n’est pas nécessaire de faire des manipulations PowerShell : tout se passe dans votre zone DNS.

Il vous faut créer l’enregistrement TXT suivant dans votre zone DNS :

  • Type : TXT
  • Nom : _dmarc
  • TTL : 3 600 secondes
  • Valeur : « v=DMARC1 ; p=<policy>; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s »

Quelques explications :

Pct=100 indique que cette règle s’applique à 100% des emails.

adkim=s indique que la règle d'alignement avec DKIM est stricte. Seuls les mails partant du domaine mondomaine.com sont valides. Les mails en provenance d'un sous-domaine de mondomaine.com ne sont pas considérés comme valides.

aspf=s indique que la règle d'alignement avec SPF est stricte. L'en-tête "De" du mail doit correspondre exactement au nom de domaine de la commande SMTP "MAIL FROM".

Le paramètre rua est optionnel. Si vous l'indiquez comme ici, cela permettra d'envoyer des rapports sur l'activité DMARC à l'adresse mail [email protected].

Vous pouvez remplacer <policy> par 3 valeurs. Il s’agit ici de configurer la stratégie à appliquer sur le serveur de messagerie si un mail est rejeté par DMARC :

  • None : vous êtes en mode surveillance uniquement.
  • Quarantine : les mails qui ne passent pas DMARC sont mis en quarantaine.
  • Reject : les mails qui ne passent pas DMARC sont rejetés

Note : Je vous conseille de commencer par la stratégie none. Cela vous permet d’analyser l’impact de DMARC sur les mails reçus lorsque vous le passerez en mode quarantaine. On ne sait pas exactement la quantité de messages que l’on risque de perdre (non délivrés dans la boîte de réception du destinataire) via une stratégie DMARC restrictive, commencez donc par la stratégie de surveillance « none ».

C. Vérifier la configuration DMARC

Afin de vérifier que votre enregistrement DMARC est bien configuré sur votre zone, je vous invite à utiliser ce lien.

Renseignez alors le nom du domaine à vérifier, et cliquez sur le bouton « Valider DNS ».

Si vous avez suivi mes recommandations sur l’implémentation de DMARC, vous devriez donc avoir un enregistrement présent avec une stratégie de type « none ».

VI. Et si on regardait les en-têtes de nos mails ?

Avant de nous quitter, vérifions maintenant ce qui se passe dans l’en-tête des mails en sortie de notre serveur de messagerie.

Je me suis donc envoyé un mail de mon adresse [email protected] à mon adresse Gmail personnelle, puis j’ai affiché l’intégralité du message pour pouvoir consulter l’en-tête.

On peut voir que le mail a bien été envoyé à partir d’un serveur Exchange Office365, nommé FRA01-PR2-obe.outbound.protection.outlook.com, et qu’il a été réceptionné par le serveur mx.google.com.

On peut également voir 4 mentions importantes dans la section Authentication-Results :

  • Dkim=pass
  • Arc=pass
  • Spf=pass
  • Dmarc=pass

Ces mentions indiquent que la configuration SPF, DKIM et DMARC mise en place ensemble est fonctionnelle, et que ce mail est légitime. Autrement dit :

  • Le serveur ayant envoyé le mail est bien un serveur autorisé et légitime pour envoyer des mails du domaine mondomaine.com
  • Le mail a bien été envoyé par [email protected], il n’y a donc pas d’usurpation d’identité.

 

Note : On peut également voir deux points supplémentaires :

  • L’échange du mail entre les deux serveurs de messagerie s’est bien effectué de façon sécurisée : le protocole TLS 1.2 a été utilisé pour cela.
  • La politique DMARC actuellement mise en place pour ce domaine est sur « none », comme je vous le conseille dans un premier temps. Pour l’anecdote, elle va changer dans les prochains jours pour passer en « quarantine ».

VII. Conclusion

Vous n’avez maintenant plus aucune excuse pour ne pas correctement configurer vos enregistrements SPF, DKIM et DMARC.

Et si vous êtes amenés à expliquer à vos collègues ou à votre DSI l’intérêt de configurer ces enregistrements, retenez simplement que cela :

  • Renforce la protection antispam & anti-phishing
  • Augmente la sécurité de votre serveur de messagerie
  • Permets de contrer les attaques « man in the middle » ainsi que l’usurpation de domaine et l’usurpation d’identité
  • Favorise la délivrabilité de vos mails

Sachez engin que Google, Microsoft et Yahoo travaille sur un nouveau standard pour toujours plus renforcer la sécurité et la délivrabilité des mails, j’ai nommé BIMI.

The post Office 365 : comment améliorer la délivrabilité et la sécurité de vos e-mails ? first appeared on IT-Connect.

Linux – Afficher la branche Git dans le prompt

17 mai 2021 à 13:00

I. Présentation

Lorsqu’on utilise Git au quotidien pour versionner son code / ses scripts, on est souvent amené à créer des branches pour tester un bout de code, corriger un bug, le tout sans impacter le script actuel qui tourne en production.

Et pour éviter un carnage en production, nous devons redoubler de vigilance, et nous assurer de bien être sur la branche de test, et non celle de production.

Il existe des commandes Git pour vérifier cela, et pour naviguer d’une branche à l’autre. Mais on peut vite s’y perdre.

Et si je vous disais qu’il est possible de manipuler le prompt de votre terminal Linux pour afficher le nom de la branche de votre repository Git sur laquelle vous travaillez ?

Note : Si vous ne voyez pas encore l’intérêt en tant que sysadmin d’utiliser Git pour gérer vos scripts et la configuration de vos serveurs, laissez-moi vous convaincre du contraire : Git c’est l’avenir du sysadmin. Ça devient même un nouveau standard dont vous ne pouvez plus passer à côté.

II. Prérequis

Afin de suivre ce tutoriel, vous devez respecter les prérequis suivants :

  • Avoir une distribution Linux fonctionnelle, que ce soit une machine virtuelle, ou une distribution sous WSL
  • Git installé
  • Avoir créé votre premier repository Git

III. Comment modifier le prompt bash

Au lancement de votre terminal Linux, vous devriez avoir par défaut un prompt affichant :

  • Votre nom d’utilisateur
  • Le hostname de votre machine
  • Le répertoire dans lequel vous vous trouvez
  • Un $, indiquant que votre compte n’est pas un compte root

Le contenu de ce prompt est stocké dans une variable nommée PS1, pour Prompt String 1.

Vous pouvez d’ailleurs afficher le contenu de cette variable via la commande :

echo $PS1

Bon, on est d’accord, vu comme ça, c’est un peu moins parlant 😉

Note : Si l’anglais n’est pas un problème pour vous, je vous invite à consulter cet article pour tout savoir en détail sur la variable PS1.

Pour afficher le nom de la branche Git sur laquelle on travaille dans notre prompt, il nous faut donc modifier le contenu de cette variable PS1.

Et pour éviter de refaire la manipulation à chaque fois que l’on démarre un nouveau terminal, on va donc ajouter un bout de code à notre profile bash, en modifiant le fichier .bashrc :

vim ~/.bashrc

Note : le caractère ~ est un raccourci pour indiquer votre répertoire d’utilisateur. Dans mon cas, cela correspond à /home/thibault.

Déplacez-vous à la fin du fichier, et ajoutez le code suivant, puis sauvegardez :

# Configuration Git Branch – Modification prompt Linux
parse_git_branch() {
     git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/ (\1)/'
}
export PS1="\[email protected]\h \[\033[32m\]\w\[\033[33m\]\$(parse_git_branch)\[\033[00m\] $ "

 

Avant de tester le bon fonctionnement du code, quelques explications s’imposent :

La fonction parse_git_branch va extraire le nom de la branche Git sur laquelle vous vous trouvez actuellement dans votre repository Git.

Le contenu de la variable PS1 est alors modifié pour inclure le nom de la branche Git.

Si on analyse en détail le contenu de la variable PS1, on a alors les propriétés suivantes :

  • \[email protected]\h \[\033[32m\] à Affiche le nom de l’utilisateur et le hostname de la machine, avec la couleur appropriée
  • \w\[\033[33m\] à Affiche le nom du répertoire de travail actuel. Lorsque vous changez de répertoire avec la commande cd, ce contenu change également de manière dynamique.
  • \$(parse_git_branch)\[\033[00m\] à Si le répertoire de travail est un repository Git (et seulement dans ce cas-là), alors on affiche le nom de la branche Git dans laquelle nous nous trouvons actuellement.

IV. Tester le bon fonctionnement

Maintenant pour tester ça, comment faire ? Et bien, il suffit de redémarrer votre terminal pour que la fonction que l'on vient de rajouter soit prise en compte.

Jusque là, vous ne devriez voir aucun changement. Normal après tout, puisque vous vous trouvez actuellement dans un répertoire qui n'est pas tracké par Git.

Pour vérifier le fonctionnement, je me déplace dans mon dossier repository Git "scripts", qui contient deux branches :

  • master
  • test/branch

On peut voir que lorsque j'utilise la commande git checkout pour changer de branche et me déplacer entre "master" et "test/branch", mon prompt change aussi en fonction.

 

V. Conclusion

Ainsi, on sait d’un coup d’œil si le répertoire de travail est suivi par Git ou non, et si c’est le cas, on connaît également la branche (production, développement, etc) sur laquelle on travaille.

Plus aucun risque de se tromper maintenant ! 😉

The post Linux – Afficher la branche Git dans le prompt first appeared on IT-Connect.

Comment ajouter un nouveau domaine dans Office 365 ?

6 mai 2021 à 11:00

I. Présentation

Ça y est, vous êtes fin prêts à abandonner votre serveur Exchange On Premise (hébergé chez vous), pour migrer vers un serveur Exchange Online.

C’est d’ailleurs dans votre intérêt si vous n’avez pas les compétences en interne pour maintenir ce serveur au quotidien, au vu des dernières failles de sécurité identifiées sur Exchange. L’avantage avec Exchange Online, c’est que c’est Microsoft qui s’occupe de tout.

Enfin presque tout. Car le paramétrage du serveur reste à votre charge. Normal, me direz-vous.

Dans cet article, je vais m’attarder sur la bonne manière de configurer les enregistrements DNS d’Exchange Online. Mais on ne traitera pas de toute la configuration du serveur, car ça pourrait faire un cours complet. ?

II. Prérequis

Pour suivre ce tutoriel, il vous faudra respecter plusieurs prérequis :

  • Déjà, avoir un serveur Exchange Online prêt à l’emploi, c'est-à-dire un abonnement Office 365 avec la messagerie.
  • Posséder les licences Office365 nécessaires pour l’utilisation de la messagerie. Si votre entreprise a opté pour un pack de licences (E3, E5), c’est déjà dedans.
  • Un nom de domaine enregistré au nom de votre entreprise ou à votre propre nom, et sur lequel vous avez la main pour modifier la zone DNS.
  • PowerShell en version 5.1 ou +

Si vous partez de zéro, consultez directement ce tutoriel : comment créer un tenant Office 365 / Microsoft 365 ?

III. Configurer un nouveau domaine (via le centre d'administration)

Pour pouvoir envoyer des mails via un domaine personnalisé, il faut commencer par le déclarer dans Exchange Online.

Connectez-vous sur le centre d’administration de votre tenant Microsoft 365 : admin.microsoft.com, puis allez dans le menu Paramètres, puis Domaines.

Cliquez sur le bouton Ajouter un domaine, et renseignez le nom de domaine à ajouter. Par exemple : mondomaine.com.

On vous demande alors de valider que vous êtes bien le propriétaire de ce nom de domaine. Comment faire ? Plusieurs méthodes s’offrent à vous. Je vous recommande personnellement la première : l’ajout d’un enregistrement TXT à votre zone DNS. Simple et efficace.

L’utilitaire de configuration va essayer de détecter le fournisseur d’hébergement DNS, autrement dit le fournisseur chez qui vous avez acheté votre nom de domaine et chez qui vous vous connectez pour modifier votre zone DNS. Dans notre cas, il s’agit d’Azure, mais vous pouvez très bien le modifier manuellement si la détection n’a pas fait correctement son job.

On vous donne alors les informations à ajouter dans votre nouvel enregistrement TXT sur votre zone DNS :

  • Nom TXT
    • @ (ou ignorer s'il n'est pas pris en charge par le fournisseur)
  • Valeur TXT
    • MS=ms57389148
  • Durée de vie
    • 3600 secondes (ou la valeur par défaut de votre fournisseur)

La procédure exacte pour ajouter cet enregistrement chez votre registrar DNS peut changer en fonction de chez qui vous êtes. Pour l’exemple, je vais vous montrer comment faire sur l’interface de Gandi. Bien sûr, les menus peuvent être différents en fonction de votre fournisseur.

Une fois sur la zone DNS de votre nom de domaine, cliquez sur le bouton Ajouter, puis choisissez TXT comme type d’enregistrement DNS :

Configurer la valeur TTL (Time To Live, ou Durée De Vie) à la valeur préconisée par Microsoft, soit : 3600 secondes.

Mettre @ ou laisser vide le nom de votre enregistrement DNS. Ce point peut différer en fonction de votre interface de gestion DNS.

Enfin dans la zone de texte, renseignez la valeur donnée par Microsoft, soit : MS=ms67153608

Une fois l’enregistrement créé, retournez sur l’interface de Microsoft, et cliquez sur le bouton Vérifier.

Si la propriété du nom de domaine est vérifiée, vous passez à l’étape suivante de configuration. Sinon, vous obtiendrez une erreur. En règle générale, l’erreur vient d’un mauvais enregistrement TXT : vous avez pu oublier le @ ou faire un mauvais copier / coller.

Cliquez sur Continuer.

Pour que les mails en provenance et à destination de votre nom de domaine puissent être correctement routés par Microsoft 365, vous avez encore quelques étapes à respecter : Configurer dans votre zone DNS les enregistrements MX, CNAME, TXT.

L’enregistrement MX indique quel est le serveur de messagerie, et indique également la priorité associée à chaque serveur s’il y en a plusieurs. Cela permet de dire via votre zone DNS quel est votre serveur de messagerie préféré, et également de configurer un serveur de messagerie secondaire.

Comme tout à l’heure, créez un nouvel enregistrement dans votre zone DNS, mais cette fois de type MX.

Créez ensuite les enregistrements CNAME et TXT demandés :

L’enregistrement CNAME « autodiscover » permet de faciliter la configuration de votre client de messagerie Outlook : il suffit d’entrer le nom de l’utilisateur et son mot de passe et la configuration serveur s’effectue automatiquement.

ATTENTION : La valeur à renseigner est bien autodiscover.outlook.com. avec un point à la fin. Cela indique à votre zone DNS que vous pointez vers une autre zone DNS, soit dans notre cas l’enregistrement autodiscover.outlook.com. Si vous oubliez le point à la fin, vous pointerez alors sur autodiscover.outlook.com.votrezonedns.extension. Ce qui ne fonctionnera pas.

L’enregistrement TXT est ce qu’on appelle un enregistrement SPF.

Vérifiez les enregistrements une fois que vous êtes prêts. Microsoft va alors interroger vos serveurs DNS pour vérifier la conformité des enregistrements, et vous remonte les erreurs s’il y en a. Par exemple, dans mon cas :

Là c’est plutôt explicite : un enregistrement SPF existait déjà sur ma zone DNS, automatiquement ajouté par Gandi. Il me reste à le supprimer et on sera bon.

NOTE : Vous pouvez aussi être amenés à supprimer des enregistrements de type MX, automatiquement ajoutés sur votre zone DNS.

Tous vos enregistrements DNS devraient maintenant être valides.

IV. Configurer un nouveau domaine (via PowerShell)

Pour effectuer la même manipulation sous PowerShell, une fois connecté à votre tenant Microsoft 365 via PowerShell, tapez la commande suivante :

New-MsolDomain -Name "mondomaine.com"

On demande ensuite les enregistrements DNS pour procéder à la vérification de la propriété du domaine :

Get-MsolDomainVerificationDns -DomainName "mondomaine.com" -Mode DnsTxtRecord

Comme dans la procédure manuelle, on se connecte sur notre espace de gestion Noms de domaine / Zones DNS, pour ajouter l’enregistrement TXT validant la propriété du nom de domaine.

On vérifie ensuite la propriété :

Confirm-MsolDomain -DomainName "mondomaine.com"

À ce stade, ce n’est plus si évident de récupérer les enregistrements MX, CNAME, et SPF pour les configurer ensuite dans votre zone DNS. Il est préférable de finir cette partie-là à la main.

Mais si vous êtes comme moi, et que vous aimez bien tout automatiser alors la suite est pour vous.

Vous aurez besoin du module AzureAD sur votre PC.

Install-Module AzureAD

Import-Module AzureAD

Connectez-vous ensuite à votre AzureAD :

Connect-AzureAD

Tapez la commande suivante pour récupérer les informations permettant de créer les enregistrements MX, CNAME et TXT :

Get-AzureADDomainServiceConfigurationRecord -Name coosol.net | Select Label, RecordType, Ttl, MailExchange, Preference, Text, CanonicalName

Si le label correspond à votre nom de domaine, lorsque vous ajouterez cet enregistrement DNS, cela correspond au @.

ATTENTION : Sur l’enregistrement CNAME, il vous faudra ajouter un point à autodiscover.outlook.com, sinon vous vous retrouverez avec un enregistrement du type autodiscover.outlook.com.mondomaine.com ce qui n’est pas du tout ce que vous souhaitez.

 

V. Script PowerShell - Récupérer les enregistrements DNS à créer

Pour aller encore plus loin, voici un script qui vous retourne en sortie un tableau propre des enregistrements DNS à ajouter dans votre zone DNS.

On réutilise les mêmes commandes que précédemment, mais cette fois on reformate les données pour que ce soit plus lisible en sortie.

#Install-Module AzureAD -Force
Import-Module AzureAD
Connect-AzureAD -Credential (Get-Credential)
$domain = "coosol.net"
$result = @()
$DNSRecords = (Get-AzureADDomainServiceConfigurationRecord -Name $domain | Select Label, RecordType, Ttl, MailExchange, Preference, Text, CanonicalName)
Foreach ($DNSRecord in $DNSRecords) {
    if ($DNSRecord.Label -eq $domain) {
        $Label = "@"
    }
    else {
        $Label = $DNSRecord.Label
    }
    $ttl = $DNSRecord.ttl + " secondes"
    switch ( $DNSRecord.RecordType )
    {
        Mx
        {
            #Enregistrement DNS de type MX
            $result += [PSCustomObject]@{
                Type = "MX"
                TTL = $ttl
                Nom = $Label
                Priorite = $DNSRecord.Preference
                Valeur = $DNSRecord.MailExchange
            }
        }
        Txt
        {
            #Enregistrement DNS de type TXT (SPF)
            $result += [PSCustomObject]@{
                Type = "TXT"
                TTL = $ttl
                Nom = $Label
                Valeur = $DNSRecord.Text
            }
        }
        Cname
        {
            #Enregistrement DNS de type CNAME
            $Valeur = $DNSRecord.CanonicalName + "."
            $result += [PSCustomObject]@{
                Type = "CNAME"
                TTL = $ttl
                Nom = "autodiscover"
                Valeur = $Valeur
            }
        }
    }
}
Clear-Host
Write-Output "Enregistrements DNS à créer :`n"
Write-Output $result

 

VI. Comment vérifier l'intégrité d'un nom de domaine sur Office 365 ?

À partir du centre d’administration admin.microsoft.com, allez dans Paramètres, puis dans Domaines.

Sélectionnez un domaine, cliquez sur le bouton Options (les 3 petits points), puis cliquez sur Vérifier l’état d’intégrité. Tous vos enregistrements devraient être au vert :

VII. À quoi sert un enregistrement SPF ?

Le sigle SPF veut dire Sender Policy Framework. Concrètement, et sans rentrer dans les détails, cet enregistrement SPF est couramment utilisé pour sécuriser nos serveurs de messagerie, plus particulièrement pour vérifier les adresses des expéditeurs.

Cela permet de vérifier qu’un email [email protected] provient bien du serveur de messagerie configuré pour relayer les mails du domaine mondomaine.com.

Cette vérification est effectuée en arrière-plan par le serveur de messagerie et n’est en aucun cas visible de l’utilisateur final.

VIII. Conclusion

Félicitations ! Vous avez configuré votre premier domaine sur Office365. Vous pouvez maintenant créer de nouvelles boîtes de messagerie et commencer à envoyer des mails.

Mais si vous souhaitez sécuriser un peu plus votre envoi / réception de mails, je vous invite à configurer également vos enregistrements DNS DKIM / DMARC.

The post Comment ajouter un nouveau domaine dans Office 365 ? first appeared on IT-Connect.

Git : Comment résoudre l’erreur « fatal : pathspec is in submodule »

3 mai 2021 à 13:00

I. Présentation

J’ai récemment réorganisé mes repository Git afin de me faciliter la vie. Plutôt que d’avoir un repository unique PowerShell, un autre Bash, un autre Python, etc, j’ai décidé de me créer un unique repository « Scripts », avec un sous-dossier par langage de scripting : Bash, Python, PowerShell.

J’étais confiant, j’y suis allé à vrai dire un peu vite, et ce qui devait arriver arriva : bim ! Une erreur ! Fatale en plus !

fatal: Pathspec '.\PowerShell\*' is in submodule 'PowerShell'

fatal: Pathspec '.\PowerShell\*' is in submodule 'PowerShell'

Restez avec moi si vous voulez savoir pourquoi cette erreur s’est affichée, et comment la corriger.

II. Prérequis

  • Git installé sur votre poste
  • Un repository distant de configuré (Github, Gitlab, Bitbucket sont les plus connus)

 

III. Explications de l’erreur fatale : Pathspec is in submodule

Jusqu’à aujourd’hui, j’avais 3 dossiers, répartis dans 3 repository Git distincts, pour stocker & gérer mes scripts :

  • Bash-scripts
  • Python
  • PowerShell

J’ai décidé de réunir ces 3 dossiers dans un nouveau repository Git, nommé « Scripts ».

Logiquement, et naïvement, j’ai donc créé un nouveau répertoire « Scripts » sur mon PC, et j’ai copié le contenu des 3 autres dedans, pour me retrouver dans la configuration suivante :

Que du classique lorsqu’on prépare un nouveau répertoire Git.

Me restait donc à initialiser le suivi du répertoire via Git :

cd E:\Repos\Scripts

git init

Une fois fait, il faut encore dire à Git quels sont les fichiers sur lesquels tracker les modifications. Ça s’effectue via la commande :

git add .

NOTE : Le . agit comme un ./* Il indique à Git de tracker tous les fichiers & sous-répertoires présents dans le répertoire de travail actuel.

 

Et c’est à ce moment-là que ça a commencé à coincer.

Mon dossier PowerShell était déjà tracké par Git, dans un autre repository, et il possédait toujours un dossier .git, avec la configuration associée.

Comme vous pouvez le voir sur la capture d'écran ci-dessous, les messages de git sont en général assez parlant. Dans notre cas, la solution nous est donnée. Enfin presque. Je vous dit tout dans un instant.

À ce stade, si vous vous entêtez, lors de votre premier commit, votre dossier « PowerShell » sera purement et simplement ignoré par Git.

Pourtant, le commit se passe bien, sans erreur.

 

Sauf que voilà : j’ai beau effectuer des modifications dans mon dossier PowerShell, git est censé les détecter, et m’afficher les changements lorsque j’utilise les commandes suivantes :

git diff

git status

Or, dans mon cas, Git me retourne un message m'indiquant qu'il n'y a eu aucun changement, et qu'il n'y a donc aucun intérêt à réaliser un commit : "nothing to commit, working tree clean".

nothing to commit, working tree clean

Et côté repository distant, sur Gitlab, je me retrouve avec un dossier PowerShell inaccessible alors que je devrais pouvoir le parcourir et avoir accès à tous mes scripts.

Vraiment, la loose !

Il y a une manière très simple de vérifier si vous avez bien la même erreur que moi. Essayez de rajouter le dossier ou le fichier dans les éléments trackés par Git :

git add ./PowerShell/*

Vous devriez alors obtenir l'erreur "fatal: Pathspec is in submodule".

fatal: Pathspec is in submodule

 

Et voilà : l’explication, c’est que mon dossier PowerShell contenait une configuration git existante. Donc lorsque j’ai initialisé git pour mon nouveau dossier Scripts, le dossier PowerShell, qui était déjà tracké, s’est automatiquement configuré en sous-module. Git considère alors que ce dossier PowerShell étant déjà suivi et ayant déjà des commit, il n'a aucun intérêt à le suivre une seconde fois, d'où le message d'erreur, et d'où le fait que mes modifications ne sont absolument pas détectées lorsque je fais un commit git.

IV. Comment corriger cette erreur ?

Maintenant, comment corriger cette erreur ? C’est très simple et ça ne vous prendra pas plus de 30 secondes.

Pour commencer, supprimez le dossier .git de votre dossier « PowerShell » s’il est encore présent.

Ensuite, vous allez faire oublier à Git le tracking de votre dossier en mode « submodule », en forçant git à supprimer son cache :

git rm --cached <nom-du-dossier>

 

NOTE : Si git est récalcitrant, vous pouvez utiliser le paramètre -f pour le forcer à supprimer son cache.

git rm --cached <nom-du-dossier> -f

 

Vous pouvez alors à nouveau ajouter le tracking git de votre dossier, et vérifier que les fichiers sont cette fois bien reconnus :

git add ./PowerShell/*

git status

Cette fois, on peut bien voir les modifications que j'ai apportées au contenu du dossier PowerShell : en vert les fichiers ajoutés (du point de vue de Git, par rapport au dernier commit).

Il ne vous reste plus qu’à faire votre git push pour envoyer vos données sur votre repository distant, et le tour est joué. ?

V. Conclusion

La prochaine fois que vous voudrez réorganiser vos repository Git, n’oubliez pas de vérifier la configuration Git du repository en question, afin d’éviter de créer par inadvertance des sous-modules là où il n’y en a pas besoin.

Pensez également à bien vérifier que tous les dossiers et fichiers qui vous intéressent sont bien intégrés à la liste des éléments trackés par Git, via la commande :

git status

Et si votre commit coince, votre premier réflexe est d’aller voir l’état de votre repository sur votre serveur distant, et également de regarder la configuration de votre repository Git local dans votre dossier .git.

The post Git : Comment résoudre l’erreur « fatal : pathspec is in submodule » first appeared on IT-Connect.

Linux : comment éviter d’entrer sa passphrase à chaque utilisation d’une clé SSH ?

30 avril 2021 à 13:00

I. Présentation

Pour s’authentifier et se connecter de manière sécurisée à un service ou un serveur, on a 2 possibilités sous Linux : le classique (et désuet) login / mot de passe, ou la clé SSH, protégée par une passphrase.

Plus besoin de se souvenir de 36 mots de passe différents : une clé SSH et c’est parti.

Oui, mais voilà : Quand on est amené à se connecter plusieurs fois par jour à des serveurs via SSH, ou qu’on effectue des rafraîchissements de son repository Git à partir du serveur, la passphrase nous sera demandée, systématiquement, à chaque nouvelle connexion.

Ce qui peut être vraiment lourd au bout de la cinquantième fois.

J’ai une astuce pour vous : vous connaissez Keepass ? Et bien on va reprendre le même principe : on va stocker de manière sécurisée la clé SSH ainsi que la passphrase dans un coffre sécurisé.

Ainsi, plus besoin de taper 50 fois votre passphrase chaque jour, vous ne la saisirez plus qu’une seule fois, au démarrage de votre système Linux. Et la magie fera le reste ! ?

Si vous souhaitez avec plus d'informations sur le système de clé privée/clé publique, je vous invite à lire ce cours écrit par Florian Burnel :

- Clés asymétriques : http://www.it-connect.fr/les-cles-asymetriques/

II. Prérequis

III. Vérifier la présence de la clé SSH

Pour commencer, on va vérifier que votre clé SSH est bien présente sur votre système Linux.

Pour cela, ouvrez un terminal, et tapez la commande :

ls -al ~/.ssh

Vous devriez voir apparaître plusieurs fichiers, celui qui nous intéresse étant id_rsa.

Note : ~ correspond au chemin de votre profil sous Linux, dans mon cas, il s’agit de : /home/thibault, comme on peut le voir sur la capture d’écran ci-dessus.

Avant d’installer et de configurer Keychain, une dernière chose à vérifier : votre clé SSH est une clé privée. Mais on va tout de même s’en assurer du côté des permissions de Linux :

On peut voir dans mon cas que ma clé privée (le fichier id_rsa) n’est pas vraiment privée. On va changer ça de suite, pour éviter des messages d’erreur de nos applications préférées :

sudo chmod 600 ~/.ssh/id_rsa

Note : Si vous n’êtes pas propriétaire des fichiers se trouvant dans votre dossier .ssh, il faudra vous réattribuer la propriété, sinon vous aurez des difficultés pour lire les fichiers.

Dans mon cas, mon nom d’utilisateur étant « thibault », cela donne :

sudo chown thibault :thibault ~/.ssh/id_rsa

On vient d’accorder des droits en lecture / écriture uniquement au propriétaire du fichier, et à personne d’autre. On ne peut pas faire plus privé. ?

IV. Installer et configurer Keychain pour sauvegarder automatiquement la passphrase

Ceux qui me connaissent savent que j'utilise Git pour le versioning de la totalité de mes scripts et des configurations serveurs / logiciels.

Et pour l'exemple, j'ai effectué un git clone, pour copier le contenu d'un répertoire distant (un repository) sur un répertoire local de mon poste. L'authentification s'effectue via ma clé SSH, et forcément, Git me demande de confirmer ma passphrase avant de lancer les actions.

Le truc particulièrement énervant, et notamment quand notre passphrase fait plus de 25 caractères, c'est que si je réexécute la même commande quelques secondes plus tard, je vais devoir à nouveau renseigner la passphrase.

Plutôt fastidieux, notamment lorsqu'on est dans mon cas et qu'on doit la renseigner plus de 50 fois par jour...

Pour éviter de taper encore et encore la même passphrase à chaque fois que l’on fait appel à notre clé SSH, on va s’installer Keychain, puis le configurer.

Pour l’installation, on reste sur du classique de chez classique :

sudo apt install -y keychain

Linux keychain ssh

Note : le -y indique de répondre « Oui » à la question : Êtes-vous sûr de vouloir continuer ? Une option particulièrement utile pour l’automatisation.

Pour vérifier que Keychain est bien installé sur votre système, tapez :

keychain --version

Il vous reste maintenant à modifier votre profil pour ajouter la configuration de keychain. Pour cela, ouvrez le fichier ~/.bashrc dans votre éditeur de texte préféré. Dans mon cas, j’utilise vim, mais libre à vous de passer sur d’autres éditeurs :

vim ~/.bashrc

Et ajoutez la ligne suivante à la fin du fichier :

eval ``keychain --eval --agents ssh id_rsa

À chaque fois que vous rebooterez votre serveur ou que vous démarrerez, un nouveau terminal, keychain s’exécutera.

À la première exécution suite à un reboot, keychain reconnaîtra votre clé SSH et vous demandera de saisir la passphrase :

Par la suite, à chaque nouveau terminal créé, keychain vous avertira qu’il a déjà en stock la clé SSH ainsi que la passphrase. Plus besoin de la taper du coup, keychain s’en chargera à votre place à chaque fois que le système en aura besoin pour se connecter à une ressource distante.

V. Conclusion

Comment s’en assurer ? Dans mon cas, je crée un nouveau répertoire de test et je relance la copie de mon repository Git avec la commande :

git clone <mon-lien-git>

Et pouf ! Par magie, ça se fait, sans action de ma part : plus besoin de taper ma passphrase tout au long de la journée. Je la saisis le matin en arrivant et c’est réglé.

Sacré gain de temps, n’est-ce pas ?

The post Linux : comment éviter d’entrer sa passphrase à chaque utilisation d’une clé SSH ? first appeared on IT-Connect.
❌