Articles Tagués ‘Azure AD’

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 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 o_O !

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.

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

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

Je vous laisse consulter cet article pour en savoir plus.

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

L’équipe MS Corp Azure AD vient de publier les dernières Updates/améliorations introduites à Azure AD.

Plusieurs nouveautés intéressantes sont désormais fournies avec l’offre IDaaS (IDentity-as-a-Service) de Microsoft, notamment :

La possibilité de définir une « White-list » avec les B2B users (Organisations/Partenaires) pour lesquelles vous souhaitez autoriser ou refuser l’accès.

Permettre à vos utilisateurs B2B Users (Guest Users) d’accéder à vos ressources OnPrem (Great News :D, non ?).

De Nouvelles « Federated Apps » disponibles depuis l’Azure AD App Gallery

La disponibilité de la fonctionnalité « SSPR : Self-Service Password Reset » à partir de l’écran de verrouillage (LockScreen) des Machines Windows 10 faisant parti d’une infrastructure Azure AD « Hybride ».

Je vous invite à consulter cet article pour en savoir plus sur toutes les nouveautés introduites à Azure Active Directory.

A bientôt

#HK