Authentification WiFi Okta : étapes de configuration, options et correctifs
Published
Le conseil le plus répandu sur l'authentification Okta WiFi consiste à pointer vos points d'accès vers Okta, d'activer le MFA et d'abandonner le mot de passe partagé. Ne basez pas votre déploiement sur cette simple phrase. Okta n'est pas un authentificateur sans fil sur vos points d'accès, un supplicant 802.1X natif ne peut souvent pas afficher une demande d'authentification interactive de manière fluide, et l'élément qui déconnecte tout un site est généralement la confiance dans les certificats ou un mauvais profil d'équipement, et non l'invite MFA.
Cela ne signifie pas que le WiFi basé sur l'identité est une mauvaise direction. Le Rapport 2024 sur les tendances de connexion sécurisée d'Okta indique que 66 % des utilisateurs d'Okta Workforce Identity s'authentifiaient avec une authentification multifacteur en janvier 2024, tandis que l'adoption parmi les administrateurs atteignait 91 %. Ces chiffres décrivent des connexions aux applications, pas des sessions WiFi, mais ils montrent que la garantie d'identité remplace les seuls mots de passe dans l'annuaire même que vous utiliserez pour la politique réseau.
Je commencerai par une question plus difficile. Quel composant termine l'échange EAP, quel système émet et renouvelle la confiance sur l'appareil, et que se passe-t-il lorsque l'un d'eux change ? Répondez à ces trois questions en laboratoire et l'authentification Okta WiFi deviendra simple à gérer. Ignorez-les et vous devrez débugger un SSID de production un système d'exploitation à la fois.
Table des matières
- Choisir la voie d'intégration Okta prise en charge par votre réseau
- Confiance des certificats et intégration des appareils avant la connexion
- Comment configurer l'agent RADIUS Okta étape par étape
- Définir les règles d'accès conditionnel et de posture des appareils
- Dépannage des échecs de connexion WiFi Okta
- Valider le pilote avant de l'étendre à d'autres sites
Choisissez le chemin d'intégration Okta pris en charge par votre réseau
Okta ne gère pas le 802.1X sur vos points d'accès de manière autonome. Un contrôleur sans fil, un point d'accès ou un service RADIUS séparé doit agir en tant qu'authentificateur, transmettre chaque requête et appliquer le Access-Accept, Access-Reject, VLAN ou rôle renvoyé. Okta fournit la décision d'identité. Il ne supprime pas le travail de protocole lié au WLAN.
C'est pourquoi le premier choix ne concerne pas un paramètre Okta. Il s'agit de l'architecture que votre contrôleur et vos clients peuvent réellement prendre en charge. La documentation d'intégration Okta Cisco Meraki RADIUS décrit une configuration de sécurité 802.1X EAP où le client sans fil fournit un nom d'utilisateur et un mot de passe Okta lors de l'authentification réseau. Il s'agit d'un parcours Meraki spécifique et documenté, et non de la preuve que chaque contrôleur et méthode EAP fonctionneront de la même manière.
Quatre voies qui répondent à des problèmes différents
| Option | Vérifications des identifiants Okta | Usage idéal | Principale limite |
|---|---|---|---|
| Agent serveur RADIUS Okta | Nom d'utilisateur et mot de passe via PAP | Contrôleurs existants avec un parcours PAP validé en laboratoire | La documentation Okta n'indique pas l'infrastructure WiFi comme prise en charge |
| Identifiants Okta sur Cisco Meraki 802.1X | Nom d'utilisateur et mot de passe Okta dans l'échange EAP | WLAN Meraki qui suivent la configuration de sécurité EAP documentée par Okta | Lié à la configuration Meraki documentée par Okta |
| Connexion SAML ou SSO sur un Portail Captif | Connexion via le navigateur auprès du fournisseur d'identités | Intégration des invités et du BYOD | N'authentifie pas les appareils du personnel au niveau 802.1X |
| Certificats délivrés par MDM avec appartenance aux groupes d'annuaire | Certificat client EAP-TLS délivré par le MDM | Appareils gérés du personnel sur plusieurs sites | Nécessite une autorité de certification, le déploiement de profils MDM et un plan de renouvellement |
Lisez attentivement la ligne consacrée à l'agent RADIUS. Traitez-le comme une passerelle d'accès réseau héritée, et non comme un plan d'identité WiFi natif. Une conception classique WPA2 ou WPA3-Enterprise basée sur l'EAP-TLS à base de certificats ne peut pas être présumée fonctionner directement avec un agent dont le protocole documenté est PAP, avec EAP-TTLS et EAP-GTC listés uniquement pour des scénarios d'application RADIUS particuliers.
Le SSO sur Captive Portal répond à un besoin différent. Il offre aux invités et aux appareils BYOD non gérés un parcours navigateur avant l'accès à Internet, et permet d'enregistrer qui est connecté. Il ne fournit pas à l'ordinateur portable d'un employé un accès 802.1X chiffré dès le premier paquet, et les appareils sans écran ne peuvent pas le terminer. Ne laissez pas une démo attrayante de portail remplacer l'authentification réseau du personnel.
Utilisez trois critères pour décider
- Prise en charge du contrôleur et EAP : Confirmez ensemble le modèle exact du contrôleur, le firmware, le demandeur et la méthode EAP. Une spécification technique mentionnant le 802.1X ne garantit pas le bon fonctionnement de votre parcours PAP, EAP-TTLS ou EAP-TLS.
- Gestion des appareils : Les ordinateurs portables et téléphones gérés peuvent recevoir automatiquement des certificats et des profils de confiance. Les appareils non gérés nécessitent une intégration basée sur un mot de passe ou un accès via portail.
- Périmètre d'impact : Comptez le nombre de sites, d'SSID et de types de contrôleurs modifiés simultanément. Un plus grand nombre de sites plaide pour une distribution centralisée des profils et des certificats, plutôt qu'une configuration manuelle.
Règle de décision : N'utilisez l'agent RADIUS qu'après avoir validé en laboratoire la combinaison exacte de contrôleur et de client. Pour les appareils gérés du personnel, planifiez d'abord le chemin de certificat et considérez les mots de passe comme une solution de secours.
Confiance dans les certificats et intégration des appareils avant la connexion
La plupart des échecs Okta WiFi qui arrivent au centre d'assistance ne sont pas des échecs MFA. Ce sont des échecs de confiance. L'appareil ne fait pas confiance au certificat du serveur RADIUS, le profil 802.1X nomme la mauvaise méthode EAP ou le mauvais serveur, le certificat client n'est pas arrivé, ou l'utilisateur n'a pas enregistré le facteur requis par la politique. Okta peut évaluer l'identité correctement alors que l'appareil n'arrive jamais assez loin pour lancer la demande.
Le point d'enrôlement est documenté et non théorique. La documentation de l'application RADIUS Okta précise que EAP-TTLS prend en charge l'authentification par mot de passe et passcode, mais que EAP-TTLS ne prend pas en charge l'enrôlement. L'authentification peut donc échouer si les utilisateurs ne sont pas déjà enrôlés dans le facteur requis. Le dépannage Meraki par Okta identifie également un certificat invalide ou non approuvé ainsi que des profils 802.1X mal déployés comme causes d'échec de connexion. Enrôlez d'abord. Connectez ensuite.
Comparez objectivement les deux choix EAP
| Méthode | Identifiant envoyé | Enrôlement avant la première connexion | Usage idéal | Imprévu à anticiper |
|---|---|---|---|---|
| EAP-TTLS avec mot de passe ou code d'accès | Mot de passe ou code d'accès Okta dans un tunnel TLS | Requis, car EAP-TTLS ne prend pas en charge l'enrôlement | Appareils mixtes ou non gérés avec utilisateurs enrôlés | Les utilisateurs non encore enrôlés dans le facteur ne peuvent pas se connecter |
| EAP-TLS avec certificat émis par MDM | Certificat client émis via SCEP | Requis, le certificat étant poussé par le MDM | Appareils d'entreprise gérés à grande échelle | Un certificat serveur ou client expiré supprime l'accès sur l'ensemble d'un site |
EAP-TTLS conserve les mots de passe dans la conception. Ils restent exposés au hameçonnage, au réemploi, aux réinitialisations par le support technique et à une gestion complexe des demandes sur un supplicant WiFi. EAP-TLS élimine le mot de passe de l'échange sans fil et offre une authentification mutuelle, mais il déplace la charge de travail vers votre autorité de certification et votre chaîne d'émission SCEP, de renouvellement et de révocation. Aucune option n'est gratuite. Vous choisissez simplement où se situe la charge opérationnelle.
Construire le cycle de vie que la plupart des guides omettent
- Choisir l'autorité de certification : Déterminez quelle CA signe le certificat du serveur RADIUS et quelle CA délivre les certificats clients. Ne les confondez pas dans le profil et ne vous laissez pas surprendre par l'expiration d'un certificat de serveur public.
- Planifier le renouvellement à l'avance : Renouvelez le certificat du serveur bien avant son expiration, déployez la nouvelle ancrage de confiance pendant que l'ancienne fonctionne toujours, et confirmez que les appareils valident le nom de serveur attendu.
- Déployer les profils via le MDM : Utilisez Intune, Jamf ou votre MDM existant pour distribuer le SSID, le type d'EAP, la CA approuvée, le nom du serveur et le certificat SCEP. L'installation manuelle n'est pas évolutive et ne peut pas être auditée.
- Ordonner l'intégration avant l'application : Offrez aux appareils un parcours d'intégration temporaire, confirmez la réception du profil et du certificat, puis appliquez le SSID du personnel. Un appareil sans chaîne de confiance ne peut pas utiliser le réseau du personnel pour récupérer sa confiance.
- Planifier la révocation et la récupération : Définissez ce qui se produit lorsqu'un appareil est perdu, qu'un certificat est révoqué, qu'une CA change ou qu'un profil MDM est supprimé. Testez la réémission sur un appareil de test.
Exécutez une matrice de test avant toute modification de site. Testez Windows, macOS, iOS et Android, chacun sous forme gérée et non gérée, lors de la première connexion, de la reconnexion, de l'itinérance entre les points d'accès et après un renouvellement de certificat simulé. Incluez un utilisateur non inscrit et un appareil dont le profil a été supprimé.
Admettons qu'un déploiement de profil échoue sans aucun avertissement dans une filiale le vendredi. Le lundi, tous les appareils gérés à cet emplacement rejettent le certificat du serveur, tandis que le siège social, qui a reçu le profil, fonctionne parfaitement. La politique Okta n'a pas changé. C'est la distribution de la confiance qui a changé. Ce scénario explique pourquoi le suivi des profils doit figurer dans vos critères de mise en production, et non dans une revue d'après incident.
Comment configurer l'agent RADIUS Okta étape par étape
Commencez par le chemin de la requête, car il vous indique où chercher lorsqu'une connexion échoue. Le contrôleur envoie une requête RADIUS à l'Okta RADIUS Server Agent, l'agent appelle les API Okta, Okta évalue la politique, un défi MFA optionnel revient via l'équipement réseau, et l'agent renvoie un Access-Accept ou Access-Reject au contrôleur. Chaque étape peut échouer sans que les autres ne soient défaillantes.
La séquence de déploiement ci-dessous suit le modèle du guide du serveur d'accès réseau d'Okta, qui positionne l'agent entre le serveur d'accès réseau et l'évaluation de la politique Okta sur le port UDP 1812. Construisez-le dans cet ordre, dans un laboratoire, avec la journalisation des paquets et de l'agent disponible dès le premier test.
Construire le parcours de laboratoire dans l'ordre
- Installez l'agent en tant que service. Installez l'Okta RADIUS Server Agent sur un hôte Windows ou Linux capable d'atteindre à la fois le contrôleur sans fil et Okta. Ne l'installez pas sur un poste de travail qui se met en veille, applique des patchs de manière imprévisible ou se trouve derrière une règle de pare-feu non documentée. L'erreur courante consiste à prouver que l'agent peut atteindre Okta depuis la console du serveur, sans jamais prouver la connectivité entre le contrôleur et l'agent.
- Créez l'application RADIUS dans Okta. Créez l'application, notez les paramètres dont l'agent a besoin et conservez un nom lié à l'SSID et au périmètre du site qu'il dessert. Les noms d'applications vagues ralentissent les recherches ultérieures dans les journaux. Ne réutilisez pas une application RADIUS VPN pour le WiFi sous prétexte que les deux utilisent le protocole RADIUS.
- Configurez le contrôleur en tant que client RADIUS. Orientez le contrôleur sans fil ou le serveur d'accès réseau vers l'adresse IP de l'agent, définissez le port UDP 1812 et saisissez un secret partagé identique aux deux extrémités. Saisissez le secret manuellement au lieu de le copier-coller depuis une messagerie qui pourrait ajouter un espace à la fin. Un secret non correspondant ressemble souvent à un mauvais mot de passe sur le client.
- Restreignez la source. Limitez l'IP source du client ou la zone réseau Okta aux seules adresses des contrôleurs. Cela empêche les hôtes internes non autorisés d'envoyer des demandes d'authentification à l'agent. L'erreur classique est d'autoriser le sous-réseau de gestion pendant les tests et de ne jamais restreindre l'accès par la suite.
- Attribuez les bons groupes Okta. Attribuez l'application RADIUS uniquement aux groupes devant accéder à cet SSID. L'attribution de groupes constitue votre limite globale entre le personnel, les prestataires et les administrateurs. N'attribuez pas l'application à toute l'entreprise en promettant de régler la segmentation plus tard avec des règles de pare-feu non rédigées.
- Testez la validation et le rejet. Connectez un client de test dans votre laboratoire avec un compte appartenant au groupe attribué, puis testez ce même compte après l'avoir retiré du groupe. Vous devez obtenir les deux résultats dans le journal du contrôleur et dans le journal Okta. Tester uniquement la réussite ne prouve rien concernant la révocation des accès.
- Vérifiez le comportement des demandes MFA. Si votre politique exige une MFA, confirmez que le demandeur client spécifique et le contrôleur peuvent afficher et traiter la demande dans le respect de leurs délais d'expiration. Beaucoup n'y parviennent pas correctement. Si l'invite ne s'affiche jamais, ne résolvez pas le problème en affaiblissant la politique en production avant de comprendre la limite du protocole.
Avant de régler quoi que ce soit d'autre, observez une authentification complète en laboratoire et comparez chaque étape avec vos journaux.
Pour la variante Meraki, le client fournit un nom d'utilisateur et un mot de passe Okta selon la configuration 802.1X EAP documentée par Okta. Vérifiez la confiance du certificat et le profil déployé sur le client de test avant de continuer à modifier les paramètres SSID. Un certificat invalide ou un mauvais profil mettra en échec une configuration de contrôleur correcte, déployez donc le profil via le MDM plutôt que de l'installer manuellement.
Si votre conception nécessite des méthodes EAP ou une échelle qu'un agent sur site gère difficilement, comparez cette contrainte avec une couche RADIUS-as-a-Service gérée avant de multiplier les serveurs d'agents sur tous les sites. Quel que soit votre choix, conservez un accès administrateur d'urgence séparé qui ne dépend pas de l'agent, des API Okta ou du service MFA. Vous en aurez besoin dès le premier incident de certificat ou de WAN, pas après.
Ne validez pas une configuration simplement parce qu'un ordinateur portable s'est connecté une fois. Validez-la lorsque l'acceptation, le rejet, la suppression de groupe, le dépassement de délai et le redémarrage de l'agent se comportent tous exactement comme vous l'avez documenté.
Définir des règles d'accès conditionnel et de posture des appareils
Placez chaque contrôle dans la couche capable de l'appliquer. Okta détermine qui est l'utilisateur, à quels groupes il appartient et quelle politique de facteurs s'applique. Le MDM détermine si l'équipement est enrôlé et conforme, puis fournit son certificat et son profil WiFi. L'agent RADIUS ou le contrôleur transforme ces données d'entrée en Access-Accept ou Access-Reject et applique le VLAN ou le rôle retourné.
L'attribution de groupes à l'application RADIUS détermine qui peut rejoindre le SSID. La politique de facteurs sur cette application détermine si le MFA est requis, mais le contrôleur et le supplicant doivent toujours transmettre la demande. La posture de l'équipement ne provient pas d'un mot de passe. Elle découle de l'enrôlement MDM et de la présence d'un certificat valide, afin qu'un appareil personnel non géré ne se retrouve pas sur le réseau du personnel simplement parce que son propriétaire possède des identifiants valides.
L'appartenance à un groupe d'annuaire peut également déterminer l'attribution après l'acceptation. Associez chaque groupe à un VLAN ou à un rôle, renvoyez cet attribut lors de l'Access-Accept, et conservez une association suffisamment restreinte pour être auditée. La restriction de source doit se faire dans la zone réseau Okta et sur l'agent. Seules les adresses du contrôleur doivent être des sources RADIUS valides. Les décisions d'accès réseau plus larges doivent rester cohérentes avec vos network access control solutions globales, et non devenir un ensemble d'exceptions spécifiques à un SSID.
Effectuer trois vérifications avant le déploiement
- Test de révocation : supprimez un compte de test réel de son groupe attribué et confirmez que la connexion suivante est rejetée. Désactivez ensuite le compte et répétez l'opération.
- Test de posture : essayez un appareil inscrit et conforme, un appareil inscrit non conforme et un appareil non inscrit. Confirmez que seul le premier accède au VLAN du personnel.
- Document d'audit : enregistrez chaque association de groupe à un VLAN, le propriétaire de chaque groupe, ainsi que le jeu de règles invités distinct dans un document unique consultable par votre centre d'assistance.
Les équipes qui renforcent ces limites entre l'identité, les points d'accès et les équipements réseau trouveront également la protection informatique de Wisely utile à titre de contexte général. Pour ce déploiement, gardez des tests ciblés. Si un contrôle ne peut pas être mesuré en modifiant une acceptation, un rejet ou un VLAN dans le laboratoire, c'est qu'il n'est pas encore configuré.
Dépannage des échecs de connexion WiFi Okta
Commencez par le symptôme le plus fréquemment signalé par les utilisateurs. Un client qui n'affiche jamais d'invite d'identifiants n'attend généralement pas Okta. Il lui manque son profil 802.1X, il propose la mauvaise méthode EAP ou il rejette le certificat du serveur avant même l'envoi des identifiants. Vérifiez le profil de l'appareil et les paramètres EAP du contrôleur avant de réinitialiser le mot de passe de quiconque.
Travailler une couche à la fois. Confirmez que le service d'agent est en cours d'exécution, lisez la raison du rejet par le contrôleur, puis modifiez un seul paramètre et retestez avec le même appareil et le même compte. Si vous modifiez simultanément le secret, le profil, le groupe et le certificat, vous résoudrez la connexion sans savoir quelle panne réapparaîtra sur le site suivant.
Associer le symptôme à la première solution
| Symptôme | Cause probable | Première solution |
|---|---|---|
| Le client n'affiche jamais de demande d'identifiants | Profil 802.1X manquant ou type EAP non correspondant | Redéployer le profil et faire correspondre la méthode EAP au contrôleur |
| L'authentification expire (timeout) | Port UDP 1812 bloqué ou service d'agent interrompu | Vérifier la trajectoire du pare-feu et le statut du service d'agent depuis le réseau du contrôleur |
| Access-Reject avec le mot de passe correct | Secret partagé incorrect ou utilisateur hors du groupe attribué | Saisir à nouveau le secret des deux côtés et confirmer l'attribution du groupe |
| Rejets provenant d'un seul contrôleur | L'IP source ou la zone réseau exclut ce contrôleur | Comparer l'adresse du contrôleur avec la zone autorisée |
| La demande MFA n'apparaît jamais | Le client ou le contrôleur ne peut pas afficher le challenge | Tester un autre client et confirmer le chemin de challenge en laboratoire |
| Fonctionne sur Windows, échoue sur iOS | Confiance de certificat ou profil non correspondant | Vérifier la chaîne de certificat du serveur et les paramètres de confiance du profil sur le système d'exploitation défaillant |
| Un site opérationnel tombe en panne après une date précise | Le certificat du serveur a expiré | Renouveler le certificat et déployer le profil de confiance mis à jour |
Séparez les corrections rapides des corrections à l'échelle du parc. Ressaisir un secret partagé, corriger un groupe, ajouter une adresse source de contrôleur ou redémarrer l'agent peut résoudre rapidement un problème de laboratoire. Renouveler un certificat de serveur, reconstruire un profil de confiance et attendre que des milliers d'appareils se synchronisent avec le MDM peut prendre plusieurs jours. Ne promettez pas une restauration du site le jour même pour un problème de chaîne de confiance.
Admettons que les ordinateurs portables Windows se reconnectent après un changement de certificat, mais que les iPhones échouent dans tout un bâtiment. Ce schéma n'incrimine pas la politique Okta, car les mêmes comptes fonctionnent ailleurs. Comparez l'AC de confiance du profil iOS, le nom de serveur attendu et la chaîne de certificats avec un appareil Windows qui fonctionne. Un OS a peut-être mis en cache ou reçu la nouvelle confiance tandis que l'autre ne l'a pas faite.
Escalader avec des preuves. Si un cycle de test ne modifie pas le motif du rejet, cessez de modifier les paramètres de production, ramenez l'appareil défaillant sur le SSID de laboratoire et comparez son association, son échange EAP, son résultat RADIUS et son VLAN attribué avec un appareil qui fonctionne. Conservez les horodatages. Les conjectures à travers quatre systèmes différents font gaspiller la fenêtre de changement.
Valider le pilote avant de l'étendre à d'autres sites
Une connexion Okta réussie ne garantit pas une session WiFi fonctionnelle. Le pilote doit mesurer la transaction complète, de l'association jusqu'à l'accès réseau exploitable, car les utilisateurs ne se soucient pas de savoir quel saut a renvoyé l'erreur. Le flux des meilleures pratiques Okta RADIUS décrit un flux de contrôle comprenant jusqu'à onze étapes logiques, incluant le transfert des identifiants, la validation API, la présentation du défi MFA, la réponse au défi, la seconde validation et la décision RADIUS finale. Instrumentez la chaîne en conséquence.
Utilisez quatre points de contrôle pour chaque appareil pilote. Premièrement, l'association et la négociation 802.1X/EAP au niveau du point d'accès. Deuxièmement, la réception de la demande RADIUS au niveau de l'agent. Troisièmement, la politique Okta et la réponse du facteur d'authentification. Quatrièmement, le message final Access-Accept ou Access-Reject au niveau du contrôleur, suivi de l'attribution du bon VLAN. Séparez la réussite dès la première tentative, la latence d'authentification médiane et au 95e centile, le taux de dépassement de délai, les demandes répétées et les causes de rejet par OS d'appareil, site, SSID, modèle de contrôleur et type de facteur.
Okta ne publie aucun indicateur de référence universel pour le succès de l'authentification WiFi, vous devez donc définir une règle d'acceptation locale et la maintenir. Par exemple, exigez au moins 99 % de réussite à la première tentative lors du pilote contrôlé, zéro rejet non expliqué, et aucun dépassement de délai d'authentification au-delà de votre budget d'itinérance. Considérez ces exigences comme vos propres seuils pilotes, puis validez-les sous une charge maximale et lors d'un test de panne WAN. Une connexion qui fonctionne pour cinq utilisateurs en laboratoire à midi peut échouer lorsqu'une équipe prend son service et que des centaines d'appareils se reconnectent simultanément.
Vos preuves doivent pouvoir être interrogées sur l'ensemble du parc. Purple Access fournit un journal d'authentification qui affiche chaque acceptation et rejet, avec l'identité, l'appareil, l'état d'enrôlement MDM, la méthode, le point d'accès, l'SSID, le site, le VLAN, le rôle, le motif et les horodatages, dans une seule requête à l'échelle du parc. Ce niveau de détail importe également pour les preuves de segmentation, d'autant plus que la norme PCI-DSS v4.0.1 Req 2.3.2 exige que les clés sans fil soient modifiées dès que toute personne la connaissant quitte l'entreprise, ce qui rend une clé partagée impraticable. Conservez la conception sous-jacente du réseau WiFi à l'esprit, car l'authentification ne peut pas pallier des limites de VLAN faibles.
Ne déployez à plus grande échelle qu'après une décision explicite de validation. Tous les OS et types de facteurs dans le périmètre doivent respecter les trois conditions d'acceptation, les rejets doivent avoir des causes identifiées, et le chemin d'accès administrateur d'urgence doit avoir été testé avec l'agent arrêté. Si une condition échoue, restez en phase pilote et corrigez cette couche. L'ajout de sites ne fait que multiplier un défaut non résolu.
Si votre conception d'authentification Okta WiFi a dépassé les mots de passe partagés, les serveurs d'agents fragiles ou la gestion manuelle des certificats, Purple Access peut placer les visiteurs, le personnel et les équipements sur des réseaux distincts basés sur l'identité, en utilisant les points d'accès que vous possédez déjà. Apportez vos modèles de contrôleurs, votre MDM et votre plan d'attribution des groupes aux VLAN, et nous vous aiderons à valider un déploiement d'abord en laboratoire avant qu'il n'atteigne un site de production.
