[Azure VWD] Liste des Prérequis et Bonnes pratiques pour vos déploiements Azure Windows Virtual Desktop

 

Introduction

L’équipe Azure en charge de l’offre Desktop-as-a-Service (DaaS), connue sous le nom Windows Virtual Desktop (WVD) a récemment publié plusieurs sessions/vidéos assez intéressantes sur le sujet, vous permettant de préparer, déployer, sécuriser, optimiser et troubleshooter vos déploiements Azure WVD.

Je vous partage à travers ce Blog post les liens des différentes sessions recordées.

Enjoy the training :).

 

Liens utiles 

Ci-après les liens des sessions dont je vous ai parlé précédemment, pour une meilleure compréhension du sujet, je vous recommande de suivre/visionner les vidéos dans l’ordre suivant :

Préparez votre environnement Azure Windows Virtual Desktop

https://lnkd.in/dnSrYpX

Déployer votre environnement Azure Windows Virtual Desktop via le Portail Azure

https://lnkd.in/d2Addne

Bonnes pratiques relatives au Profile Management avec FSLogix

https://lnkd.in/dM4G2jr

Moderniser votre Stratégie de gestion d’image pour Azure Windows Virtual Desktop

https://lnkd.in/decx2R3

Optimiser votre déploiement Azure Windows Virtual Desktop

https://lnkd.in/deq99Xy

Sécuriser votre déploiement Azure Windows Virtual Desktop

https://lnkd.in/d3wJEPQ

Troubleshooter & Diagnostiquer votre environnement Azure Windows Virtual Desktop

https://lnkd.in/d3FYk9u

Deployment best practices for latency sensitive workloads

https://lnkd.in/dSGAssZ

 

A bientôt,

 

 

Universal Print : Microsoft lance son Serveur d’impression dans Azure !

Introduction 

Microsoft vient de lancer un programme d’expérimentation pour son nouveau service d’impression Cloud appelé ‘Azure Universal Print’

Universal Print est un nouveau service cloud qui centralise sur Azure la gestion des systèmes d’impression.

 

Note importante : Pour participer à cette expérimentation, vous devez vous inscrire sur la Private Preview « Universal Print » (via ce Formulaire), notez que vous devez impliquer au moins 20 users/collaborateurs.

 

Universal Print est accessible dans le cadre des licences Microsoft 365 Entreprise et Éducation. Il s’appuie sur Azure Active Directory pour la gestion d’identité et d’accès.

Microsoft travaille en étroite collaboration avec des fournisseurs d’imprimantes (tel que Canon) pour garantir une compatibilité native avec son nouveau service Cloud.

En attendant, l’utilisation de Universal Print nécessite l’installation un connecteur (agent), qu’est disponible au moment de la rédaction du présent post que pour Windows 10 et Windows Server 2016 et 2019.

 

Universal Print : Console d’Administration

La console Universal Print ressemble à ceci :

Vous pouvez reporter vos feedbacks /remarques /incidents directement depuis les liens disponibles depuis l’onglet « Getting started« .

Sous « Manage« , vous avez la possibilité de déployer et suivre l’install de vos connecteurs (agents) mais aussi déployer (inscrire) ou supprimer (désinscrire) vos imprimantes (Printers), depuis le volet « Printers », vous pouvez également checker le statut de vos imprimantes déployées prête(ready), arrêtée (stopped)…

 

Ce qu’il faut retenir 

Azure Universal Print vous offre la possibilité de déployer des imprimantes et les inscrire (Register) au niveau de ce service d’impression Cloud sans avoir besoin de déployer des infrastructures/services d’impression complexe et difficile à gérer/exploiter.

Les imprimantes inscrites dans Universal Print peuvent être facilement préconfigureés et détectées par vos Devices (Machines) Windows joints au domaine Azure Active Directory.

Vos utilisateurs (Azure) pourront ainsi imprimer depuis leurs devices Windows ou Apps Office de manière transparente.

Universal Print pourra désormais remplacer vos serveurs d’impression OnPrem, en effet, Universal Print déplace les principales fonctionnalités d’impression de Windows Server vers le Cloud « Azure /O365 », vous n’avez plus besoin de déployer et gérer des serveurs d’impression Windows OnPrem, il n’y a plus besoin non plus d’installer et maintenir à jour des pilotes d’imprimante sur vos devices Windows. De plus, Universal Print ajoute des nouvelles fonctionnalités clés telles que des groupes de sécurité pour l’accès à l’imprimante, la découverte d’imprimante basée sur l’emplacement et une riche expérience d’administrateur.

 

Participer au programme d’expérimentation & Joindre la Tech Community Universal Print

Pour participer au programme d’expérimentation d’Universal Print lancée par Microsoft, remplissez ce formulaire

Pour joindre la Communauté technique Universal Print, rendez-vous sur ce lien.

Quelques liens utiles

Je vous ai regroupé ici quelques liens utiles pour bien démarrer avec Azure Universal Print

Documentation officielle sur Universal Print

Prise en main d’Universal Print

Installation des connecteurs Universal Print

 

My feedbacks

Je suis en train d’expérimenter Universal Print avec mes équipes (K&K Group), je partagerai avec vous mon feedback d’ici quelques semaines.

Stay connected 🙂 !

 

[Free eBook] Azure pour les Architectes [Seconde Edition]

Microsoft a récemment publié la seconde Edition de son free eBook « Azure for Architects« .

Consultez la Table des Matières ci-dessous pour en savoir plus :

Table des matières_1

Table des matières_2

Table des matières_3

Table des matières_4

Table des matières_5

Table des matières_6

Table des matières_7

Table des matières_8

Table des matières_9

Table des matières_10

Table des matières_11

Table des matières_12

 

La bonne nouvelle c’est que cette seconde Edition est proposée aussi bien en « Anglais » qu’en « Français » :). Ce qui n’était pas le cas pour la première Edition.

L’eBook « Azure pour les Architectes | Seconde Edition » peut être téléchargé directement depuis les lien/boutons suivants :

 

 

Bonne lecture à tous :).

A bientôt.

[Azure – Tip of the Week] Documentez votre architecture Azure !

 

Si vous intervenez sur des environnements Cloud Azure, en tant que Consultant /Architecte ou même auditeur, vous avez sûrement eu besoin de documenter la ou les architecture Azure sur lesquelles vous avez travaillé pour sortir une Big Picture illustrant tous les services /features /composants qui y sont déployés.

J’ai récemment audité une infra Azure d’un de mes clients, ce dernier ne disposant d’aucun schéma /DAT, j’ai été amené à documenter son architecture Azure.

Pour ce faire, j’ai dû utiliser plusieurs Outils/Templates/Visio stencil… j’ai donc décidé de publier ce post pour partager ces ressources avec vous :).

 

Outils & Liens Utiles

Tous les liens /documentations /ressources utilisées pour documenter une Architecture Azure sont listés ci-dessous :

• Azure Solutions Architecture : (https://azure.microsoft.com/en-us/solutions/architecture/)
• Centre d’Architecture Azure (https://docs.microsoft.com/fr-fr/azure/architecture/)
• Microsoft 3D Visio How to walk through – (https://www.youtube.com/watch?v=Tag2HNAJh4Y&feature=youtu.be)
• Template Visio 3D Microsoft (https://www.microsoft.com/en-us/download/confirmation.aspx?id=48243)
• Microsoft Azure, Cloud and Enterprise Symbol / Icon Set – Visio stencil, PowerPoint, PNG, SVG (https://www.microsoft.com/en-us/download/details.aspx?id=41937)
• Cloudockit (https://www.cloudockit.com)

 

Enjoy, à bientôt,

#HK

[Public Preview] Azure Private Link : Tout ce que vous devez savoir !

Introduction

Les clients Azure ont de plus en plus besoin d’accéder à leurs données et services Cloud de manière privée et sécurisée.

Plusieurs Services Azure (offres PaaS et SaaS principalement) sont (par défaut) déployés avec des interfaces Publics. Eg Database Azure SQL ou Compte de Stockage Azure déployés avec des URL Publics/DNS Name routable sur Internet.

Microsoft avait introduit un service appelé « VNET Service Endpoint » (Points de terminaison) permettant d’associer un service Azure partagé (Shared) à un VNET privé.

Vous pouvez en effet sécuriser la connexion à un service Partagé tel qu’une base Azure SQL PaaS en utilisant les points de terminaison VNET, ces derniers maintiennent le trafic sur le réseau interne Microsoft et permettent de « Lock-down » la ressource PaaS sur votre réseau virtuel uniquement.

En revanche, les points de terminaison PaaS restent accessibles via une adresse IP publique et ne peuvent donc pas être atteints depuis votre réseau local/onPrem via un Peering privé ExpressRoute ou une Passerelle VPN Azure.

Pour rendre ses services PaaS et SaaS Publics accessibles de manière privée et sécurisée, Microsoft a introduit un nouveau service appelé « Azure Private Link » !

 

Azure Private Link : qu’est-ce que c’est ? 

Tant attendu, Azure Private Link (APL) est un service qui va vous permettre d’accéder à des services Azure tels que Azure Storage, SQL (Offres PaaS), des Services tiers (Marketplace Azure) ou encore des ressources Buildées par vous via une liaison privée/sécurisée et complètement déconnectée d’Internet.

Une fois configuré et intégré à votre VNET, Azure Private Link établit un lien privé via des Private Endpoints avec tous les services Azure partagés pris en charge (Azure SQL, Azure Storage…), ces derniers deviennent accessibles via une Adresse IP Privée/Locale faisant parti de votre Range IP, comme n’importe quelle ressource déployée et associée à un de vos VNET Azure.

Notez qu’Azure Private Link s’intègre également avec les Zones DNS Privées d’Azure.

Prenons l’exemple suivant : Architecture Hybride Azure avec liaison ER (Private Peering)

Azure présente une extension de votre Datacenter (OnPrem), ce dernier est interconnecté avec Azure via une liaison « ExpressRoute » en Private Peering.

Vous déployez une base de données Azure SQL, par défaut, ce service est accessible via une URL publique (Routable sur Internet). Azure Private Link permet de rendre cette ressource Publique (DB Azure SQL), privée en l’associant à votre VNET et en lui attribuant une adresse IP locale. Les utilisateurs OnPrem peuvent donc (via le lien Private Peering ExpressRoute) accéder à cette DB Azure SQL via son adresse IP Privée/Locale, la ressource sera visible et accessible comme n’importe quelle ressource déployée dans vos environnements locaux ou Cloud.

Cela réduit considérablement le risque lié à l’exposition des ressources Azure sur Internet, car tout le trafic passe à travers le réseau Interne de MS Azure (Azure Backbone Network).

Le Schéma suivant illustre le fonctionnement du service Azure Private Link :

 

Vous pouvez aussi regarder la vidéo ci-dessous pour en savoir plus sur APL :

[Cliquez sur l’image pour visionner la vidéo]

 

Pourquoi utiliser Azure Private Link : Quels avantages ? Quels Use-Cases ?

L’utilisation d’Azure Private Link présente plusieurs avantages :

• Configuration réseau simplifiée : la configuration et gestion des règles de filtrage réseau reste la même car tous les services Publics partagés (eg : Azure SQL Database) deviennent privés et sont accédées via leurs interfaces IP privées comme n’importe quelle ressource associée à votre VNET (même accès et connectivité que les VM Azure par exemple).

Vous pouvez utiliser Azure Private Link dans les scénarios suivants :

• Si vous voulez établir une connexion privée avec les services PaaS Azure : comme mentionné précédemment, grâce à Azure Private Link, vous pouvez désormais accéder à des services partagés Multi-tenant tels que le Stockage Azure, Azure SQL de manière privée et sécurisée. Vous pouvez simplement créer un Private Endpoint dans votre VNET et le mapper sur votre ressource PaaS (votre compte de stockage Azure ou base de données SQL), APL attribue ensuite des adresses IP locales/privées à ces services PaaS et les rendent accessibles depuis votre réseau Azure (VNET) ou Local (OnPrem).
• Si vous voulez Établir une connexion privée avec les services SaaS Azure : Plusieurs Partenaires de Microsoft offrent aujourd’hui leurs solutions sous forme de SaaS (Software-as-a-Service) à travers la Marketplace Azure. Ces solutions SaaS sont souvent accessibles que depuis Internet. Certains clients Azure souhaitent utiliser ces SaaS au sein de leurs réseaux privés comme s’elles étaient déployées au sein de leurs Datacenters. La possibilité de consommer les solutions SaaS à titre privé au sein du réseau du client est une demande courante. Avec Azure Private Link, la connectivité privée est aussi étendue aux partenaires Microsoft. Quand APL sera en GA, vous allez surement constater la disponibilité de plusieurs offres/solutions SaaS du Marketplace via un Azure Private Link : nous allons donc parler plutôt de Private SaaS.
• Si vous voulez  établir une connexion privée avec vos services Azure (autres que PaaS et SaaS) : Le scope d’Azure Private Link ne se limite pas aux services/offres PaaS et SaaS d’Azure, vous pouvez en effet étendre APL aux autres Workloads comme par exemple des VMs Azure (faisant office de Web Server) ou des Azure WebApps placés derrière un Équilibreur de charge (Load Balancer) Standard. Le diagram suivant illustre une architecture avec et sans APL :

 

 

Comme montré dans le schéma ci-dessus, avec Azure Private Link, vous pouvez déployer et placer des ressources Azure derrière un Load Balancer Standard, et configurer ce dernier pour permettre à vos utilisateurs faisant parti d’autres tenant AAD (ou abonnements) de donc depuis d’autres VNET d’atteindre sans avoir besoin d’exposer vos ressources sur Internet.

La création d’un Azure Private Link Service est nécessaire.

 

Composants d’Azure Private Link

Il faut bien noter qu’Azure Private Link fonctionne de la manière suivante :

• Les Azure Private Endpoints sont utilisés pour rendre la communication privée avec les services PaaS/SaaS
• Les Azure Private Link Services sont utilisés pour faire référence à vos ressources (VMs) placées derrière un Load Balancer Standard.

 

Services Azure pris en charge par Azure Private Link

Services Azure PaaS pris en charge 

Encore en Public Preview au moment de la rédaction de ce post, Azure Private Link prend uniquement en charge les services PaaS suivants :

• Azure Storage
• Azure SQL Database
• Azure SQL Data Warehouse
• Azure Data Lake Storage (Gen2)

 

Autres Services Azure pris en charge 

• Services Azure placés derrière un Load Balancer Standard

 

Régions prenant en charge Azure Private Link

La Public Preview d’Azure Private Link prend uniquement en charge les régions Azure suivantes :

Type de service (Scénario)	Services pris en charge	Régions disponibles
Private Link pour vos services Azure	Services derrière un Load Balancer Standard	West Central US WestUS South Central US East US North US
Private Link pour les services Azure PaaS	Azure Storage	East US West US West Central US
	Azure SQL Database	East US West US West Central US
	Azure SQL Data Warehouse	West Central US WestUS South Central US East US North US
	Azure Data Lake Storage Gen2	West Central US WestUS South Central US East US North US

Note importante : si des règles de sécurité/Compliance vous obligent à déployer des services Azure uniquement en France (Central /Sud) ou en Europe (Nord & Ouest), vous ne pouvez malheureusement activer/configurer/tester Azure Private Link. Eg : une Azure Policy qui force le déploiement des services Azure dans les Régions France et Europe uniquement vous empêchera de déployer APL. Voir avec les Cloud SecAdmin pour faire une exclusion sur un RG de test ou réaliser vos tests sur un Abonnement dédié au Sandbox/Dev/Test.

 

Limitations

Au moment de la rédaction du présent article, Azure Private Link (encore en Public Preview) présente les limitations suivantes :

Ressource/Object	Limitation
Nombre de « Private Endpoints » par VNET	1000
Nombre de « Private Endpoints » par Abonnement	64000
Nombre de Service « Private Link » par Abonnement	32
Nombre de Configurations IP pour un Service « Private Link »	8 (Adresses IP NAT IP utilisées par PLS)
Nombre de « Private Endpoints » pour le même Service « Private Link »	1000

 

Pricing

Au moment de la rédaction de ce post, Azure Private Link est facturé de la manière suivante :

Service Liaison privée	Le service Liaison privée n’est pas facturé
Point de terminaison privé	0,005 € par heure
Données entrantes (IN) traitées	0,005 € par Go
Données sortantes (OUT) traitées	0,005 € par Go

Notez que pendant toute la période « Public Preview » du service Azure Private Link, vous bénéficiez d’une remise de 50% sur les tarifs indiqués dans le tableau ci-dessus.

 

HowTo : créer un service Azure Private Link

Pour pouvoir créer un Private Link Azure, vous devez d’abord créer un Private endpoint. Azure Private Link s’appuie en effet sur le Private endpoint pour établir les différents canaux privés entre le VNET et les services Azure cibles (PaaS, SaaS, Ressources propriétaires).

Nous allons découvrir durant cette partie comment activer et configurer Azure Private Link.

Dans l’exemple suivant, le but est de sécuriser la communication entre une DB Azure SQL (PaaS) et une VM Azure (IaaS) depuis le réseau privé (VNET) Azure.

Notre service cible (DB Azure SQL) sera accessible de manière privée via son @IP privée/locale et ne sera donc plus visible depuis Internet.

Prérequis

Si vous ne disposez pas encore de compte Azure, vous pouvez en créer un gratuitement en cliquant ici.

 

Sandbox : Informations de configuration

Voici la configuration de notre LAB Azure :

• 1 VNET :
  • Espace Adressage 10.10.0.0/16
  • Subnet 10.10.0.0/24
• 1 VM Azure :
  • WS Server 2016 (Datacenter Edition)
  • Avec SSMS (SQL Server Management Studio) installé
  • IP : 10.10.0.4
• [PaaS] Azure SQL Database :
  • Nom SQL Server : hklabdbserver.database.windows.net
  • Nom Database SQL : hklabdatabase
  • Zone DNS Privée Azure
    • Nom de la zone : hklabprivatelink.windows.database.net
    • Record A pour la base PaaS :
      • Hostname : hklabdbserver.hklabprivatelink.windows.database.net
      • IP Address (privée) : 10.10.0.5

 

Outils de déploiement

L’activation et configuration d’Azure Private Link peuvent être réalisées via différents tools (Azure Portal, Az PowerShell Module, Az CLI…).

Pour notre LAB, Azure CLI sera utilisé car c’est mon tool préféré (:D) mais aussi parce que je trouve que l’interaction avec Azure est 2 à 3 fois plus rapide par rapport à WS PS.

 

HowTo : créer un service Azure Private Link

Pour pouvoir créer et tester Azure Private Link, nous allons d’abord déployer notre infra de test, comprenant :

• 1 VNET + 1 Subnet
• 1 VM
• 1 SQL Server-as-a-Service
• 1 Database SQL Azure
• 1 Zone DNS Privée Azure + 1 Record pour notre Azure DB Server
• Le tout placé dans un Resource Group 

 

Pour ce faire, connectez-vous sur le Cloud Shell Azure et exécutez les commandes suivantes :

• Note : vous pouvez changer les noms des objets et renseigner ceux qui vous conviennent le plus (eg : respecter une convention de nommage d’un env LAB Azure de votre société ou client).

 

#1 : Création du Ressource Groupe

Exécutez la commande suivante pour créer un groupe de ressource nommé « hk-lab-rg » au niveau de la région France Central :

#2 : Création du VNET et Subnet

Exécutez les commandes suivantes pour créer un nouveau VNET nommé « hk-lab-vnet » avec un subnet de /24 nommé « hk-lab-subnet » :

#3 : Création de la VM

Exécutez les commandes suivantes pour créer une nouvelle VM WS2019Datacenter nommé « hk-lab-vm« :

 

#4 : Création d’un nouveau Server Azure SQL (hklabdbserver) et une base de données de test (hklabdatabase)

Exécutez les commandes suivantes pour créer une nouveau Server Azure SQL :

az sql server create \
–name « hklabdbserver » \
–resource-group « hk-lab-rg » \
–location francecentral \
–admin-user « hksqladmin » \
–admin-password P@$$w0rd_2019!

Exécutez ensuite les commandes suivantes pour créer une nouvelle DB Azure SQL :

az sql db create \
–resource-group hk-lab-rg \
–server hklabdbserver \
–name hklabdatabase \
–edition GeneralPurpose \
–family Gen5 \
–capacity 1

 

#5  : Mettez à jour les stratégies Réseaux au niveau du Subnet « hk-lab-subnet »

Les stratégies réseaux et règles de filtrage (eg : règles NSG) ne prennent pas en charge les Private endpoints.

Le sous-réseau auquel nous allons associer les Ressources Private Link (via les Private endpoints) doit être configuré/mis à jour pour exclure les Privates Endpoints de toute règle réseau/filtrage définie.

Pour désactiver ces stratégies réseaux du subnet sur lequel vous allez créer et associer des Private endpoints, il suffit d’exécuter les commandes suivantes :

az network vnet subnet update \
–name hk-lab-subnet \
–resource-group hk-lab-rg \
–vnet-name hk-lab-vnet \
–disable-private-endpoint-network-policies true

 

Note importante : si vous créez votre Private endpoint via le Portail Azure (GUI mode), cette mise à jour des network policies est faite de manière automatique par l’assistant. Elle doit être réalisée à la main seulement quand vous déployer des private Endpoints via Windows PowerShell (Az Module) ou Azure CLI.

 

#6 : Création du Private Endpoint

Maintenant que les ressources requises pour notre LAB ont été créées et les stratégies réseaux ont été désactivées, nous allons créer et configurer Azure Private Link.

Pour ce faire, vous devez simplement créer un Private Endpoint car APL s’appuie en effet ce dernier pour faire communiquer des ressources comme les VMs Azure avec les ressources Private Link (de type Base PaaS Azure SQL ou Compte de stockage Azure).

Commencez donc par créer un Private endpoint en exécutant la commande Az CLI suivante

az network private-endpoint create \
–name hktestprivateendpoint \
–resource-group hk-lab-rg \
–vnet-name hk-lab-vnet \
–subnet hk-lab-subnet \
–private-connection-resource-id « /subscriptions/id/resourceGroups/hk-lab-rg/providers/Microsoft.Sql/servers/hklabdbserver »/ \
–group-ids hklabdbserver \
–connection-name hklabprivateendpointconnection

 

Tip : vous devez avoir l’ID de votre Az SQL Server (paramètre –private-connection-resource-id), pour l’obtenir, vous pouvez exécuter la commande suivante :

az sql server show -n hklabdbserver -g hk-lab-rg

 

#7 : Création de la Zone DNS privé Azure ainsi que le record pour la PaaS SQL Azure

Pour créer la zone DNS privée « hklabprivatelink.database.windows.net« , exécutez la commande suivante :

az network private-dns zone create –resource-group hk-lab-rg \
–name « hklabprivatelink.database.windows.net »

Créez ensuite le lien DNS privé, en exécutant la commande suivante :

az network private-dns link vnet create –resource-group hk-lab-rg \
–zone-name « hklabprivatelink.database.windows.net »\
–name hklabdnslink \
–virtual-network hk-lab-vnet \
–registration-enabled false

Nous allons maintenant déclarer/ajouter un record (A) et l’associer à notre serveur SQL Azure (hklabdbserver <> IP locale/privée : 10.10.0.5 car le 10.10.0.4 est attribuée à notre VM WS2016) en exécutant les deux commandes suivantes :

az network private-dns record-set a create –name hklabdbserver –zone-name hklabprivatelink.database.windows.net –resource-group hk-lab-rg

az network private-dns record-set a add-record –record-set-name hklabdbserver –zone-name hklabprivatelink.database.windows.net –resource-group hk-lab-rg -a 10.10.0.5

Et voilà le tour est joué :).

HowTo : Créer /Configurer Azure Private Link via PowerShell & Azure Portal

Pour créer et configurer Azure Private Link via PowerShell (Az Moduel), consultez cet article.

Pour créer et configurer Azure Private Link via le Portail Azure, consultez cet article.

 

Tester l’accès à votre service PaaS (SQL Server Azure) via son @IP locale

Nous allons maintenant tester la connectivité (privée) entre notre VM Azure (10.10.0.4) et notre Azure SQL Server (10.10.0.5), pour ce faire :

• Connectez-vous via RDP sur la VM Azure (Click Connect pour récupérer le RDP File). Si vous n’avez pas attachée une Public IP à votre VM, vous pouvez toujours vous connecter en RDP via le service Azure Bastion. Pensez à utiliser l’URL « Preview » pour avoir l’option « Bastion : RDP|SSH » sur votre VM.
• Une fois la session Windows ouverte, lancez l’invite de commande (CMD.exe) et faites un test nslookup avec le DNS name du serveur SQL Azure en exécutant la commande suivante : nslookup hklabdbserver.hklabprivatelink.database.windows.net
• Comme montré dans la capture d’écran suivante, L’@IP retournée est 10.10.0.5 (IP locale)

• Nous allons maintenant tester la communication via le port 1433 (SQL) sur l’@IP 10.10.0.5. Pour ce faire, lancez Windows PowerShell (en tant qu’Admin) et saisissez la commande suivante : Test-NetConnection -ComputerName 10.10.0.5 -Port 1433, le résultat retourné doit indiquer ‘True’, c’est qui veut dire que la communication entre votre VM et le service PaaS Azure SQL sur le port 1433 est OK via l’@IP locale (10.10.0.5)

• Enfin, installez SQL Server Management Studio sur la VM Azure (10.10.0.4) et connectez-vous sur le serveur Azure SQL (hklabdbserver <> 10.10.0.5) à l’aide des credentials Admin SQL renseignés lors de la création du service Azure SQL
  • Note : Vous pouvez télécharger SSMS (SQL Server Management Studio) depuis l’URL suivante : https://go.microsoft.com/fwlink/?linkid=2105412

• Comme montré dans la screenshot ci-dessous, la connexion sur le serveur Azure SQL a été réalisée avec succès, nous sommes bien connectés sur notre instance hklabdbserver via l’IP locale 10.10.0.5 :

 

S(ervice) L(evel) A(greement)

Une fois en GA (General Availability), Microsoft annonce une disponibilité trois 9 (99,9) du service Azure Private Link.

Source : https://azure.microsoft.com/fr-fr/pricing/details/private-link/

 

Azure Private Link : La Roadmap ?

L’équipe Azure Networking Corp annonce plusieurs New Features dans la Roadmap Azure Private Link, à savoir :

• Disponibilité d’Azure Private Link dans de nouvelles Régions : Les régions France Central/Sud et Europe Nord/Ouest seront donc bientôt prises en charge (selon le PM Azure Networking)
• Pris en charge de plusieurs nouveaux services PaaS : Azure Cosmos DB | Azure MySQL | Azure PostgreSQL | Azure MariaDB | Azure Application Service | Azure Key Vaul
• Pris en charge de Nouveaux Services Partner (Service Tiers du Marketplace)

Quand il sera en GA, Azure Private Link prendra en charge une liste de services nettement plus importante.

Stay connected on : https://azure.microsoft.com/fr-fr/updates/?product=virtual-network

 

Lien Utile /Documenttion « Azure Private Link » 

La documentation officielle sur Azure Private Link est disponible depuis l’URL ci-dessous :

https://docs.microsoft.com/en-us/azure/private-link/

 

That’s All :).

A bientôt, #HK

[Azure Free Training] Lesson2 : Protégez vos ressources Azure, Appliquez des « Locks Azure »

Premier module de la série « Gouvernance Azure »

Le premier Module de la série « Gouvernance Azure » > « Azure Naming Convention » est disponible depuis l’URL suivante :

[Azure Free Training] Lesson1 : Définissez votre Convention de Nommage Azure

 

Introduction

Si vous devez migrer des Workloads depuis votre Corporate Network (aka Onprem) vers Azure (Lift & Shift Mode) ou construire de nouvelles architectures Azure (« Cloud Native » Mode), 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 :

• Convention de nommage (définition de vos naming standards pour vos ressources Azure)
• Modèle de délégation (RBAC)
• Policies (Stratégies Azure)
• Tags (Azure Resources Tags)
• Azure Locks
• Subscrption Design (Nombre d’abonnements à créer..etc)
• …Etc

 

Durant la « Lesson 2 », nous allons découvrir la composante « Azure Locks » ou « Verrous Azure » en Français.

Il s’agit d’une Feature de sécurité Azure qui vous permet de protéger vos abonnements, Groupes de Ressources ou encore des ressources Azure spécifiques contre la modification ou suppression accidentelle.

 

Step-by-step guide sur Azure Locks : Introduction & HowTo

Le document est disponible sur SlideShare, à cet URL.

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

[Azure Governance] Lesson 2 : Azure Locks from ☁ Hicham KADIRI ☁

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 Module : Azure Tags

La troisième Module « Azure Tags » est disponible à cet URL :

[Azure Free Training] Lesson3 : Tout ce que vous devez savoir sur Azure Tags

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

A bientôt,

#HK

Différence entre Windows Server Active Directory (ADDS) vs Azure Active Directory (AAD) vs Azure AD Domain Services (AADDS)

Hi All,

Suite à la réalisation de plusieurs missions (Consulting /Expertise Azure), j’ai pu constater que plusieurs clients se posent toujours la même question quant il s’agit de gérer les identités et accès aux applications Cloud.

The Question est la suivante :

Quelle est la différence entre une infrastructure AD (Windows Server Active Directory) traditionnelle, Azure Active Directory (AAD) et Azure Active Directory Domain Services (AADDS) ?

Si vous vous posez aussi la même question, eh bien sachez que vous êtes à la bonne adresse :).

Let’s see la différence !

 

First of all, définissons ce que c’est Windows Server Active Directory, Azure AD et Azure ADDS !

Windows Server Active Directory (ADDS)

ADDS pour Active Directory Domain Services (aka AD pour Active Directory) est un rôle natif fourni (par défaut) sur toute nouvelle installation de Windows Server, que ce soit en mode GUI (Graphical User Interface) ou en mode Core (Installation Minimale)

Le rôle ADDS vous permet de déployer un annuaire AD (Base de données AD : NTDS.dit) pour stocker et gérer de manière centralisée tous vos objets réseaux et sécurité : ordinateurs, utilisateurs, imprimantes, partages, GPOs…etc

Cet annuaire permet également de stocker et gérer les données relatives aux applications pouvant être intégrées dans un AD et l’interroger via LDAP.

A l’aide de GPOs (Group Policy Objects) de domaine, vous pouvez également centraliser la configuration, le paramétrage et la sécurisation de vos comptes utilisateurs et ordinateurs du réseaux.

ADDS représente la base (Backbone) d’un réseau Microsoft d’entreprise.

 

Azure Active Directory (Azure AD)

Azure Active Directory (aka AAD) est l’offre IDaaS (IDentity-as–a–Service) proposé par Microsoft Azure.

AAD est une solution (service Cloud mutualisé >> Mulit-Tenant) de gestion des identités et des accès pour les applications (principalement WEB) hébergées et exécutées dans le Cloud Azure mais aussi celles hébergées dans vos Datacenters OnPrem(ise).

Je vous invite à regarder la vidéo suivante pour en savoir plus sur Azure AD :

La documentation complète sur Azure Active Directory est disponible à cet URL.

Azure Active Directory Domain Services (Azure ADDS)

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

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, Manage et sécurise les Domain Controller pour vous.

Vous n’avez plus à vous soucier de la sécurité de vos Domain Controllers (Patch Management, Hardening, Monitoring, 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« 

 

Mais quelle est la différence entre un annuaire AD (traditionnel), un Azure AD et une instance Azure ADDS ?

Nous allons tout d’abord voir la différence entre Windows ADDS et Azure AD, car il s’agit des deux items souvent confondus par les clients.

Pour commencer, il faut toujours garder à l’esprit qu’un Azure AD n’est pas une solution remplaçante ou équivalente d’Active Directory dans le Cloud.

Quand on parle d’Active Directory (AD), on pense généralement à :

• Forêt /Domaine (Root & Child) Active Directory
• Contrôleurs de domaine (DC : Domain Controller) hébergés chez vous généralement et sur lesquels vous avez Full Control (qu’ils soient physiques ou virtuels).
• Service d’annuaire qui a une structure hiérarchique basée sur X.500
• Annuaire pouvant stocker de multiple type d’objet : utilisateurs, ordinateurs, imprimantes, GPOs, Sites AD, Partages…
• Service DNS utilisé en tant que « Locator » de ressources réseaux (traduction d’@IP en Host et vice versa)
• Annuaire pouvant être interrogé à l’aide du protocole LDAP (Lightweight Directory Access Protocol) ou LDAPS
• Authentification via Kerberos/NTLM
• Organisation des objets à l’aide d’OU (Organitional Unit)
• Configuration des postes clients (Ordinateurs) et utilisateurs à l’aide de GPO (Group Policy Object)
• Relation d’approbation entre deux ou plusieurs forêts/Domaine AD si ces dernières ont besoin de discuter et partager des ressources entre elles.

 

Un Azure AD quant à lui est :

• Un service Cloud (IDaaS) : cela veut dire que Microsoft conçoit, déploie et gère toute l’infrastructure (mutualisée) hébergeant Azure AD. Et vous, en tant que « Cloud Customer », vous consommez et payer ce service de manière mensuelle (en fonction du nombre d’utilisateurs s’authentifiant à travers votre Azure AD).
• Authentifie les utilisateurs aux niveaux des applications hébergées dans Azure ou celles hébergées chez vous OnPrem, via l’utilisation du service Azure AD Application Proxy.
• L’authentification se fait via Internet : Azure AD s’appuie principalement sur une authentification over Internet (HTTP/80 ou HTTPS/433).
• L’authentification ne se limite pas aux devices connectés sur le réseau Corporate de l’Entreprise mais plutôt to Any Device (vu que la communication avec un Azure AD se fait à l’aide des protocoles HTTP ou HTTPS, il suffit d’avoir un device connecté à Internet pour pouvoir communiquer avec un Azure AD.
• Azure AD s’appuie quant à lui sur des protocoles dis « Modern Authentication Protocol » tels que OpenID Conncet /Oauth2 /SAML /WS-FEDERATION (Goodbye Kerberos & NTLM ^_^).
• Contrairement à un Active Directory, Azure AD peut être interrogé via une interface REST API, appelée AD Graph API
• Azure AD étant un service Cloud (IDentity-as-a-Service), vous n’avez pas la main sur l’infrastructure hébergeant cette solution IAM, il n’y pas de gestion de GPO possible, la création d’une structure d’OU n’est pas non plus disponible car il s’agit d’une structure Plate (Flat).
• Azure AD stocke et gère uniquement les objets « Users » et « Groups » : pas de GPO, pas de partage réseau, pas de sites AD…etc
• La manière dont les objets AD classiques (users, computers, partages, groupes….) sont stockés et gérés est complètement différente entre un AD et Azure AD :
  • AD : Structure Hiérarchique (Hierarchical Structure)
  • Azure AD : Structure plate (Flat Structure)

Les deux schémas suivants illustre les deux types de structures :

 

En ce qui concerne Azure ADDS, c’est ni plus ni moins qu’un Active Directory traditionnelle déployé et géré par Microsoft. Les mêmes caractéristiques liées à AD listées ci-haut s’appliquent également à un Azure ADDS, ce dernier s’appuie sur Kerberos/NTLM pour authentifier les utilisateurs du réseau, permet l’organisation des objets dans des OU et vous permet de créer et configurer des GPOs. Il existe tout de même certaines limitations relatives à un Azure ADDS :

• Contrairement à un AD, Azure ADDS ne vous permet pas d’établir/créer de relations d’approbation entre plusieurs instances Azure ADDS.
• Vous n’avez plus la main sur les comptes « Admins Entreprises » et « Admins du Schéma »
• Et enfin, l’extension du schéma AD n’est pas possible sur un domaine (Managé) Azure ADDS.

 

Ce qu’il faut retenir !

Ce qu’il faut garder en tête :

Windows Server Active Directory (ou Services de Domaine Active Directory, ou encore Windows ADDS) est un rôle natif dans les plateformes Windows Server (from Windows Server 2000 :)). ADDS authentifie les utilisateurs via les protocoles Kerberos (ou NTLM), vous permet de créer tout type d’objet dans l’AD et les stocker dans des OUs. Ces objets peuvent être gérés à l’aide de GPO (User ou Computer).

Azure Active Directory (ou Azure AD, ou encore AAD), est une offre IDaaS (IDentity-as-a-Service) de Microsoft Azure, qui vous permet d’authentifier vos utilisateurs sur les applications Cloud (ou locales via l’utilisation d’Azure AD Application Proxy). Il peut héberger uniquement des objets « Utilisateurs » et « Groupes ». Ces objets peuvent être directement créés dans Azure AD (Cloud Only mode) ou récupérés depuis votre AD local via une synchronisation AD to AAD à l’aide de l’outil Azure AD Connect (Synchro Mode). Azure AD est conçu pour les Apps/Services Web, il s’appuie sur les protocoles Web Modernes tels que SAML /WS-FEDERATION /OAuth2…etc.

Quand vous déployez un Azure AD, vous êtes considérés comme un « Tenant » > Client Cloud

Votre Azure AD étant « Trusted » par défaut avec plusieurs annuaires (comme ceux de Facebook, Google..etc), vous pouvez automatiquement accéder à d’autres services Web en utilisant le même compte Azure AD (SSO by default).
Pour finir, il faut considérer Azure AD comme un « Federation Hub » car vous pouvez à tout moment « Trust » un autre Azure AD (d’autres clients/partenaires) et accéder à leurs ressources (et vice versa) en rien de temps !

Azure Active Directory Domain Services (ou Azure ADDS ou encore AADDS) est une offre DCaaS (DC-as-a-Service) de Microsoft Azure. Cette plateforme représente votre infrastructure AD locale dans Azure, la différence réside dans le fait que c’est Microsoft (le Cloud Provider) qui créé, déploie, gère et sécurise les Contrôleurs de domaine pour vous. Il s’agit d’une instance « Standalone » d’une forêt AD isolée et déconnectée de votre réseau local. Si vous avez des contraintes de sécurité relatives à la réplication de votre AD local vers Azure (vers des DCs hébergés sous forme de VMs Azure), l’offre Azure ADDS peut être une solution à adopter pour créer rapidement une nouvelle forêt dédiée pour Azure, pour authentifier (via Kerberos/NTLM) vos utilisateurs/machines Windows hébergés dans Azure. Azure ADDS reste aussi le meilleur compromis (Sécu, Réduction de coût /Réduction des efforts liés aux MCO) quand il s’agit de migrer des plateformes/locales Apps « Legacy » vers Azure et donc faire du Lift-and-Shift (ou As-Is) Migration.

 

That’s All,

A bientôt :).

#HK

Etendre son infrastructure Active Directory vers Azure Active Directory | Design Considerations Guide

Bonjour tout le monde,

Si vous souhaitez étendre votre infrastructure Active Directory (OnPrem) vers le Cloud (Azure), Microsoft propose un outil All-in-one (AADC : Azure AD Connect) qui vous permet de synchroniser votre annuaire AD vers l’offre IDaaS (IDentity-as–a-Service) de Microsoft qu’est Azure Active Directory.

Pour étendre son AD vers Azure AD, plusieurs options & scénarios sont possibles, à savoir :

Fédération d’identité à l’aide des services ADFS
PHS (Password Hash Synchronization) : Synchronisation de l’annuaire AD local avec Azure AD & envoi d’une copie de la base AD vers Azure AD (groupes, comptes utilisateurs et leurs password associés)
PTA (Pass-Through Authentication) : Synchronisation de l’annuaire AD local avec Azure AD & envoi d’une copie de la base AD vers Azure AD (groupes, comptes utilisateurs seulements, sans mots de passe, ceux-ci restent OnPrem).

Chaque scénario présente des avantages et des inconvénients, et selon le besoin de votre client final, un ou plusieurs Options/Scénarios peuvent être adoptés.

Pour vous aider à prendre la meilleure décision, et suite à plusieurs REX clients, j’ai décidé de rédiger et partager avec la communauté un document détaillant toutes les informations dont vous aurez besoin pour Designer correctement votre future Hybrid IDentity Management solution.

Le document est disponible sur Slideshare (Read-Only mode) et en téléchargement sur la Gallery TechNet.

Vos feedbacks sont les bienvenus.

#HK

[Microsoft Azure] Inside Azure Datacenters : Architecture « Software & Hardware »

Hello Everyone,

Si vous souhaitez découvrir les Datacenters Azure de plus près et en savoir plus sur les différentes couches logicielles et matérielles qui les composent, incluant le « Compute /Storage /Network », je vous invite donc à consulter cette présentation.

Très bonne PPT, par le grand Mark Russinivoch, CTO MS Azure Corp.

Bonne lecture à tous.

HK o__O.