Re-joignez la force d’Azure AD

La jointure d’appareil à Azure AD est un sujet à lui tout seul. Celle-ci apporte pourtant un grand nombre de bénéfices pour la sécurité de son environnement 365 grâce à aux polices de compliance ou d’accès conditionnels. Très régulièrement, une confusion émane en provenance des messages parlant de jointure à Azure AD. Souvent ambigus, ils sont provoqués par l’authentification d’un utilisateur à un service 365 du Cloud Microsoft.

Dans cet article, nous allons apprendre les différents types de jointures possible à Azure AD notions et effectuer plusieurs tests sur un environnement de démo.

Qu’est-ce qu’Azure AD ?

Le tout en moins d’une minute 😎.

Pourquoi joindre un appareil à Azure AD ?

Les appareils joints Azure AD ont pour objectif de simplifier :

  • Les déploiements Windows sur des appareils professionnels
  • L’accès aux applications .365 et aux ressources de l’organisation à partir de n’importe quel appareil Windows
  • Gestion cloud des appareils professionnels
  • Aux utilisateurs de se connecter à leurs appareils à partir de leurs comptes Azure AD ou Active Directory synchronisés professionnels ou scolaires.

Existe-t-il plusieurs types de jointure à Azure AD ?

Cette question a plusieurs réponses possibles et le choix va dépendre de l’identité du propriétaire des données, de la personne qui gère l’appareil et du type d’identification de l’utilisateur utilisé pour l’authentification :

Inscrire un appareil sur Azure :

L’objectif des appareils inscrits sur Azure AD (également appelés appareils joints à l’espace de travail) est de fournir à vos utilisateurs la prise en charge des scénarios d’appareil mobile et Bring Your Own Device (BYOD). Dans ces scénarios, un utilisateur peut accéder aux ressources de votre organisation à l’aide d’un appareil personnel.

Microsoft Doc
  • Appareil appartenant à une entreprise et géré par elle
  • L’authentification au dispositif se fait à l’aide d’un identifiant local ou d’un identifiant personnel dans le Cloud.
  • Authentification aux ressources de l’entreprise à l’aide d’un identifiant d’utilisateur sur AAD.

Joindre un appareil sur Azure :

Les appareils joints Azure AD sont connectés au moyen d’un compte professionnel Azure AD. L’accès aux ressources peut être contrôlé en fonction du compte Azure AD et des stratégies d’accès conditionnel appliquées à l’appareil. Les administrateurs peuvent sécuriser et mieux contrôler les appareils joints Azure AD à l’aide d’outils de gestion des périphériques mobiles (GPM), tels que Microsoft Intune ou dans des scénarios de cogestion à l’aide de Microsoft Endpoint Configuration Manager. 

Doc Microsoft
  • Dispositifs appartenant à l’entreprise et gérés par elle
  • Authentification à l’aide d’un identifiant d’entreprise existant dans Azure AD.
  • L’authentification se fait uniquement par AAD.

Jointure hybride d’un appareil sur Azure :

Le meilleur des deux mondes !

  • Appareils appartenant à l’entreprise et géré par elle
  • Authentifié à l’aide d’un identifiant d’utilisateur d’entreprise qui existe dans l’AD local et dans Azure AD.
  • L’authentification peut être faite en utilisant les deux moyens : On-Prem AD et Azure AD.

Le tableau ci-dessous explique bien les 3 scénarios en détail :

Voici donc plusieurs des tests pour comprendre un peu mieux comment on génère ces méthodes de jointure :

  • Test I : Jointure Azure AD : Inscription + MDM Intune
  • Test II : Jointure Azure AD : Inscription
  • Test III : Absence de jointure Azure AD
  • Test IV : Jointure Azure AD : Join + MDM Intune
  • Test V : Jointure Azure AD : Hybride AD / Azure AD

Etape 0 : Rappel des prérequis

Pour effectuer ces tests, nous allons partir d’un environnement Azure et y déployer plusieurs machines virtuelles Azure. Avant cela, voici la courte liste des composants déjà présents sur mon environnement :

  • Tenant Azure
  • Souscription Azure valide
  • Un compte Azure AD avec une licence Office365

Test I : Jointure Azure AD : Inscription + MDM Intune

Déployez une première machine virtuelle avec Windows 10 dans votre souscription Azure comme ceci :

Connectez-vous en bureau à distance à cette dernière avec le compte administrateur local :

Exécutez la commande ci-dessous et constatez l’absence d’informations relatives à Azure AD :

dsregcmd /status

Exécutez l’application Office directement disponible via le menu Démarrer :

Cliquez comme ceci pour lancer le processus d’authentification 365 :

Choisissez l’option suivante et saisissez les identifiants de votre compte 365 :

Laissez cochée la case suivante et cliquez sur OK :

Un message de traitement apparaît alors et vous invite à attendre :

Fermez la fenêtre une fois le traitement réussi :

Relancez la commande précédente pour constater les changements relatifs à Azure AD :

dsregcmd /status

Retournez sur la page listant vos appareils dans le portail Azure AD :

Consultez également sur la page de vos appareils Windows dans le portail Intune :

Ce test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, mais que l’appareil est malgré tout gérable dans Intune. Ce scénario pourrait correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test II : Jointure Azure AD : Inscription

Déployez une seconde machine virtuelle depuis votre Azure, identique à la première :

Ouvrez là encore une session de bureau à distance avec un utilisateur local.

Effectuez les mêmes opérations pour arriver jusqu’à l’écran ci-dessous. Mais décochez cette fois la case et cliquez sur OK :

Le message de traitement vous invitant à patienter est toujours présent :

Attendez la fin du traitement et fermez la fenêtre :

Lancez la commande suivante pour constater d’éventuels changements par rapport au précédent test de jointure :

dsregcmd /status

Retournez sur la page de vos appareils dans votre portail Azure AD et constatez l’apparition de cette seconde machine virtuelle :

La colonne MDM n’est pas remplie, cela s’explique par la case décochée précédemment.

Retournez sur la page de vos appareils Windows dans le portail Intune :

Comme attendu, la seconde machine virtuelle n’apparaît pas.

Ce second test nous apprend que la jointure à Azure AD n’est faite que sous forme d’inscription, et que l’appareil n’est pas gérable dans Intune. Ce scénario pourrait lui aussi correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test III : Absence de jointure Azure AD

Déployez une troisième machine virtuelle Azure pour continuer à tester une autre possibilité de jointure.

Effectuez les mêmes opérations pour arriver jusqu’à cet écran. Cliquez sur Non, authentifiez-vous uniquement sur l’application :

Pas de traitement ou de message de fin.

Relancez la commande suivante pour voir d’éventuels changements avec les précédents tests :

dsregcmd /status

Un tour dans la liste des devices d’Azure AD pour constater une éventuelle apparition :

Aucune nouvelle machine virtuelle.

Il en est de même dans le portail Intune : 0 changement.

Ce troisième test nous apprend qu’aucune jointure à Azure AD, et que l’appareil n’est pas non plus gérable dans Intune. Ce scénario pourrait lui aussi encore correspondre à un appareil personnel utilisé dans le cadre professionnel.

Test IV : Jointure Azure AD : Join + MDM Intune

A l’inverse des tests précédents, la jointure de ce test va s’effectuer dans la configuration Windows.

Déployez une quatrième machine virtuelle Azure, toujours identique aux précédentes :

Connectez-vous sur votre machine virtuelle avec l’utilisateur local et allez dans les Comptes de vos Paramètres Windows :

Connecter votre compte Azure AD comme ceci :

Cliquez sur l’option ci-dessous pour joindre la machine virtuelle à un tenant Azure AD :

Renseignez le compte 365 de votre utilisateur :

Approuvez la jointure en cliquant sur Joindre :

Attendez que la jointure s’applique :

Le message de succès vous indique que vous pouvez maintenant utiliser votre compte Azure AD pour ouvrir la session Windows :

La jointure est bien confirmée grâce à l’indication suivante :

Pour vous connecter sur la machine virtuelle avec votre compte Azure AD, décochez la case suivante dans les propriétés système de celle-ci :

Fermez la session RDP ouverte précédemment.

Sur votre poste, modifiez le fichier RDP avec un éditeur de texte pour y ajouter les paramètres suivants :

enablecredsspsupport:i:0
authentication level:i:2

Cela donne un fichier contenant les lignes suivantes :

Ouvrez ce programme RDP et renseignez comme ceci votre compte 365 :

Sur cette nouvelle session RDP ouverte, exécutez la commande ci-dessous :

dsregcmd /status

Retournez et constatez la présence de cette nouvelle machine virtuelle dans la liste des appareils d’Azure AD, avec un nouveau type de jointure :

Il en est de même dans le portail Intune :

La quatrième machine virtuelle apparaît bien comme appartenant à l’entreprise.

A l’inverse des tests précédents, celui-ci nous apprend que la jointure à Azure AD complète, et que l’appareil est aussi gérable dans Intune. Ce scénario pourrait correspondre à un appareil professionnel utilisé dans le cadre professionnel.

Test V : Jointure Azure AD : Hybride AD / Azure AD

Ce nouveau test demandera un peu plus d’efforts. Pour y arriver, il va nous falloir disposer d’un domaine Active Directory. Commencez donc par créer une première machine virtuelle basée sur une image Windows Server :

Une fois déployée, connectez-vous en RDP sur cette machine virtuelle Windows Server :

Ajoutez à votre serveur les rôles de Contrôleur de domaine et de Serveur DNS et laissez-vous guider jusqu’au lancement de l’installation :

Terminez la configuration de l’Active Directory en créer une nouvelle forêt de domaine :

Lancez la finalisation de l’installation avec des options de base et malgré l’affichage d’alertes non bloquantes :

Attendez que la session RDP se ferme automatiquement :

Retournez sur le portail Azure pour ajouter dans la résolution DNS du réseau virtuel par l’adresse IP de votre nouveau serveur DC / DNS :

Réouvrez une session RDP avec le nouveau compte administrateur de domaine :

N’attendez pas la fin du chargement de session et retournez sur votre portail Azure :

Créez une autre machine virtuelle sous Windows 10 sur le même réseau virtuel que la machine de domaine :

Ouvrez une session RDP avec un compte utilisateur local et joignez cette machine au domaine Active Directory :

Redémarrez cette machine virtuelle :

Retournez sur la session RDP ouverte sur le serveur Active Directory et utilisez le lien suivant pour y installer Azure AD Connect :

Lancez l’exécutable MSI téléchargé et choisissez l’option ci-dessous :

Cochez la case SSO dans la configuration de votre Azure AD Connect :

Renseignez le compte Administrateur Global de votre tenant 365 :

Renseignez le compte Administrateur d’entreprise de votre domaine Active Directory :

Cliquez sur Suivant :

Cochez la case et cliquez sur Suivant :

Synchronisez l’ensemble du domaine Active Directory :

Cliquez sur Suivant :

Cliquez encore sur Suivant :

Cliquez toujours sur Suivant :

Renseignez les identifiants d’Administrateur d’entreprise et cliquez sur Suivant :

Lancez l’installation de la configuration :

Une fois la configuration terminée, quittez le configurateur :

L’affichage des appareils d’Azure AD ne montre pour l’instant aucune nouvelle machine provenant de ce test :

Quelques minutes plus tard, relancez la configuration d’Azure AD Connect :

Cliquez comme ceci pour activer la jointure hybride AD / Azure AD :

Après avoir renseigné les identifiants d’Administrateur global du tenant 365, activez la fonctionnalité de jointure hybride :

Cochez la case pour les prendre en compte machines en Windows 10 ou ultérieures :

Renseignez les identifiants d’Administrateur d’entreprise du domaine Active Directory :

Démarrez la mise à jour de la nouvelle configuration :

Une fois la reconfiguration terminée, fermez la fenêtre d’installation d’Azure AD Connect :

Lancez en PowerShell la commande suivante pour forcer une nouvelle synchronisation entre l’AD et Azure AD :

Start-ADSyncSyncCycle -PolicyType Delta

Rafraîchissez la page des appareils d’Azure AD pour constater une nouvelle apparition :

Ouvrez une session RDP avec un compte de domaine sur la machine Windows 10 et retournez quelques minutes plus tard sur la page des appareils d’Azure AD pour constater le changement :

Conclusion

Les tests sur Azure AD sont toujours une précieuse méthode pour comprendre tous les mécanismes d’Azure. Enfin voici une vidéo explicative reprenant différentes étapes de nos tests 😎😎

Azure AD Connect à la sauce multi-tenants !

Déjà disponible en preview depuis quelques temps, Azure AD Connect apporte la synchronisation vers plusieurs tenants Azure AD en disponibilité générale (GA). Cette nouvelle fonctionnalité permet la réplication d’utilisateurs et de groupes présents dans un Active Directory vers plusieurs environnements Microsoft Cloud.

Pour arriver à cette situation, il faudra alors installer plusieurs agents Azure AD Connect sur différents serveurs (un par tenant à associer). Avant de rentrer ensemble dans la technique, voici un rappel de ce qu’Azure AD Connect apporte :

Quels sont les moyens actuels pour structurer un tenant Azure AD ?

Un tenant correspond le plus souvent une organisation souhaitant posséder et gérer environnement spécifique de services Microsoft Cloud (Azure / Office365).

Comme le recommande Microsoft, envisager l’utilisation de plusieurs tenants Azure AD ne doit pas être la norme. L’utilisation d’un seul tenant apporte les bénéfices suivants :

  • Identité Cloud unique (un seul UPN pour se connecter)
  • Simplification dans la gestion des services et des licences
  • Simplification du management IT et de la sécurité

Bien qu’Azure AD soit construit en structure plate, il existe aussi les unités administratives. Ces dernières peuvent couvrir plusieurs besoins, dans lesquels un seul tenant suffira :

La gestion des identités dans le cas B2C ne nécessite pas non plus la création d’un nouveau tenant B2B :

Que reste-t-il donc pour justifier la création d’autres tenants Azure AD ?

  • Création d’un environnement de test ou pour du développement applicatif
  • Séparation de branches d’une même entreprise
  • Exigences particulières de sécurité
  • Besoin de disposer de plusieurs variantes d’Azure (Azure Gov, Azure China, Azure Germany)
  • Limitations Azure AD
  • Limitations Azure

Quels seront les inconvénients à multiplier les tenants Azure AD ?

Il ne faut pas oublier que l’utilisation de plusieurs identités Cloud va compliquer le quotidien, comme par exemple :

  • Risque ou obligation de doublons de licence (erreur ou contrainte)
  • Complexification pour les utilisateurs finaux
  • Installation alourdie (une seule instance d’Azure AD Connect par serveur. Prévoir autant de serveur que de tenants à synchroniser. Prévoir également l’installations d’Azure AD Connect sur des serveurs de secours (redondance).
  • Synchronisation limitée : certains objets comme les périphériques ou les groupes des tenants ne seront pas remontés dans Active Directory
  • Gestion des mots de passe : synchronisation des hashs des mots de possible entre Active Directory et les tenants Azure AD sous certaines conditions

Test d’un changement de mot de passe pour un utilisateur synchronisé sur plusieurs tenants Azure AD

Microsoft signale justement une fonctionnalité intéressante concernant la gestion des mots de passe pour les utilisateurs synchronisés dans plusieurs tenants :

Il est possible de configurer la synchronisation du hachage de mot de passe depuis Active Directory avec plusieurs locataires Azure AD pour le même objet utilisateur. Si la synchronisation du hachage de mot de passe est activée pour un locataire, la réécriture du mot de passe peut également être activée, ce qui peut être fait sur plusieurs locataires : si le mot de passe est modifié sur un locataire, la réécriture du mot de passe est mise à jour dans Active Directory, et la synchronisation du hachage de mot de passe met à jour le mot de passe dans les autres locataires.

Microsoft Doc

Dans cet article, nous allons donc tester ensemble les différentes étapes pour mettre cette fonctionnalité en place.

Etape 0 : Rappel des prérequis

Comme toujours, des prérequis sont nécessaires pour réaliser cette démonstration d’Azure AD Connect :

  • Un premier tenant, Tenant A, synchronisé avec l’Active Directory
  • Un premier serveur, Serveur A, gérant un domaine Active Directory et avec l’agent Azure AD Connect d’installé
  • Un second tenant, Tenant B, non synchronisé à l’Active Directory
  • Un second serveur, Serveur B, joint au même domaine Active Directory

Serveur A : mon agent Azure AD Connect installé sur mon premier serveur synchronise déjà mes utilisateurs vers le tenant A

Tenant A : Filtrez vos utilisateurs pour ne voir que ceux provenant de la synchronisation de l’AD

Tenant B : Effectuez la même opération de filtrage pour constater l’absence d’utilisateurs synchronisés

Tenant B : un contrôle sur les propriétés Azure AD Connect du tenant B affiche un paramétrage encore vierge

Etape I : Installation d’Azure AD Connect sur le second serveur

Serveur B : connectez-vous en RDP sur ce second serveur pour y installer la dernière version d’Azure AD Connect, disponible sur cette page Microsoft

Rappel de sécurité :
On ne conseille jamais d‘installer Azure AD Connect sur un contrôleur de domaine.

Laissez-vous guider par l’installeur

Etape II : Configuration d’Azure AD Connect sur le second serveur

Serveur B : acceptez les termes, puis cliquez sur Continuer

Cliquez sur Installer

Choisissez la synchronisation des hash des mots de passe, puis cliquez sur Suivant

Inutile de cocher la case SSO car il ne sera pas possible de joindre un PC en hybride sur 2 tenant Azure AD.

Renseignez le compte Azure AD d’un administrateur global ou d’un administrateur de gestion des identités hybrides, puis cliquez sur Suivant

Ajoutez votre Active Directory grâce à l’utilisation d’un compte administrateur d’entreprise, puis cliquez sur Suivant

Cochez la case de confirmation de contrôle des UPN, puis cliquez sur Suivant

Définissez les OUs à synchroniser vers le tenant B, puis cliquez sur Suivant

Cliquez sur Suivant

Cliquez sur Suivant

Cochez la case concernant les mots de passe, puis cliquez sur Suivant

Cliquez sur Installer

Une fois la configuration terminée avec succès, fermez le configurateur Azure AD

Etape III : Vérifications de la synchronisation d’Azure AD Connect sur le second tenant

Serveur B : ouvrez Synchronisation Service Manager, disponible depuis le menu Démarrer

Vérifiez la bonne présence et le succès des 6 lignes de synchronisation

Cliquez sur la ligne d’exportation vers le tenant B pour y constater l’ajout d’utilisateurs

Tenant B : Retournez sur le portail Azure et rafraîchissez la liste des utilisateurs filtrés sur le tenant B

Etape IV : Test de l’authentification utilisateur sur le second tenant

Tenant B : testez l’authentification d’un utilisateur synchronisé depuis un navigateur privé avec son mot de passe AD

La connexion fonctionne bien et vous affiche la page d’accueil d’Office 365 :

Etape V : Premier test de changement de mot de passe sur le tenant B

Tenant B : essayez de changer mot de passe depuis le tenant B via le bouton de paramétrage en haut à droite

La réponse de Microsoft sur le tenant B est assez claire : il ne semble pas possible de modifier le mot de passe sur le tenant B, qui n’est pas le tenant « principal »

Fermez le navigateur privé

Etape VI : Second test de changement de mot de passe sur le tenant A

Tenant A : essayez à nouveau de changer mot de passe depuis le tenant A via la même procédure de navigateur privé

Aucun blocage pour ce second essai sur le tenant A, définissez-y alors un nouveau mot de passe sur cet utilisateur

Une fois modifié, fermez le navigateur privé

Optionnel : Si cela est possible, ouvrez une session RDP sur une machine du domaine AD avec le compte utilisateur modifié

Si la session Windows de l’utilisateur s’ouvre bien, le nouveau mot de passe a bien été pris en compte sur l’AD

Tenant B : ouvrez à nouveau un navigateur privé pour retenter l’opération d’authentification du même utilisateur avec le nouveau mot de passe sur le tenant B

Attendez quelques minutes et retentez l’opération avec le nouveau mot de passe sur le tenant B

Si la page d’accueil d’Office 365 s’ouvre bien, le mot de passe est été pris en compte sur l’Azure AD du tenant B

Conclusion

Comme nous le supposions, la gestion d’identités d’un Active Directory vers plusieurs tenants Azure AD est possible. Notre démonstration nous a aussi permis de tester la réplication des hashs des mots de passe sur plusieurs tenants sous certaines conditions.

Pour continuer sur la gestion de plusieurs tenants Azure, je trouvais intéressant de vous parler d’Azure AD Cross-Tenant Access

Associez FSLogix avec Azure AD

Microsoft vient tout juste de l’annoncer en préview : vous pouvez maintenant gérer les identités d’un partage de fichiers Azure PaaS directement avec Azure AD !

C’est une excellente nouvelle, attendue depuis plusieurs mois par de nombreux utilisateurs d’Azure Virtual Desktop, notamment pour mettre en place des solutions comme FSLogix, déjà utilisée pour la gestion des profils utilisateurs, sans serveur AD DS. Par contre, il y a encore une petite mauvaise nouvelle :

Cette fonctionnalité nécessite actuellement que les utilisateurs aient des identités hybrides, gérées dans Active Directory.

Documentation Microsoft

Quel est donc l’intérêt ?

Cette contrainte d’avoir un environnement hybride, qui sous-entend donc la présence d’un domaine AD, n’est pas forcément une mauvaise chose. Il s’agit ici d’une avancée technique intermédiaire. Nul doute que ce prérequis ne sera plus nécessaire à moyen terme.

Dans cet article, nous allons donc tester cette nouvelle fonctionnalité. Le but de tester cette préview de gestion des tickets Kerberos par Azure AD est de mesurer les avancées Microsoft. Vous pouvez suivre la documentation leur officielle ici.

Etape 0 : Rappel des prérequis

Comme vous allez travailler avec des tickets Kerberos spécifiques à Azure AD, il est obligatoire que les postes ayant accès au partage de fichiers PaaS disposent de l’un des OS suivants :

  • Windows 11 Enterprise mono ou multisession
  • Windows 10 Enterprise mono ou multisession, en version 2004 ou ultérieure avec la mise à jour KB5007253
  • Windows Server, version 2022 avec la dernière mise à jour KB5007254

Dans mon cas, j’ai utilisé l’environnement suivant :

  • une VM Windows Server 2022 pour jouer le contrôleur de domaine
  • Une environnement AVD composé de VMs en Windows 11 Enterprise multisession

Comme annoncé avant, les postes en accès au partage de fichier doivent donc être joints à Azure AD ou en mode hybride (Active Directory + Azure AD). Néanmoins, les utilisateurs doivent être « hybrides », il est donc nécessaire de passer par Azure AD Connect pour y arriver. Le choix du domaine managé Azure AD DS n’est donc pas possible ici :

  • Azure Active Directory Domain Services (Azure AD DS) : Azure AD DS fournit des services de domaine managé avec un sous-ensemble de fonctionnalités AD DS traditionnelles, comme la jonction de domaine, la stratégie de groupe, le protocole LDAP et l’authentification Kerberos/NTLM.
  • Active Directory Domain Services (AD DS) : serveur LDAP (Lightweight Directory Access Protocol) qui fournit des fonctionnalités clés telles que l’identité et l’authentification, la gestion des objets, la stratégie de groupe et les approbations.

Au final, les prérequis sont donc les suivants :

  • Un tenant Microsoft (Azure AD)
  • Des licences comprenant Windows 10 Entreprise pour vos utilisateurs AVD
  • Une souscription Azure active avec le rôle de propriétaire :
  • Un domaine Active Directory Domain Services (AD DS) :
  • Des utilisateurs AVD présents dans AD DS et synchronisés avec Azure AD :
  • Un environnement Azure Virtual Desktop déployé et lié à votre domaine AD DS :
  • Des machines virtuelles AVD jointes é la fois à votre AD DS et enrôlées dans votre Azure AD :

Une fois cela en place, déroulez les prochaines étapes d’installation depuis votre contrôleur de domaine.

Etape I : Création d’un nouveau compte de stockage

Sur votre portail Azure, commencez par créer votre nouveau compte de stockage :

Une fois créé, stockez l’ID de la souscription Azure, le nom du groupe de ressources et le nom du compte de stockage dans les variables suivantes :

$resourceGroupName = "<MyResourceGroup>"
$storageAccountName = "<MyStorageAccount>"
$Subscription = "<MySubscriptionID>"

Etape II : Configuration de l’authentification Azure AD

Vous allez utiliser plusieurs nouvelles fonctionnalités, il est donc préférable de réinstaller des modules PowerShell sur votre poste. Ouvrez PowerShell ISE en mode administrateur et lancez la commande suivante :

Install-Module -Name Az.Storage -AllowClobber
Install-Module -Name AzureAD -AllowClobber

Validez les messages d’avertissement si besoin :

L’activation de l’authentification via Azure AD passe elle aussi par une commande PowerShell :

Connect-AzAccount
$ApiVersion = '2021-04-01'

$Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

$json = 
   @{properties=@{azureFilesIdentityBasedAuthentication=@{directoryServiceOptions="AADKERB"}}};
$json = $json | ConvertTo-Json -Depth 99

$token = $(Get-AzAccessToken).Token
$headers = @{ Authorization="Bearer $token" }

try {
    Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json;
} catch {
    Write-Host $_.Exception.ToString()
    Write-Error -Message "Caught exception setting Storage Account directoryServiceOptions=AADKERB: $_" -ErrorAction Stop
}

Le lancement du script PowerShell vous demandera de vous authentifier en utilisant un compte propriétaire de la souscription Azure :

Le lancement réussi du script devrait vous donner le résultat suivant :

Constatez l’activation de la fonctionnalité en préview, directement sur le compte de stockage :

Il ne reste en plus qu’à générer une nouvelle clef pour le protocole Kerberos :

Set-azcontext -Subscription $Subscription
New-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -KeyName kerb1 -ErrorAction Stop

Cette clef n’est pas contre pas visible sur le portail Azure.

Etape III : Création d’une identité principal de service

L’activation des droits d’Azure AD sur le compte de stockage n’est pas encore possible via le portail Azure. Commencez par générer un mot de passe, basé sur la nouvelle clef Kerberos de votre compte stockage, et stocker le dans une variable grâce à la commande PowerShell suivante :

$kerbKey1 = Get-AzStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName -ListKerbKey | Where-Object { $_.KeyName -like "kerb1" }
$aadPasswordBuffer = [System.Linq.Enumerable]::Take([System.Convert]::FromBase64String($kerbKey1.Value), 32);
$password = "kk:" + [System.Convert]::ToBase64String($aadPasswordBuffer);

Lors d’une étape précédente, vous vous êtes déjà connecté à Azure. Connectez-vous maintenant à Azure AD :

Connect-AzureAD
$azureAdTenantDetail = Get-AzureADTenantDetail;
$azureAdTenantId = $azureAdTenantDetail.ObjectId
$azureAdPrimaryDomain = ($azureAdTenantDetail.VerifiedDomains | Where-Object {$_._Default -eq $true}).Name

Utilisez ici un compte administrateur global du tenant :

Préparer la génération du principal de sécurité :

$servicePrincipalNames = New-Object string[] 3
$servicePrincipalNames[0] = 'HTTP/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[1] = 'CIFS/{0}.file.core.windows.net' -f $storageAccountName
$servicePrincipalNames[2] = 'HOST/{0}.file.core.windows.net' -f $storageAccountName

Créez et chargez dans une variable les éléments nécessaires à la future Enregistrement d’applications :

$application = New-AzureADApplication -DisplayName $storageAccountName -IdentifierUris $servicePrincipalNames -GroupMembershipClaims "All";

Générez alors le principal de sécurité :

$servicePrincipal = New-AzureADServicePrincipal -AccountEnabled $true -AppId $application.AppId -ServicePrincipalType "Application";

Configurez le mot de passe stocké précédement pour celui-ci :

$Token = ([Microsoft.Open.Azure.AD.CommonLibrary.AzureSession]::AccessTokens['AccessToken']).AccessToken
$apiVersion = '1.6'
$Uri = ('https://graph.windows.net/{0}/{1}/{2}?api-version={3}' -f $azureAdPrimaryDomain, 'servicePrincipals', $servicePrincipal.ObjectId, $apiVersion)
$json = @'
{
  "passwordCredentials": [
  {
    "customKeyIdentifier": null,
    "endDate": "<STORAGEACCOUNTENDDATE>",
    "value": "<STORAGEACCOUNTPASSWORD>",
    "startDate": "<STORAGEACCOUNTSTARTDATE>"
  }]
}
'@
$now = [DateTime]::UtcNow
$json = $json -replace "<STORAGEACCOUNTSTARTDATE>", $now.AddDays(-1).ToString("s")
  $json = $json -replace "<STORAGEACCOUNTENDDATE>", $now.AddMonths(12).ToString("s")
$json = $json -replace "<STORAGEACCOUNTPASSWORD>", $password
$Headers = @{'authorization' = "Bearer $($Token)"}
try {
  Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method Patch -Headers $Headers -Body $json 
  Write-Host "Success: Password is set for $storageAccountName"
} catch {
  Write-Host $_.Exception.ToString()
  Write-Host "StatusCode: " $_.Exception.Response.StatusCode.value
  Write-Host "StatusDescription: " $_.Exception.Response.StatusDescription
}

Etape IV : Définir les autorisations API sur l’application nouvellement créée

Comme indiqué dans la documentation Microsoft, la suite du processus peut se faire dans le portail Azure. Ouvrez votre portail Azure Active Directory :


Dans vos Enregistrement d’applications, cliquez sur Toutes les applications, puis enfin sélectionnez l’application dont le nom correspond à votre compte de stockage :

Dans les autorisations API dans le volet de gauche, ajoutez une autorisation comme ceci :

Sélectionnez Microsoft Graph, puis choisissez délégation des permissions :

Dans la section OpenID, sélectionnez Profile :

Descendez plus bas dans la liste pour retrouver la section User. Cochez alors User.Read et cliquez sur Ajouter :

Une fois sur retourné sur l’écran des permissions, cliquez ci-dessous pour ajouter le consentement global à tout votre tenant :

Constatez la bonne application de celui-ci grâce au statut à droite :

Etape V : Création du partage de fichier

Retournez sur votre compte de stockage pour créer un nouveau partage de fichier comme ceci :

Etape VI : Jointure du partage de fichier Azure au domaine Active Directory

Pour l’instant, le partage de fichier Azure nécessite encore l’attribution de droits RBAC aux utilisateurs Azure Virtual desktop. Dans votre cas cette fonctionnalité nécessite d’activer l’authentification AD DS sur le compte de stockage.

Commencez par télécharger sur GitHub la version la plus récente du module PowerShell AzFilesHybrid.zip :

Décompressez les fichiers sur le disque C sur une VM, jointe à votre domaine :

Démarrez Windows PowerShell ISE en tant qu’administrateur et exécutez ce qui suit pour supprimer le flux de données alternatif Zone.Identifier, qui a une valeur de 3, indiquant qu’il a été téléchargé à partir d’Internet :

Get-ChildItem -Path C:\AzFilesHybrid -File -Recurse | Unblock-File

Toujours en PowerShell, connectez-vous à Azure :

Connect-AzAccount

Lancez alors le script suivant en modifiant les paramètres, selon votre configuration :

.\CopyToPSPath.ps1
Import-Module -Name AzFilesHybrid
Join-AzStorageAccountForAuth `
  -ResourceGroupName 'aadjoin-rg' `
  -StorageAccountName 'jloaadjoin2' `
  -DomainAccountType 'ComputerAccount' `
  -OrganizationalUnitDistinguishedName 'OU=AVDJOIN-Devices,DC=jloudev,DC=ml'

Constatez le retour de commande suivant :

Vous pouvez aussi contrôler la bonne activation sur le compte de stockage :

Restez sur votre compte de stockage pour assigner le rôle Storage File Data SMB Share Contributor à votre utilisateurs Azure Virtual Desktop :

Dans notre démonstration, nous allons seulement autoriser le groupe d’utilisateurs Azure Virtual Desktop.

Etape VII : Attribution des autorisations

Pour empêcher les utilisateurs d’accéder aux profils utilisateurs d’autres utilisateurs, vous devez également attribuer des autorisations au niveau du répertoire.

Le système que vous utilisez pour configurer les permissions doit répondre aux exigences suivantes :

  • La poste a une version de Windows répond aux exigences des systèmes d’exploitation des prérequis
  • Le poste doit être joint à Azure AD ou à Hybrid Azure AD à Azure AD
  • Le poste est relié au contrôleur de domaine

Installez ou importez si besoin sur le poste le module PowerShell ActiveDirectory. Dans mon cas, je n’ai pas eu à faire cette opération car j’ai tout exécuté depuis mon contrôleur de domaine :

Import-module ActiveDirectory

Azure AD ne prenant pas actuellement en charge la configuration des listes de contrôle d’accès dans Shell, il doit s’appuyer sur Active Directory. Pour configurer Shell sur votre compte de stockage, exécutez la commande suivante dans PowerShell ISE en tant qu’administrateur :

function Set-StorageAccountAadKerberosADProperties {
    [CmdletBinding()]
    param(
        [Parameter(Mandatory=$true, Position=0)]
        [string]$ResourceGroupName,

        [Parameter(Mandatory=$true, Position=1)]
        [string]$StorageAccountName,

        [Parameter(Mandatory=$false, Position=2)]
        [string]$Domain
    )  

    $AzContext = Get-AzContext;
    if ($null -eq $AzContext) {
        Write-Error "No Azure context found.  Please run Connect-AzAccount and then retry." -ErrorAction Stop;
    }

    $AdModule = Get-Module ActiveDirectory;
     if ($null -eq $AdModule) {
        Write-Error "Please install and/or import the ActiveDirectory PowerShell module." -ErrorAction Stop;
    }	

    if ([System.String]::IsNullOrEmpty($Domain)) {
        $domainInformation = Get-ADDomain
        $Domain = $domainInformation.DnsRoot
    } else {
        $domainInformation = Get-ADDomain -Server $Domain
    }

    $domainGuid = $domainInformation.ObjectGUID.ToString()
    $domainName = $domainInformation.DnsRoot
    $domainSid = $domainInformation.DomainSID.Value
    $forestName = $domainInformation.Forest
    $netBiosDomainName = $domainInformation.DnsRoot
    $azureStorageSid = $domainSid + "-123454321";

    Write-Verbose "Setting AD properties on $StorageAccountName in $ResourceGroupName : `
        EnableActiveDirectoryDomainServicesForFile=$true, ActiveDirectoryDomainName=$domainName, `
        ActiveDirectoryNetBiosDomainName=$netBiosDomainName, ActiveDirectoryForestName=$($domainInformation.Forest) `
        ActiveDirectoryDomainGuid=$domainGuid, ActiveDirectoryDomainSid=$domainSid, `
        ActiveDirectoryAzureStorageSid=$azureStorageSid"

    $Subscription =  $AzContext.Subscription.Id;
    $ApiVersion = '2021-04-01'

    $Uri = ('https://management.azure.com/subscriptions/{0}/resourceGroups/{1}/providers/Microsoft.Storage/storageAccounts/{2}?api-version={3}' `
        -f $Subscription, $ResourceGroupName, $StorageAccountName, $ApiVersion);

    $json=
        @{
            properties=
                @{azureFilesIdentityBasedAuthentication=
                    @{directoryServiceOptions="AADKERB";
                        activeDirectoryProperties=@{domainName="$($domainName)";
                                                    netBiosDomainName="$($netBiosDomainName)";
                                                    forestName="$($forestName)";
                                                    domainGuid="$($domainGuid)";
                                                    domainSid="$($domainSid)";
                                                    azureStorageSid="$($azureStorageSid)"}
                                                    }
                    }
        };  

    $json = $json | ConvertTo-Json -Depth 99

    $token = $(Get-AzAccessToken).Token
    $headers = @{ Authorization="Bearer $token" }

    try {
        Invoke-RestMethod -Uri $Uri -ContentType 'application/json' -Method PATCH -Headers $Headers -Body $json
    } catch {
        Write-Host $_.Exception.ToString()
        Write-Host "Error setting Storage Account AD properties.  StatusCode:" $_.Exception.Response.StatusCode.value__ 
        Write-Host "Error setting Storage Account AD properties.  StatusDescription:" $_.Exception.Response.StatusDescription
        Write-Error -Message "Caught exception setting Storage Account AD properties: $_" -ErrorAction Stop
    }
}

Lancez alors la fonction précédente grâce à cette commande :

Connect-AzAccount
Set-StorageAccountAadKerberosADProperties -ResourceGroupName $resourceGroupName -StorageAccountName $storageAccountName

Cette commande fait alors rebasculer le statut Active Directory sur compte de stockage comme ceci :

Etape VIII : Création de la GPO

Toujours sur votre contrôleur de domaine, ouvrez le gestionnaire des polices :

Sous votre OU des postes AVD, créez une nouvelle police et éditez là :

Activer la police suivante :

Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon

Ajoutez également une règle de registre sur cette même police :

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

Redémarrez les VMs Azure Virtual Desktop pour la bonne prise en compte de la GPO :

Connectez-vous à une session Azure Virtual Desktop grâce à Windows Remote Desktop :

Utilisez un compte utilisateur d’AVD.

Une fois la session AVD ouverte, ouvrez une ligne de commande et tapez le code suivant :

dsregcmd /RefreshPrt

Verrouillez votre session AVD, puis déverrouillez-là :

Saisissez les deux lignes de commande suivantes :

klist purge
klist get krbtgt

Constatez la présence de :

krbtgt/KERBEROS.MICROSOFTONLINE.COM @ KERBEROS.MICROSOFTONLINE.COM

Lancez enfin la commande net use pour monter le lecteur réseau et vérifiez le bon fonctionnement :

net use Z: \\jloaadjoin2.file.core.windows.net\avdfileshare
Il arrive par moment que la commande échoue la première fois.

On retrouve bien le disque réseau dans l’explorateur Windows :

En retournant sur les tickets Kerberos, un nouveau CIFS a fait son apparition :

Etape IX : Configuration de FSLogix

Une fois l’architecture en place, on peut combiner cette dernière pour la gestion des profils utilisateurs via FSLogix. Pour cela, il nous faut rajouter la configuration FSLogix et une règle de registre en plus pour Azure AD.

#Variables
$storageAccountName = "jloaadjoin2"
$filesharename = "avdfileshare"

#Create Directories
$LabFilesDirectory = "C:\LabFiles"

if(!(Test-path -Path "$LabFilesDirectory")){
New-Item -Path $LabFilesDirectory -ItemType Directory |Out-Null
}
if(!(Test-path -Path "$LabFilesDirectory\FSLogix")){
New-Item -Path "$LabFilesDirectory\FSLogix" -ItemType Directory |Out-Null
}

 #Download FSLogix Installation bundle
  if(!(Test-path -Path "$LabFilesDirectory\FSLogix_Apps_Installation.zip")){
       Invoke-WebRequest -Uri "https://experienceazure.blob.core.windows.net/templates/wvd/FSLogix_Apps_Installation.zip" -OutFile     "$LabFilesDirectory\FSLogix_Apps_Installation.zip"

 #Extract the downloaded FSLogix bundle
 function Expand-ZIPFile($file, $destination){
     $shell = new-object -com shell.application
     $zip = $shell.NameSpace($file)
     foreach($item in $zip.items()){
     $shell.Namespace($destination).copyhere($item)
     }
 }

 Expand-ZIPFile -File "$LabFilesDirectory\FSLogix_Apps_Installation.zip" -Destination "$LabFilesDirectory\FSLogix"

}
   #Install FSLogix
   if(!(Get-WmiObject -Class Win32_Product | where vendor -eq "FSLogix, Inc." | select Name, Version)){
       $pathvargs = {C:\LabFiles\FSLogix\x64\Release\FSLogixAppsSetup.exe /quiet /install }
       Invoke-Command -ScriptBlock $pathvargs
   }
   #Create registry key 'Profiles' under 'HKLM:\SOFTWARE\FSLogix'
   $registryPath = "HKLM:\SOFTWARE\FSLogix\Profiles"
   if(!(Test-path $registryPath)){
       New-Item -Path $registryPath -Force | Out-Null
   }

   #Add registry values to enable FSLogix profiles, add VHD Locations, Delete local profile and FlipFlop Directory name
   New-ItemProperty -Path $registryPath -Name "VHDLocations" -Value "\\$storageAccountName.file.core.windows.net\$filesharename" -PropertyType String -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "Enabled" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "DeleteLocalProfileWhenVHDShouldApply" -Value 1 -PropertyType DWord -Force | Out-Null
   New-ItemProperty -Path $registryPath -Name "FlipFlopProfileDirectoryName" -Value 1 -PropertyType DWord -Force | Out-Null
    
    reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1

   #Display script completion in console
Write-Host "Script Executed successfully"

L’ouverture d’une nouvelle session utilisateurs d’AVD vous affiche bien la mention FSLogix :

Un tour dans le partage de fichier du compte de stockage montre bien la présence du dossier du profil utilisateur géré par FSLogix :

Conclusion

La gestion des tickets Kerberos par Azure AD est une belle avancée. Bien évidemment, le processus de prise en charge complète d’un compte de stockage de manière native n’est pas encore là, mais nous y sommes en bonne voie 😎 Comme à chaque fois, n’hésitez pas à utiliser les commentaires pour exprimer de vos retours 😋

AVD + Azure AD Join

Attendu depuis longtemps par la communauté Azure Virtual Desktop, Azure AD Join est enfin là ! Lancé il y a seulement quelques jours en public preview, la possibilité de se passer d’un Active Directory pour environnement AVD permet d’envisager certains projets avec une architecture 100% Cloud. Dans cet article, nous allons voir ensemble cette fonctionnalité et les bénéfices apportés par cette dernière.

Point important : cette amélioration pose un souci pour l’utilisation de la gestion des profiles via FSLogix, car l’utilisation d’un partage de fichier nécessite une authentification SMB, non possible pour l’instant via la gestion des identités Azure AD.

Introduction

Gestion des identités sur Azure Virtual Desktop : Rappel de l’existant

Jusqu’à présent, un environnement Azure Virtual Desktop (anciennement Windows Virtual Desktop) nécessitait de joindre les machines virtuelles Azure à un domaine Active Directory. Ce domaine pouvait provenir d’un Windows Server, ayant le rôle d’Active Directory sur un machine virtuelle Azure, ou via le service de domaine managé Azure AD DS.

Merci à Dean pour cette explication claire sur la gestion des identités sous AVD.

Qu’est-ce qu’un périphérique joint à Azure AD ?

La jonction Azure AD est destinée aux organisations axées en priorité ou uniquement sur le cloud. Toute organisation peut déployer des appareils joints Azure AD, quels que soient leur taille et leur secteur d’activité. La jonction Azure AD fonctionne même dans un environnement hybride et permet l’accès aux applications et ressources locales et cloud

Documentation Microsoft

Attention, il est possible de joindre des machines en Windows 10 à Azure AD, à l’exception de Windows 10 Famille.

Cette jointure à Azure AD est prévu à l’origine pour des entreprises ne disposant pas d’une infrastructure Windows Server Active Directory locale.

Dans le cas contraire, il est malgré tout possible de fonctionner de manière hybride. L’avantage sera de protéger les appareils Windows 10, tout en conservant l’accès aux ressources locales qui nécessitent une authentification locale. Dans ce cas précis, nous parlerons alors des machines jointes à Azure AD hybride. Ces appareils sont joints à votre annuaire Active Directory local et à votre Azure AD.

Appareils joints Azure AD

Pourquoi se passer d’un contrôleur de domaine pour AVD ?

Le premier argument est le coût ! Beaucoup de projets Azure Virtual Desktop sont petits et concernent un petit nombre d’utilisateurs en Remote Desktop. L’ajout d’un domaine sur des VMs ou via un domaine managé augmente la facture environ plus une centaine d’euros par mois .

Enfin, la gestion des machines AVD peut également se faire via Intune (Endpoint Manager). Que vous utilisiez des machines virtuelles partagées ou individuelles pour AVD, Intune peut gérer les deux 😋Un précédent article en parle et explique le processus d’intégration sur Intune pour les machines AVD partagées ici.

Vue générale des fonctionnalités d’Intune (MEM + MAM).

Déploiement d’un AVD utilisant Azure AD

On y est ! On va détailler ici, étapes par étapes, la création d’un environnement Azure Virtual Desktop en ne disposant d’aucun domaine Active Directory en place. Pour rappel, à l’heure où ces lignes sont écrites, la fonctionnalité de jointure avec Azure AD est toujours en public preview.

Etape I : Création du réseau virtuel

Habituellement, le réseau virtuel hébergeant AVD est déjà présent par le domaine existant. Dans un environnement vide, il faut donc commencer la création de celui-ci en premier :

Je prends soin de choisir la région adaptée à mon architecture AVD.

La configuration de la plage réseau et des sous-réseaux ne change pas d’un projet classique AVD. Dans mon exemple rapide, on ira au plus simple :

Une fois la création du réseau virtuel terminée, je peux passer à la création de mon environnement Azure Virtual Desktop.

Etape II : Déploiement d’Azure Virtual Desktop

Comme pour un déploiement classique d’Azure Virtual Desktop, notre travail commence par déployer un pool d’hôtes. Vous trouverez ce dernier dans la barre de recherche d’Azure :

Taper « virtual desktop » dans la barre de recherche pour voir le service AVD apparaître.

La procédure de départ reste identique au processus habituel pour AVD. Cependant, il est important de cocher la Validation environnement à OUI pour réussir la jointure avec Azure AD :

Dans mon exemple, j’ai choisi un host pool composé de VMs personnelles, il est possible de le faire avec des VMs partagées.

Note : l’assignement de type automatique dans le cadre de machines virtuelles individuelles va directement affecter ces dernières aux personnes se connectant à AVD dans la mesure où ces utilisateurs y sont autorisés.

Dans l’onglet des machines virtuelles, je défini les options relatives à ces dernières. Aucune particularité concernant la jointure avec Azure AD dans la première partie :

La copie d’écran ci-dessous concernant Azure AD et connaît une évolution sur deux points :

  • Type de domaine à joindre : il est maintenant possible de choisir Azure Active Directory
  • Intune : il est également possible d’automatiser l’enrôlement des machines virtuelles AVD dans Intune. Cela permet de configurer ces dernières, que ce soient des machines virtuelles dédiées ou partagées entre utilisateurs.
En sélectionnant Azure Active Directory, un certain nombre de champs disparaissent de la configuration de base.
Plus besoin ici de renseigner un login du domaine.

La création de l’espace de travail ne change pas par rapport aux environnements AVD classiques :

Une fois tous les champs correctement renseignés, il ne reste plus qu’à lancer la création des ressources :

Une fois la création terminée, nous pouvons constater les ressources suivantes dans notre groupe de ressources :

Etape III : Affectation des utilisateurs

Comme pour tout environnement Azure Virtual Desktop, il est nécessaire d’affecter des utilisateurs ou des groupes d’utilisateurs pour que ces derniers soient autorisés à se connecter aux machines virtuelles. Cela se passe par ici :

Etape IV : Ajout d’un argument RDP

Pour que la connexion RDP avec l’identité utilisateur Azure AD se fasse bien, il est nécessaire d’ajouter un argument spécifique. La gestion des propriétés RDP se font directement sur le pool d’hôtes d’AVD :

targetisaadjoined:i:1

Vous retrouverez ici la liste de toutes les options RDP possibles, dont seulement certaines sont compatibles avec Azure Virtual Desktop. Voici les arguments utilisés sur la copie d’écran ci-dessus :

drivestoredirect:s:;audiomode:i:0;videoplaybackmode:i:1;redirectclipboard:i:1;redirectprinters:i:1;devicestoredirect:s:;redirectcomports:i:1;redirectsmartcards:i:1;usbdevicestoredirect:s:*;enablecredsspsupport:i:1;use multimon:i:1;targetisaadjoined:i:1

Etape V : Ajout des rôles RBAC

Afin d’autoriser les utilisateurs à se connecter aux machines virtuelles, l’attribution des rôles RBAC est nécessaire. Pour rappel, ces rôles sont différents de ceux dans Azure AD, puisqu’ils sont affectés au ressources d’Azure. Dans notre AVD, l’affectation de deux rôles RBAC est nécessaires et se font assigner directement le groupe de ressources AVD :

  • Virtual Machine Administrator Login : Groupe d’utilisateurs ayant les droits d’administrateur local sur les machines virtuelles AVD
  • Virtual Machine User Login : Affecter le rôle Virtual Machine User Login au même groupe d’utilisateurs que celui utilisé pour le groupe d’application AVD

Etape VI : Test de la solution côté utilisateur via Remote Desktop

Une fois les étapes précédentes terminées, il ne reste plus qu’à tester le bon fonctionnent de la solution. Cela se fait en téléchargeant le client Remote Desktop PC dédié à Azure Virtual Desktop (téléchargeable ici), ou via l’accès web multi-plateformes (accessible )

Application Remote Desktop

Renseigner ici un compte Azure AD présent dans le groupe d’utilisateurs AVD.
L’écran de gestion du poste arrive dans la foulée, inutile de lier votre poste local à l’identité Azure AD.

L’écran ci-dessous nous emmène sur l’environnement Azure Virtual Desktop. Ici se trouvent tous les espaces de travail affectés à l’utilisateur, dans lesquels se trouvent toutes les applications (Remote Desktop ou Remote Apps) affectées à l’utilisateurs :

Ecran du Remote Desktop PC.

Une seconde demande d’authentification est affichée pour accéder à la machine virtuelle via le protocole RDP :

Le mot de passe peut être mémorisé pour éviter la ressaisie ultérieure.

Une fois le mot de passe saisi, l’ouverture d’une fenêtre RDP donne l’accès au bureau Windows 10 d’AVD. A noter que la jointure AVD apporte également le Seamless Sign on, rendant l’expérience utilisateur encore plus agréable :

Etape VII : Test de la solution côté utilisateur via HTML 5

Il est également possible de se connecter à Azure Virtual Desktop via un navigateur internet. Pour rappel, la page d’accès est la suivante : aka.ms/wvdarmweb :

Comme pour l’application Remote Desktop, l’authentification utilise le compte Azure AD.

On se retrouve alors, de la même manière que précédemment, sur une page donnant accès aux espaces de travail et aux applications :

Une seconde demande d’authentification est demandée pour accéder à la machine virtuelle.

Etape VIII : Vérifications Azure Virtual Desktop

Vérification de la jointure sur la machine virtuelle

Afin de regarder plus en détail cette jointure, la commande dsregcmd /status sur la machine virtuelle AVD nous en dit plus :

La jointure avec Azure AD est bien là mais aucune jointure à un domaine n’est faite.
Les informations relatives au tenant d’Azure AD.
Les informations relatives à l’activation de la fonctionnalité SSO.

Vérification de l’ajout des machines virtuelles dans Azure AD

Les machines virtuelles créées par Azure Virtual Desktop sont bien retranscrites dans la section Devices d’Azure AD. Cet ajout est réalisé lors de la jointure des machines virtuelles à Azure AD :

Vérification de l’ajout des machines virtuelles dans Intune

Comme j’ai coché la gestion des machines virtuelles AVD via la solution Intune, je retrouve bien mes machines virtuelles dans la console de cette dernière (lien ici)

Vérification du pool d’hôtes d’Azure Virtual Desktop

Comme cet exemple reposait sur un environnement AVD avec des machines virtuelles individuelles, je retrouve bien sur chacune un utilisateur assigné :

Etape IX : Gestion des erreurs liées à la jointure avec Azure AD

Il est possible de rencontrer des erreurs lors du déploiement de cet environnement AVD, en jointure avec Azure AD. Pour vous aider, Microsoft met à votre disposition cette page d’aide. Voici quelques exemples d’erreurs possibles :

Les machines virtuelles sont bien déployées, mais elles sont encore marquées comme indisponibles, plusieurs minutes après le déploiement d’AVD :

>> Avez-vous bien marqué à OUI la case de validation de l’environnement ?

Erreur de mot de passe de l’ouverture de la session RDP : « The logon attempt failed »

J’ai passé du temps sur cette erreur 😎.

>> Si vous rencontrez une erreur indiquant que la tentative de connexion a échoué à l’invite des informations d’identification de sécurité Windows, vérifiez les éléments suivants :

  • Vous êtes sur un appareil qui est joint à Azure AD ou à Azure AD hybride au même locataire Azure AD que l’hôte de session OU
  • Vous êtes sur un appareil exécutant Windows 10 2004 ou version ultérieure qui est Azure AD enregistré auprès du même locataire Azure AD que l’hôte de session
  • Le protocole PKU2U est activé à la fois sur le PC local et sur l’hôte de session

La dernière hypothèse est fortement probable dans ce cas. Il faut donc penser à vérifier cette option sur la machine locale ET sur la machine virtuelle AVD, grâce à la commande secpol.msc :

Cette option est également configurable via GPO. la commande rsop.msc vous permet de voir cela.

Conclusion

Comme à chaque fois, Dean de l’Azure Academy nous met à disposition une vidéo très explicative sur tout le processus de cette nouvelle fonctionnalité d’Azure Virtual Desktop :

On attend bien évidemment avec impatience la prise en charge de la solution FSLogix dans ce scénario de jointure avec Azure AD. Comme à chaque fois, pensez également à partager dans les commentaires vos propres expériences sur Azure Virtual Desktop 😋