Articles Tagués ‘Microsoft Azure’

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-asaService) 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-aService) de Microsoft Azure, cette offre est aussi connue sous le nom de DCaaS (DomainController-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, 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

Publicités

Hi Azure Guys,

Aujourd’hui je vais vous parler d’un Powerful Web tool dédié à l’offre IaaS d’Azure : Azure Virtual Machine

Il s’agit de AzurePrice.Net

Cet outil web vous permet de trouver et comparer rapidement les différentes offres Azure VM depuis une seule et même page.

Plusieurs clients trouvent qu’Azure Pricing Calculator n’est pas très pertinent quand il s’agit de sélectionner et calculer le prix de plusieurs VM Azure à la fois.

Azure Pricing Calculator est organisé par volet /par service Azure, il vous offre également la possibilité de calculer le prix d’une configuration spécifique/personnalisée, c’est la raison pour laquelle il reste l’outil à privilégier quand il s’agit de calculer le coût global d’une infrastructure Azure.

En revanche, si vous cherchez un outil simple & easy à utiliser pour calculer rapidement le coût d’une ou plusieurs VM Azure, (uniquement), eh bien AzurePrice.Net reste le meilleur outil. A garder dans sa Toolbox.

DEMO

Dans l’exemple suivant, je veux simplement connaître le coût mensuel (en €) d’une VM Azure de type « Standard_A2_v2 » hébergée en France.

Les filtres sont configurés avec les paramètres suivants :

  • Région : France Central
  • Coût : Euro (€)
  • Mode Facturation : Mensuel

 

Résultat de ma recherche :

Comme indiqué dans la Screenshot, le résultat retourné inclut également une colonne (Best Price /couleur verte) vous indiquant la Région Azure offrant le meilleur prix pour la même VM (West US 2 dans notre exemple). Si vous n’avez pas de contrainte spécifique pour héberger votre VM en dehors de la France (eg : contraintes légales), vous pouvez donc choisir d’héberger votre VM dans cette Région et économisez 28,3% sur le coût global comparé à un hébergement en France Central.

Enjoy :).

A bientôt.

#HK

 

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, 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« 

Prérequis

Avant d’aller plus loin dans ce Post, vérifiez que vous disposez bien d’un :

  • Abonnement Azure
  • Azure AD configuré
  • Une instance Azure ADDS configurée
  • Un certificat SSL délivré :
    • Par votre CA Entreprise interne (CA Privée)
    • Par une CA Public
    • Ou encore un certificat Self-Signed que vous générez-vous même : Déconseillé pour une instance AAD-DS de Prod

 

4 Steps pour configurer/forcer LDAPS sur votre Domaine « Managé » Azure ADDS

La configuration du LDAPS sur votre domaine Managé Azure ADDS se fera en 4 étapes :

  • Etape 1 : Générer un certificat SSL (auto-signé) pour les communications LDAPS
  • Etape 2 : Exporter le certificat SSL LDAPS vers un fichier .PFX
  • Etape 3 : Activer LDAPS sur votre Domaine Managé depuis le Portail Azure
  • Etape 4 : Configurer le DNS pour pouvoir accéder à votre Domaine Managé Azure ADDS depuis Internet

 

HowTo : Configurez LDAPS sur votre domaine « Managé » Azure ADDS 

Etape 1 : Générer votre certificat SSL pour les communications LDAPS (pour environnement Dev/Test/Training… Only !!)

Comme indiqué dans la capture d’écran ci-dessous, le nom de mon Domaine Managé Azure ADDS est HK.Corp :

Le certificat SSL à générer devra donc être configuré pour ce même DNS Name (HK.Corp)

Vous pouvez utiliser le script P(ower)S(hell) suivant pour générer votre Cert SSL Self-Signed :

Note : vous devez bien évidemment remplacer les valeurs des paramètres « -Subject » et « -DnsName » par celles correspondant à votre environnement.

Ce script PS est disponible en téléchargement depuis la Gallery TechNet :

 

Le certificat SSL (Auto-Signé) généré est automatiquement stocké dans le Magasin de certificats (Cert Store) local de la machine à partir de laquelle vous avez exécuté le Script

  • Pour le visualiser, lancez une console MMC vierge en exécutant l’outil MMC.exe depuis le Menu Démarrer ou Exécuter > Fichier > Ajouter/Supprimer des composants logiciel enfichable… > Certificats > AjouterUn Compte d’ordinateur > Ordinateur local > Terminer > OK

  • Maintenant, développez « Personnel » > « Certificats« 

Etape 2 : Exporter le certificat SSL LDAPS vers un fichier PFX 

Nous allons maintenant exporter le certificat (Self-signed) généré précédemment vers un fichier PFX. En effet, Azure ADDS s’appuie sur ce type de fichier pour forcer le LDAPS sur le domaine Managé.

Pour ce faire, suivez les instructions suivantes :

  • Faites un Click-droit sur le certificat auto-signé généré (HK.Corp dans l’exemple suivant), et sélectionnez « Toutes les tâches » > Exporter…
  • L’assistant d’exportation de certificat apparaît, cliquez sur « Suivant« 
  • Veillez à bien cocher « Oui, exporter la clé privée« , cela est très important sinon la sécurisation de votre domaine AADDS à l’aide de ce certificat ne pourra être effectuée

  • Maintenant, vérifiez que l’option « Echange d’informations personnelles (.PFX) » est bien cochée et cliquez sur « Suivant » :

  • Cochez « Mot de passe« , spécifiez votre mot de passe et confirmez-le, cliquez ensuite sur « Suivant » pour continuer :

  • Spécifiez un emplacement pour enregistrer le fichier .PFX et cliquez sur « Suivant« :

  • Enfin, cliquez sur « Terminer » pour lancer l’exportation du certificat (en .PFX File) :

  • Si le certificat est exporté avec succès, le message suivant apparaît, cliquez sur « OK » pour fermer la boite de dialogue :

Etape 3 : Activer LDAPS sur votre Domaine Managé depuis le Portail Azure

Pour activer LDAPS sur votre domaine Managé Azure ADDS, suivez les instructions suivantes :

  • Connectez-vous sur le Portail Azure (https://portal.azure.com)
  • Localisez et cliquez sur le service « Azure AD Domain Services« 

  • Cliquez sur votre Domaine Managé AADDS (HK.Corp dans l’exemple suivant) :

  • Par défaut, LDAPS est désactivé sur tout Domaine Managé Azure ADDS déployé :

  • Cliquez sur « Activé« , localisez et sélectionnez le PFX exporté précédemment, renseignez ensuite le mot de passe associé a ce fichier et cliquez sur « Enregistrer« . Comme illustré dans l’image suivante, n’autorisez pas l’accès LDAPS à votre domaine Managé sur Internet 

  • La configuration du LDAPS sur votre Domaine Managé démarre… notez que cette opération peut prendre jusqu’à 10 voire 15 minutes, soyez donc patient 🙂 !

Comme mentionné dans le message/avertissement suivant, le port 636 doit être autorisé (en Inbound) au niveau de vos DC-as-a-Service AADDS, faute de quoi les communications LDAPS entre vos clients et Domain Controllers AADDS échoueront !

Note : comme indiqué dans la Screenshot précédente, LDAPS (LDAP over SSL) communique sur le port 636. Vous pouvez le confirmer en consultant la base IANA (Internet Assigned Numbers Authority) à cette URL.

Vous devez donc le configurer (autoriser) manuellement au niveau de votre NSG (Network Security Group) :

  • Dès que l’opération de configuration du LDAPS sur votre Domaine Managé est terminée, les informations suivantes apparaissent depuis le volet « Vue d’Ensemble » : Empreinte de votre Certificat ainsi que sa date d’expiration 

Etape 4 : Configurer le DNS pour accéder à votre Domaine Managé Azure ADDS depuis Internet

Azure vous offre la possibilité d’accéder à votre domaine Managé Azure ADDS depuis Internet, cela vous permet de joindre des machines distantes (connectées depuis n’importe ou !!) à votre domaine Managé.

  • Il suffit d’activer l’option « Autoriser l’accès LDAP sécurisé sur Internet » :

  • Suite à cette opération, une Adresse IP (ADRESSE IP EXTERNE DE LDAP SÉCURISÉ) est générée et est disponible depuis les Propriétés de votre Domaine Managé Azure ADDS :

 

Maintenant, il vous reste plus qu’à créer un enregistrement DNS (publique) qui pointe vers cette @IP publique. Il faut simplement se connecter sur l’interface d’Administration Web de votre fournisseur de domaine et créer cette entrée DNS (cf documentation de votre hébergeur/fournisseur de domaine).

WARNING !!

Je ne suis pas Fan de cette option car exposé son annuaire AD à Internet n’est pas Best Practice (Sécu), en effet cela vous expose à des risques assez important (Password Brute-force-Attack : Attaque Directe sur votre Domaine Managé vu qu’il sera accessible depuis le réseau Internet).

Azure vous avertir d’ailleurs quand activez l’accès LDAPS sur Internet, en effet, le message d’avertissement suivant est affiché en permanence depuis le volet « Vue d’ensemble« :

Nous pouvons toujours filtrer le trafic (entrant) à l’aide de Rule NSG mais le risque restera toujours présent, le moindre changement (erreur de config !!) des règles NSG peut rendre votre domaine accessible via Internet !

MS recommande la mise en place de ce filtrage comme WorkAround/Option de sécurisation mais faites moi confiance, exposer son annuaire AD sur Internet n’a jamais été un Best Practice et ne le sera jamais, so Fortget this option !

De plus, aucun client acceptera la publication de son domaine AD (Managé en plus :s) sur Internet et donc l’exposer à la terre entière !

Option donc à éviter. Ce n’est pas quelque chose que je pousse chez mes clients aujourd’hui, et je vous recommande de faire la même chose.

La DEMO est donnée ici  à titre indicatif si toutefois vous souhaitez tester les différentes options fournies avec un Domaine Managé Azure ADDS

That’s All :).

N’hésitez pas à vous abonner sur mon Blog, plusieurs articles autour de l’Azure arrive les prochains jours/semaines.

A bientôt

#HK

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 (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 :

  • 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 Module : Azure Locks

La deuxième Module « Azure Locks » est disponible à cet URL :

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

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

A bientôt,

#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