Poursuivant sur notre thème Windows Autopilot, la série est écrite par Michael Niehaus, employé Microsoft basé à Seattle. Vous pouvez trouver cela et plus encore sur son propre blog – Out of Office Hours.

L’un des plus grands défis que nous rencontrons avec les clients qui souhaitent adopter Windows Autopilot pour déployer de nouveaux appareils est la variété des configurations réseau. 

Cela peut être décomposé en quelques catégories de haut niveau:

• Défis pour les appareils qui doivent établir une connexion initiale au réseau d’entreprise, en raison des mécanismes de sécurité du réseau tels que 802.1x, qui utilisent souvent des certificats d’ordinateur ou d’utilisateur pour accorder l’accès. Parfois, ces mécanismes s’appliquent uniquement aux réseaux Wi-Fi (ce qui signifie que les connexions câblées conviennent), mais ils peuvent également s’appliquer aux connexions réseau câblées.
• Défis pour les appareils qui ont besoin d’une connectivité à Internet, ce qui peut nécessiter un accès via un serveur proxy ou un pare-feu. Cela peut être particulièrement problématique dans les cas où l’authentification de l’utilisateur est nécessaire (que ce soit à l’aide des informations d’identification AD / AAD, des certificats ou d’autres mécanismes), mais il existe également des problèmes de découverte (c.-à-d. Comment le client découvre-t-il qu’il doit utiliser un serveur proxy).
• Défis pour les appareils qui ont besoin d’une connectivité à partir d’Internet, ce qui peut nécessiter un accès via VPN, généralement nécessaire pour les scénarios basés sur Active Directory (par exemple, Hybrid Azure AD Join).

Généralement, tous ces problèmes peuvent être considérés comme des problèmes de «démarrage». Dans le passé, lorsque les clients utilisaient des mécanismes de déploiement traditionnels basés sur des images, ils construisaient des mécanismes pour contourner ces problèmes, résolvant souvent les problèmes avant que l’appareil ne soit livré à l’utilisateur final. Lors du passage à Windows Autopilot, ces mécanismes peuvent ne plus fonctionner (selon les spécificités).

Nos conseils généraux pour la mise en réseau de Windows Autopilot se concentrent sur les connexions sortantes, c’est-à-dire à quels services Internet l’appareil doit-il parler pour terminer le processus d’approvisionnement de Windows Autopilot. Mais cela ne parle pas vraiment des éléments que j’ai mentionnés ci-dessus.

Il existe des solutions générales qui peuvent être appliquées aux défis ci-dessus. Il est utile d’en parler avant d’entrer dans les scénarios qui en profitent le plus. Voici une liste:

• WPAD. Il s’agit d’un mécanisme qui permet à un appareil de découvrir quel script de serveur proxy (PAC) doit être utilisé pour communiquer avec Internet. (Notez que de nombreuses équipes réseau n’aiment pas WPAD car il est considéré comme un risque pour la sécurité – les appareils dans les espaces publics peuvent être dirigés vers un serveur proxy qui surveille le trafic réseau à l’insu de l’utilisateur. En outre, les serveurs proxy qui effectuent l’inspection SSL sont mauvais et vont probablement casser Windows Autopilot et d’autres services qui valident les certificats de serveur SSL.)
• Liste blanche. Il s’agit d’un mécanisme utilisé dans plusieurs situations:
  • Avec un pare-feu, pour autoriser l’accès via le pare-feu à une liste d’adresses Internet (noms IP ou DNS).
  • Avec un pare-feu, pour permettre à certaines machines de se connecter à une liste d’adresses Internet via un processus de pré-autorisation (par exemple, enregistrer leurs adresses MAC à l’avance).
  • Avec un proxy, pour permettre l’accès via le serveur proxy à une liste d’adresses Internet (noms IP ou DNS), sans aucune authentification d’utilisateur ou de périphérique.
    
    
• Réseau d’invités. Les appareils peuvent se connecter à un réseau limité (par exemple, autoriser uniquement l’accès à Internet, peut-être avec un portail captif pour authentifier les utilisateurs).
• Inscription au certificat. Pour accéder au réseau d’entreprise (c’est-à-dire en utilisant 802.1x), l’appareil ou l’utilisateur peut avoir besoin d’un certificat. Le déploiement à partir d’un autre réseau (invité ou directement sur Internet) peut permettre l’inscription de ces certificats afin que l’appareil puisse accéder ultérieurement au réseau d’entreprise. Intune utilise SCEP pour parler à un service d’inscription de certificat (par exemple, un serveur NDES des services de certificats Active Directory) pour émettre les certificats nécessaires.
• VPN. Si l’appareil ne peut pas accéder directement au réseau d’entreprise, mais peut accéder à Internet ou à un réseau invité distinct, il peut alors établir une connexion VPN. (Si la connexion VPN a besoin d’un certificat, l’inscription au certificat peut toujours s’appliquer.)
• Contournement temporaire. L’utilisateur peut se voir attribuer un mécanisme pour se connecter au réseau de l’entreprise sans certificats pendant une période de temps (heures). Cela peut être le réseau Wi-Fi normal ou un réseau restreint distinct. Cela nécessiterait généralement un appel au service d’assistance.
• Pré-approvisionnement. Les techniciens peuvent configurer des appareils sur un réseau distinct (OEM, partenaire ou réseau client) pour obtenir la configuration de l’appareil avant que l’appareil ne soit remis à l’utilisateur.
• Image personnalisée. L’OEM peut charger une image personnalisée qui a la configuration de périphérique requise préchargée dans l’image. (Pour garder le client hors du secteur de l’imagerie, l’un des principaux objectifs de Windows Autopilot, il serait préférable de simplement fournir les «ajustements» à l’OEM et de les laisser faire ces ajustements dans l’image.)

Maintenant, parlons des différents scénarios de Windows Autopilot.

User-driven Azure AD Join

La meilleure chose à propos de Azure AD Join est qu’elle nécessite simplement un accès Internet. Voyons comment les solutions ci-dessus peuvent s’appliquer:

• WPAD. Cela peut être efficace pour permettre aux appareils de découvrir le serveur proxy qu’ils utilisent. Si WPAD n’est pas pris en charge et qu’un proxy doit être utilisé, il n’existe actuellement aucun moyen simple de spécifier les paramètres du proxy. (Vous pouvez trouver des solutions de contournement dans d’autres blogs qui poussent directement l’URL du serveur proxy dans le système à l’aide d’une invite de commande Shift-F10, mais ce n’est pas du tout convivial.)
• Liste blanche. Cela est très efficace pour permettre aux appareils d’accéder aux URL Internet nécessaires (par exemple, pour Windows Autopilot, Azure AD, Intune, etc.).
• Réseau d’invités. C’est aussi très efficace – généralement, les réseaux invités n’utilisent pas de serveurs proxy, ils évitent donc les problèmes liés à cela (configuration, liste blanche). Intune peut ensuite déployer la configuration requise (par exemple, certificats, paramètres de proxy, connexions WI-fi) afin que l’appareil puisse plus tard utiliser le réseau d’entreprise.
• Inscription au certificat. Une fois que l’appareil dispose d’une connexion Internet, il peut obtenir des certificats pour pouvoir accéder ultérieurement à des réseaux sécurisés (par exemple 802.1x).
• VPN. Cela ne devrait jamais être nécessaire avec Azure AD Join.
• Contournement temporaire. Cela pourrait être utilisé si le réseau d’entreprise est autrement trop restrictif ou nécessite un proxy qui ne peut pas être préconfiguré.
• Pré-approvisionnement. Cela sera discuté plus tard, car c’est vraiment un scénario de gants blancs piloté par un technicien.
• Imagerie personnalisée. Cela peut certainement résoudre les problèmes liés à la configuration du serveur proxy (peut être préconfiguré dans l’image) et liés à la certification de la machine (pour l’authentification de la machine 802.1x). Il ne peut rien faire avec les certificats d’utilisateur (qui peuvent également être utilisés avec 802.1x) car l’utilisateur doit d’abord se connecter (problème de poulet et d’œuf).

Alors qu’est-ce que je recommande? C’est une sorte d’organigramme:

• Si votre réseau d’entreprise se comporte comme une connexion Internet ouverte (peut résoudre les noms DNS et accéder à tous les hôtes HTTP et HTTPS, sans authentification, certificats ou mandataires), vous êtes prêt.
• Si vous avez un proxy, pouvez-vous le contourner en ajoutant des URL à la liste blanche qui peuvent passer directement par le pare-feu, en contournant le proxy? Si oui, vous êtes prêt.
• Si vous utilisez 802.1x avec Wi-Fi mais pas de réseaux câblés, pouvez-vous provisionner des appareils en utilisant Ethernet?
• Si vous utilisez 802.1x avec des réseaux Wi-Fi et câblés et que vous pouvez vous authentifier à l’aide de certificats machine, pouvez-vous demander à l’OEM d’intégrer un certificat dans l’image de l’appareil?
• Si vous utilisez 802.1x avec des réseaux Wi-Fi et câblés et que vous pouvez vous authentifier en utilisant uniquement des certificats utilisateur, vous devrez utiliser un réseau invité (idéalement un réseau avec un accès Internet ouvert et non authentifié, bien qu’un portail captif fonctionne correctement).
• Si tout le reste échoue, les utilisateurs peuvent provisionner des appareils sur un réseau différent (maison, coffeeshop, etc.).

User-driven Hybrid Azure AD Join

La jointure Azure AD hybride a les mêmes exigences que la jointure Azure AD, mais avec une autre: elle a besoin d’une connectivité à un contrôleur de domaine Active Directory, donc l’appareil doit être sur le réseau d’entreprise. Encore une fois, en examinant la liste de solutions ci-dessus:

• WPAD. Ceci est efficace pour aider les appareils à découvrir le serveur proxy dont ils ont besoin pour accéder à Internet.
• Liste blanche. Cela est également efficace pour aider les appareils à accéder aux URL Internet nécessaires.
• Réseau d’invités. Cela n’est généralement pas efficace, car vous devez toujours «percer des trous» dans votre réseau d’entreprise normal pour accéder à un contrôleur de domaine Active Directory. La plupart des responsables de la sécurité désapprouveraient cela.
• Inscription au certificat. Si l’appareil ne peut pas s’inscrire à Intune et rejoindre AD, il ne pourra inscrire aucun certificat.
• VPN. Ceci n’est actuellement pas pris en charge avec Windows Autopilot Hybrid Azure AD Join. C’est quelque chose que nous envisageons pour une future version.
• Contournement temporaire. Cela pourrait être utilisé pour permettre l’accès à la fois au réseau d’entreprise et à Internet.
• Pré-approvisionnement. Comme avec Azure AD Join, cela sera discuté plus tard dans le cadre de la discussion sur les gants blancs.
• Image personnalisée. Cela peut aider avec les certificats d’ordinateur et la configuration du proxy, mais pas avec les certificats d’utilisateur (comme Azure AD Join).

Encore une fois, des recommandations:

• Les appareils doivent être connectés au réseau d’entreprise et avoir accès à Internet.
• Si vous utilisez un serveur proxy, il doit être détectable ou préconfiguré, ou contourné.
• Si vous utilisez 802.1x avec des réseaux Wi-Fi mais pas câblés, approvisionnez les appareils via Ethernet.
• Si vous utilisez 802.1x avec des réseaux Wi-Fi et câblés et que vous pouvez vous authentifier à l’aide de certificats de machine, le fabricant OEM peut intégrer un certificat dans l’image.
• Si vous utilisez 802.1x avec des réseaux Wi-Fi et câblés et que vous pouvez vous authentifier en utilisant uniquement des certificats d’utilisateur, vous avez un problème – consultez la solution de gants blancs ci-dessous pour une solution potentielle.

User-driven Azure AD Join avec pré-provisionnement gants blancs

Le pré-approvisionnement de gants blancs Windows Autopilot divise le processus d’approvisionnement des appareils en deux parties, une phase technicien et une phase utilisateur. La bonne chose à propos de la phase de technicien est qu’elle peut être effectuée sur n’importe quel réseau (le vôtre, un partenaire, un OEM ou un distributeur, etc.) et peut donc fournir tous les paramètres de proxy ou certificats de machine nécessaires, avant même que l’utilisateur n’obtienne l’appareil.

La seule chose qu’il ne peut pas faire: pré-approvisionner les certificats d’utilisateur. Pour ce faire, l’utilisateur doit réellement se connecter (créer le profil utilisateur). Donc, si vous utilisez 802.1x avec des certificats utilisateur, cela n’aidera pas à obtenir la machine sur le réseau d’entreprise. Les mêmes suggestions dans la section user-driven Azure AD Join ci-dessus s’appliquent toujours à la partie utilisateur du processus.

User-driven hybrid Azure AD Join avec pré-provisionnement gants blancs

Les conditions requises pour effectuer une jointure Azure AD hybride à l’aide du pré-approvisionnement de gants blancs sont en réalité différentes d’un déploiement normal user-driven Azure AD Join Windows Autopilot. Plus précisément, il n’est pas nécessaire que la phase technicien du processus soit effectuée sur le réseau d’entreprise – elle peut être effectuée sur n’importe quel réseau car elle n’a pas besoin de parler directement à un contrôleur de domaine Active Directory. Donc, cela peut aussi être fait sur n’importe quel réseau (le vôtre, un partenaire, un OEM ou un distributeur, etc.) Cela joindrait l’appareil à Active Directory via le processus de jonction de domaine hors ligne (en utilisant le connecteur Intune pour Active Directory, alias le connecteur ODJ ) et approvisionnez tous les paramètres de proxy ou certificats de machine nécessaires avant même que l’utilisateur n’obtienne l’appareil.

Comme avec le pré-approvisionnement de gant blanc pour Azure AD Join, cela a également la même limitation en ce qui concerne les certificats d’utilisateur – toujours aucun moyen d’obtenir ceux sur l’appareil sans que l’utilisateur se connecte, ce qui doit être fait sur le réseau d’entreprise car il doit être validé par un contrôleur de domaine Active Directory. Consultez donc les exigences et suggestions Hybrid Azure AD Join ci-dessus pour cette partie du processus (en gardant à l’esprit la configuration qui peut être effectuée par le processus du technicien).

Self-deploying Azure AD Join

Le mode de déploiement automatique de Windows Autopilot prend uniquement en charge Azure AD Join. Il a donc également les mêmes exigences que la section user-driven Azure AD Join ci-dessus. Il existe cependant des exigences de mise en réseau supplémentaires, car certains appareils ne sont pas livrés avec le certificat EK requis sur le TPM et doivent pouvoir obtenir ce certificat sur Internet «juste à temps» pour qu’il puisse être utilisé par le processus d’attestation du TPM. Les URL exactes nécessaires pour cela peuvent varier selon le fabricant du TPM.

Résumé

Microsoft recherche des moyens d’améliorer Windows Autopilot pour prendre en compte la complexité des réseaux d’entreprise existants. Microsoft envisage notamment:

• Prise en charge du processus hybride Azure AD Join complet sur VPN (comme mentionné précédemment, un travail en cours pour une future version de Windows 10).
• Prise en charge de la configuration des paramètres de proxy, soit manuellement (par exemple, saisissez-les pendant OOBE) soit via le profil Windows Autopilot.
• Prise en charge de l’obtention d’une liste complète des adresses MAC de tous vos appareils enregistrés dans Windows Autopilot, afin que vous puissiez utiliser ces informations pour mettre les appareils en liste blanche (par exemple, les utiliser au lieu de 802.1x).
• Prise en charge du pré-approvisionnement des certificats utilisateur et des profils utilisateur. (Ceci est particulièrement difficile, donc cela peut s’avérer impossible.)

Si l’un de ces éléments vous intéresse, veuillez soumettre des suggestions via https://microsoftintune.uservoice.com

Vous pouvez également envisager de modifier votre réseau également. Les réseaux de confiance zero trust gagnent en popularité, déplaçant la frontière de sécurité vers un autre endroit (au lieu d’essayer de protéger chaque partie du réseau). Ou vous pouvez envisager d’utiliser un proxy transparent sur votre réseau (pas besoin de configurer des machines individuelles pour cela).