Active Directory dans un contexte CSP

Pour rappel, Azure CSP (Cloud Solution Provider) est un programme destiné aux partenaires Microsoft qui fournit un canal de licence pour divers services cloud Microsoft. L’ensemble de la gestion du CSP se fait par le portail partenaire, en Powershell ou encore via des API. Cependant, il est différent d’un EA (Enterprise Agreement) ou d’une souscription Azure « classique » car il est Multi-Tenant. Donc, pour traiter certains sujets comme la facturation, par exemple, ou encore Active Directory, le CSP renferme quelques spécificités.

Avant de rentrer dans le vif du sujet, il est très important d’avoir quelques notions de base sur Azure, enfin on parle vraiment de vocabulaire et terminologie ! Si nous regardons l’illustration ci-dessous, cela représente un environnement Azure. En haut, nous avons un annuaire Azure Active Directory. Azure AD (ou AAD) peut être utilisé pour Office 365 et / ou Azure. Il existe une différence entre un Active Directory traditionnel (contrôleur de domaine à l’ancienne sur un serveur physique) et Azure AD. Le premier parle de Kerberos, NTML, LDAP, … et le second parle de OAuth, SAML, …  Nous pouvons voir dans l’exemple ci-dessous que le Tenant AAD comporte 4 souscriptions/abonnements Azure différent, comportant chacun des ressources différentes.

 

Ci-dessous, une autre façon de présenter les choses. J’insiste, mais on entends trop souvent « le Tenant Office 365 » etc… cela peut porter à confusion dans les workshops !

Dans un TENANT (Azure AD), nous pouvons ajouter des abonnements (SUBSCRIPTION) différents, dans notre exemple, nous avons 3 abonnements pour l’Annuaire AD (TENANT) e-Novatic, avec un système de facturation différent des autres.

Rentrons maintenant dans le vif du sujet, et vous allez comprendre pourquoi j’insiste sur le  vocabulaire à utiliser. Le schéma suivant illustre le fonctionnement général du modèle CSP. Contoso a un annuaire Azure AD qui dispose également d’un partenariat avec un fournisseur de solutions cloud (CSP donc) qui déploie et gère les ressources de son abonnement Azure CSP. Contoso peut également avoir des abonnements Azure ordinaires (directs), qui lui sont facturés directement et les manager distinctement.

 

Le Tenant du partenaire CSP dispose trois groupes d’agents : les agents d’administration, les agents de support technique et les agents de vente. Le groupe des agents d’administration est attribué au rôle d’administrateur du Tenant Azure AD du client. Quand le partenaire CSP provisionne un abonnement Azure CSP pour un client, son groupe d’agents d’administration est affecté au rôle de propriétaire pour cet abonnement (SUBSCRIPTION). Ainsi, les agents d’administration du partenaire CSP ont les privilèges nécessaires pour provisionner des ressources Azure telles que des machines virtuelles, des réseaux virtuels moyennant une petite manipulation.

Le tableau suivant détaille l’ensemble complet des activités que chaque rôle peut effectuer dans l’Espace partenaires.

Rôle dans l’Espace Partenaires Ce qu’il peut faire Ce qu’il ne peut pas faire
Agent d’administration
  • Gestion des clients
  • Gestion des abonnements
  • État du service et demandes de service pour les clients
  • Demander des privilèges d’administrateur délégués
  • Afficher les tarifs et les offres
  • Facturation
  • Administrateur pour le compte de
  • Inscrire un revendeur à valeur ajoutée
  • Gestion des utilisateurs
  • Demandes de service pour l’Espace partenaires
Commercial
  • Gestion des clients
  • Gestion des abonnements
  • Afficher les tickets de support
  • Demander une relation
  • Gérer les prospects
  • Afficher le contrat client
  • Inscrire un revendeur à valeur ajoutée
  • Créer des tickets de support pour les services ou l’Espace partenaires
  • Résoudre les tickets de support
  • Afficher l’état du service
  • Afficher les tarifs et les offres
  • Facturation
  • Administrateur pour le compte de
Agent du support technique
  • Rechercher et afficher un client
  • Modifier les détails du client
  • État du service et demandes de service
  • Administrateur pour le compte de
  • Afficher les profils de partenaire
  • Créer une liste de clients
  • Modifier les informations de facturation du client
  • Gestion des abonnements
  • Demander une relation
  • Gérer les prospects
  • Afficher les tarifs et les offres
  • Afficher le contrat client
  • Facturation
  • Inscrire un revendeur à valeur ajoutée
Administrateur global
  • Peut accéder à tous les comptes/services Microsoft avec des privilèges complets
  • Créer des tickets de support pour l’Espace partenaires
  • Afficher les contrats, les listes de prix et les offres
  • Facturation
  • Afficher, créer et gérer les utilisateurs partenaires
Administration de facturation
  • Peut accéder à toutes les factures émises par Microsoft avec des privilèges complets
  • Afficher les contrats, les listes de prix et les offres
  • Facturation
Administrateur de la gestion des utilisateurs
  • Afficher, créer et gérer des utilisateurs
  • Afficher tous les profils de partenaire

 

Comme je vous présenté rapidement ci-dessus, Azure AD ne parle pas nativement NTLM/Kerberos etc… Il va falloir utiliser Azure AD Domain Services qui fournit des services compatibles avec Windows Server AD dans Azure, tels que LDAP, l’authentification Kerberos/NTLM, la jonction de domaine, la stratégie de groupe (GPO) etc… Dans l’exemple ci-dessous, on peut faire qu’une VM Azure est intégrée dans un domaine Azure AD Domain Services.

Les deux schémas ci-dessous illustrent bien le fonctionnement de AAD-DS qui offre aux workloads s’exécutant dans Azure des services de domaine AD, avec les objets provenant de l’AD On-Premise. Microsoft utilise alors la terminologie de DOMAINE MANAGé, qui est stand-alone, qui n’est pas un autre site AD, qui est managé par MS (patch, …). 

Néanmoins, il existe des limitations, car on est un peu dans de l’ADaaS. Quelques différences entre une VM dans Azure et exécutant un DC, et un AAD-DS (pour voir si vous suivez 🙂 )

Fonctionnalités Azure AD Domain Services (AAD-DS) VM dans Azure et exécutant un DC
Managed service
Secure deployments Nécessite de sécuriser le DC, respect des bonnes pratiques, donc 2 DC à minima, etc…
DNS server ✓ (service managé)
Domain or Enterprise administrator privileges
Domain join
Domain authentication using NTLM and Kerberos
Kerberos constrained delegation resource-based resource-based & account-based
Custom OU structure
Schema extensions
AD domain/forest trusts
LDAP read
Secure LDAP (LDAPS)
LDAP write
Group Policy
Geo-distributed deployments
Partagez si ça vous plait !
0 0 votes
Évaluation de l'article
S’abonner
Notification pour
guest

0 Commentaires
Commentaires en ligne
Afficher tous les commentaires
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x