Articles Tagués ‘Hicham KADIRI’

Printf « Hello RDS Guys ^__^ »

Comme vous le savez, Windows Server 2019 est disponible (GA > Generally Available) depuis début Octobre.

Note : consultez cet article pour en savoir plus

Plusieurs améliorations ont été apportées au rôle R(remote) D(esktop) S(ervices) sous Windows Server 2019, cela concerne la partie Server (RD Servers), End-User (Experience Utilisateur) mais aussi la partie intégration avec le Cloud (Azure bien évidemment :)).

Je vous présenterai donc à travers cet article toutes les nouveautés introduites avec RDS Windows Server 2019 et ce qu’il faut retenir pour vos prochains projets de migration vers RDS 2019.

 

Les « Areas » de développement

L’équipe RDS Corp a focalisé sur efforts sur les axes de développement suivants :

  • Simplifier la gestion d’une infrastructure RDS
  • Améliorer l’expérience utilisateur
  • Améliorer la sécurité des environnements RDS
  • Faciliter l’intégration d’une infra RDS avec le Cloud (Azure)

 

Gestion simplifiée d’une infrastructure RDS

Deux améliorations majeures à noter :

  • La première concerne le service RDLS (Remote Desktop Licensing Server)
  • La deuxième est relative aux applications publiées (RemoteApp) jugées comme « Slow RemoteApp Experience« 
RD Licensing Server : HA & Mode Offline Active Directory

Enfinnnnnnnn du HA pour le RDLS :xD

Avec RDS 2019, vous pouvez désormais configurer le service RD Licensing dans un vrai mode « HA : High Availability ».

Avec les versions RDS 2016, 2012 R2 ou encore 2012, la seule possibilité permettant la redondance du service RDLS consistait à déployer deux serveurs RDLS (ou +) et y installer la même quantité de CAL pour permettre une continuité de service en cas de perte d’un des deux serveurs.

Avec RDS 2019, il est désormais possible de configurer le service de Licensing RDS en mode HA avec une Built-in Feature, similaire à celle du Broker. Vous aurez donc besoin d’une instance SQL pour héberger la base de données RDLS-HA qui stockera la configuration de la haute disponibilité du service RDLS.

En outre, une nouvelle amélioration pour le service RDLS a été introduite avec Windows Server 2019, il s’agit de la prise en charge d’un Mode « Offline Active Directory« .

Je m’explique :

Sur les anciennes versions RDS (2016 et antérieur), le rôle RDLS avait toujours besoin d’accéder aux services d’annuaires Active Directory (ADDS) et plus précisément d’une connectivité avec un Domain Controller pour mettre à jour certains attributs AD avec les informations relatives aux Licences Utilisateurs (CAL RDS Per-User), avec RDS 2019 cela n’est plus nécessaire. En effet, un RDLS supporte désormais un mode « AD Offline » et peux mettre à jour les informations de Licensing d’un user RDS sur ses propriétés AD sans avoir besoin de contacter un DC.

Nouvelle API PerfMon pour les « Slow RemoteApp »

Des nouveaux compteurs de performances ont été ajoutés pour RDS 2019 à travers une nouvelle PerfMon API (Application Programming Interface). Ces compteurs vous aideront à collecter les données/informations (metrics et autres) liées aux RemoteApp présentant des problèmes de stabilité et de performance pour diagnostiquer et améliorer l’expérience utilisateur.

 

Expérience Utilisateur améliorée

Toujours dans un souci d’amélioration de l’expérience utilisateur, Microsoft a bien travaillé la partie End-User Experience pour les environnements RDS 2019, résultats :

  • Ajout de Notifications « Modernes » sur les Sessions Bureau à distance et plus précisément au niveau du « Centre de Notifications », le but étant d’améliorer l’utilisation des RemoteApp telles que Microsoft Outlook ou encore Teams.
  • La redirection des « Caméras » intégrées ou externes (USB) vers une Session RDS est désormais possible : Vous pouvez rediriger jusqu’à 8 Caméras sur une Session Bureau à distance :

  • Des nouvelles améliorations ont été apportées au niveau du DDA (Discrete Device Assignment) sous RDS 2019 pour augmenter le niveau de sécurité et assurer une meilleure isolation des VMs. Ces améliorations des technologies de virtualisation des GPU se traduiront par une réduction du trafic réseau et une lecture vidéo plus fluide.

  • Enfin, l’utilisation du CPU et la Bande Passante sur le client Web et Serveur RDSH ont été réduites, cela permet une meilleure expérience des utilisateurs se connectant via le nouveau Client Web.

 

Plus de sécurité avec RDS 2019

L’équipe produit RDS a également concentré ses efforts sur l’aspect « Sécurité ».

La sécurité RDS a été amélioré à travers :

  • L’Intégration avec « Windows Admin Center » : cela vous permet de regrouper tous les serveurs Remote Desktop locaux et distants (RD Broker, Web Access…) en une seule console et les gérer de manière centralisée
  • L’Optimisation de Windows Defender pour prise en charge du Multi-Session et une meilleure sécurité des environnements Bureau à distance
  • Le RD Web Client prend désormais en charge le SSO (Single Sign-On) pour simplifier le processus d’authentification et rendre l’expérience utilisateur meilleure pour les clients se connectant via le Client Web
  • De nouvelles fonctionnalités de sécurité comme par exemple le chiffrement DTLS (Datagram Transport Layer Security) qui peut être activé facilement pour renforcer la sécurité au niveau de vos déploiements RDS.

 

RDS 2019 & Microsoft Azure

La vision de Microsoft depuis la sortie de Windows Server 2016 déjà, était de pousser ses clients à déployer RDS dans Azure.

En effet, avec RDS 2016, vous aviez déjà la possibilité de configurer le service Broker en mode HA en utilisant l’offre PaaS (Platform-as-aService) Azure qu’est Azure SQL Database.

L’utilisation du Cloud Azure offre plusieurs avantages par rapport à un hébergement traditionnel (dans un Datacenter OnPrem > sur du VMware vSphere ou Hyper-V Server) :

  • Réduction des coûts : en utilisant le Cloud Azure, vous passez généralement du mode CAPEX (investissement dans le matériel & logiciel) au mode OPEX (consommation). Avec Azure, vous êtes généralement dans un mode « Pay-as-you-go », cela veut dire que vous payez uniquement les ressources Azure (Compute/VM, Stockage, Réseau…) quand celles-ci sont utilisées (eg : je consomme mes services RDS uniquement du Lundi au Vendredi de 8h à 18h).
  • Tirer profit de la puissance de calcul du Cloud, de la scalabilité, flexibilité et agilité
    • Eg : vous pouvez configurer vos VM avec du scaling-out & down pour que vos serveurs RDS peuvent monter en charge (de manière automatique) quand des pics d’activité se présentent et redescendre à leur configuration initiale quand une baisse de charge a lieu. Dans un mode traditionnel, vous devez rajouter de la RAM, vCPU voire acheter un nouveau matériel (serveur, changer le type de la carte réseau…etc)
  • Réduction MCO/Effort de gestion : Azure étant une plateforme de Cloud Publique, toute l’infrastructure physique Serveur/Storage/Network est gérée et maintenue par l’éditeur (MS), vous n’avez donc plus à vous soucier des pannes matérielles, maintenances à planifier …Etc

Pour faciliter l’adoption du Cloud Azure, Microsoft a introduit un mode « RDS Hybride ». En effet, l’infrastructure RDS 2019 peut désormais être déployée en mode « Hybride », mode dans lequel les serveurs RD Connection Broker, Web Access et Gateway sont hébergés dans Azure et les Hôtes de Session hébergés dans votre Datacenter local.

 

Prise en charge  {Azure Key Vault} & {Azure SQL Database}

Une des améliorations majeure quant au déploiement du rôle RDS dans Azure est l’intégration avec le service « Azure Key Vault ».

Azure Key Vault est la solution de « Key Management » d’Azure qui vous permet de stocker de manière sécurisée vos clés de chiffrement, Codes/Secrets/Crédentials…etc

Dans le cadre d’un déploiement RDS, les certificats SSL utilisés pour chiffrer les différents échanges au niveau de la Gateway, Web Access et RD Publishing/SSO peuvent désormais être stockés dans un Azure Key Vault.

Note : je prépare un Step-by-step guide à travers lequel je vous détaillerai comment utiliser Azure Key Vault pour stocker les certificats SSL RDS, il sera bientôt publié sur mon Blog So Stay Connected :).

 

De plus, Azure SQL Database peut héberger vos bases de données RDCB et RDLS HA, cela vous évite le déploiement d’une infrastructure SQL OnPrem dédiée (et complexe :)).

Enfin, Microsoft promets un nouveau model de Licensing RDS sur Azure à travers le Programme CSP (Cloud Solution Provider), nous aurons plus d’informations sur le sujet bientôt, fin Octobre normalement.

 

Useful Informations /Documentations

Pour les personnes n’ayant peu ou pas de connaissance sur les services Azure cités plus haut, je vous invite à consulter les liens suivants :

Je suis en train de finaliser plusieurs articles autour de RDS 2019, abonnez-vous sur mon Blog (si ce n’est pas déjà fait :)) pour rester informé de tout nouvel article publié.

A bientôt

#HK

Publicités

L’équipe Windows Corp a récemment annoncé (01 Octobre/18) la disponibilité des paramètres de la « Security Configuration Baseline » pour Windows 10 1809 (RS5 > “Redstone 5« ) et Windows Server 2019.

Notez qu’il s’agit ici d’une version « Draft« . La version finale ne devrait pas tarder à arriver. Stay connected, abonnez-vous sur le Blog de MS TechNet

Le contenu de cette « Security Baseline » est disponible en téléchargement à l’URL suivante :

Windows-10-1809-Security-Baseline-DRAFT.zip

 

Contenu de la Security Baseline ?

Le zip file contient plusieurs :

  • GPOs : plusieurs GPOs sont fournies avec le fichier zip téléchargé via le lien ci-dessus. Ces GPOs peuvent être importées directement dans votre environnement Windows.
  • Script PowerShell : des scripts PowerShell sont également fournis avec le fichier zip. Ceux-ci vous permettent d’appliquer directement les GPOs à vos stratégies locales
  • Fichiers ADMX personnalisés
  • Documentations : plusieurs documents techniques intéressants sont disponibles :
    • MS Security Baseline Windows 10 v1809 and Server 2019.xlsx : La liste complète des paramètres applicables à WS 10 1809 et WS Server 2019
    • BaselineDiffs-to-v1809-RS5-DRAFT.xlsx : La liste des paramètres qui sont modifiés entre Windows 10 1803 et Windows 10 1809, et ceux modifiés entre Windows Server 2016 et Windows Server 2019
    • Windows 10 1803 to 1809 New Settings.xlsx : Les nouveaux paramètres introduits avec Windows 10 1809
    • Server 2016 to 2019 New Settings.xlsx : Les nouveaux paramètres introduits avec Windows Server 2019

 

Consultez cet article pour en savoir plus

Hi Folks, Great News !!!!

L’équipe Windows Server a récemment (Le 02/10/2018), annoncé la disponibilité générale de la nouvelle version d’OS Server : Windows Server 2019

Si vous êtes client SA (Software Assurance) Microsoft, vous pouvez désormais télécharger la version finale de Windows Server 2019 depuis le Portail VLSC (Volume Licensing Service Center) :

La version d’évaluation de Windows Server 2019 est aussi disponible sur l’Evaluation Center de Microsoft.

 

Windows Server 2019 est déjà sur le Marketplace Azure 🙂

Windows Server 2019 est également disponible depuis le Marketplace Azure, en revanche, l’image disponible est encore en « Pre-Release Software« , donc A NE PAS DEPLOYER SUR LES ENVIRONNEMENTS DE PRODUCTION :

Si vous devez déployer des Workloads (IaaS Azure) dans Azure, il faut (pour l’instant) déployer des images Windows Server 2016, car ce dernier reste jusqu’à présent le seul OS Server stable pouvant héberger des applications de production.

 

Disponibilité sur le MSDN & MPN

L’équipe Windows Server Corp a également confirmé la disponibilité (pour fin Octobre) des images Windows Server 2019 sur les Portails « Visual Studio Subscription (l’ancien portail MSDN) mais aussi M(icrosoft) P(artner) N(etwork).

Si vous êtes Partner MS (MPN), vous devrez voir apparaître les images WS2019 d’ici quelques semaines, donc soyez patients :).

Note : je suis en train de préparer un article détaillé sur les nouveautés introduites sur Windows Server 2019, vous aurez aussi mon Feedback suite aux différents P(roof) o(f) C(oncept) que j’ai réalisé sur cette nouvelle version.

 

Useful Links

Je vous ai regroupé ci-dessous quelques liens utiles pour Get Starter sur Windows Server 2019 :

 

A bientôt

#HK | Just Another IT Guy

 

Introduction

Dans le cadre d’un projet de Hardening/Sécurisation d’infrastructures systèmes (Windows Server ou Client), vous pouvez avoir comme exigence « La désactivation des ports USB /Accès aux USB Devices ».

Cela peut concerner sur les serveurs (Physiques ou Virtuels) et/ou Postes de travail.

Pour répondre à cette exigence, Microsoft fourni par défaut dans ses OS (Client & Server) des paramètres de Stratégie de Groupe vous permettant de mettre en place cette restriction.

Alors, comment ça marche ?

Avant l’application de la procédure décrite ci-dessous, Notez que dans l’exemple ci-dessous, mon Laptop (un WS10 > 1803) permet toujours l’accès à mes devices USB :

Maintenant lancez l’outil GPMC.msc si vous souhaitez appliquer cette restriction sur plusieurs machines jointes à un domaine AD, ou GPEdit.msc si vous souhaitez d’abord tester et valider la procédure sur une machine localement.

Développez ensuite :

Configuration Ordinateur > Stratégies > Modèles d’Administration > Système > Accès au stockage amovible > Toutes les classes de stockage amovible : refuser tous les accès

Pour désactiver l’accès aux devices USB, il suffit de cochez « Activé » :

Après application/refresh des stratégies de groupe (GpUpdate /Target:Computer), l’accès aux USB devices (USB Keys, External Disks…etc) devient interdit (accès refusé) :

 

Astuce : Désactiver les ports USB via Script 

La désactivation des ports USB peut également se faire via Script.

Dans l’exemple suivant, un simple script Batch basé sur le Command-Line Tool « REG.exe » vous permet de réaliser cette opération en changeant la valeur de la Clé « Start » et la positionnant à 4 (au lieu de 3).


REM ==== Important : vous devez exécuter le script en tant qu’Administrateur !
REM ===================================================

REG ADD HKLM\SYSTEM\CurrentControlSet\Services\USBSTOR /v Start /t REG_DWORD /d 4 /f


Information utile

Si vous souhaitez ré-activer l’accès aux ports USB, il suffit d’éditer le fichier (Script Batch) et positionnez la valeur de la clé « Start » à 3

 

Téléchargez le script

Ce script est disponible en téléchargement gratuit depuis la Gallery TechNet.

Téléchargez le script ici.

Hello again everyone,

Après un mois d’absence, now i’m back :).

Je vais enchaîner courant les prochaines à venir toutes les Last Updates/News/Improvements introduites à « My Favorite » Public Cloud Platform : Microsoft Azure 😀

Si vous étiez comme moi, impatient d’avoir la possibilité de déplacer vos Managed Disks/VMs vers d’autre Groupe de Ressource ou Abonnement Azure, eh bien sachez que cela est désormais possible, Yes ou pas Yes ^__^ ?

L’équipe Azure Corp a en effet annoncée (le 25/09) la disponibilité d’une feature permettant cette opération.

Cette feature est fournie à travers un « FeatureProvider » Azure, qu’il faut d’abord enregistrer au niveau de votre Azure Tenant.

HowTo : Déplacez vos Managed Disks/VMs vers un autre Groupe de Ressource ou Abonnement

Tout d’abord, connectez-vous sur votre compte Azure depuis une instance PowerShell locale, pour ce faire, saisissez les commandes suivantes :

IpMo AzureRM : pour importer le module PowerShell AzureRM

Note : si le module PS AzureRM n’est pas présent sur votre machine locale, je vous invite à suivre les instructions détaillées dans cet article pour l’installer correctement.

Login-AzureRMAccount : pour lancer la fenêtre d’authentification Microsoft

Une fois connecté, exécutez la Cmd-Let « Get-AzureRMSubscription » pour afficher la liste des abonnements (Subscriptions) Azure associés à votre compte :

Pour notre DEMO, l’abonnement « Microsoft Azure Sponsorship » sera utilisé, la commande suivante a donc été utilisée : Select-AzureRMSubscription -Subscription « Microsoft Azure Sponsorship »

Maintenant, connectez-vous sur le portail Azure (https://portal.azure.com) et sélectionnez le RG (Resource Groups) contenant les Managed Disks à déplacer.

Dans l’exemple suivant, trois RGs sont hébergés au niveau de mon abonnement « Microsoft Azure Sponsorship » :

Le but de cette DEMO, est de déplacer la VM hkdeviisvm001 (avec son Managed Disk) placée dans le RG « hk-dev-rg » vers « hk-preprod-rg » :

Comme discuté précédemment, pour pouvoir déplacer votre ou vos VMs utilisant des « Managed Disks », vous devez d’abord enregistrer la feature « ManagedResourceMove« , fournie avec le le fournisseur d’espace de nom « Microsoft.Compute« .

Pour ce faire, exécutez les deux commandes PS ci-dessous :

Register-AzureRmProviderFeature -FeatureName ManagedResourcesMove -ProviderNamespace Microsoft.Compute

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.Compute

Comme indiqué au niveau de l’état d’enregistrement (RegistrationState), la fonctionnalité « ManagedResourcesMove » est toujours en « Registering »

Avant de pouvoir déplacer vos Managed Disks/VMs, l’enregistrement de cette fonctionnalité doit passer à « Registered »

Nous allons maintenant déplacer la VM hkdeviisvm001 vers le RG « hk-preprod-rg« , pour ce faire, il suffit simplement de sélectionner la VM et ses objets associés (NIC, Disk, …), cliquez sur le bouton « ->Déplacer » et cliquez ensuite sur « Déplacer vers un autre groupe de ressource » :

Note : vous avez également la possibilité de déplacer ces mêmes ressources Azure vers un autre Abonnement, vous devez sélectionner la deuxième option qu’est « Déplacer vers un autre abonnement« 

Vous êtes automatiquement rediriger vers la fenêtre suivante. Spécifiez le groupe de ressource cible, cochez « Je comprends que les outils et scripts…. » et cliquez sur « Ok » pour confirmer l’opération :

Le déplacement de notre Managed Disk/VM démarre :

L’opération nécessite quelques minutes (selon la taille du/des disque(s) Managed à déplacer.

Une fois terminée, vos ressources apparaissent désormais dans le nouveau groupe de ressource (hk-preprod-rg dans notre cas) :

 

Note importante : Ce qui n’est pas pris en compte par la MoveFeature

Cette nouvelle MoveFeature présente tout de même quelques limitations, à savoir :

  • Pas de Move possible pour les VM ayant des Disks Managed ET sur lesquels une sauvegarde Azure Backup est configurée
  • Pas de Move possible pour les VMs ayant des Disks Managed avec des références Azure Key Vault

Note : cette Big-Picture est disponible en téléchargement ici.

Introduction

Si vous êtes amenés à déployer et administrer des VM IaaS dans Azure, il est fortement déconseillé d’établir des connexions Directes RDP & SSH (à travers Internet) sur celles-ci : il s’agit d’une « Bad Practice » /cas courant dans les entreprises !

Les VMs Azure disposant d’une interface Public (@IP Public) sont exposées à Internet et donc à plusieurs Security Risks liés aux protocoles RDP et SSH.

Quels « Best Practices » ?

La « Best Practice » consiste à utiliser une connexion VPN Site-to-Site (entre le VNET Azure et votre réseau local : canal sécurisé IPSec /IKEv2) ou Point-to-Site (entre le VNET Azure et votre Machine d’Administration : canal sécurisé SSTP/IKEv2).

Avec cette architecture, vous réduisez la surface d’attaque en supprimant l’interface Publique de vos VMs (utilisation d’une Private NIC Only).

L’objectif du présent post est de vous détailler (step-by-step) la procédure à suivre pour SetuPé et configurer une connexion VPN Point-to-Site entre votre environnement Azure et votre ou vos machines d’administration distantes.

Let’s do it 🙂

 

# OS Client supporté pour la connexion VPN Point-to-Site

Les Operating System (OS) suivants sont pris en charge pour la connexion VPN Point-to-Site :

  • Windows :
    • Windows Client : Windows 7, 8, 8.1 et 10
    • Windows Server : Windows Server 2008, 2008 R2, 2012, 2012 R2 et 2016
  • Mac OS X

 

#[Prérequis] Créez votre compte Azure

Pour mettre en pratique les différentes techniques expliquées dans le présent article, vous devez disposer d’un compte Azure. Vous pouvez en créer un gratuitement via ce lien.

Useful info : MS vous offre 200$ de crédit Azure pour tout nouveau compte créé. Cette offre est valable pendant 30 jours (Trial Mode).

 

#Utilisation de l’interface Azure CLI 2.0 vs Ouverture de Session Azure Cloud Shell

Les scripts/lignes de codes listées ci-dessous peuvent être exécutées depuis :

  • Interface Azure CLI 2.0 (mode local)
  • Azure Cloud Shell  (mode web)

Si vous souhaitez exécuter les lignes de codes ci-dessous localement depuis votre machine d’administration, je vous invite à installer l’interface Azure CLI 2.0 en suivant les instructions détaillées dans cet article.

Sinon, vous pouvez simplement vous connecter sur le site shell.azure.com, ouvrir directement une session Azure Cloud Shell exécutez les scripts décrits ci-dessous.

Console Azure Cloud Shell Web

Note : Azure Cloud Shell représente votre machine d’administration hébergée dans le Cloud Azure. Elle est accessible depuis n’importe ou et via n’importe quel device. Le Cloud Shell Azure est accessible depuis le Portail Azure (portal.azure.com), il peut également être accédé directement depuis l’URL shell.azure.com

 

#Créez votre connexion VPN Azure Point-to-Site

Pour créer une connexion VPN Point-to-Site (P2S), vous devez créer et configurer plusieurs objets/services Azure : Passerelle VPN Azure, Public @IP de la Gateway, Certificat pour l’authentification de vos clients VPN distants

Voici les étapes à suivre pour créer et configurer correctement votre connexion VPN P2S.

  1. Créer un nouveau groupe de ressource qui regroupera toutes les ressources Azure qui seront créées
  2. Créer un nouveau VNET Azure
  3. Créer/Déclarer le Gateway Subnet du VNET Azure créé
  4. Créer une Nouvelle Passerelle VPN P2S (Point-to-Site)
  5. Créer une nouvelle @IP Public pour la nouvelle Passerelle VPN
  6. Créer/Générer un nouveau certificat Self-Signed (Auto-signé) pour authentifier les clients VPN Distants
  7. Déclarer le contenu de la clé Public du Certificat Root sur la configuration VPN Point-to-Site

 

Note #1 : les étapes 1, 2 et 3 peuvent être by-passées si vous souhaitez configurer une connexion VPN P2S sur un VNET existant. Vous devriez dans ce cas changer les valeurs décrites ci-dessous par celles correspondant aux objets Azure existants (nom groupe de ressource, nom VNET, IP Address Prefix/CIDR…Etc)

Note #2 : si vous disposez d’une PKI sur le réseau local ou dans le Cloud, vous pouvez générer un certificat SSL signé/validé par votre CA et l’importer dans Azure. Dans notre cas, nous allons simplement utiliser un certificat Auto-Signé :).

 

Pour créer votre connexion VPN Azure P2S, exécutez les lignes de codes listées ci-dessous.

Notez que chaque bloc de code correspond à une des étapes décrite ci-haut.

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

#Etape1 :  Creation du ressource groupe
az group create -n hkdemorg -l WestEurope

#Etape2 : Creation du VNET
az network vnet create –name hkdemovnet –resource-group hkdemorg -l WestEurope –address-prefixes 10.110.0.0/16 –subnet-name hkdemosubbe –subnet-prefix 10.110.1.0/24 –ddos-protection false

#Etape3 : Creation du sous-reseau de la Passerell ‘Subnet Gateway’
az network vnet subnet create –address-prefix 10.110.254.0/24 –name GatewaySubnet –resource-group hkdemorg –vnet-name hkdemovnet

#Etape4 : Creation de l’adresse IP Public de la Gateway VPN
az network public-ip create –name hkdemovpngtwpip –allocation-method Dynamic –location westeurope –resource-group hkdemorg –sku Basic

#Etape5 : Creation de la Gateway VPN P2S
az network vnet-gateway create –name hkdemovpngtw -g hkdemorg –vnet hkdemovnet –public-ip-addresses hkdemovpngtwpip –location westeurope –gateway-type Vpn –sku VpnGw1 –vpn-type RouteBased –address-prefixes 172.116.1.0/24 –client-protocol SSTP

||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||

Plusieurs résultats vous sont retournés à la fin de l’exécution de chaque commande, cela vous permet de vérifier si les services Azure ont été créés correctement (ou pas : retour d’un ou plusieurs Error Messages).

Nous allons maintenant vérifier si tous les services Azure créés précédemment apparaissent depuis le Portail Azure.

Pour ce faire, connectez-vous sur Portal.azure.com et cliquez sur « Groupes de Ressources » ou « Resource Groups » si votre interface Web est en « Anglais ».

Notre Groupe de Ressource (hkdemorg) créé en « Etape 1 » doit apparaître sous « Groupe de ressources » :

Cliquez cette fois-ci sur le Groupe de Ressource hkdemorg pour visualiser toutes les ressources créées (VNET,  Passerelle VPN et son Adresse IP Publique associée) :

 

#Création du certificat Auto-Signé pour l’authentification des clients distants

Les Certificats sont utilisés par Azure pour authentifier les clients distants se connectant sur votre VNET Azure à travers la connexion VPN Point à Site.

Dès que vous aurez obtenu votre certificat (obtenu via votre PKI Enterprise ou un auto-signé), vous devez renseigner les informations relatives à sa clé Public au niveau de la configuration Point-to-Site Azure. Ce Certificat sera donc considéré comme étant « Trusted » pour toute connexion VPN P2S à votre VNET.

En outre, vous devez générer le certificat client à partir du Certificat Root de Confiance, vous l’installez ensuite sur chaque poste client devant s’authentifier/se connecter à travers le canal VPN P2S.

Maintenant que nous avons découvert à quoi servent les certificats dans une configuration VPN Azure, nous passerons à l’étape 6 qui consiste à créer/générer un certificat auto-signé Root pour l’authentification de nos postes clients VPN.

Pour générer ce certificat Auto-Signé, deux options s’offrent à vous :

  • Utilisation de l’outil MakeCert.exe
  • Utilisation de la Cmd-Let New-SelfSignedCertificate 

 

Note importante : l’outil MakeCert est considéré comme « Obsolète » et n’est plus recommandé par l’éditeur. Voir cet article pour en savoir plus

Nous allons donc utiliser la Cmd-let New-SelfSignedCertificate pour générer notre certificat

Commencez par ouvrir une Session Windows sur un Poste Windows 10, lancez ensuite PowerShell ISE en tant qu’Administrateur et exécutez les commandes suivantes :

#Etape6-Part1 : Creation du Certificat Auto-signe « Root »
$hkcert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=HKP2SRootCert" -KeyExportPolicy Exportable
-HashAlgorithm sha256 -KeyLength 2048 `
-CertStoreLocation « Cert:\CurrentUser\My » -KeyUsageProperty Sign -KeyUsage CertSign

#Etape6-Part2 :  Generation du certificat client
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature -Subject "CN=HKP2SChildCert" -KeyExportPolicy Exportable
-HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My"
-Signer $hkcert -TextExtension @(« 2.5.29.37={text}1.3.6.1.5.5.7.3.2 »)

Après exécution des commandes PowerShell ci-dessus, deux certificats sont générés au et stockés dans votre Magasin de certificats local (Certificats – Utilisateur Local):

  • HKP2SRootCert : certificat Root (dont la clé Public doit être déclarée sur Azure)
  • HKP2SChilfCert : certificat client (à installer sur chaque poste/client VPN).

Suivez les instructions suivantes pour exporter les deux certificats (Root & Child).

Export du Certificat Root, Pourquoi ?

Cette opération est importante car elle nous permettra de récupérer les informations sur la clé Public du Certificat Root pour les déclarer au niveau d’Azure (Config P2S) :

  1. Saisissez CertMgr.msc depuis le Menu Démarrer et lancez l’outil retourné dans les résultats de recherche
  2. La console « Certificats » apparaît. Développez « Personnel » > « Certificats« 
  3. Faites un Clic-droit sur HKP2SRootCert > Toutes les Tâches > Exporter…
  4. L’assistant suivant apparaît, cochez « Non, ne pas exporter la clé privée » et cliquez sur « Suivant » :

  1. Cochez « X.509 encodé en base 64 (*.cer) » et cliquez sur « Suivant » pour continuer :

  1. Cliquez sur « Parcourir… » et sélectionnez un emplacement dans lequel le certificat (.cer) sera placé (D:) dans l’exemple suivant) :

  1. Enfin, cliquez sur « Terminer » pour fermer l’assistant:

 

Export du Certifica Child (Client), Pourquoi ?

Le certificat client doit être installé sur chaque machine cliente devant se connecter (via le VPN P2S) sur votre VNET Azure. La procédure décrite ci-dessous vous permettra de générer un fichier PFX (avec son mot de passe associé).

  1. Saisissez CertMgr.msc depuis le Menu Démarrer et lancez l’outil retourné dans les résultats de recherche
  2. La console « Certificats » apparaît. Développez « Personnel » > « Certificats« 
  3. Faites un Clic-droit sur HKP2SChildCert > Toutes les Tâches > Exporter…
  4. L’assistant suivant apparaît, cochez « Oui, exporter la clé privée » et cliquez sur « Suivant » :

  1. Cochez « Echange d’informations personnelles – PKCS #12 (.PFX) » et cliquez sur « Suivant » pour continuer :

  1. Cochez « Mot de passe« , spécifiez un mot de passe, sélectionnez AES256 comme algorithme de chiffrement et cliquez sur « Suivant » :

  1. Choisissez un emplacement pour stocker votre fichier .Pfx et cliquez sur « Suivant » :

  1. Enfin, cliquez sur « Terminer » pour fermer l’assistant :

Le fichier PFX doit être installé sur toutes les machines d’administration depuis lesquelles vous pouvez être amenés à vous connecter pour établir la connexion VPN P2S Azure.

 

#Déclarer le contenu de votre certificat Root sur Azure (Configuration Point-to-Site)

A l’aide de Notepad ou Notepad++, éditez le fichier .Cer (Certificat Root Exporté précédemment) et copiez le contenu de sa clé Public comme montré ci-dessous :

Ces informations doivent être déclarées côté Azure (Configuration Point-to-Site).

Pour ce faire, exécutez la commande Az CLI suivante :

Note importante : remplacez la valeur du paramètre « –public-cert-data » par le contenu du Cert Root que vous avez copié précédemment.

#Etape7 Declaration du Cert Root au niveau de la configuration Point-to-Site Azure
az network vnet-gateway root-cert create –resource-group hkdemorg –gateway-name hkdemovpngtw –name hkvpnp2scert –public-cert-data « MIIC6zCCAdOgAwIBAgIQN9CJJEC3KopF32cKXpvOLTANBgkqhkiG9w0BAQsFADAY
MRYwFAYDVQQDDA1IS1AyU1Jvb3RDZXJ0MB4XDTE4MDcyNzIwNDQyMFoXDTE5MDcy
NzIxMDQyMFowGDEWMBQGA1UEAwwNSEtQMlNSb290Q2VydDCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAMHLP5DxRhA9nem2F2/nELeHLyjD+NSLl9NWjikO
I6fTF2gnl6+cmRfoFbuZmjl6ocS7h9g9bNatTDeN/AFQx1xyf7ZKp9nZryEM9VdC
HoaTGkMlmdiqmXmyHzxBH457s4spEvM4udCIrnCkczn8ocWX11ea96BF1ZaUJ6x7
t3o8V8FzvcVh/7zeoK8x+sQU/j8f6Qs20/prjFrrcZ7olI1C2R8eBZkBw1mEe1Nt
0txmd8lmkjWZJNi17V5C+SOxpWwuyZml/Hw186jNi4wvNXCg9nK3Wn0NLCfOkILN
oQIbvraz7yYWNBZLq/xKqSumGtF4aV0t9yL/0dRfENpkQD0CAwEAAaMxMC8wDgYD
VR0PAQH/BAQDAgIEMB0GA1UdDgQWBBQCR1tl1iycoP6oJDjKrWcRAh6+hTANBgkq
hkiG9w0BAQsFAAOCAQEABRpmIzysxcKEBrCm/EtgjOYoPaj5SlKD8wJhTk1BGXG0
OE9yLTeuIscmZygT1Wt20lAaWlJAqbRmuTkhXbbinttc+WOyWbqvWrAnsIbydVAP
DYqz0vOEfTIxROeAw+keorAc/jhmszBgLbkRAhJ9CDamutKtPGxNYq0lI9BAs46e
l109pxxz/6hDLGOJFNPXdZDWqceoxjtFhWnFNBMXj6Z/2NEIA3u474eI2hDoguRE
rz3NJ9qJyINrjf9ncg4Yc0/RlM3LaVhLjcLpCp31dkbfPXx1/3IqSusiiUUSFLHG
64XQ9jVxvozhkuUXqBbmKekCnOTfHPbIeHA5mcv9RA== »

#Téléchargez le Package « VPN Client »

Avant de télécharger le client VPN (Fichier .Exe), commencez par vérifier que la clé Public de votre certificat Root a bien été déclarée au niveau de la configuration Point-à-Site Azure.

Enfin, cliquez sur « Télécharger le client VPN » pour générer le client VPN à installer sur votre machine d’administration : il s’agit d’un .Exe qui configure automatiquement la connexion VPN avec toutes les informations que vous avez configurées tout au long de ce post.

Une fois téléchargé, Dé-zippez le fichier et exécutez le Setup File correspondant à la version de votre OS Client.
Dans mon cas, j’utilise une machine Windows 10 64-bit. Le fichier WIndowsAmd64\VpnClientSetupAmd64.exe a donc été exécuté :

Le Setup VPN Client installe et configure automatiquement la connexion VPN Suivante :

Cliquez sur le nom de la connexion (hkdemovnet) pour faire apparaître la boite de dialogue suivante :

Cliquez sur « Se connecter« , et ensuite sur « Connecter » pour établir la connexion VPN P2S :

Une fois connecté, le statut de la connexion passe à « Connecté« , vous pouvez également vérifier l’adresse IP qui vous a été attribuée depuis l’invite de commande > IPConfig /All et la comparer à celle qui apparaît depuis le volet « Configuration Point-à-Site »  :

Et voilà le tour est joué :).

N’hésitez pas à me laisser un commentaire si vous avez des questions.
A bientôt Dear Readers.

#HK

AD Guys, Hello again 🙂

Si vous souhaitez connaître la date d’expiration des password de vos comptes users AD, eh bien pouvez simplement exécuter le code PS suivant :

Requirements
  • Lancez Windows PowerShell en tant qu’Admin
  • Exécutez les lignes de codes ci-dessous depuis un DC (not recommended) ou une machine d’administration ayant les outils RSAT installés et notamment le module PowerShell « ActiveDirectory » (recommended :)).

 

HowTo : connaitre la date d’expiration des mots de passes de vos comptes users AD

Get-ADUser -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} –Properties « DisplayName », « msDS-UserPasswordExpiryTimeComputed » | Select-Object -Property « Displayname »,@{Name= »ExpiryDate »;Expression={[datetime]::FromFileTime($_. »msDS-UserPasswordExpiryTimeComputed »)}}

Tip : si vous souhaitez trier les informations retournées par « Date la plus récente », exécutez la commande suivante :

Get-ADUser -filter {Enabled -eq $True -and PasswordNeverExpires -eq $False} –Properties « DisplayName », « msDS-UserPasswordExpiryTimeComputed » | Select-Object -Property « Displayname »,@{Name= »ExpiryDate »;Expression={[datetime]::FromFileTime($_. »msDS-UserPasswordExpiryTimeComputed »)}} | Sort ExpiryDate -Descending

Le résultat retourné par cette commande est affiché dans la screenshot ci-dessous :