L'équipe IT reçoit l'erreur 'Licenses not assigned. License agreement failed for one user' lors de l'attribution des licences Azure AD Premium P1. L'abonnement dispose pourtant de licences disponibles. Quelle est la cause la plus probable et comment la résoudre ?

La cause la plus probable est que certains utilisateurs n'ont pas de champ 'Usage Location' (emplacement d'utilisation) défini dans leur profil Azure AD. Azure AD exige qu'un emplacement d'utilisation soit renseigné avant d'attribuer une licence, car les conditions d'utilisation des services Microsoft varient selon les pays. Pour résoudre le problème, il faut accéder au profil de chaque utilisateur concerné dans le portail Azure AD, naviguer vers le panneau 'Profil', puis renseigner le champ 'Usage Location' avec le pays approprié (ex : France). Une fois cette modification effectuée, l'attribution de la licence pourra être réalisée avec succès. Pour éviter ce problème à l'avenir lors de synchronisations avec Azure AD Connect, il est recommandé de s'assurer que l'attribut correspondant est peuplé dans l'Active Directory local avant la synchronisation.

L'administrateur du tenant souhaite inviter contractor1@outlook.com dans le tenant fabrikam.com, mais l'utilisateur chargé des invitations reçoit l'erreur 'Unable to invite user – Generic authorization exception'. Quelle action doit être effectuée pour résoudre ce problème, et comment créer un groupe qui sera automatiquement supprimé après 180 jours pour gérer l'accès de ce prestataire à la bibliothèque SharePoint ?

L'erreur 'Generic authorization exception' indique que les paramètres de collaboration externe du tenant restreignent les invitations. Pour résoudre ce problème, un administrateur global doit accéder au portail Azure AD, puis dans le panneau 'Users', modifier les paramètres 'External collaboration settings' afin d'autoriser les membres à inviter des utilisateurs externes, ou d'élargir les permissions d'invitation à l'utilisateur concerné. Concernant le groupe temporaire pour l'accès SharePoint, il faut créer un groupe de type 'Office 365' (Microsoft 365 Group), car la fonctionnalité d'expiration de groupe dans Azure AD s'applique uniquement aux groupes Office 365. Une politique d'expiration doit ensuite être configurée avec une durée de vie de 180 jours. Les groupes de sécurité classiques (Security Groups) ne supportent pas cette fonctionnalité d'expiration automatique et ne doivent donc pas être utilisés pour ce besoin.

L'équipe IT souhaite permettre aux 120 utilisateurs du département Finance de contourner la MFA pendant 14 jours sur les appareils auxquels ils se sont connectés avec succès. Quelle configuration doit être effectuée et où ? Par ailleurs, si la SSPR est configurée avec 2 méthodes requises (téléphone mobile + questions de sécurité, 3 questions requises), un utilisateur du département Finance qui ne fournit qu'une seule question de sécurité peut-il réinitialiser son mot de passe ?

Pour permettre la mémorisation de la MFA sur les appareils de confiance, l'administrateur doit accéder à la page d'authentification multifacteur (portail Azure AD > Security > MFA), puis naviguer vers 'Service settings'. Dans cette section se trouve l'option 'Remember Multi-Factor Authentication on trusted device' qui permet de configurer une durée en jours (ici 14 jours). Une fois activée, les utilisateurs pourront cocher une case lors de leur connexion MFA pour que l'appareil soit mémorisé pendant la durée configurée. Concernant la SSPR : non, un utilisateur qui ne fournit qu'une seule question de sécurité ne peut pas réinitialiser son mot de passe. La configuration exige 2 méthodes d'authentification pour la réinitialisation, et si l'utilisateur choisit les questions de sécurité comme méthode, il doit obligatoirement répondre aux 3 questions configurées. Fournir une seule question ne satisfait pas les exigences de la politique SSPR, et la réinitialisation sera refusée.

L'équipe IT doit configurer Azure File Sync entre les serveurs locaux et un partage de fichiers Azure existant. Quelles sont les deux actions à effectuer dans l'abonnement Azure pour préparer cette synchronisation ? De plus, dans un groupe de synchronisation Group1 utilisant share1 comme point de terminaison cloud, est-il possible d'ajouter share2 (dans un autre compte de stockage) comme second point de terminaison cloud ?

Pour préparer l'abonnement Azure à Azure File Sync, deux actions sont nécessaires côté Azure : premièrement, créer un Storage Sync Service, qui est la ressource de niveau supérieur représentant la relation de confiance avec les serveurs à synchroniser ; deuxièmement, créer un groupe de synchronisation au sein de ce Storage Sync Service, qui définit la topologie de synchronisation en regroupant le point de terminaison cloud et les points de terminaison serveurs. Ces deux étapes doivent être réalisées dans cet ordre avant d'enregistrer les serveurs locaux et d'ajouter les points de terminaison serveurs. Concernant l'ajout de share2 comme second point de terminaison cloud pour Group1 : non, cela n'est pas possible. Un groupe de synchronisation Azure File Sync ne peut avoir qu'un seul point de terminaison cloud (un seul partage de fichiers Azure). Il est impossible d'ajouter un deuxième partage Azure comme cloud endpoint dans le même groupe de synchronisation. En revanche, plusieurs points de terminaison serveurs peuvent coexister dans un même groupe, y compris des dossiers sur des volumes différents d'un même serveur ou sur des serveurs différents.

L'équipe IT souhaite utiliser AzCopy pour copier les fichiers de plans vers le compte de stockage Azure (Blob Storage et File Storage). Quelle méthode d'authentification doit être utilisée pour chaque service de stockage ? Par ailleurs, si l'entreprise souhaite exporter ultérieurement ces données depuis Azure via le service Azure Import/Export, quelles données peuvent être exportées ?

Pour AzCopy avec Azure Blob Storage, deux méthodes d'authentification sont supportées : Azure Active Directory (via la commande 'azcopy login') et les Shared Access Signatures (SAS tokens). L'authentification Azure AD est recommandée car elle ne nécessite pas la gestion de tokens expirables. Pour AzCopy avec Azure File Storage, seule l'authentification par Shared Access Signature (SAS) est supportée. Azure AD n'est pas compatible avec File Storage pour AzCopy, contrairement à Blob Storage. Il faut donc générer un SAS token avec les permissions appropriées sur le partage de fichiers avant d'utiliser AzCopy. Concernant le service Azure Import/Export pour l'exportation : seules les données stockées dans Azure Blob Storage (blobs de blocs et blobs de pages) peuvent être exportées. Les partages Azure Files, les bases de données Azure SQL et les autres services de stockage ne sont pas compatibles avec les travaux d'exportation Azure Import/Export. Ainsi, les fichiers de plans stockés dans Blob Storage pourront être exportés, mais pas les fichiers dans les partages Azure Files.

L'équipe IT doit créer un compte de stockage Azure répondant aux exigences suivantes : supporter les niveaux hot, cool et archive ; assurer la tolérance aux pannes en cas de sinistre régional ; minimiser les coûts. Quelle combinaison de type de compte et de réplication doit être choisie ? De plus, quel est le nombre minimal de stratégies de sauvegarde Azure Backup à créer pour protéger les 80 VM, 15 bases de données SQL et 30 partages de fichiers Azure ?

Pour le compte de stockage, la combinaison correcte est : type StorageV2 (General Purpose v2) avec réplication Standard_GRS (Geo-Redundant Storage). Le type StorageV2 est obligatoire pour supporter les trois niveaux de blob : hot, cool et archive. Le type BlobStorage supporte également ces niveaux mais est plus limité. La réplication GRS assure la tolérance aux pannes régionales en répliquant les données dans une région secondaire distante d'au moins 500 km, garantissant la durabilité même en cas de sinistre affectant la région principale. Cette combinaison est moins coûteuse que GZRS tout en satisfaisant les exigences. Concernant les stratégies de sauvegarde Azure Backup : le nombre minimal est 3 stratégies. Azure Backup nécessite une stratégie distincte par type de ressource car les paramètres, fréquences et fonctionnalités de rétention diffèrent selon le workload : 1 stratégie pour les 80 machines virtuelles Azure, 1 stratégie pour les 15 bases de données Azure SQL, et 1 stratégie pour les 30 partages de fichiers Azure. Il n'est pas nécessaire de créer une stratégie par ressource individuelle ; une stratégie peut s'appliquer à plusieurs ressources du même type.

L'équipe Développement doit pouvoir créer des Azure Logic Apps dans le groupe de ressources DevOps-RG. Quelle solution RBAC doit être appliquée ? Par ailleurs, quel rôle doit être attribué à User1 pour lui permettre d'attribuer des stratégies Azure Policy au groupe d'administration racine du tenant ?

Pour permettre à l'équipe Développement de créer des Azure Logic Apps dans DevOps-RG, il faut attribuer le rôle intégré 'Logic App Contributor' au groupe Développement sur le groupe de ressources DevOps-RG. Ce rôle RBAC intégré permet spécifiquement de créer et gérer des Logic Apps sans accorder d'accès aux autres ressources ni aux données. L'attribution doit se faire au niveau du groupe de ressources (scope : DevOps-RG) et non au niveau de l'abonnement, pour respecter le principe du moindre privilège. Concernant User1 et les stratégies Azure Policy au groupe d'administration racine : il faut attribuer le rôle 'Owner' (Propriétaire) à User1 au niveau du groupe d'administration racine. Ce rôle est nécessaire car le groupe d'administration racine a une portée qui englobe l'intégralité de l'annuaire. De plus, User1 devra activer lui-même l'accès à la gestion des ressources Azure depuis ses paramètres Azure AD, car l'accès au groupe d'administration racine nécessite une élévation spécifique que seul l'Administrateur Global peut s'accorder.

L'équipe IT doit créer le rôle personnalisé 'NetRole' basé sur le rôle Reader. Quelle commande PowerShell doit être exécutée en premier avant de créer ce rôle ? Par ailleurs, pour configurer le tenant de connexion par défaut dans le portail Azure lorsqu'on gère les deux tenants northwind.onmicrosoft.com et external.northwind.onmicrosoft.com, quelle action doit être effectuée ?

Pour créer un rôle Azure personnalisé basé sur le rôle Reader, la première commande à exécuter est 'Get-AzRoleDefinition' avec le nom du rôle Reader, puis convertir la sortie en JSON via 'ConvertTo-Json'. Cette commande récupère la définition complète du rôle Reader depuis Azure RBAC (actions, notActions, assignableScopes), qui sert de point de départ pour créer le rôle personnalisé. Le résultat JSON est ensuite modifié pour changer le nom (en 'NetRole'), ajuster les permissions (Actions/NotActions) et définir les scopes d'assignation appropriés, avant d'être utilisé avec 'New-AzRoleDefinition' pour créer le rôle. Concernant le tenant de connexion par défaut dans le portail Azure : l'administrateur doit utiliser la fonctionnalité 'Switch Directory' (Changer de répertoire) disponible dans le portail Azure, accessible depuis l'icône de profil en haut à droite. En sélectionnant le tenant souhaité comme répertoire actif, le portail Azure mémorise cette préférence et l'utilise comme tenant par défaut lors des connexions suivantes. Cette opération ne nécessite aucune modification dans Azure AD lui-même.

Les auditeurs financiers de Northwind doivent consulter les coûts Azure de la semaine écoulée. Quel panneau du portail Azure doivent-ils utiliser ? De plus, un utilisateur nommé User3 a créé le tenant external.northwind.onmicrosoft.com. Un collègue (User4, Global Administrator du tenant principal) souhaite créer des comptes utilisateurs dans ce nouveau tenant. Peut-il le faire directement, et pourquoi ?

Les auditeurs financiers doivent utiliser le panneau 'Cost Management + Billing' et plus spécifiquement la section 'Cost Analysis' ou 'Invoices' dans le portail Azure. Le panneau Invoices permet de consulter les factures et les coûts Azure sur des périodes passées spécifiques, y compris la semaine précédente. Ce panneau est adapté aux auditeurs car il offre une vue en lecture seule des dépenses sans permettre de modifier les ressources. Pour une vue détaillée par semaine, Cost Analysis avec un filtre de date personnalisé est également pertinent. Concernant User4 et la création de comptes dans external.northwind.onmicrosoft.com : non, User4 ne peut pas créer directement des comptes dans ce tenant. Chaque tenant Azure AD est une entité indépendante avec sa propre gestion des rôles. Être Global Administrator dans le tenant principal (northwind.onmicrosoft.com) ne confère aucun droit dans le tenant external.northwind.onmicrosoft.com. Seul User3, qui a créé ce nouveau tenant et en est automatiquement devenu le Global Administrator, peut créer des comptes utilisateurs dans external.northwind.onmicrosoft.com, ou déléguer ce droit à d'autres utilisateurs en leur attribuant le rôle User Administrator ou Global Administrator dans ce tenant spécifique.

L'équipe IT retire l'OU 'Administratif' de la synchronisation Azure AD Connect, puis relance la synchronisation. Des utilisateurs de l'OU Administratif sont membres d'un groupe du service RH (OU RH, toujours synchronisée). Que se passe-t-il pour ces utilisateurs et leurs appartenances aux groupes dans Azure AD après la synchronisation ?

Lorsqu'une OU est retirée de la synchronisation Azure AD Connect et qu'une nouvelle synchronisation est lancée, les objets (utilisateurs, groupes, contacts) de cette OU qui n'ont de dépendances que dans l'OU retirée sont supprimés d'Azure AD. Cependant, si des utilisateurs de l'OU Administratif sont membres de groupes situés dans des OUs encore synchronisées (ici l'OU RH), leur comportement est particulier : les comptes utilisateurs eux-mêmes sont supprimés d'Azure AD car ils appartiennent à l'OU désynchronisée. Toutefois, leurs entrées d'appartenance dans les groupes de l'OU RH peuvent être conservées sous forme de références fantômes selon la configuration. En pratique, Azure AD Connect gère cela par une suppression progressive : les utilisateurs de l'OU Administratif ne seront plus présents en tant qu'objets utilisateurs dans Azure AD, mais la logique de nettoyage des groupes s'assure que les groupes de l'OU RH restent présents et synchronisés avec leurs membres encore actifs. Les administrateurs doivent vérifier manuellement la cohérence des appartenances aux groupes après une telle modification de périmètre de synchronisation.

La réécriture du mot de passe (Password Writeback) est désactivée dans l'environnement Azure AD Connect d'Alpine Healthcare. Un utilisateur nommé MedUser1 a été créé directement dans l'Active Directory local (alpine.local) et synchronisé avec Azure AD. Un autre utilisateur nommé CloudUser1 a été créé directement dans Azure AD (cloud-only). Lequel de ces deux utilisateurs peut réinitialiser son mot de passe via SSPR, et pourquoi ?

Seul CloudUser1 (utilisateur cloud-only) peut réinitialiser son mot de passe via SSPR. Voici l'explication détaillée : MedUser1 a été créé dans l'Active Directory local et synchronisé vers Azure AD. Son mot de passe est géré dans l'AD local. Sans la réécriture du mot de passe (Password Writeback), lorsque MedUser1 tenterait de réinitialiser son mot de passe via SSPR dans Azure AD, la modification ne pourrait pas être répercutée vers l'Active Directory local. Azure AD ne peut pas modifier unilatéralement le mot de passe d'un compte dont l'autorité de référence est l'AD local. MedUser1 doit donc se connecter depuis un ordinateur joint au domaine alpine.local pour réinitialiser son mot de passe via les mécanismes AD classiques. CloudUser1, en revanche, est un utilisateur dont le mot de passe est géré directement dans Azure AD. SSPR peut modifier ce mot de passe sans nécessiter de réécriture vers un AD local. CloudUser1 peut donc utiliser pleinement la fonctionnalité SSPR, à condition d'avoir préalablement enregistré les méthodes d'authentification requises (2 méthodes : téléphone mobile et/ou 3 questions de sécurité).

L'équipe IT doit ajouter et vérifier le domaine personnalisé 'alpine.ch' dans Azure AD pour permettre le Seamless SSO. Quel type d'enregistrement DNS doit être créé dans la zone DNS publique de alpine.ch pour que Azure AD puisse vérifier ce domaine ? Par ailleurs, lors de la jonction d'un ordinateur Windows 10 à Azure AD par UserA, quels comptes sont automatiquement ajoutés au groupe Administrateurs local de cet ordinateur ?

Pour vérifier le domaine personnalisé alpine.ch dans Azure AD, Microsoft exige la création d'un enregistrement DNS de type MX (ou TXT) dans la zone DNS publique du domaine. Azure AD fournit lors de l'ajout du domaine une valeur spécifique (chaîne de caractères unique) qui doit être ajoutée dans cet enregistrement. L'enregistrement MX est le type traditionnel utilisé pour cette vérification, bien que TXT soit également accepté. Une fois l'enregistrement DNS propagé (ce qui peut prendre jusqu'à 72 heures), Azure AD peut vérifier la propriété du domaine et l'activer pour le tenant. Ce domaine vérifié permettra ensuite de configurer le Seamless SSO en associant le domaine alpine.local au domaine Azure AD alpine.ch via Azure AD Connect. Concernant la jonction d'un Windows 10 à Azure AD par UserA : lors de cette opération, Azure AD ajoute automatiquement deux comptes au groupe Administrateurs local de l'ordinateur : (1) UserA, l'utilisateur qui a effectué la jonction (il reçoit des droits d'administration locaux automatiquement), et (2) le compte Global Administrator du tenant Azure AD (le compte administrateur global est systématiquement ajouté comme administrateur local sur les appareils joints à Azure AD). Les autres utilisateurs standard ne sont pas ajoutés automatiquement au groupe Administrateurs local.

DevUser1 souhaite configurer Laptop2 pour établir une connexion VPN point à site vers VNet1. Il a téléchargé et installé le package de configuration VPN sur Laptop2, mais la connexion échoue. Un collègue suggère de modifier les stratégies d'authentification Azure AD pour résoudre le problème. Cette approche est-elle correcte ? Quelle est la solution appropriée ?

Non, la modification des stratégies d'authentification Azure AD ne résout pas ce problème et n'est pas la solution appropriée. Dans un scénario VPN point à site utilisant des certificats auto-signés, Azure AD n'intervient pas dans le processus d'authentification. Le mécanisme repose entièrement sur les certificats X.509. Le problème avec Laptop2 est que, bien que le package de configuration VPN ait été installé, le certificat client n'a pas été installé sur cet ordinateur. Voici comment fonctionne l'authentification P2S par certificat : un certificat racine auto-signé est créé et son contenu public est chargé dans Azure (gateway VPN). Depuis ce certificat racine, un certificat client est généré et doit être installé dans le magasin de certificats personnel de chaque ordinateur client qui doit établir la connexion. Le package de configuration VPN contient uniquement les paramètres de connexion (adresse du gateway, protocole, etc.) mais pas le certificat client. La solution correcte est donc d'exporter le certificat client depuis Computer1 (où la connexion fonctionne déjà) et de l'installer dans le magasin de certificats personnel (Current User > Personal) de Laptop2. Une fois le certificat client installé, la connexion P2S pourra être établie avec succès.

L'équipe IT doit créer une zone DNS privée 'stellaris.internal' et la lier aux réseaux virtuels Dev-VNet et Shared-VNet. Dev-VNet doit être configuré comme réseau d'enregistrement (registration network) et Shared-VNet comme réseau de résolution uniquement. Quelle est la différence entre ces deux configurations, et combien de réseaux d'enregistrement peuvent être associés à une zone DNS privée Azure ?

La différence entre un réseau d'enregistrement et un réseau de résolution dans une zone DNS privée Azure est fondamentale. Un réseau d'enregistrement (registration network) permet l'enregistrement automatique des enregistrements DNS : lorsqu'une machine virtuelle est créée, démarrée ou que son adresse IP change dans un réseau virtuel configuré comme réseau d'enregistrement, un enregistrement A est automatiquement créé (et mis à jour) dans la zone DNS privée. Cela simplifie considérablement la gestion DNS car les enregistrements sont maintenus automatiquement sans intervention manuelle. Un réseau de résolution (resolution network) permet uniquement aux ressources de ce réseau virtuel de résoudre les noms DNS définis dans la zone privée, mais n'enregistre pas automatiquement les VM dans la zone. Les VM de Shared-VNet pourront résoudre les noms 'stellaris.internal' mais leurs propres enregistrements ne seront pas ajoutés automatiquement. Concernant les limites : une zone DNS privée Azure peut avoir au maximum 1 réseau d'enregistrement. En revanche, elle peut être liée à plusieurs réseaux de résolution (jusqu'à 1 000 liens de réseau virtuel par zone DNS privée). Cette contrainte est importante à connaître pour la conception d'architectures DNS hybrides dans Azure.

L'équipe DevOps doit implémenter une stratégie de sauvegarde Azure Backup pour les ressources de production avec des politiques de rétention différentes selon les types de ressources. Quel est le nombre minimal de stratégies de sauvegarde à créer ? Par ailleurs, le Recovery Services Vault utilisé pour la sauvegarde doit-il impérativement se trouver dans la même région que les ressources à sauvegarder ?

Le nombre minimal de stratégies de sauvegarde à créer est 3. Azure Backup nécessite une stratégie distincte pour chaque type de workload car les paramètres de sauvegarde (fréquence, rétention, options spécifiques) sont différents selon la nature de la ressource : 1 stratégie pour les 45 machines virtuelles Azure (avec rétention 30 jours), 1 stratégie pour les 8 bases de données Azure SQL (avec rétention 30 jours), et 1 stratégie pour les 20 partages de fichiers Azure (avec rétention 14 jours). Il n'est pas nécessaire de créer une stratégie par ressource individuelle : une même stratégie peut s'appliquer à plusieurs ressources du même type si elles partagent les mêmes paramètres de rétention. Dans cet exemple, les VM et les bases SQL ont toutes deux une rétention de 30 jours, mais elles restent de types différents et nécessitent des stratégies séparées. Concernant la région du Recovery Services Vault : oui, le vault doit obligatoirement se trouver dans la même région Azure que les ressources à sauvegarder. Par exemple, un vault en West Europe ne peut pas sauvegarder des VM situées en France Central. Si les ressources de Stellaris Tech sont réparties sur plusieurs régions Azure, il faudra créer un vault distinct par région hébergeant des ressources à protéger. Cette contrainte de co-localisation est une règle fondamentale d'Azure Backup.