[Guide pas à pas] Comprendre les rôles Azure : Rôles Azure RBAC vs Rôles Azure AD vs Rôles Classiques Azure

 

Introduction 

La notion de rôles dans Azure est souvent oubliée par les clients qui veulent aller « trop vite » et commencer à migrer/déployer des Workloads dans le Cloud.

Après plusieurs dizaines de missions autour d’Azure, j’ai constaté que la plupart des clients (pour ne pas dire tous ^_^), confondent toujours les rôles « RBAC » Azure de type « Owner, Contributor ou encore User Access Administrator« , avec les rôles Azure AD de type « Global Administrator /User Administrator ou encore Application Administrator/Developper« .

Sans parler des rôles Azure historiques « Classiques » de type « Administrateur de Comptes, Administrateur de Service ou encore Co-Administrateur« , introduits avec la toute première version d’Azure (Azure ASM : Azure Service Manager) dont peu de personnes connaissent l’existence.

Pour bien démarrer avec Azure, il est très important de comprendre chaque type de rôle, son utilité (quand et comment l’utiliser) et à quel niveau (Scope).

L’objectif du présent post est de vous présenter les différents rôles Azure, la différence entre eux, limitations relatives à chaque type de rôle et comment les implémenter dans vos environnements Cloud Azure.

Bonne lecture à tous !

 

Les rôles fournis avec Microsoft Azure

Trois types de rôles sont fournis aujourd’hui avec Microsoft Azure, à savoir :

• Les rôles Azure « Classiques » (rôles historiques)
• Les rôles Azure « RBAC »
• Les rôles Azure « Active Directory »

Reportez-vous aux sections suivantes pour en savoir plus !

Les rôles « Azure Classic » : Un peu d’historique

Quand Azure était proposé pour la première fois (sous le modèle de déploiement ASM : Azure Service Manager), la gestion des accès aux ressources se faisait via l’utilisation de trois rôles (Administrateurs) uniquement, à savoir :

• Administrateur de compte (Account Administrator)
• Administrateur de Service (Service Administrator)
• Co-Administrateur (Co-Administrator)

 

Lors de l’inscription à Microsoft Azure (création d’un nouveau compte/environnement Azure), le compte (Adresse Email) utilisé est automatiquement défini/déclaré en tant que « Administrateur de compte » et « Administrateur de Service ». Des Co-Administrateurs pourront ensuite être déclarés pour déléguer l’accès et la gestion des ressources Azure hébergées au niveau des abonnements.

Tip : Connectez-vous sur le Portail Azure, sélectionnez un de vos abonnements, et cliquez ensuite sur « Propriétés« , notez le nom du compte (Adresse Email) portant le rôle « Administrateur de compte » et « Administrateur de Service »

Les administrateurs « Classiques » ont un accès/contrôle total à la Souscription Azure. Ils peuvent gérer les ressources en utilisant le portail Azure ou via les API Azure ARM et ASM.

Note : Les Administrateurs de Services et les Co-administrateurs sont équivalents au rôle « Owner /Propriétaire » du nouveau modèle RBAC (Azure ARM) et offrent un accès total au niveau de l’abonnement. Le rôle « Administrateur de compte » quant à eux, ne permet pas la gestion des ressources. Cf tableau ci-dessous

Le tableau suivant décrit en détails les différences entre ces trois rôles Azure historiques :

Ce tableau peut être downloadé depuis ce lien Direct.

Vous aurez compris, avec Azure ASM, nous étions plus dans un modèle de Tout ou Rien (All-or-Nothing), car seuls les trois Administrateurs cités précédemment étaient disponibles, si votre politique de sécurité impose le principe du moindre privilège (PoLP : Principle of Least Privilege) et que vous deviez par exemple, limiter l’accès et la gestion de vos VMs Azure à un groupe d’utilisateurs spécifique, eh bien techniquement cela n’était pas possible, car tous les membres du groupe Azure AD auquel vous allez attribuer un des rôles Azure Classique se verront attribuer un rôle d’Administrateur (Co-Administrateur généralement), leur permettant automatiquement un accès total sur toutes les ressources Azure de votre abonnement.

Gérer l’attribution et la suppression des rôles Azure Classiques

Pour gérer l’attribution et la suppression des rôles Azure « Classiques », sélectionnez un abonnement,  groupe de ressources ou encore une Ressource Azure, et rendez-vous ensuite sous la Blade « Contrôle d’accès (IAM) » > onglet « Administrateurs Classiques » :

• La liste des Administrateurs Classiques (Administrateurs de Service et Co-Administrateurs) est affichée :

Note : le compte ayant servi à l’inscription sur Azure, est automatiquement déclaré en tant que « Administrateur de services fédérés ».

• Pour ajouter ou supprimer un Co-Administrateur, cliquez sur « Ajouter« , et sélectionnez ensuite « Ajoute un coadministrateur » :

N’hésitez pas à ajouter et supprimer un compte co-administrateur sur vos environnements de Test/Sandbox Azure et tester les droits qui lui seront attribuer.

 

En savoir plus sur les rôles Azure « Classiques »

Pour en savoir plus sur les rôles « Classiques » Azure, je vous invite à consulter cette documentation.

 

Ce qu’il faut retenir  

Azure étant proposé aujourd’hui qu’en mode ARM (Azure Resource Manager), la notion de rôles « Classiques » ne doit pas être prise en considération lors du design de votre modèle de délégation de droits Azure.

Le focus doit être porté sur les nouveaux rôles « RBAC » et « Azure AD ».

La section précédente avait simplement pour but de vous expliquer l’historique des premiers rôles apparus avec la première version d’Azure ASM.

 

Les rôles « Azure RBAC »

Avec l’introduction du modèle de déploiement Azure ARM (Azure Resource Manager), un nouveau modèle/système de gestion des droits d’accès a été introduit, il s’agit du modèle RBAC (Role-Based Access Control).

RBAC a permis à plusieurs entreprises ayant un niveau de sécurité « sérieux » de décoller et d’aller vers le Cloud.

Ce nouveau système de gestion de droits a résolu la problématique liée à l’ancien model de droit d’accès ASM offrant un niveau d’accès limité de type All-or-Nothing.

Azure RBAC permet en effet une gestion de droits d’accès plus fine et inclut (par défaut) plusieurs dizaines de rôles prédéfinis (Built-in) vous permettant de restreindre au maximum l’accès et la gestion à vos ressources et services Azure.

Microsoft a pensé son modèle RBAC de la manière suivante :

• Un type de rôle par Service/Offre Cloud (eg : Azure VM Contributor | Azure Sentinel Contributor…)
• Plusieurs profils au niveau du même rôle RBAC (eg : Azure Security Admin | Azure Security Reader …)

Note importante : les rôles Azure RBAC sont dédiés à l’accès et gestion des ressources Azure uniquement telles que les VMs Azure, Bases de données SQL Clusters HDI, Services Réseaux (VNET, Subnet, Gateway VPN, NSG, LB…) ou encore les WebApp, Mobile App…etc. La gestion de l’annuaire Azure AD et ses objets associés nécessitent d’autres droits /rôles (Rôles Azure AD), voir section suivante pour en savoir plus !

 

Il existe plus précisément (au moment de la rédaction du présent post) 166 rôles Azure intégrés (Built-in). Vous pouvez les visualiser depuis la Blade « Contrôle d’accès (IAM) » > « Rôles » :

RBAC vous permet de créer un modèle de délégation par profil (Build Team), par modèle de service Cloud (IaaS Builder, PaaS Contributor…) ou par offre Cloud(VM Builder, VNET Admin, Azure SQL Admin)…

 

Liste des « Built-in » Rôles RBAC Azure 

La liste complète des Built-in rôles RBAC Azure est disponible depuis l’URL suivante :

https://docs.microsoft.com/fr-fr/azure/role-based-access-control/built-in-roles

L’équipe Azure en charge de la partie RBAC mets régulièrement à jour cette liste, généralement après introduction d’un nouveau service /offre Cloud (eg : Azure Sentinel > introduction de nouveaux Built-in Roles : Azure Sentinel Contributor | Azure Sentinel Reader…).

Note : La suppression d’un service Cloud implique également la suppression des Built-in rôles RBAC associés. Avant de commencer vos travaux de conception du modèle RBAC, je vous recommande vivement de consulter cette page.

 

Les rôles RBAC fondamentaux 

Comme expliqué précédemment, il existe aujourd’hui plus de 150 Rôles RBAC Built-in.

Les 4 principaux rôles RBAC Built-in à retenir sont listés dans le tableau :

Rôle RBAC	Autorisations	Notes
Propriétaire (Owner)	Accès total à toutes les ressources Délégation de l’accès à d’autres personnes	L’administrateur de services et les coadministrateurs se voient attribuer le rôle Propriétaire/Owner au niveau de chaque abonnement. Ce rôle s’applique à tous les types de ressources.
Contributeur (Contributeur)	Création et gestion de tous les types de ressources Azure Ne peut pas attribuer/déléguer l’accès à d’autres personnes	Ce rôle s’applique à tous les types de ressources.
Lecteur (Reader)	Consultation/Lecture des ressources Azure uniquement	Ce rôle s’applique à tous les types de ressources.
Administrateur de l’accès utilisateur (User Access Administrator)	Gestion de l’accès utilisateur aux ressources Azure

 

Gérer l’attribution et la suppression des rôles Azure RBAC

Pour gérer l’attribution et la suppression des rôles Azure « RBAC », sélectionnez un abonnement, groupe de ressources ou une ressource et rendez-vous ensuite sous la Blade « Contrôle d’accès (IAM) » > onglet « Attributions de rôles » :

• Les attributions de rôles RBAC déclarées peuvent être consultées depuis cet onglet :

• Pour ajouter une nouvelle attribution de rôle, cliquez sur « Ajouter » et sélectionnez ensuite « Ajouter une attribution de rôle » :

• Dans l’exemple suivant, nous allons attribuer le rôle Virtual Machine Contributor (Contributeur de machines virtuelles) au groupe Azure AD « HK Run Team« .
  • Note : il faut cliquer ensuite sur « Enregistrer » pour que cette nouvelle attribution de rôle soit prise en compte.

• La nouvelle attribution de rôle RBAC (VM Contributor) apparaît désormais sous « Attribution de rôles« :

• Pour supprimer une attribution de rôle existante, il suffit de la sélectionner, et cliquez sur « Supprimer » :

• Vous serez invités à confirmer cette suppression en cliquant sur « Oui » :

 

Les Custom Rôles RBAC

Azure RBAC vous offre également la possibilité de créer vos propres rôles RBAC, appelés « Custom Roles » ou « Rôles personnalisés« .

Si les rôles RBAC « Built-In » fournis par défaut avec Azure ne répondent pas à vos besoins, vous pouvez créer vos rôles Custom et définir des droits/autorisations personnalisées.

Si votre politique de sécurité définit un modèle RBAC basé sur le concept du Least privilège, avec une utilisation de groupes (Azure AD) distincts permettant uniquement :

• La lecture et exportation de Logs Azure AD & des ressources
• Le démarrage, redémarrage et l’arrêt des services IaaS (VM) et PaaS (Serveurs SQL Azure)
• Création et lecture des règles NSG

vous avez la possibilité de créer des Custom Roles avec les autorisations nécessaires correspondant aux droits définis dans votre modèle de droit d’accès.

Un Custom Role est créé sur la base d’un fichier JSON, avec une structure (setting <> data value) spécifique.

L’exemple suivant, montre un Custom Role permettant uniquement le démarrage, arrêt et redémarrage des VMs Azure :

Je vous invite à consulter cet article pour en savoir plus sur les Azure Custom Roles.

 

Azure RBAC : Limitations

Il existe certaines limitations relatives à l’utilisation des rôles RBAC Azure, voir tableau ci-dessous :

ID Limitation	Description de la limitation
#1	Vous pouvez avoir jusqu’à 2 000 attributions de rôle dans chaque Souscription Azure
#2	Vous pouvez avoir jusqu’à 500 attributions de rôle dans chaque Management Group
#3	Vous pouvez avoir jusqu’à 5000 Custom roles par Tenant Azure

Note importante : la limitation #1 comprend l’attribution de rôles Built-in et Customs.

 

En savoir plus sur les rôles Azure « RBAC »

Pour en savoir plus sur les rôles RBAC Azure, je vous invite à consulter cette documentation.

 

Les rôles « Azure Active Directory »

Les rôles Administrateurs Azure AD (aka AAD) sont utilisés pour gérer les ressources de l’annuaire Azure AD, par exemple pour créer ou modifier des comptes utilisateurs Azure, attribuer des rôles d’administration à d’autres personnes ou gérer l’appartenance aux groupes Azure AD, réinitialiser les mots de passe des utilisateurs, gérer les licences utilisateur et encore gérer les propriétés du domaine Azure AD.

 

Liste des « Built-in » Rôles Azure AD 

La liste complète des Built-in rôles Azure AD est disponible depuis l’URL suivante :

https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-assign-admin-roles#available-roles

Il existe (au moment de la rédaction du présent post) 56 rôles Built-in Azure AD.

L’équipe Azure en charge de la partie « IDentity/IAM | Azure AD » mets régulièrement à jour cette liste, je vous invite à consulter cette page avant de démarrer vos travaux de conception des droits Azure AD.

 

Les rôles Azure AD fondamentaux 

Les 3 principaux rôles Built-in Azure AD à retenir sont listés dans le tableau :

Rôle AzureAD	Autorisations	Notes
Administrateur général (Global Administrator)	·       Gestion de l’accès à toutes les fonctionnalités d’administration dans Azure Active Directory, ainsi que les services qui sont fédérés à Azure Active Directory ·       Attribution des rôles d’administrateur à d’autres personnes ·       Réinitialisation des mots de passe des utilisateurs et de tous les autres administrateurs	La personne/utilisateur qui déploie l’annuaire Azure Active Directory est automatiquement déclarée en tant qu’Administrateur général.
Administrateur d’utilisateurs (Users Administrator)	·       Création et gestion de tous les aspects liés aux utilisateurs et aux groupes ·       Gestion des tickets de support ·       Suivi de l’intégrité des services ·       Changement des mots de passe des utilisateurs, des administrateurs du support technique et autres administrateurs d’utilisateurs
Administrateur de facturation (Billing Administrator)	·       Achats ·       Gestion des abonnements Azure ·       Gestion des tickets de support ·       Suivi de l’intégrité des services

 

Gérer l’attribution et la suppression des rôles Azure AD

Pour gérer l’attribution et la suppression des rôles « Azure AD », cherchez et sélectionnez le service « Azure Active Directory », et rendez-vous ensuite sous la Blade « Rôles et Administrateurs »:

• La liste des rôles Azure AD vous est retournée (à droite)
• Vous pouvez également voir le rôle Azure AD qui vous est attribué actuellement sur Azure AD:

• Pour ajouter une attribution de rôle Azure AD, commencez par sélectionner (cliquer) sur le rôle en question (Users Administrator/Administrateurs d’utilisateurs dans l’exemple suivant), et cliquez ensuite sur « Ajouter des affectations« . Dans l’exemple ci-dessous, nous avons ajouté/déclaré l’utilisateur (Hicham KADIRI) en tant que « Users Administrator »:

• Les affectations de rôles Azure AD peuvent être consultés depuis le rôle Azure AD, ou en sélectionnant un compte utilisateurs et cliquant sur « Rôles affectés » :

• Pour supprimer une attribution/affectation de rôle Azure AD, il suffit de sélectionner le compte utilisateur, et cliquez sur « Supprimer les attributions« .

 

Les Custom Rôles Azure AD

Comme pour les rôles Azure RBAC, vous avez la possibilité de créer vos propres rôles Azure AD Custom et définir vos droits/autorisations personnalisées.

Les Custom Roles Azure AD sont créés à partir de fichiers JSON aussi, et disposent la même syntaxe/structure que les Custom Roles RBAC.

Si vous voulez en savoir plus sur les Custom Roles Azure AD, je vous recommande la consultation de cette page.

 

En savoir sur sur les rôles Azure Active Directory

Pour en savoir plus sur les rôles Azure AD, je vous invite à consulter cette documentation.

 

Quelle est la différence entre les rôles « Azure RBAC » vs « Azure AD » ? Se chevauchent-ils entre eux ? 

Comme expliqué précédemment, les rôles Azure RBAC sont dédiés à la gestion des droits d’accès au niveau des services /ressources Azure (Compute, Storage, Network…), alors que les rôles Azure AD, sont plutôt dédiés à la gestion des objets Azure AD et des ressources Office 365 associées.

L’image ci-dessous illustre la séparation (Scope) de ces deux types de rôles :

 

Note importante [ce qu’il faut retenir !] : les rôles RBAC vous permettent de définir un modèle de déléguation /droit d’accès aux ressources Azure (VM, Compte de Stockage, VNet, Base PaaS SQL, WebApp, Cluster HDI…), les rôles Azure AD quant à eux, vous permettent de définir un modèle de droit d’accès aux objets associés à l’annuaire Azure AD (objets Utilisateurs, Groupes, Apps…). De plus, Azure RBAC contrôle l’accès aux ressources Azure à l’aide d’Azure Resource Management (ARM) alors que les Custom Roles Azure AD contrôlent l’accès aux ressources Azure AD à l’aide de l’API Graph.

 

Ayant des étendues (Scopes) différents, les rôles Azure RBAC et Azure AD ne se chevauchent jamais entre eux.

Les droits attribués via les deux catégories de rôles (RBAC & Azure AD) sont uniques et définis à des scopes distincts (Ressources Azure <> annuaire Azure AD), par conséquent, aucun impact /chevauchement n’a lieu.

 

Licensing Azure RBAC vs Azure AD

Azure RBAC est un service gratuit :), aucune licence n’est requise pour implémenter vos rôles RBAC Built-in et Custom.
En revanche, la création de rôles Custom pour Azure AD, nécessite un niveau de Licensing Azure AD Premium 1 ou 2.

 

Élévation de privilège : From « Azure AD Global Administrator » to « User Access Admin » 

En tant qu’administrateur général (Global Administrator) dans Azure Active Directory (Azure AD), il est possible que vous n’ayez pas accès à tous les abonnements et groupes d’administration de votre annuaire. Cet article décrit les méthodes pour élever votre accès à tous les abonnements et groupes d’administration.

 

Pourquoi devez-vous élever votre accès ?

Si vous êtes Azure AD Global Admin, il peut vous arriver de vouloir effectuer les opérations suivantes :

• Récupérer l’accès à un abonnement ou groupe d’administration Azure quand un utilisateur a perdu cet accès
• Accorder à un autre utilisateur ou à vous-même l’accès à un abonnement ou groupe d’administration Azure
• Voir tous les abonnements ou groupes d’administration Azure au sein d’une organisation
• Autoriser une application d’automation (telle qu’une application de facturation ou d’audit) à accéder à tous les abonnements ou groupes d’administration Azure

 

Comment fonctionne l’accès avec élévation de privilèges ?

Les ressources Azure AD et Azure sont sécurisées de façon indépendante les unes des autres. Ainsi, les attributions de rôles Azure AD n’accordent pas d’accès aux ressources Azure et inversement, les attributions de rôles Azure n’accordent pas d’accès à Azure AD. En revanche, si vous êtes administrateur général dans Azure AD, vous pouvez vous attribuer à vous-même un accès à tous les abonnements et groupes d’administration Azure de votre annuaire. Utilisez cette fonctionnalité si vous n’avez pas accès aux ressources de l’abonnement Azure, comme les machines virtuelles ou les comptes de stockage, et que vous voulez utiliser vos privilèges d’administrateur général pour accéder à ces ressources.

Quand vous élevez votre accès, le rôle Administrateur de l’accès utilisateur vous est attribué dans Azure au niveau de l’étendue racine (/). Ceci vous permet de voir toutes les ressources et d’attribuer des accès dans n’importe quel abonnement ou groupe d’administration de l’annuaire. Les attributions de rôles Administrateur de l’accès utilisateur peuvent être supprimées à l’aide d’Azure PowerShell, d’Azure CLI ou de l’API REST.

Vous devez supprimer cet accès avec élévation de privilèges après avoir effectué les modifications nécessaires au niveau de l’étendue racine.

 

Comment élever l’accès d’un Global Administrator Azure AD

Suivez les instructions suivantes pour élever les privilèges d’un Compte Global Administrator Azure AD :

#1. Connectez-vous au Portail Azure ou au Centre d’administration Azure Active Directory en tant qu’administrateur général.

#2. Recherchez et sélectionnez Azure Active Directory

#3. Sous Gérer, sélectionnez Propriétés.

#4. Sous Gestion de l’accès pour les ressources Azure (Access management for Azure Resources), sélectionnez « Oui /Yes« :

Quand vous sélectionnez « Oui », le rôle Administrateur de l’accès utilisateur (User Access Administrator) vous est attribué dans Azure RBAC au niveau de la racine (/). Ceci vous accorde l’autorisation d’attribuer des rôles dans tous les abonnements et groupes d’administration Azure associés à cet annuaire Azure AD. Cette option est disponible seulement pour les utilisateurs auxquels le rôle Administrateur général a été attribué dans Azure AD.

Quand cette option est définie sur Non, le rôle Administrateur de l’accès utilisateur dans Azure RBAC est supprimé de votre compte d’utilisateur. Vous n’aurez plus la possibilité de vous attribuer des droits/rôles aux niveaux des abonnements et groupes d’administration Azure associés à votre Azure AD.

 

#5. Cliquez sur Enregistrer pour que la modification soit prise en compte.

Note importante : cette option n’est pas une propriété globale et s’applique uniquement à l’utilisateur connecté. Vous ne pouvez pas élever l’accès des autres utilisateurs Azure AD Global Admin.

 

#6. Déconnectez-vous et reconnectez-vous pour actualiser votre accès.

Vous devez maintenant avoir accès à tous les abonnements (Subscriptions) et à tous les groupes d’administration (Management Groups) de votre annuaire Azure AD.

 

Guide pas à pas sur « Azure RBAC » 

Je suis en train de finaliser un guide assez détaillé (step-by-step) sur le sujet « Azure RBAC ».

Ce guide sera bientôt disponible en téléchargement gratuit sur Slideshare, n’hésitez pas à vous abonner pour rester informé dès sa publication :).

 

Conclusion

La notion de rôles dans Azure est un item important à prendre en considération dans la phase « Design » de tout projet de migration vers Azure ou le déploiement d’infra Cloud Native.

Le modèle RBAC est un composant critique du modèle de gouvernance Global Azure, prenez donc le temps d’étudier le sujet avant de commencer à déployer vos Workloads dans le Cloud.

 

 

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

[Azure ADDS – Tip of the Week] Configurer/Forcer LDAPS sur votre domaine « Managé » Azure AD Domain Services

Introduction à 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 (Domain Controller-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 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 > Ajouter > Un 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

[Azure Security] Introduction à Azure AD Password Protection et « Smart Lockout » : Désormais disponibles en ‘Public Preview’

 

Hi Folks,

Une very Powerful « Security » feature a été introduite/intégrée à Azure Active Directory (Azure AD).

Il s’agit d’Azure AD Password Protection, disponible en « Public Preview » au moment de la rédaction de cet article, cette fonctionnalité vous permet de définir une liste de mots de passe à bannir (Banned passwords) pour réduire tout risque lié à l’utilisation de « Weak Password », tels que MonPrenom2018$, MaSociete2018! ou encore Password2018$.

Azure AD Password Protection vous permet de :

1. Protéger les comptes utilisateurs hébergés au niveau de votre tenant Azure AD mais aussi dans votre infrastructure Active Directory (Locale/OnPrem) en empêchant les utilisateurs de sélectionner des mots de passe à partir d’une liste prédéfinie contenant plus de 500 mots de passes connus/communs proposés par MS.
2. Configurer et appliquer votre stratégie de Protection de mots de passe Azure AD pour votre tenant Azure AD ainsi que votre infra AD locale depuis une seule interface d’Admin : Portail Azure > Azure AD Blade
3. Personnaliser et configurer vos options de verrouillage de comptes utilisateurs : Smart Lockout
4. Spécifier une Liste de mots de passe « Personnalisés » à interdire : mot s de passe spécifiques à votre organisation.

 

Pourquoi auriez-vous besoin d’Azure AD Password Protection ?

Eh bien la réponse est simple : interdire l’utilisation de certains mots de passe !

En effet, plusieurs utilisateurs pensent utiliser des mots de passe « Forts » qui respectent la politique relative aux mots de passe (critères de complexité/longueur de mot de passe…), des mots de passe de type : P@$$w0rd, P@$$w0rd2018, ou encore P@$$W0RD2018!….etc,

Alors que c’est complètement faux !!

Les Hackers savent comment les utilisateurs réfléchissent voire devinent certains mots de passe, c’est la raison pour laquelle il faut toujours garder à l’esprit les trois règles suivantes :

Las Hackers :

• Savent comment les utilisateurs construisent leurs mots de passe : utilisation des caractères spéciaux tels que « $ » (à la place du S)
• Savent que si des règles de complexité de password sont mises en place, la plupart des utilisateurs vont construire leurs mots de passe de la même manière : PREMIERE LETTRE MAJUSCULE, utilisation d’un chiffre ou caractère spécial à la fin…etc
• Enfin, Les Hackers savent que les utilisateurs doivent changer leurs mots de passe de manière périodique, par conséquent, la plupart des utilisateurs ont tendance à garder une partie du mot de passe et changer deux ou trois caractères à la fin. eg : Remplacement du « MyP@$$w0rd2017! » par « MyP@$$w0rd2018! »

 

Note importante : Microsoft a publié une liste de « Best Practices » quant à l’utilisation des mots de passe [Password Guideline]. Je vous recommande la consultation de ce document.

 

L’application d’une stratégie de protection de mots de passe basée sur une liste de « Mots de passe Interdits » permet de répondre à cette contrainte de sécurité.

La fonctionnalité « Azure AD Password Protection », peut vous aider à réduire ce risque en appliquant une Password Policy sur vos environnements Cloud (users Azure AD) mais aussi pour vos infrastructures OnPremise.

 

Configurez votre stratégie AAD Password Protection & Smart Lockout en « Trois Clicks » !

La configuration de l’option de protection de mots de passe Azure AD ainsi que le Smart Lockout se fait en trois clicks. Voyons comment ça marche 🙂

Note importante: il faut savoir que par défaut, toutes les opérations de définition/changement/réinitialition de mots de passe associés aux comptes utilisateurs Azure AD Premium sont configurées pour utiliser l’Azure AD Password Protection. Cette option de protection s’appuie sur une liste de « Banned passwords » définie par défaut et maintenue par l’équipe Azure AD.

La bonne nouvelle c’est que vous avez toujours la possibilité de configurer une liste personnalisée de mots de passe « Interdits » au niveau de votre stratégie Azure AD Password Protection.

Pour ce faire, suivez les instructions suivantes.

 

#Step1 : Configurer la stratégie de protection de password pour votre Tenant Azure Active Directory

Connectez-vous sur le (New) portail Azure : https://portal.azure.com

Une fois authentifié, allez directement à :

Azure Active Directory > Sécurité > Méthodes d’authentification

Vous êtes automatiquement redirigé vers le Blade « GERER » > « Protection par mot de passe (Preview)« .

Sous « Mots de passe interdits personnalisés« , activez l’option « Appliquer la liste personnalisée » en cochant « Oui » et définissez la liste des mots de passe que vous souhaitez interdire au sein de votre tenant Azure AD.

Dans l’exemple suivant, plusieurs dizaines de mots de passes personnalisés « interdits » ont été ajoutés :

eg : HICHAM, Hicham, hicham, h!cham, h!ch@m, PARIS, Paris, paris, P@ris, P@r!s, p@ris, PASSWORD, Password, P@$$w0rd…etc

Note : ces mots de passe sont données juste à titre d’exemple !

Personnalisez donc votre liste de mots de passe et cliquez ensuite sur « Enregister » pour appliquer cette stratégie.

#Step2 : Configurer les options de vérrouillage (Smart Lockout)

Vous avez pu constater que depuis le même Blade, deux options relatives au Smart Lockout sont disponibles :

• Seul de verrouillage : nombre de tentatives échouées aboutissant à un Lockout du compte utilisateur AAD
• Durée du verrouillage en secondes : la durée pendant laquelle le compte reste verrouillé

Comme illustré dans la capture d’écran ci-dessous, mes best practices sont :

Seul de verrouillage : 5

Durée du verrouillage en secondes : 1800 (30 minutes)

Configurez ces options en fonction de vos standards/policies de sécurité et cliquez sur « Enregister » pour que ces modifications soient prises en comptes.

#Step3 : Etendre votre politique de protection de password à votre infrastructure Active Directory locale (OnPrem)

Enfin, sachez que la nouvelle feature Azure AD Password Protection peut également être configurée sur votre infrastructure AD traditionnelle (environnement OnPrem ADDS).

Il suffit de cliquer sur « Oui » au niveau de l’option « Activer la protection par mot de passe sur Windows Server Active Directory »

Notez que deux modes existent lors de la rédaction du présent article :

Mode « Activée /Enforced » : la stratégique est appliquée et poussée sur vos W(ritable) Domain Controller

Mode « Surveillance /Audit Only » : la stratégie est configurée en mode « Audit Only ». Si des mots interdits faisant parti de la liste personnalisée des mots de passe interdits est utilisé, cette information est journalisée et remontera dans les logs AD, ce qui vous permettra de suivre et monitorer l’utilisation des mots de passe par vos network users.

Une fois activées, les mêmes options configurées précédemment sont donc poussées sur votre AD Local, ce qui vous permet d’appliquer les mêmes Security Policies aussi bien sur votre environnement Cloud (Tenant Azure AD) que sur votre infra AD locale.

Notez qu’il existe un certain nombre de prérequis et notamment le déploiement d’un agent sur chaque (Writable) Domain Controller de votre domaine AD local (ou chaque DC de chaque Domaine AD si vous en avez plusieurs).

Cet agent est disponible en téléchargement gratuit ici.

Si l’extension de l’option « Azure AD Password Protection » sur votre environnement AD locale vous intéresse, je vous invite à consulter cet article pour en savoir plus.