Migration multi-site vers RADIUS : ordonnancement des sites, des points d'accès et de la politique

Vous pouvez faire migrer un parc multi-site vers un serveur RADIUS cloud en quatre phases, sans bascule brutale, lorsque les anciens et les nouveaux serveurs fonctionnent côte à côte. Chaque SSID répertorie les deux, et chaque appareil fait confiance au nouveau certificat du serveur. Chaque site bascule sous 802.1X avec un test de sortie écrit. Sur Purple, la bascule elle-même est généralement une opération réalisée le week-end.

Qu'est-ce qui change lors d'une migration RADIUS multi-site, et qu'est-ce qui ne change pas ?

L'état final est une politique RADIUS cloud unique desservant chaque site, l'identité définissant le VLAN. Le protocole RADIUS, défini dans la norme RFC 2865, est utilisé par vos points d'accès pour demander à un serveur si un appareil peut se connecter. Le serveur accepte ou rejette l'appareil. Il peut également renvoyer des attributs tels que le VLAN, le segment de réseau sur lequel l'appareil arrive.

Sur un réseau sécurisé, cet échange s'exécute au sein de la norme 802.1X, le standard pour le contrôle d'accès réseau basé sur les ports. 802.1X transporte EAP (Extensible Authentication Protocol) entre l'appareil, le point d'accès et le serveur. EAP-TLS, défini dans la norme RFC 5216, authentifie les deux parties avec des certificats. PEAP encapsule un échange de mot de passe dans un tunnel TLS.

Quatre éléments changent :

• Chaque point d'accès ou contrôleur pointe vers une nouvelle adresse de serveur et un nouveau secret partagé. RADIUS nomme cet appareil le NAS (network access server).
• Les appareils voient un nouveau certificat de serveur pendant la poignée de main EAP.
• La politique lit les groupes à partir de Microsoft Entra ID, Okta ou Google Workspace plutôt qu'à partir d'un annuaire local.
• Les journaux sont transférés vers une nouvelle console.

Les éléments qui restent identiques comptent davantage. Vous conservez vos points d'accès, vos noms d'SSID, vos identifiants VLAN, vos trunks de commutateurs et vos zones de pare-feu. Personne ne change de mot de passe ni ne rejoint un nouveau réseau.

La même approche s'applique aux trois réseaux sur Purple Access. Sur les réseaux ouverts, de nombreux Captive Portals autorisent les appareils via RADIUS. Les réseaux sécurisés utilisent EAP-TLS ou PEAP. Sur les réseaux xPSK, RADIUS attribue à chaque appareil ou résident sa propre clé prépartagée. Ce guide suit le réseau sécurisé, car c'est celui qui comporte le plus de risques.

{"tone":"warning","title":"Le risque majeur : la confiance dans le certificat du serveur","text":"Les appareils sous EAP-TLS ou PEAP vérifient le certificat du serveur RADIUS, et beaucoup ne font confiance qu'à l'autorité de certification de l'ancien serveur. Déployez la nouvelle AC sur chaque profil d'appareil avant la migration du premier site, sinon ces appareils échoueront à se connecter et retenteront continuellement."}

Une fois que vous avez réglé la confiance accordée au certificat, le reste de la migration consiste en des travaux de configuration et des périodes d'observation.

Que faut-il vérifier avant la phase 1 ?

Cinq conditions doivent être réunies avant de créer la moindre politique. Si l'une d'elles manque, elle causera des problèmes lors d'une phase ultérieure.

Un inventaire NAS complet

Lisez chaque appareil qui envoie des requêtes à l'ancien serveur. Cela inclut les points d'accès, les contrôleurs sans fil, les commutateurs effectuant du 802.1X filaire et les passerelles VPN. Établissez la liste à partir de la liste de clients RADIUS de l'ancien serveur, et non à partir du schéma réseau. S'il manque un NAS dans l'inventaire, vous ne pourrez pas éteindre l'ancien serveur lors de la phase 4.

Une carte des politiques, ligne par ligne

Inscrivez chaque règle appliquée par l'ancien serveur, avec sa condition, son résultat et les attributs qu'il renvoie. Les lignes typiques ressemblent à ceci : groupe de personnel vers VLAN du personnel, prestataires vers un VLAN restreint, ordinateurs portables d'entreprise par certificat vers le VLAN d'entreprise. Notez quels attributs transportent le VLAN. La RFC 3580 définit l'ensemble standard : Tunnel-Type, Tunnel-Medium-Type et Tunnel-Private-Group-ID. Certains parcs utilisent plutôt des attributs spécifiques au fournisseur, et vous devez les reproduire à l'identique.

Un plan de certificat

Décidez quelle autorité de certification (CA) délivre le nouveau certificat de serveur. Sur les appareils gérés, déployez cette CA via Microsoft Intune, Jamf ou votre plateforme de gestion des appareils mobiles (MDM) avant tout déplacement de site. Pour EAP-TLS, le nouveau serveur doit également faire confiance à la CA qui a délivré vos certificats d'appareil.

Une source d'identité lisible par le nouveau serveur

Connectez votre fournisseur d'identité et confirmez que chaque groupe de la carte des politiques y existe. Si un groupe existe uniquement sur l'ancien serveur, récréez-le d'abord chez le fournisseur d'identité.

Accessibilité, propriétaires et fenêtres de changement

Chaque site a besoin d'un chemin réseau vers le serveur cloud, en utilisant les adresses et les ports figurant dans la documentation d'intégration de Purple. Désignez un propriétaire pour chaque site et convenez de fenêtres de changement avec les responsables de site. Indiquez le déclencheur de retour en arrière avant tout déplacement.

{"title":"Check-list de migration RADIUS multi-site","groups":[{"heading":"Avant la phase 1","items":[{"text":"Exporter la liste des clients RADIUS de l'ancien serveur et la rapprocher de l'inventaire NAS","why":"Un NAS oublié bloque la mise hors service"},{"text":"Cartographier chaque règle de stratégie : condition, résultat et attributs retournés"},{"text":"Confirmer que chaque groupe de stratégies existe dans Microsoft Entra ID, Okta ou Google Workspace"},{"text":"Déployer la nouvelle AC du serveur sur les appareils gérés via votre MDM"},{"text":"Ouvrir les accès indiqués dans la documentation d'intégration de Purple sur chaque site"},{"text":"Désigner un responsable et une fenêtre de changement par site, et valider la condition de retour arrière par écrit"}]},{"heading":"Phase 1 : construction","items":[{"text":"Geler les modifications de stratégie sur l'ancien serveur"},{"text":"Recréer chaque ligne de stratégie sur le nouveau serveur"},{"text":"Tester une identité par ligne sur les deux serveurs et comparer les réponses"}]},{"heading":"Phases 2 et 3 : pilote et vagues","items":[{"text":"Enregistrer un taux de rejet de référence par site avant la bascule"},{"text":"Ajouter le nouveau serveur à côté de l'ancien sur chaque SSID"},{"text":"Confirmer que chaque classe d'appareil s'authentifie sur le nouveau serveur"},{"text":"Maintenir chaque vague pendant un cycle d'activité complet avant de passer à la suivante"}]},{"heading":"Phase 4 : mise hors service","items":[{"text":"Retirer l'ancien serveur de chaque SSID et NAS"},{"text":"Confirmer l'absence totale de requêtes sur l'ancien serveur pendant la période d'inactivité convenue"},{"text":"Exporter et conserver les journaux de l'ancien serveur conformément à votre politique de conservation"},{"text":"Revoker les secrets partagés utilisés avec l'ancien serveur"},{"text":"Mettre à jour le guide opérationnel et archiver le rapport de test de sortie de chaque site"}]}],"download":{"filename":"radius-migration-checklist.csv"}}

Quelles sont les 4 phases, dans l'ordre ?

Le plan comporte quatre phases. Chacune se termine par un test de sortie à valider. Rien ne passe à la phase suivante tant que le test n'est pas réussi, ce qui vous évite une bascule globale et risquée.

{"kind":"timeline","direction":"lr","caption":"Un parc illustratif de 40 sites : quatre phases, chacune clôturée par un test de sortie","alt":"Chronologie montrant la préparation, puis la phase 1 de création, la phase 2 de pilote, la phase 3 de déploiement progressif et la phase 4 de mise hors service sur environ 12 semaines.","nodes":[{"id":"p0","label":"Avant la phase 1","sub":"Inventaire, cartographie des règles, déploiement d'AC, source d'identité","tone":"neutral","when":"Semaines 1-2"},{"id":"p1","label":"Phase 1 : création et miroir","sub":"Règles réétablies sur RADIUS-as-a-Service, réponses de laboratoire identiques","tone":"brand","when":"Semaine 3"},{"id":"p2","label":"Phase 2 : site pilote","sub":"Un site, ancien serveur conservé en secondaire","tone":"brand","when":"Semaines 4-5"},{"id":"p3","label":"Phase 3 : vagues de déploiement","sub":"Cinq, puis 10, puis les 24 sites restants","tone":"brand","when":"Semaines 6-10"},{"id":"p4","label":"Phase 4 : mise hors service","sub":"Zéro requête sur l'ancien serveur, puis arrêt","tone":"success","when":"Semaines 11-12"}],"edges":[{"from":"p0","to":"p1","label":"prérequis remplis"},{"from":"p1","to":"p2","label":"réponses de laboratoire identiques"},{"from":"p2","to":"p3","label":"test de sortie du pilote"},{"from":"p3","to":"p4","label":"basculement de tous les sites"}]}

{"caption":"Plan de phase pour une migration RADIUS multi-sites","asOf":"2026-06-10","columns":[{"key":"phase","label":"Phase"},{"key":"scope","label":"Périmètre"},{"key":"owner","label":"Responsable"},{"key":"exit","label":"Test de sortie"}],"rows":[["Avant la phase 1","Inventaire NAS, cartographie des règles, déploiement d'AC, source d'identité, chemins d'accès aux sites","Responsable informatique avec le responsable de la gestion des identités et des accès","Chaque NAS répertorié, chaque groupe de règles chez le fournisseur d'identités, nouvelle AC sur les appareils gérés"],["Phase 1 : création","Règles réétablies sur RADIUS-as-a-Service, aucun trafic en direct","Responsable de la gestion des identités et des accès","Une identité de test par ligne obtient la même réponse et le même VLAN sur l'ancien et le nouveau"],["Phase 2 : pilote","Un site représentatif, nouveau serveur principal, ancien secondaire","Architecte réseau","Un cycle d'activité sans rejet inexpliqué et chaque classe d'appareil observée sur le nouveau serveur"],["Phase 3 : vagues de déploiement","Sites restants en vagues croissantes, regroupés par modèle de console","Architecte réseau avec les responsables de site","Chaque vague réussit le test de sortie du pilote avant que la suivante ne commence"],["Phase 4 : mise hors service","Ancien serveur supprimé de chaque SSID et NAS","Responsable informatique","Zéro requête sur l'ancien serveur pendant la période d'inactivité, journaux conservés, secrets retirés"]],"footnote":"Les responsables sont des rôles et non des personnes désignées. Définissez la période d'inactivité sur au moins un cycle de réauthentification plus une semaine ouvrée.","download":{"filename":"radius-migration-phase-plan.csv"}}

Que se passe-t-il dans chaque phase ?

Phase 1 : créer et dupliquer les règles en miroir

Reconstruisez la cartographie des règles sur le nouveau serveur avant qu'aucune requête en direct ne l'atteigne. Connectez le fournisseur d'identités, puis recréez chaque ligne avec sa condition, son résultat et ses attributs renvoyés. Conservez des identifiants VLAN identiques pour que la configuration du commutateur et du pare-feu ne change jamais.

Testez chaque ligne depuis un laboratoire. Utilisez eapol_test, un outil du projet wpa_supplicant. Il envoie un échange EAP réel à un serveur RADIUS et affiche la réponse. Exécutez une identité par ligne sur les deux serveurs et comparez les réponses. Le test de validation finale exige une correspondance sur chaque ligne, avec le même accord ou rejet et le même VLAN.

Phase 2 : piloter un site pilote

Choisissez un site représentatif de l'ensemble du parc, et non le plus simple. Il doit contenir toutes les classes d'équipements que vous exploitez, y compris les plus complexes. Pensez aux lecteurs d'emplacements portables, aux terminaux de paiement sur WiFi et aux ordinateurs portables plus anciens. Vous avez également besoin de quelqu'un sur place capable de tester un appareil sur demande.

Ajoutez le nouveau serveur à côté de l'ancien, testez-le, puis définissez le nouveau serveur comme principal. Laissez-le fonctionner pendant un cycle d'activité complet. Pour un hôtel, cela correspond à une semaine complète de plannings d'équipes. Pour un bureau, cela signifie une semaine de connexions du lundi matin. Le pilote est validé lorsque deux conditions sont remplies. Premièrement, chaque classe d'équipement s'est authentifiée sur le nouveau serveur. Deuxièmement, le taux de rejet n'est pas supérieur à votre niveau de référence.

Phase 3 : migrer le parc par vagues

Augmentez la taille de chaque vague à mesure que les précédentes sont validées. Un parc de 40 sites peut migrer un site pilote, puis cinq, puis 10, puis les 24 restants. Regroupez chaque vague par modèle de console ou par groupe, afin qu'une seule modification atteigne chaque site concerné. Les modèles de configuration Meraki, les modèles WLAN Juniper Mist et les groupes HPE Aruba Central conviennent tous à cette approche.

Effectuez la bascule pendant que le personnel du site est présent, et non à 3 heures du matin. Une modification que personne ne teste avant le matin est une modification que vous n'avez pas testée. Évitez de regrouper d'autres modifications réseau dans la même fenêtre d'intervention.

Phase 4 : décommissionner l'ancien serveur

Retirez l'ancien serveur de chaque SSID et de chaque NAS de l'inventaire, puis surveillez ses journaux d'événements. Les requêtes doivent tomber à zéro. Tout ce qui arrive encore provient d'un NAS que vous avez oublié. Maintenez cette période d'observation pendant au moins un cycle de réauthentification plus une semaine d'activité. Exportez ensuite les journaux d'événements conformément à votre politique de conservation, éteignez le serveur et supprimez ses secrets partagés.

Étude de cas : un groupe de 40 hôtels sur Cisco Meraki

Prenons un groupe de 40 hôtels exploitant un réseau WiFi pour le personnel sur Cisco Meraki. Il utilise PEAP vers un serveur RADIUS sur site au siège social. Chaque requête traverse le WAN vers un seul bâtiment, de sorte qu'une panne au siège social interrompt le WiFi du personnel dans chaque hôtel.

Le groupe déploie la nouvelle CA via son MDM la première semaine. Il reconstruit cinq lignes de règles sur le RADIUS cloud connecté à Microsoft Entra ID, puis lance un pilote dans un hôtel urbain de 120 chambres. Des vagues de cinq, 10 et 24 hôtels suivent, chacune correspondant à un modèle de configuration Meraki. Un hôtel effectue un retour en arrière pendant un après-midi parce qu'une tablette du service d'étage ne fait confiance qu'à l'ancienne CA. Il migre à nouveau une semaine plus tard.

Le résultat :

• Les 40 hôtels migrent en six fenêtres d'intervention.
• Un seul site effectue un retour en arrière une seule fois.
• Le siège social ne se trouve plus sur le chemin d'authentification.

Comment les anciens et nouveaux serveurs RADIUS fonctionnent-ils côte à côte ?

Le fonctionnement en parallèle dépend de la façon dont les points d'accès basculent en cas de défaillance. Un NAS envoie chaque requête au premier serveur de sa liste. Il n'essaye le serveur suivant que lorsque le premier ne répond pas dans le délai imparti.

Un Access-Reject compte comme une réponse, pas comme une défaillance, donc le NAS ne réessaiera pas la requête ailleurs. Cela a deux conséquences :

• Les deux serveurs doivent donner la même réponse. S'ils diffèrent, l'expérience d'un appareil dépend du serveur qui a répondu par hasard.
• Le fonctionnement en parallèle est un filet de sécurité, pas un test. Testez la politique en phase 1 et lors du pilote. Ne la testez pas en attendant de voir ce que fait le basculement.

Vérifiez les délais d'attente avant le déplacement du premier site. Un serveur cloud est plus éloigné qu'un serveur situé dans votre salle informatique. Comparez les paramètres de délai d'attente et de réessai du NAS de chaque site avec son temps d'aller-retour. Si les paramètres sont trop stricts, les requêtes basculeront vers l'ancien serveur sans raison valable, ce qui masquera les problèmes. Déplacez la comptabilité RADIUS vers le nouveau serveur en même temps que l'authentification, afin que les enregistrements de session résident au même endroit.

La bascule sur chaque site consiste simplement à inverser l'ordre des deux serveurs. Ces étapes s'appliquent à chaque site, avec les différences spécifiques aux fournisseurs présentées à l'étape 2.

{"title":"Basculer un site sans interrompre le service","steps":[{"title":"Confirmer que le site est prêt","body":"Vérifiez le site par rapport à la liste de contrôle de migration : NAS répertorié, nouvelle autorité de certification sur les appareils gérés, accès à Purple ouvert, responsable sur site.","check":"Chaque prérequis pour le site est coché."},{"title":"Ajouter le nouveau serveur à côté de l'ancien","body":"Ajoutez le cloud RADIUS de Purple à la liste des serveurs RADIUS de l'SSID, en utilisant le secret partagé fourni par Purple pour le site. Laissez l'ancien serveur en premier pour l'instant.","check":"La console affiche les deux serveurs pour l'SSID.","variants":[{"label":"Meraki","body":"Dans le tableau de bord Meraki, ajoutez le serveur dans les paramètres de contrôle d'accès de l'SSID, idéalement dans le modèle de configuration."},{"label":"Aruba","body":"Dans HPE Aruba Central, ajoutez le serveur au groupe de serveurs d'authentification utilisé par le WLAN."},{"label":"Ruckus","body":"Ajoutez le serveur au profil de serveur AAA utilisé par le WLAN, en tant que serveur secondaire."},{"label":"Mist","body":"Dans le portail Juniper Mist, ajoutez le serveur aux serveurs d'authentification RADIUS du WLAN, idéalement dans le modèle WLAN."},{"label":"UniFi","body":"Dans l'application UniFi Network, ajoutez le serveur au profil RADIUS attribué au réseau WiFi."}]},{"title":"Tester avant de basculer","body":"Depuis un hôte de test enregistré comme client RADIUS, envoyez une identité par ligne de politique vers le nouveau serveur.","code":{"lang":"bash","text":"eapol_test -c eap-tls.conf -a <purple-radius-address> -p 1812 -s <shared-secret>"},"check":"Chaque identité reçoit Access-Accept ou Access-Reject selon la carte des politiques, avec le VLAN attendu."},{"title":"Inverser l'ordre","body":"Définissez le nouveau serveur comme principal et conservez l'ancien serveur comme secondaire. C'est le basculement.","check":"Les journaux du nouveau serveur affichent les requêtes de chaque point d'accès du site."},{"title":"Observer pendant un cycle d'activité","body":"Comparez le taux de rejet avec votre référence et confirmez que chaque classe d'appareil s'est authentifiée.","check":"Aucun rejet inexpliqué, et le site réussit son test de sortie."}]}

Comment annuler le basculement d'un site ou d'une vague ?

L'annulation est le processus inverse du basculement : vous remettez l'ancien serveur en premier. Sur chaque console mentionnée ci-dessus, cela représente une seule modification de configuration. Cela ne fonctionne que si l'ancien serveur est toujours en cours d'exécution, inchangé, avec ses secrets partagés intacts. C'est pourquoi le déclassement intervient en dernier. C'est également la raison pour laquelle vous gelez la politique sur l'ancien serveur dès le début de la phase 1.

Convenez des déclencheurs avant de commencer. Les déclencheurs classiques sont :

• Une classe d'appareils qui ne peut pas se connecter et ne dispose d'aucune solution le jour même.
• Des attributions de VLAN qui diffèrent de la carte des politiques.
• Un taux de rejet supérieur à la référence que vous ne pouvez pas expliquer pendant la fenêtre de changement.

{"title":"Poursuivre, suspendre ou annuler une vague","start":"q1","nodes":[{"id":"q1","question":"Une classe d'équipements échoue-t-elle sur le nouveau serveur alors qu'elle réussissait sur l'ancien ?","help":"Comparez les rejets par type d'équipement avec la référence enregistrée avant la bascule.","options":[{"label":"Oui","to":"q2"},{"label":"Non","to":"q3"}]},{"id":"q2","question":"L'échec est-il limité à une seule classe d'équipements bénéficiant d'un correctif connu ?","help":"Une AC manquante dans un profil est un correctif connu. Des rejets sur plusieurs classes ne le sont pas.","options":[{"label":"Oui","to":"o2"},{"label":"Non","to":"o3"}]},{"id":"q3","question":"Chaque identité de test arrive-t-elle sur le VLAN attendu sur chaque site de la vague ?","options":[{"label":"Oui","to":"q4"},{"label":"Non","to":"o3"}]},{"id":"q4","question":"La vague a-t-elle fonctionné pendant un cycle d'activité complet sans rejet inexpliqué ?","options":[{"label":"Oui","to":"o1"},{"label":"Non","to":"o2"}]},{"id":"o1","outcome":"Poursuivre : lancer la vague suivante","detail":"Enregistrez le résultat du test de sortie par site et planifiez la vague suivante.","link":"[Une seule politique sur l'ensemble des sites](guide:cloud-radius-multi-site)"},{"id":"o2","outcome":"Suspendre : corriger, puis retester","detail":"Placez l'ancien serveur en premier uniquement sur le SSID concerné, corrigez le profil ou la règle, et réexécutez le test de sortie."},{"id":"o3","outcome":"Annuler la vague","detail":"Placez l'ancien serveur en premier sur chaque SSID de la vague, capturez les journaux des deux serveurs et identifiez la cause avant de réessayer.","link":"[Lorsque RADIUS est inaccessible](guide:radius-server-down-wifi)"}]}

Après toute annulation, exportez les journaux des deux serveurs pour la période d'échec. Identifiez la cause et corrigez-la dans la nouvelle politique. Réexécutez ensuite le test de laboratoire de la phase 1 pour la ligne concernée avant que le site ne soit déplacé à nouveau.

Comment savoir si la migration est terminée ?

La migration est terminée lorsque les preuves le confirment, et non lorsque le dernier site est déplacé. Cinq tests permettent de la clôturer :

1. L'ancien serveur n'a enregistré aucune requête pendant la période d'inactivité convenue.
2. Chaque NAS de l'inventaire apparaît dans les journaux du nouveau serveur.
3. Un équipement réel a exécuté chaque ligne de politique et a abouti sur le VLAN attendu.
4. Le taux de rejet est inférieur ou égal à la référence enregistrée avant la phase 2.
5. L'ancien serveur est éteint, ses journaux sont conservés, ses secrets sont révoqués et le manuel d'exploitation est mis à jour.

Conservez un registre d'une page pour chaque site, comprenant la date, le résultat du test de sortie et toute annulation. Associés aux nouveaux journaux d'authentification, ces registres constituent vos preuves pour les contrôles d'accès ISO 27001 et la journalisation PCI-DSS. Ils servent également de preuves de contrôle des modifications pour le prochain cycle d'audit.

Modes de défaillance observés sur le terrain

Équipements qui ne font confiance qu'à l'ancien certificat

Il s'agit de la défaillance la plus courante. Les équipements PEAP non gérés peuvent demander le nouveau certificat ou le refuser catégoriquement. Certains profils gérés verrouillent le nom du serveur ainsi que l'AC. Vérifiez ces deux éléments avant le pilote.

Un NAS que personne n'a répertorié

Les contrôleurs oubliés, les commutateurs 802.1X filaires et les passerelles VPN occupent l'ancien serveur bien après le déplacement du WiFi. La période de calme de la phase 4 permet de les repérer.

Stratégie qui résidait sur l'ancien serveur

Les groupes locaux, les listes MAC codées en dur et les règles d'horaires d'accès n'existent souvent que sur l'ancien serveur. S'ils ne figurent pas dans la carte des stratégies, ils disparaissent lors du basculement.

Incohérences de secret partagé et d'attributs

Un secret mal saisi échoue silencieusement sur certaines consoles. Un VLAN renvoyé par son nom plutôt que par son identifiant peut faire basculer les appareils sur le VLAN par défaut. Ces deux problèmes doivent apparaître lors des tests de la phase 1, et vous devez les vérifier à nouveau lors du pilote.

Délais d'expiration réglés pour un serveur hébergé dans le bâtiment

Des délais d'expiration trop courts sur un NAS provoquent un basculement intempestif vers l'ancien serveur. Tout semble fonctionner jusqu'à ce que l'ancien serveur soit supprimé.

Scénario concret : un distributeur de 120 magasins sur deux consoles

Prenons l'exemple d'un distributeur de 120 magasins dont les anciens points de vente utilisent HPE Aruba et les plus récents Juniper Mist. Les terminaux portables et les ordinateurs portables des magasins utilisent EAP-TLS avec une paire de serveurs RADIUS sur site. Le pilote et les vagues se déroulent sans problème, regroupés par groupe Aruba Central et modèle WLAN Mist.

En phase 4, les anciens serveurs continuent d'enregistrer des requêtes provenant de trois adresses après le déplacement de chaque SSID. Deux d'entre elles sont des contrôleurs de centres de distribution situés en dehors du parc des magasins. La troisième est une passerelle VPN pour les ordinateurs portables du siège social. L'équipe ajoute ces trois éléments à l'inventaire, les déplace dans une fenêtre supplémentaire et redémarre la période de calme. Le déclassement se termine avec deux semaines de retard, sans aucune interruption dans aucun magasin.

La place de Purple

Purple Access gère des réseaux ouverts, sécurisés et xPSK sur une seule plateforme, en utilisant les points d'accès que vous possédez déjà. Le réseau sécurisé prend en charge cette migration. Il fournit un service cloud RADIUS, EAP-TLS et la gestion des identités à partir de Microsoft Entra ID, Okta ou Google Workspace. Il prend également en charge Passpoint, également appelé Hotspot 2.0, qui permet aux appareils de rejoindre automatiquement un réseau sécurisé avec des identifiants. Purple est indépendant du matériel, de sorte qu'une seule stratégie sert les sites sur ces plateformes :

• Cisco Meraki
• HPE Aruba
• Ruckus
• Juniper Mist
• Ubiquiti UniFi
• Cambium
• Extreme Networks
• Fortinet

Cela signifie qu'un parc mixte peut migrer selon un seul plan.

Purple exploite le plus grand cloud RADIUS au monde. Il est assorti d'un SLA de disponibilité RADIUS de 99,9 %, sur une plateforme fonctionnant à 99,999 % de disponibilité. Comme le côté Purple est configuré avant le début de la phase 2, le basculement de chaque site est généralement une opération effectuée le week-end. Le découpage en phases existe pour gérer le risque au sein de votre parc, et non sur notre plateforme.

{"items":[{"value":"80,000+","label":"sites actifs","note":"Données propres à Purple"},{"value":"90","label":"pays"},{"value":"99.9%","label":"SLA de disponibilité RADIUS","note":"Sur une plateforme fonctionnant à 99,999 %"}]}

{"tone":"proof","title":"WiFi du personnel à l'échelle des succursales","text":"JPMorgan exploite le WiFi du personnel sur Purple dans 5 000 succursales."}

Consultez cloud RADIUS sur Purple Access pour le détail du produit, et le guide de sécurité entreprise WiFi pour l'ensemble des contrôles. Le marketing invité se trouve dans Engage et le filtrage DNS dans Shield. Aucun des deux ne change lors d'une migration RADIUS.

Foire aux questions

Combien de temps prend une migration RADIUS multi-sites ?

Prévoyez plusieurs semaines pour l'ensemble du parc et un week-end par site. Sur Purple, le basculement de chaque site est généralement une opération d'un week-end. Le parc prend plus de temps car chaque vague attend un cycle d'activité avant que la suivante ne commence. Un parc illustratif de 40 sites s'étend sur environ 12 semaines, de l'inventaire au déclassement. La majeure partie de ce temps est consacrée à la préparation et aux périodes d'attente, non aux travaux de modification.

Faut-il de nouveaux points d'accès pour passer au cloud RADIUS ?

Non. Le cloud RADIUS modifie le serveur que vos points d'accès interrogent, pas les points d'accès eux-mêmes. Purple fonctionne avec Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme et Fortinet. Vous ajoutez le nouveau serveur à la liste de serveurs RADIUS de chaque SSID dans la console que vous utilisez déjà. Vos SSID, identifiants VLAN et la configuration de vos commutateurs restent inchangés.

Comment modéliser le coût du cloud RADIUS sur plusieurs sites ?

Modélisez-le sur deux chiffres : les sites et les identités. Comptez chaque site qui s'authentifie et chaque identité qui se connecte, y compris les appareils sur EAP-TLS. Comparez ensuite cela au coût total de l'ancien serveur : matériel, licences, correctifs, haute disponibilité et chemin WAN vers le siège social. Notre guide sur la modélisation du coût du cloud RADIUS par site détaille le calcul.

Puis-je conserver l'ancien serveur RADIUS comme solution de secours après la migration ?

Conservez-le pendant le fonctionnement en parallèle, puis éteignez-le. Tant qu'il est répertorié comme secondaire, il couvre les dépassements de délai sur les sites faisant encore partie des vagues. Après la phase 4, un serveur conservant une copie figée de l'ancienne politique devient un risque, car toute réponse qu'il fournit utilise des règles obsolètes. Dès lors, la résilience provient du SLA de disponibilité RADIUS de 99,9 % et d'un plan de reprise en cas de panne.

Les collaborateurs devront-ils réinscrire leurs appareils ?

Pas si le certificat du nouveau serveur est approuvé avant le basculement. Déployez la nouvelle AC sur les appareils gérés via votre MDM pendant la phase de création. Les appareils EAP-TLS conservent leurs certificats clients existants, à condition que le nouveau serveur fasse confiance à l'AC qui les a délivrés. Les appareils PEAP non gérés font exception, car certains demandent une fois d'accepter le nouveau certificat. Envoyez à ces collaborateurs une courte notification avant le déplacement de leur site.

La migration affecte-t-elle nos preuves ISO 27001 ou PCI DSS ?Cela modifie la provenance de vos preuves, vous devez donc l'anticiper dès le départ. Les journaux d'authentification, les définitions de stratégies et les historiques de modifications sont transférés vers la nouvelle plateforme. Conservez les journaux de l'ancien serveur conformément à votre politique de conservation et archivez le rapport de test de sortie de chaque site. Purple détient la certification ISO 27001, ce qui fournit à vos auditeurs les preuves nécessaires pour la partie plateforme. Vos propres contrôles nécessitent toujours leurs propres preuves.

En quoi cela diffère-t-il pour un MSP gérant plusieurs environnements ?

Les phases restent identiques. La différence réside dans l'isolation entre les environnements. Un MSP exécute les quatre mêmes phases pour chaque environnement, mais chacun nécessite sa propre stratégie, sa source d'identité et ses propres journaux sur une plateforme partagée. Les vagues suivent généralement les limites contractuelles plutôt que les modèles de console. Notre guide sur le RADIUS multi-tenant pour les MSP explique comment maintenir l'isolation de chaque environnement pendant et après la transition.