Articles Tagués ‘Microsoft Azure’

Introduction à Azure ADDS

AADDS (Azure Active Directory Domain Services) est une offre PaaS (Platform-as-aService) de Microsoft Azure, cette offre est aussi connue sous le nom de DCaaS (Domain Controller-as-aService).

Azure AD DS est une instance (Forêt AD standalone) Windows Server Active Directory managée par Microsoft, cela veut dire que Microsoft créé, déploie et manage les Domain Controller pour vous.

Vous n’avez plus à vous soucier de la sécurité de vos Domain Controllers (Patch Management, Hardening, Sécurité Physique…etc).

Consultez cet article pour en savoir plus sur Azure Active Directory Domain Services.

Note importante : Le fait que MS manage les Domain Controllers à votre place présente certaines limitations que vous devez prendre en considérations, voir cet article pour en savoir plus : https://docs.microsoft.com/en-us/azure/active-directory-domain-services/active-directory-ds-comparison > Rubrique « Compare Azure ADDS to DIY AD« 

Ancienne limitation/restriction relative à la stratégie (par défaut) de mot de passe d’une instance AADDS 

Par défaut, la durée de vie des mots des passe dont le hash est stocké dans une base Azure ADDS était définie à 90 jours.

Cette stratégie de mot de passe ne convient bien évidemment pas à tout le monde, par exemple :

  • Une société ayant des exigences de sécurité fortes : durée de vie des mots de passe des Domain Admin et Comptes à Haut privilège à 60 voire 30 jours !
  • Une société avec moins de crainte de sécurité ayant une stratégie de sécurité « Plus Relax » : durée de vie des mots de passe des Domain Admin et Comptes à Haut privilège à 180 jours voire 365 jours.

 

Plusieurs Customers (Clients) Azure ont donc remonté cette limitation (moi y compris :)) aux équipes MS Azure Corp.

Ces feedbacks ont été pris en compte et l’équipe Azure a fait un Goodjob sur cette partie en intégrant les stratégies de mots de passe affinées (FGPP : Fine-Grained Password Policy) au niveau des services ADDS Azure.

Note : si vous n’êtes pas encore familier avec les FGPP, je vous invite à consulter cet article.

 

Prérequis 

Vous devez bien évidemment disposer d’un abonnement Azure ainsi que :

  • Une instance Azure AD (IDaaS)
  • Une instance Azure ADDS configurée (DCaaS)
  • Une machine d’Administration membre de votre domaine managé Azure ADDS

 

Useful Links

Si vous ne disposez pas encore de compte/abonnement Azure, je vous invite à en créer un depuis cette URL : https://azure.microsoft.com/fr-fr/free/

Si vous n’avez pas encore créer et configurer un domaine Managé Azure ADDS, je vous invite à suivre les instructions détaillées dans ce post : https://docs.microsoft.com/fr-fr/azure/active-directory-domain-services/active-directory-ds-getting-started

Pour joindre une machine d’administration à votre domaine Azure ADDS, suivez les instructions détaillées dans cet article : https://docs.microsoft.com/fr-fr/azure/active-directory-domain-services/active-directory-ds-admin-guide-join-windows-vm-portal

Dans l’exemple suivant, le DNS name configuré sur mon domaine Managé AADDS est hk.corp

 

Tout d’abord, vérifions la FGPP configurée par défaut sur un domaine managé Azure ADDS

Depuis votre machine d’administration membre du domaine managé, lancez la console DSAC (Active Directory Administrative Center) et développez : votre domaine managé > System > Password Settings Container, enfin double-cliquez sur ‘AADDSSTFPSO

Comme indiqué dans la Screenshot ci-dessous, la stratégie de mot de passe configurée par défaut sur votre domaine managé Azure ADDS a les caractéristiques/propriétés suivantes :

  1. Longueur minimale du password : 7 caractères
  2. Durée de vie des mots de passe : 90 Jours 
  3. Le mot de passe doit respecter les règles de complexité : Oui

Note importante : La stratégie de sécurité par défaut (AADDSSTFPSO) ne peut être modifiée ni supprimée !

 

HowTo : Configurez une stratégie de mot de passe personnalisée pour votre domaine Managé Azure ADDS

Nous allons dans l’exemple suivant, créer et configurer une stratégie de sécurité personnalisée pour définir les paramètres suivants :

  1. Longueur minimale du password : 16 caractères
  2. Durée de vie des mots de passe : 60 Jours 
  3. Le mot de passe doit respecter les règles de complexité : Oui

Les valeurs relatives aux options de verrouillage de compte (Lockout) respectent le standard de sécurité adopté aujourd’hui dans les entreprises, nous allons donc garder les mêmes valeurs, à savoir :

  • Compte verrouillé suite à : 5 tentatives de connexion échouées
  • Durée pendant laquelle le compte reste verrouillé : 30 minutes

 

Notez que cette nouvelle stratégie de sécurité (personnalisée) sera appliquée uniquement au groupe : Domain Admins

Comment ça marche ?

Suivez les instructions suivantes pour configurer votre stratégie de mots de passe au niveau de votre domaine AD managé AADDS :

  • Ouvrez une Session Windows sur la machine d’administration membre de votre domaine managé Azure ADDS
  • Lancez l’outil DSAC (ou DSAC.exe)
  • Naviguez jusqu’au : System > Password Settings Container > Depuis le volet ‘Tasks’, cliquez sur ‘New’ > ‘Password Settings’

  • Renseignez toutes les informations de configuration de votre nouvelle stratégie de sécurité, n’oubliez pas de spécifier le groupe « Domain Admins » au niveau de « Directly Applies To« , pour éviter que cette nouvelle stratégie de sécurité s’applique à tout le monde : un password lifetime pour un end user (utilisateur métier : basic/standard user) ne passera jamais :).

Note importante : veillez à bien décocher l’option « Protection from accidental deletion« , sinon la stratégie de sécurité ne pourra être créée (problème de permissions : by design sur l’instance Azure ADDS) : voir capture d’écran suivante avec le message d’erreur :

 

#HK | Just Another IT Guy

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (Onprem) vers Azure et/ou construire de nouvelles architectures (Mode « Cloud Only »), notez que la Step1 de votre projet va consiste à définir un Modèle de Gouvernance Global pour Azure.

Comme illustré dans le schéma ci-dessus, le modèle de Gouvernance Azure (Azure Scaffold) est composé de :

  • Modèle de délégation (RBAC)
  • Policies (Stratégies Azure)
  • Tags (Azure Resources Tags)
  • Abonnements (Azure
  • Et Surtout la convention de nommage (Naming Convention/Standards) qui est un objet « transferve » du modèle de Gouvernance Azure.

 

La convention de Nommage est l’une des composantes « Critique » de ce modèle de Gouvernance Azure.

En effet, définir une bonne convention de nommage vous facilitera la vie quand il s’agit de Reporter, faire du Billing Track, Localiser les ressources Cloud facilement….etc

Pour vous aider à construire ce modèle de Convention de Nommage Azure, je vous ai préparé un document détaillé (SlideShare) à travers lequel je vous explique toutes les contraintes et restrictions (Naming Rules Azure) à prendre en compte, et surtout mes Best Practices pour réussir la définition de votre Document de Convention de Nommage Azure.

 

Step-by-step guide : Comment construire sa convention de nommage Azure ?

Le document est disponible sur SlideShare, à cet URL.

Vous pouvez aussi le visualiser directement depuis ce post, voir Slide ci-dessous :

Ce Slide a été rédigé en Anglais (pour atteindre un public plus large) mais sera bientôt disponible en Français sur la même plateforme.

 

Next Lesson ?

Je travaille actuellement sur les autres « Lessons/Modules » du modèle de Gouvernance Global Azure, à savoir :

  • Les Policies Azure
  • RBAC Azure
  • Resources Groups
  • Et Resources Tags

 

N’hésitez pas à vous abonner à mon Blog pour rester informé de toute nouvelle publication.

Sinon, vos Comments/Feedbacks sont bien évidemment les bienvenus :).

#HK

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

La fonctionnalité tant attendue voit enfin le jour : Prise en charge de l’authentification Azure AD par le stockage Azure 🙂

Eh oui, vous pouvez désormais vous appuyez sur votre service Azure AD pour authentifier, gérer et contrôler les accès à vos données hébergées au niveau des comptes de stockage Azure, et plus précisément dans Azure Blobs et Azure Queue (File d’attente Azure).

Je vous laisse consulter cet article pour en savoir plus.

Cette feature est encore en mode « Public Preview » mais selon les informations que j’ai pu échangé avec MS Corp, la GA ne devrait pas tarder so stay tuned :).

 

Si vous êtes amenés à gérer et administrer un ou plusieurs tenants Azure AD au quotidien, et que vous souhaitez automatiser toutes les tâches et opérations répétitives et fastidieuses, eh bien sachez que vous êtes à la bonne adresse :).

Aujourd’hui, je vais vous parler d’un module PowerShell qui va vous faciliter la vie quand il s’agit de déployer, gérer, administrer mais aussi troubleshooter Azure Active Directory.

Il s’agit du module « AzureAD » (ou Azure Active Directory PowerShell for Graph).

Les Cmd-Lets fournies avec ce Module vous permettent de récupérer les données à partir de l’annuaire/service Azure Active Directory, créer de nouveaux objets, modifier et mettre à jour les objets existants, supprimer des objets AAD, mais aussi configurer votre tenant Azure AD et ses options /fonctionnalités associées.

Enfin, notez que le module AzureAD vous permet également de gérer vos AAD Application Proxy et Connecteurs.

HowTo : Installer le module PowerShell AzureAD

Le module AzureAD est disponible depuis la PowerShellGallery et peut être installer via un simple

Install-Module AzureAD

 

HowTo : Utiliser le module PowerShell AzureAD

Une fois installé, commencez par importer le module « AzureAD » en saisissant la commande suivante :

Import-Module AzureAD

ou simplement

ipmo AzureAD

Exécutez ensuite la commande suivante pour lister toutes les Cmd-lets du module PowerShell AzureAD :

Get-Command -Module AzureAD | ft -AutoSize

Vous pouvez connaitre le nombre exact des Cmd-lets fournies avec le module AzureAD en exécutant la commande ci-dessous :

(Get-Command -Module AzureAD).Count

164 Cmd-Lets au total sont fournies avec le module PowerShell AzureAD, cela vous permet d’automatiser presque toutes les opérations disponibles depuis le Nouveau Portail Azure (portal.azure.com)

Avant de pouvoir créer et gérer vos objets (users & groups) Azure AD, vous devez connecter votre Interface PowerShell à votre tenant AzureAD, pour ce faire, saisissez la commande suivante :

Connect-AzureAD

Vous êtes invités à renseigner votre compte Microsoft (ou Professionnel) pour vous connecter :

Comme montré ci-dessous, mon compte Azure a été connecté correctement :

Commençons maintenant par lister tous les users AzureAD existants, saisissez la commande suivante :

Get-AzureADUser

Pour créer un nouvel utilisateur AzureAD, la commande suivante sera utilisée :

Note : dans l’exemple suivant, nous allons créer un nouvel utilisateur avec les informations suivantes :

UPN : hicham.kadiri-demo@k-nd-k-group.com

GivenName : hicham.kadiri-demo

DisplayName : Hicham KADIRI

City : Paris

Country : France

Department : IT

Mot de passe : « MyP@ss0rd2018! »

 

$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile $PasswordProfile.Password = « MyP@ss0rd2018! »

New-AzureADUser -City Paris -Country France -Department IT -DisplayName « Hicham KADIRI » -GivenName hicham.kadiri-demo -JobTitle « Azure Cloud Architect » -AccountEnabled $true -PostalCode 75000 -UserPrincipalName hicham.kadiri-demo@k-nd-k-group.com -PasswordProfile $PasswordProfile -MailNickName hicham.kadiri-demo

Pour supprimer cette fois-ci l’utilisateur créé précédemment, exécutez la commande suivante :

  • Notez que vous devez d’abord exécutez la Cmd-let Get-AzureADUser pour récupérer l’ObjectID de l’utilisateur à supprimer (af3dbbdd-e51b-44e3-8944-91150d296fd4 dans l’exemple suivant) :
    • Remove-AzureADUser -ObjectId af3dbbdd-e51b-44e3-8944-91150d296fd4

Vous pouvez lister tous les domaines AAD déclarés/enregistrés en saisissant la commande suivante :

Get-AzureADDomain

La liste des devices enregistrés dans votre domaine Azure AD peut être obtenue via la commande suivante :

Get-AzureADDevice

Je vous invite à consulter cet article pour en savoir plus sur l’ensemble des Cmd-lets fournies avec le module AzureAD.