FreshRSS

🔒
❌ À propos de FreshRSS
Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Azure AD certificate-based user authentication

11 mai 2022 à 15:59

Certificate-based authentication is an extremely robust and secure mechanism for validating a user's identity. However, until recently, you had to deploy Active Directory Federation Services (AD FS) to make it available for Azure AD. Microsoft has recently introduced an Azure AD certificate-based authentication service (Azure CBA), which significantly simplifies implementing certificate-based authentication.

The post Azure AD certificate-based user authentication first appeared on 4sysops.

Configuring SSO between Active Directory and Azure using pass-through authentication

2 mai 2022 à 14:36

Pass-through authentication is an alternative to AD FS and password hash synchronization in Azure AD. This technology allows users to access cloud apps after authenticating against the local Active Directory. The configuration of pass-through authentication is less complex than that of AD FS, for example.

The post Configuring SSO between Active Directory and Azure using pass-through authentication first appeared on 4sysops.

Passwordless authentication with FIDO2 and Azure Active Directory

25 avril 2022 à 15:40

Getting rid of unsecure password authentication is becoming a priority for many businesses. Companies using Microsoft's Azure Active Directory have many options to implement passwordless authentication. One of these is using a FIDO2 security key.

The post Passwordless authentication with FIDO2 and Azure Active Directory first appeared on 4sysops.

Office 365 : Activer le SSO sur Windows pour Edge, Chrome, Teams, etc.

25 avril 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir comment activer le SSO (Single Sign-On) entre un environnement Active Directory local et Office 365, afin d'être automatiquement authentifié avec son compte lors de l'ouverture de Teams, de Word, d'Excel, ou encore du portail Office ou du SharePoint de l'entreprise, à partir du navigateur Microsoft Edge ou Google Chrome.

Grâce à la mise en place du SSO, lorsqu'un utilisateur se connecte sur une machine du domaine Active Directory avec son compte utilisateur, et qu'il accède au portail Office avec son navigateur, à Teams (en mode Web ou avec l'application), à Outlook, ou encore qu'il ouvre une application de la suite Microsoft 365 Apps sur sa session, il est automatiquement connecté avec son compte. Autrement dit, il est connecté dans les applications sans avoir à saisir son adresse e-mail et son mot de passe. Avec une configuration supplémentaire, on peut également appliquer le SSO au client OneDrive, ainsi qu'au navigateur Mozilla Firefox.

Pour suivre ce tutoriel, vous avez besoin des éléments suivants :

  • Instance Azure AD Connect en place (si besoin, suivez ce tutoriel : comment installer Azure AD Connect ?)
  • Contrôleur de domaine Active Directory pour créer une GPO
  • Serveur membre du domaine Active Directory
  • Compte utilisateur de l'Active Directory, synchronisé sur le tenant Office 365 via Azure AD Connect

II. Activer le SSO dans Azure AD Connect

Premièrement, nous devons configurer Azure AD Connect de manière à activer l'authentification unique (SSO) dans les paramètres. Pour cela, ouvrez Azure AD Connect sur le serveur où il est installé, et cliquez sur "Modifier la connexion utilisateur" dans la liste des tâches disponibles, puis sur "Suivant".

Ensuite, vous allez devoir indiquer un compte pour vous authentifier sur l'environnement Cloud. Une fois que c'est fait, l'écran "Connexion utilisateur" s'affiche. A cet endroit, vous devez cocher l'option "Activer l'authentification unique" correspondante au SSO, et pour la méthode d'authentification, si vous utilisez "Synchronisation de hachage du mot de passe", c'est bon. Une alternative consiste à utiliser le mode "Authentification directe".

Dès que c'est fait, cliquez sur "Suivant" et il faudra s'authentifier une nouvelle fois, cette fois-ci avec un compte administrateur de l'Active Directory.

Activer le SSO dans Azure AD Connect

Patientez pendant quelques secondes le temps que la configuration est actualisée, puis fermez Azure AD Connect.

Si vous souhaitez vérifier que la nouvelle configuration est bien prise en charge, vous pouvez ouvrir le portail Azure, accéder à Azure Active Directory, puis cliquer sur "Azure AD Connect" dans le menu à gauche. Ici, il faudra vérifier que "Authentification unique fluide" est bien activé pour votre domaine.

Enfin, sachez que dans l'Active Directory, un nouvel objet de type "ordinateur" nommé "AZUREADSSOACC" a été créé et qu'il est indispensable au bon fonctionnement du SSO. Pour des raisons de sécurité, il est nécessaire de positionner cet objet dans une OU protégée contre les suppressions accidentelles et l'accès à cet objet doit être limité aux administrateurs. Puisque la partie Azure AD Connect terminée, nous pouvons passer à la suite de la configuration.

III. Créer la GPO pour le SSO Office 365

A. Paramètre "Liste des attributions de sites aux zones"

Deuxièmement, nous devons créer une stratégie de groupe à partir de la console de création de GPO. Pour ma part, je nomme cette GPO "O365 - SSO" et je la positionne directement sur l'OU "Personnel" puisqu'elle contient les comptes utilisateurs du personnel de mon entreprise fictive. Tout cela pour dire que cette GPO contient des paramètres utilisateurs.

Modifiez cette GPO et parcourez les paramètres de cette façon :

Configuration utilisateur > Stratégies > Modèles d'administration > Composants Windows > Internet Explorer > Panneau de configuration Internet Explorer > Onglet Sécurité

Ici, vous devez ouvrir le paramètre "Liste des attributions de sites aux zones".

Afin de configurer ce paramètre, cliquez sur "Activé" (1), puis sur le bouton "Afficher" (2) et indiquez "https://autologon.microsoftazuread-sso.com" comme nom pour la valeur et indiquez la valeur "1", comme ceci :

SSO Azure AD via GPO Internet Explorer

En fait, cette configuration permet de dire à la machine que cette adresse appartient à la zone Intranet - d'où la valeur "1" - pour que Windows accepte de transmettre des informations d'identification à cette URL.

B. Paramètre "Autoriser les mises à jour de la barre d'état via le script"

Continuons la configuration en activant le paramètre "Autoriser les mises à jour de la barre d'état via le script" :

Configuration utilisateur > Stratégies > Modèles d'administration > Composants Windows > Internet Explorer > Panneau de configuration Internet Explorer > Onglet Sécurité > Zone Intranet

Comme ceci :

Autoriser les mises à jour de la barre d'état via le script

Une fois que c'est fait, nous devons configurer un dernier paramètre pour déployer une valeur de Registre Windows.

C. Clé de Registre "https"

Pour déployer ce troisième paramètre dans le Registre, rendez-vous dans la section suivante (toujours dans la partie utilisateur) :

Préférences > Paramètres Windows > Registre

Ensuite, effectuez un clic droit et sous "Nouveau", cliquez sur "Élément Registre". Créez un nouvel élément avec la configuration suivante :

  • Action : Mettre à jour
  • Ruche : HKEY_CURRENT_USER
  • Chemin d'accès à la clé : Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
  • Nom de la valeur : https
  • Type de valeur : REG_DWORD
  • Données de la valeur : 00000001

Ce qui donne :

Registre - microsoftazuread-sso.com autologon

La GPO est prête, nous obtenons la configuration suivante :

Avec cette configuration, le SSO pourra fonctionner au sein de plusieurs applications : Microsoft Edge, Google Chrome, Microsoft Teams, et la suite Office. En revanche, pour que le SSO fonctionne dans Firefox et OneDrive, une configuration supplémentaire doit être apportée.

IV. Tester le SSO sur un poste Windows

Suite à la configuration que l'on vient d'effectuer, le SSO devrait fonctionner ! Afin de le vérifier, il n'y a qu'une seule solution : tester depuis un poste client intégré au domaine, en se connectant avec un compte utilisateur concerné par la GPO "O365 - SSO".

A. Visualiser les paramètres intranet

Tout d'abord, une fois que la session est ouverte, on peut s'assurer que le paramètre de zone Intranet est bien appliqué. Ce n'est pas obligatoire, mais pour vérifier cela, il faut ouvrir le panneau de configuration, cliquer sur "Options Internet" puis l'onglet "Sécurité". Une fois dans cet onglet, il faut sélectionner "Intranet local" (1), cliquer sur "Sites" (2) puis le bouton "Avancé" (3) et enfin s'assurer que l'URL "autologon" est bien dans la liste des sites (4). Comme ceci :

B. Connexion aux différentes applications

Concernant le SSO en lui-même, il y a plusieurs façons de le tester... Pour Teams, c'est tout simple, il suffit d'ouvrir Teams et de voir ce qu'il se passe : normalement l'utilisateur est authentifié directement. À partir d'un navigateur, en l'occurrence Chrome ou Edge, si vous accédez à "portal.office.com", cela ne fonctionnera pas. En effet, vous devez utiliser une URL spécifique qui contient votre domaine (format classique ou format onmicrosoft.com).

Pour le domaine "it-connect.tech", cela donne :

https://portal.office.com/?domain_hint=it-connect.tech
https://portal.office.com/?domain_hint=itconnect.onmicrosoft.com

Avec les deux URL ci-dessus, le SSO fonctionne bien. C'est également le cas avec cette adresse :

https://myapps.microsoft.com/itconnect.onmicrosoft.com

Mais aussi avec un accès sur le SharePoint de l'entreprise, par exemple :

https://itconnect.sharepoint.com/

En fait, pour que le SSO fonctionne dans le navigateur, il faut utiliser des URL personnalisées qui permettent d'identifier votre environnement Cloud. À mon avis, il est intéressant de déployer des favoris dans les navigateurs ou des raccourcis sur le Bureau des sessions avec les bons liens.

Enfin, sachez que si vous utilisez le SSO couplé avec le MFA, cela fonctionne tout de même. Néanmoins, le nom d'utilisateur et le mot de passe sont automatiquement "saisit", mais la fenêtre MFA s'affiche : ce qui permet d'optimiser le processus d'authentification malgré tout, surtout si l'on approuve l'appareil, cela ne reviendra pas systématiquement.

C. Debug du SSO Office 365

Si cela ne fonctionne pas, il y a plusieurs raisons possibles : GPO pas appliquée, Azure AD Connect mal configuré, etc... Ou encore, un poste de travail qui n'est pas à l'heure. Pour analyser le problème, vous pouvez ouvrir une console dans la session de l'utilisateur et exécuter la commande ci-dessous pour lister les tickets Kerberos.

klist

Normalement, vous devez voir un ticket avec l'URL autologon, comme ceci :

SSO Office 365 - klist

Si ce n'est pas le cas, vous pouvez essayer de purger vos tickets Kerberos, redémarrer la machine puis rouvrir la session. Pour supprimer les différents tickets, utilisez cette commande :

klist purge

Afin d'avoir des informations supplémentaires sur le dépannage du SSO, vous pouvez consulter la documentation de Microsoft.

Le SSO Office 365 est en place au sein de votre environnement : ce sont les utilisateurs qui vont apprécier !

The post Office 365 : Activer le SSO sur Windows pour Edge, Chrome, Teams, etc. first appeared on IT-Connect.

Comment démarrer automatiquement une VM Azure ?

20 avril 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à démarrer automatiquement les VMs Azure à partir d'Azure Automation et d'un runbook PowerShell. Grâce à cette méthode, vous pourrez configurer certaines machines virtuelles Azure pour qu'elles s'arrêtent et démarrent automatiquement, à l'heure que vous le souhaitez.

Avant tout, il faut savoir que dans Azure, lorsqu'une VM tourne elle vous coûte de l'argent. En partant de ce constat, on peut chercher à optimiser les coûts pour que la facture soit un peu moins salée à la fin du mois. Pour certaines VM, l'arrêt n'est tout simplement pas envisageable, alors que pour d'autres cela peut avoir du sens. Par exemple, des VMs de test ou de préproduction que l'on utilise seulement la journée.

Azure Automation permet d'automatiser certaines tâches, notamment en exécutant des scripts PowerShell ou Python, pour automatiser certains processus. C'est surtout cet aspect d'Azure Automation qui va nous intéresser aujourd'hui. Même si ce service est payant, si l'on regarde les tarifs de "Process Automation", on peut voir que l'on a le droit à "500 minutes" d'exécution gratuite par mois. Étant donné que le démarrage d'une VM consomme quelques secondes, cette solution semble intéressante pour optimiser ses coûts 🙂

Dans cet article où l'on va effectuer la configuration pas à pas, je vais utiliser les valeurs suivantes :

  • VM à gérer automatiquement : SRV-WSUS
  • Groupe de ressources : IT-CONNECT_VM_SRV_WSUS
  • Compte Azure Automation :  IT-Connect_Automation
  • Nom du runbook : Start-VM-7am
  • Planification : Tous_les_jours_07h00

Pour une solution sans Azure Automation, consultez ce tutoriel :

II. Configurer l'arrêt automatique d'une VM Azure

Tout d'abord, nous devons activer l'arrêt automatique sur notre machine virtuelle "SRV-WSUS". Cette option est proposée lorsque l'on crée une machine virtuelle, et on peut revenir dessus à tout moment. Pour cela, il suffit de cliquer sur la VM puis de cliquer sur "Arrêt automatique" (1), de cocher l'option "Activé" (2), de définir l'heure à laquelle la VM doit s'arrêter et choisir le fuseau horaire (3). Enfin, il faut enregistrer (4).

Arrêt automatique d'une VM Azure

L'opération doit être répétée sur l'ensemble des VMs dont vous souhaitez gérer l'arrêt et le démarrage en mode auto. C'est également possible d'effectuer la configuration via PowerShell.

La première étape est un succès : notre VM va s'arrêter tous les jours à 23h00. Maintenant, voyons comment gérer le démarrage automatiquement, et là c'est un peu plus complexe.

III. Créer un compte Azure Automation

En premier lieu, à partir du portail Azure, recherchez "Automation" afin d'accéder à Azure Automation. La première fois, il sera indispensable de créer un compte Automation, en cliquant sur le bouton "Créer".

Il faut attribuer un groupe de ressources et un nom à ce compte Automation, par exemple "IT-Connect" en ce qui me concerne. Ensuite, lancez la création.

La création s'effectue en quelques secondes.

IV. Créer un runbook PowerShell dans Automation

La ressource étant créée, nous avons accès à notre compte "Azure Automation" et aux différentes fonctionnalités. Pour démarrer automatiquement les VMs, nous allons créer un runbook qui va exécuter un script PowerShell.

Sachez également qu'il y a une solution nommée "Start/stop VMs during off-hours" qui est proposée par Microsoft sous la forme d'une "application" pour Azure Automation. Vous pouvez accéder à cette méthode via votre compte Automation, puis en cliquant sur "Start/Stop VM" dans le menu de gauche. Cette solution est liée à Azure Automation et Log Analytics, alors elle va être plus coûteuse.

Start/stop VMs during off-hours

Commençons la configuration de notre runbook PowerShell... Toujours à partir d'Azure Automation (1), cliquez sur "Runbooks" dans le menu de gauche puis sur "Créer un runbook" (3).

Nous devons nommer ce runbook, par exemple "Start-VM-7am" car nous allons démarrer les VMs ciblées à 7h du matin. Pour le "Type de runbook", prenez "Flux de travail PowerShell". Continuez.

Azure Runbook PowerShell

À la suite de la création du runbook, un éditeur de code s'affiche. C'est ici qu'il va falloir coder notre runbook PowerShell en partant de ce bloc comme point de départ :

workflow Start-VM-7am
{
< notre code doit être intégré ici >
}

Voici le code à inclure (et ensuite je vous l'explique) :

workflow Start-VM-7am
{
    # Obtenir les informations du compte Azure Automation
    $ConnexionAz = Get-AutomationConnection -Name 'AzureRunAsConnection'

    # Ajouter le compte à la session en cours
    Add-AzureRMAccount -ServicePrincipal -Tenant $ConnexionAz.TenantID -ApplicationId $ConnexionAz.ApplicationId -CertificateThumbprint $ConnexionAz.CertificateThumbprint

    # Récupérer la liste des machines virtuelles à démarrer
    $VmAz = Get-AzureRMVM

    # Démarrer chaque VM
    $VmAz | Start-AzureRMVM
}

En image, cela donne :

La première étape consiste à récupérer les informations de connexion à Azure Automation via "Get-AutomationConnection", puis d'ajouter les informations du compte à la session en cours via Add-AzureRMAccount et notre variable $ConnexionAz.

Pour la suite, c'est-à-dire la cmd "Get-AzureRMVM" c'est pour récupérer la liste des machines virtuelles à démarrer et stocker cette liste dans une variable nommée $VmAz. Dans mon exemple, je récupère la liste de toutes les VMs, donc je vais démarrer toutes les VMs. Autrement dit, vous allez probablement vouloir faire autrement, en faisant un filtre sur un tag, par exemple.

Pour cela, il faudra ajuster cette ligne :

$VmAz = Get-AzureRMVM | Where-Object {$_.Tags.EtatVM -eq "Test"}

Dans l'exemple ci-dessus, je récupère uniquement les VMs dont le tag "EtatVM" est égal à "Test". A vous d'adapter selon vos tags. Pour cibler une VM spécifique, il faut préciser son nom et le groupe de ressources associé à cette VM. Voici un exemple avec "SRV-WSUS" :

$VmAz = Get-AzureRMVM -ResourceGroupName "IT-CONNECT_VM_SRV_WSUS" -Name "SRV-WSUS"

Une fois que la liste des VM est récupérée, on démarre chaque VM grâce à la commande Start-AzureRMVM puis le tour est joué ! En fin de compte, quand votre bout de code est prêt (tout en sachant qu'il est modifiable à tout moment), cliquez sur "Enregistrer" et "Publier".

Vous pouvez également cliquer sur "Volet de test" afin de tester votre runbook ! Attention, cela va réellement exécuter le script et démarrer les machines virtuelles.

Si la valeur "Terminée" s'affiche, c'est tout bon !Enfin, si vous obtenez une erreur et que vous voyez le texte "Run Login-AzureAccount to login", suivez l'étape suivante pour corriger le problème.

V. J'obtiens l'erreur "Run Login-AzureAccount to login" : que faire ?

Avant tout, sachez que cette partie du tutoriel s'adresse seulement à ceux qui ont rencontré l'erreur ci-dessous lors du test.

Run Login-AzureAccount to login

Pour corriger cette erreur, il faut accéder à la section "Comptes d'identification" (1) d'Azure Automation, puis créer un "Compte d'identification Azure" (2).

Run Login-AzureAccount to login

Une fois cette opération effectuée, ce compte Azure Automation sera capable de s'authentifier sur Azure et d'agir sur les ressources. Vous pouvez réexécuter votre test pour valider que cela fonctionne !

VI. Planifier l'exécution du runbook

La dernière étape consiste à créer une planification et à l'affecter à notre Runbook PowerShell. Pour créer une nouvelle planification à partir d'Azure Automation, nous devons cliquer sur "Planifications" (1) puis "Ajouter une planification" (2).

Azure Automation - Créer une planification

Nous pouvons nommer cette planification "Tous_les_jours_07h00" et définir la configuration suivante :

  • Démarrages : sélectionnez le lendemain et indiquez "07:00" (ou un autre horaire)
  • Fuseau horaire : France - Central European Time
  • Récurrence : périodique, tous les 1 jour
  • Définir l'expiration : "non" car cette planification doit s'exécuter tous les jours, pour toute la vie 🙂

Cliquez sur "Créer" pour valider.

Nous n'avons plus qu'à lier la planification avec le runbook "Start-VM-7am". Cliquez sur le runbook dans Azure Automation puis sur "Lier à une planification".

Choisissez l'objet "Tous_les_jours_07h00" qui correspond à la planification que nous venons de créer et validez.

La planification est bien liée à notre runbook ! Il est à noter que l'on peut ajouter plusieurs planifications à un même runbook, mais dans cet exemple ce n'est pas utile.

La configuration est terminée ! Ainsi, la machine virtuelle va s'arrêter à 23h00 et démarrer à 07h00, automatiquement, tous les jours !

The post Comment démarrer automatiquement une VM Azure ? first appeared on IT-Connect.

Comment démarrer et arrêter une VM Azure avec PowerShell ?

19 avril 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons voir qu'il est possible d'arrêter ou de démarrer une VM Azure avec PowerShell. Pour diverses raisons, on peut avoir besoin d'agir sur l'état d'une VM Azure à partir d'un script PowerShell, ce qui peut être le cas lorsque l'on cherche à réaliser des économies.

En effet, sur Azure, il faut payer lorsqu'une machine virtuelle tourne, alors si on l'arrête la nuit, on peut envisager de réaliser quelques économies. Même si cela ne s'applique pas à tous les types de machine, car certains services doivent tourner H24, ce n'est pas forcément le cas des VM de test.

Dans cet article, je vais simplement vous expliquer comment réaliser ces actions manuellement avec PowerShell, sans exploiter un autre service Azure. Dans un second article, nous verrons comment démarrer automatiquement les machines virtuelles chaque jour, à une heure spécifique, via PowerShell et Azure Automation.

II. Les modules Az.Accounts et Az.Compute

Pour établir une connexion à Azure puis agir sur les serveurs virtuels, nous avons besoin de deux modules PowerShell : Az.Accounts et Az.Compute.

Pour installer le module Az.Accounts :

Install-Module -Name Az.Accounts

Pour installer le module Az.Compute :

Install-Module -Name Az.Compute

III. Connexion au tenant Azure avec PowerShell

Pour agir sur le Cloud Azure avec PowerShell, nous devons établir une connexion avec le cmdlet Connect-AzAccount du module Az.Accounts :

$CredAzure = Get-Credential
Connect-AzAccount -Credential $CredAzure

Si vous souhaitez plus d'informations sur les différentes méthodes de connexion, vous pouvez lire ce tutoriel :

IV. Arrêter une VM Azure avec Powershell

Tout d'abord, sachez que vous pouvez obtenir l'état d'une machine virtuelle avec cette commande :

Get-AzVM -Name "SRV-WSUS" -Status

Cela permettra de voir si elle est démarrée ou arrêtée, mais aussi de récupérer le nom du groupe de ressource (nous en aurons besoin plus tard).

Si l'on part du principe qu'elle est démarrée et que l'on souhaite l'arrêtée, on va utiliser le cmdlet "Stop-AzVM". Pour utiliser ce cmdlet, nous devons préciser plusieurs paramètres :

  • -ResourceGroupName : nom du groupe de ressource de la VM
  • -Name : nom de la VM
  • -Force : arrêter la VM sans demander la confirmation
  • -StayProvisioned : arrêter la VM tout en réservant les ressources (pour être sûr de pouvoir la démarrer ultérieurement)

Ce qui donne :

Stop-AzVM -ResourceGroupName "IT-CONNECT_VM_SRV_WSUS" -Name "SRV-WSUS" -Force -StayProvisioned

En regardant la sortie dans la console, vous pouvez savoir si l'opération a fonctionnée ou non :

OperationId : f8b64a38-yyyy-zzzz-8ba9-xxxxxxxx
Status : Succeeded
StartTime : 4/11/2022 9:42:57 AM
EndTime : 4/11/2022 9:43:28 AM
Error :

Maintenant, on pourrait s'appuyer sur les tags (étiquettes) pour cibler plusieurs machines virtuelles. Personnellement, je trouve les tags particulièrement pratiques, car cela facilite le ciblage, notamment quand on utilise PowerShell. J'utilise sur mes VMs une étiquette nommée "Type" qui peut prendre deux valeurs : "Serveurs" ou "PC", afin de différencier mes VM "Serveurs" de mes VM qui sont des PC virtualisés.

Note : on peut imaginer créer des tags correspondants à des heures d'extinctions, et se baser sur cette valeur pour éteindre les VMs au bon moment.

Par exemple :

Exemple d'un tag sur une VM Azure

Ainsi, on peut récupérer la liste des VM à arrêter en se basant sur une valeur spécifique pour le Tag. Pour récupérer la liste des VMs avec l'étiquette "Type = PC", on peut faire :

$VMtoStop = Get-AzVM | Where-Object {$_.Tags.Type -eq "PC"}

Il ne reste plus qu'à créer une boucle Foreach qui va parcourir la variable $VMtoStop et arrêter l'ensemble des machines :

Foreach($VM in $VMtoStop){
     Stop-AzVM -ResourceGroupName $VM.ResourceGroupName -Name $VM.Name -Force -StayProvisioned
}

Ceci est un exemple avec un filtre basé sur un tag, mais il y a bien sûr d'autres filtres possibles (nom, groupe de ressource, localisation, etc.).

V. Démarrer une VM Azure avec PowerShell

Nous venons de voir comment arrêter une VM Azure avec PowerShell. Désormais, nous allons voir comment démarrer une VM Azure avec PowerShell via le cmdlet Start-AzVM. Son utilisation est également très simple puisqu'il suffit de préciser le nom du groupe de ressource et le nom de la VM en elle-même. Ces deux paramètres sont obligatoires.

Voici un exemple pour démarrer un ordinateur virtuel nommé "SRV-WSUS" du groupe de ressource "IT-CONNECT_VM_SRV_WSUS" :

Start-AzVM -ResourceGroupName "IT-CONNECT_VM_SRV_WSUS" -Name "SRV-WSUS"

Là encore, en nous inspirant de l'exemple précédent basé sur la valeur d'une étiquette, nous pourrions démarrer uniquement certaines machines virtuelles.

The post Comment démarrer et arrêter une VM Azure avec PowerShell ? first appeared on IT-Connect.

Comment obtenir l’état d’une VM Azure avec PowerShell ?

14 avril 2022 à 13:00

I. Présentation

Dans ce tutoriel, nous allons voir comment une simple commande PowerShell peut nous permettre d'obtenir l'état d'une VM Azure, afin de savoir si elle est en cours d'exécution, arrêtée, voire même arrêtée et libérée.

Pour obtenir l'état de la machine virtuelle, il faut interagir directement avec le tenant et la souscription Azure où se situe vos ressources Cloud.

II. Utilisation de Get-AzVM

A. Comment utiliser Get-AzVM ?

La commande Get-AzVM doit être utilisée pour obtenir l'état d'une machine virtuelle Azure en ligne de commande, à l'aide de PowerShell. Cette commande est accessible directement à partir d'Azure Cloud Shell (avec un navigateur sur le portail Azure, voire même depuis Windows Terminal), d'une console PowerShell ou de votre éditeur de code préféré.

Pour une utilisation en local, via une console Windows PowerShell par exemple, il faudra au préalable installer le module "Az.Compute" de PowerShell dont fait partie cette commande.

Install-Module -Name Az.Compute

Ensuite, il faut établir une connexion au tenant Azure et s'authentifier afin d'avoir accès aux différentes ressources. Plusieurs façons de faire, la plus simple étant de saisir les identifiants dans un navigateur :

Connect-AzAccount

Si vous souhaitez plus d'informations sur les différentes méthodes de connexion, vous pouvez lire ce tutoriel :

B. Récupérer le statut d'une VM avec Get-AzVM

Donc, une fois que la connexion est établie, on peut requêter notre tenant pour obtenir l'état de la machine virtuelle avec Get-AzVM. Nous pouvons essayer de récupérer l'état de la VM nommée "SRV-WSUS" présente sur mon tenant Azure. Pour obtenir l'information, il suffit de spécifier le nom de la VM et d'ajouter le paramètre -Status.

Get-AzVM -Name "SRV-WSUS" -Status

Ici, la commande retourne une colonne nommée "PowerState" avec la valeur "VM running". Nous pouvons en déduire que la VM est en cours d'exécution.

Get-AzVM avec l'option -Status

La valeur pourrait être différente :

  • VM deallocated : signifie que la VM est arrêtée et libérée
  • VM stopped : signifie que la VM est arrêtée (et non libérée)

Si l'on ne précise pas le nom d'une machine virtuelle, on peut obtenir le statut de toutes les VM :

Get-AzVM -Status

Il est également possible de filtrer par région Azure (ou par groupe de ressources), sans oublier à chaque fois le paramètre -Status afin d'avoir la colonne "PowerState" :

Get-AzVM -Location francecentral -Status

Je vais terminer cet article par un dernier exemple : comment obtenir la liste de toutes les VM Azure éteintes ? Tout simplement, en ajoutant un filtre sur la propriété PowerState, comme ceci :

Get-AzVM -Status | Where{ $_.PowerState -eq "VM Stopped" }

Bien sûr, vous pouvez modifier la valeur du filtre pour obtenir la liste des machines virtuelles arrêtées et libérées, par exemple. Vous n'oublierez pas de déconnecter la session Azure après avoir joué avec PowerShell :

Disconnect-AzAccount

Pour plus d'informations sur la commande Get-AzVM :

The post Comment obtenir l’état d’une VM Azure avec PowerShell ? first appeared on IT-Connect.

Azure Conditional Access policies not working in Google Chrome

12 avril 2022 à 11:21

Microsoft offers many solutions and services to defend your Microsoft 365 tenancy. One of the most touted features available in Azure AD Premium P1 (and higher) is Azure Conditional Access. Conditional Access allows you to set policies that determine what type of devices, which users, and under what conditions a request to access a service may be allowed or blocked.

The post Azure Conditional Access policies not working in Google Chrome first appeared on 4sysops.

Comment se connecter à Azure avec PowerShell ?

12 avril 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à nous connecter sur un compte Azure en PowerShell à l'aide de la commande Connect-AzAccount, disponible au sein du module Az.Accounts.

L'objectif est de se connecter au Cloud Azure dans le but de pouvoir interagir avec des ressources, notamment des VM Azure, à partir d'une console PowerShell, d'un éditeur de code ou d'un script. Pour se connecter à Azure AD, c'est une autre méthode qu'il faut utiliser. Ce tutoriel me semble important, car l'authentification sur Azure est une étape indispensable avant de pouvoir exécuter des actions au travers d'autres commandes.

Avant de commencer, vous devez installer le module Az.Accounts sur votre machine afin de pouvoir utiliser Connect-AzAccount :

Install-Module -Name Az.Accounts

II. Se connecter avec la méthode interactive

Nous allons commencer par la méthode interactive, qui consiste à s'authentifier manuellement dans un navigateur. Pour utiliser cette méthode, il suffit d'exécuter la commande sans paramètre :

Connect-AzAccount

Le navigateur par défaut défini sur votre machine va s'ouvrir afin de vous demander de vous authentifier sur Microsoft Azure. Il vous suffit de sélectionner un compte dans la liste ou de saisir votre adresse e-mail, puis d'indiquer le mot de passe correspondant.

Connect-AzAccount

Ensuite, une page blanche va s'afficher avec ce message

Authentication complete. You can return to the application. Feel free to close this browser tab.

Vous n'avez plus qu'à fermer la fenêtre ! La connexion est établie !

Dans le cas de l'utilisation d'un compte Microsoft personnel pour s'authentifier sur Azure, c'est un peu différent. En général, la console PowerShell retourne un message qui commence par :

WARNING: Unable to acquire token for tenant '699090000000000000'

Et, il est demandé de relancer la commande en précisant l'ID du tenant. En fait, soit on récupère l'ID du tenant dans la console PowerShell, ou en amont via le portail Azure en mode Web.

Ce qui donne :

Connect-AzAccount -TenantId 699090000000000000

Là encore, il est nécessaire de s'authentifier et de valider la connexion avec la double authentification. Par exemple, via un code de sécurité envoyé sur l'adresse e-mail de secours.

Au final, on arrive quand même à se connecter à Azure même si c'est légèrement différent.

III. Se connecter avec les identifiants

Pour se connecter automatiquement à l'aide d'un script, ou utiliser une méthode plus habituelle, on peut s'appuyer sur l'utilisation d'identifiants via un objet PSCredential. Pour cela, on va stocker les identifiants dans une variable, par exemple $CredsAz et les utiliser au moment d'appeler Connect-AzAccount.

Pour obtenir les identifiants, il y a plusieurs façons de faire, notamment la manière interactive avec Get-Credential.

Ce qui donne :

$CredsAz = Get-Credential
Connect-AzAccount -Credential $CredsAz

En image :

Connect-AzAccount avec identifiants

Là encore, cette opération fonctionne très bien avec un compte Microsoft professionnel, rattaché à Office 365, par exemple.

Par contre, avec un compte Microsoft personnel, c'est pénible mais la connexion n'est pas possible de cette façon. La console retourne l'erreur "Connect-AzAccount: UsernamePasswordCredential authentication failed: ROPC does not support MSA accounts.". Personnellement, je n'ai pas trouvé de solution.

IV. Se connecter avec la méthode Device Login

La méthode de connexion "Device Login" nécessite de saisir un code de connexion sur le site de Microsoft. Ce code de connexion est généré sur la machine locale depuis laquelle on souhaite se connecter, d'où cette notion de "Device Login", car on authentifie le périphérique en quelque sorte.

Dans le but d'utiliser cette méthode de connexion, il faut utiliser le cmdlet Connect-AzAccount avec le paramètre "-DeviceCode" :

Connect-AzAccount -DeviceCode

Suite à l'exécution de cette commande, le message suivant s'affiche dans la console :

WARNING: To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code EST3WY5DN to authenticate.

En fait, il faut se connecter sur le site "https://microsoft.com/devicelogin" (depuis la même machine ou une autre machine), s'authentifier et saisir le code indiqué dans la console PowerShell, ici "EST3WY5DN".

Une fois que c'est fait, le message ci-dessous s'affiche dans le navigateur.

You have signed in to the Microsoft Azure PowerShell application on your device. You may now close this window.

La connexion est établie dans la console PowerShell : il ne reste plus qu'à l'exploiter ! 🙂

Sachez que pour déconnecter toutes les sessions ouvertes par l'utilisateur en cours, il y a une commande magique :

Clear-AzContext

Dans les prochains articles, nous verrons comment exploiter cette connexion à Azure établie avec PowerShell pour réaliser diverses actions.

The post Comment se connecter à Azure avec PowerShell ? first appeared on IT-Connect.

Azure Arc: Manage on-prem Windows Server VMs with Azure Resource Manager

8 avril 2022 à 11:39

Azure Arc allows organizations to extend the Azure Resource Manager control plane from the public cloud to their on-premises environments so that they can manage these resources like they natively existed in Azure and utilize services like Automanage. This provides functions such as remediation of configuration drifts, setting up backup and monitoring, and hotpatching Windows Server.

The post Azure Arc: Manage on-prem Windows Server VMs with Azure Resource Manager first appeared on 4sysops.

Using Azure AD dynamic groups for Microsoft 365 resources

17 mars 2022 à 11:20

Azure AD supports so-called dynamic groups. A dynamic group can comprise devices or users on which you set query rules to determine their membership. These groups can then be used throughout your Microsoft 365 tenancy to provide access to resources, with a few exceptions for Microsoft Exchange Online.

The post Using Azure AD dynamic groups for Microsoft 365 resources first appeared on 4sysops.

VPN IPsec site-à-site entre Azure et PfSense

15 mars 2022 à 10:00

I. Présentation

Dans ce tutoriel, nous allons apprendre à monter tunnel VPN IPsec entre un pare-feu PfSense et Azure, le Cloud de Microsoft. Grâce à ce tunnel VPN, les machines situées derrière le pare-feu PfSense pourront communiquer avec les ressources Azure, notamment les machines virtuelles. Même s'il est possible de monter un véritable firewall dans Azure, ici l'objectif est de s'appuyer sur une gateway virtuelle proposée par Azure.

Récemment, j'ai mis en place ce tunnel VPN entre mon lab chez OVH sur lequel j'utilise un PfSense, et le Cloud Azure, sur lequel j'envisage de créer des serveurs virtuels supplémentaires. L'objectif étant de permettre aux serveurs de communiquer entre eux, malgré qu'ils soient sur deux Cloud différents.

Voici le schéma qui représente ce que l'on va faire :

Schéma VPN Azure PfSense

Je pars du principe que le pare-feu Pfsense est déjà en place. Côté Azure, je pars de zéro : aucune machine virtuelle au sein de la souscription que je vais utiliser. Cela est important dans le sens où le réseau virtuel créé dans le cadre de ce tutoriel sera utilisé par la suite pour connecter des VMs sur un sous-réseau dédié.

Si vous avez un environnement Azure existant avec un réseau virtuel, vous pouvez ajouter un sous-réseau supplémentaire et la passerelle de réseau virtuel sur ce même réseau.

II. Configurer un tunnel VPN dans Azure

Commençons par la préparation de l'environnement Azure, étape par étape.

A. Créer un réseau virtuel

À partir du portail Azure, recherchez "Réseaux virtuels" dans tous les services, comme ceci :

Cliquez sur le bouton "Créer", un assistant va démarrer... Il faudra tout d'abord choisir l'abonnement et le groupe de ressources, ce qui est classique. Ensuite, il faut nommer ce réseau virtuel ; pour ma part, je choisis "VNET-10.10.0.0-16", car je vais utiliser le réseau "10.10.0.0/16".

Dans l'onglet "Adresses IP", on détermine le réseau IP à utiliser, ici "10.10.0.0/16". Il faut ensuite "Ajouter un sous-réseau" : ce sera le sous-réseau pour connecter les VM, puisque le sous-réseau pour le VPN sera ajouté plus tard. Conformément à mon schéma, je définis le sous-réseau "10.10.100.0/24" et je le nomme "VM-10.10.100.0".

Il ne reste plus qu'à poursuivre jusqu'à la fin et créer le réseau virtuel.

Première étape validée.

B. Créer un sous-réseau de passerelle

Accédez au réseau virtuel qui vient d'être créé, puis sur la gauche cliquez sur "Sous-réseaux" et ensuite sur le bouton "Sous-réseau de passerelle".

Le nom est fixe, en l'occurrence "GatewaySubnet" et on va lui attribuer un sous-réseau IP, ici "10.10.110.0/24". Ce sous-réseau sera utilisé pour les communications dans le tunnel VPN en lui-même.

Validez la création, car il n'y a pas d'autres paramètres à définir.

Deuxième étape validée !

C. Création de la passerelle de réseau virtuel

Nous devons créer une passerelle de réseau virtuel. Pour cela, dans tous les services, recherchez "Passerelles de réseau virtuel", comme ceci :

Nommez cette passerelle, par exemple "VPN-Azure-Pfsense" et choisissez "VPN" comme "Type de passerelle", puis "Basé sur itinéraires" comme "Type de VPN".

Ensuite, il faut sélectionner un type de passerelle (option "Référence (SKU)"). Ce choix doit-être fait en fonction de vos besoins, notamment la bande passante, toute en sachant que c'est passerelle Azure a un coût. Afin de faire le bon choix, je vous recommande de consulter cette page : Tarification Passerelle VPN. Mais aussi celle-ci pour des infos plus techniques : Microsoft Docs.

Il restera à choisir le réseau virtuel "VNET-10.10.0.0-16" créé précédemment et qui contient le sous-réseau "GatewaySubnet". Ce dernier sera automatiquement sélectionné.

Pour l'adresse IP publique, je n'en ai pas, donc je choisis "Créer" et je la nomme "IP-VPN-Azure-Pfsense". Il n'y a pas d'autres options à configurer.

La passerelle VPN peut-être créée ! Cette opération est assez longue, je dirais environ 20 minutes : patientez pendant que le message "Le déploiement est en cours" s'affiche. Enfin, je veux dire, allez prendre un café ! 🙂

Quand ce sera fait, direction l'étape suivante !

D. Ajouter une connexion site-à-site

La passerelle VPN nous donne accès à son adresse IP publique, dans la section "Vue d'ensemble". Une valeur à garder de côté pour la suite des événements.

Sur la gauche, cliquez sur "Connexions" puis "Ajouter".

L'ajout de la connexion va permettre de déclarer notre pare-feu Pfsense puisqu'il représente l'autre extrémité du tunnel VPN. Cette connexion sera nommée "Peer_Pfsense" de mon côté. Il faut choisir "Site à site (IPsec)" comme "Type de connexion", puis cliquez sur "Choisir une passerelle de réseau local".

Cela va permettre de déclarer le PfSense, avec son adresse IP ou son nom DNS (FQDN), comme ceci :

Validez afin de revenir sur la création de la connexion. Cette fois-ci, la passerelle "Peer_Pfsense_Net" apparait bien. Il ne reste plus qu'à définir une clé partagée complexe et qui sert de secret pour l'authentification dans le tunnel VPN. Choisissez "IKEv2", car plus sécurisé et le tour est joué !

Validez ! La partie Azure est terminée ! Passons à la configuration de Pfsense.

III. Créer le tunnel IPSec sur PfSense

A. IPSec Phase 1

IPsec est pris en charge nativement par Pfsense donc il n'est pas nécessaire d'installer un paquet additionnel. Sous le menu "VPN", cliquez sur "IPsec".

Dans l'onglet "Tunnels", cliquez sur le bouton "Add P1" pour configurer la phase 1 de notre tunnel. Choisissez "IKEv2" au sein de "Key Exchange Version", car nous allons configurer la phase 2 dans un second temps, et c'est cette version que nous avons choisie sur Azure. Ce tunnel est en IPv4 et nous allons utiliser l'interface WAN du Pfsense. Concernant le champ "Remote Gateway", indiquez l'adresse IP publique de la passerelle VPN Azure (valeur obtenue précédemment).

Pour l'authentification, choisissez "Mutual PSK" afin de définir la même clé partagée que sur l'interface Azure au niveau du champ "Pre-Shared Key". Les deux passerelles VPN doivent utiliser le même secret partagé. Pour les algorithmes de chiffrement, vous pouvez utiliser la même configuration que dans cet exemple.

Pas de modification à effectuer pour le reste des options. Cliquez sur "Save".

B. IPSec Phase 2

Au sein de l'onglet "Tunnels", créez la phase 2 associée à la phase 1 que l'on vient de créer. Là encore, il faut renseigner plusieurs options :

  • Local network : le réseau local qui peut accéder au réseau distant, ici c'est mon "LAN subnet" de mon Pfsense, c'est-à-dire le sous-réseau derrière la carte LAN.
  • Remote network : le réseau distant, à l'autre extrémité du tunnel VPN auquel on souhaite accéder, ici c'est "10.10.100.0/24" puisque c'est mon sous-réseau Azure où mes VMs sont connectées

Il faut également configurer les algorithmes pour l'échange de clés. Voici ma configuration :

Ainsi que les algorithmes de hachage. Une fois que c'est fait, cliquez sur "Save".

C. Etat du tunnel IPsec

La configuration est terminée, l'état du tunnel IPsec est visible dans "Status > IPsec". Il y a notamment un bouton pour lancer la connexion. Dans le même temps, je vous invite à tenter de vous connecter sur une ressource distante, située sur le Cloud Azure, par exemple une VM. Ensuite, le tunnel va passer sur l'état "ESTABLISHED", comme ceci :

Tunnel ipsec azure pfsense

Si ce n'est pas le cas et que le tunnel ne veut pas se connecter, vous pouvez cliquer sur le bouton rouge dans PfSense, à gauche du point d'interrogation, pour voir les logs IPsec. Depuis mon LAN Pfsense, je parviens à me connecter à un serveur du réseau "10.10.100.0/24" hébergé sur Azure.

VPN Azure Pfsense

Voilà, le tunnel VPN IPsec est monté : il n'y a plus qu'à en profiter !

Sachez que les règles de firewall du LAN Pfsense vers Azure doivent être gérées dans l'onglet "LAN" du pare-feu (Firewall > Rules > LAN). Pour les règles d'Azure vers le LAN Pfsense, c'est dans l'onglet "IPsec" du pare-feu (Firewall > Rules > IPsec).

The post VPN IPsec site-à-site entre Azure et PfSense first appeared on IT-Connect.

Joining Azure AD fails—Can't connect to URL for your organization's MDM terms

10 février 2022 à 05:26

When joining a device to Azure AD, you may receive the following error message:

Something went wrong. It looks like we can't connect to the URL for your organization's MDM terms of use. Try again, or contact your system administrator with the problem information from this page.

The post Joining Azure AD fails—Can't connect to URL for your organization's MDM terms first appeared on 4sysops.

Permanently delete a Key Vault in Azure using PowerShell

4 février 2022 à 15:33

In this post, we will be looking at purging options to permanently delete a Key Vault and fully erase all the secrets, keys, and certificates in it. Sometimes destroying data properly is as important as keeping it secure. We all know that there are some cases in which the data is actually not deleted completely, even if we think it is. Key Vaults in Azure are a good example of this.

The post Permanently delete a Key Vault in Azure using PowerShell first appeared on 4sysops.

Restore Azure Files with PowerShell

28 janvier 2022 à 18:12

On Azure, the files in file shares can be protected with integration of a Recovery Services vault. In this way, you can create backups, and you can restore files and folders easily whenever needed. In this post, we will be looking at configuring Recovery Services vaults on Azure file shares and restoring deleted files from a backup using PowerShell.

The post Restore Azure Files with PowerShell first appeared on 4sysops.
❌