Cisco Secure Client Always-On : déployez d'abord le profil

Les paramètres côté appareil ne peuvent pas faire qu'un ordinateur portable non enrôlé se comporte comme un poste géré, et la plupart des déploiements Always-On se bloquent précisément dans cet écart. Cisco Secure Client applique la stratégie via le profil présent sur la machine, donc la distribution de ce profil fait partie du plan d'application et n'en est pas un détail. Parcourez les cinq étapes ci-dessous dans l'ordre et arrêtez-vous à la première qui ne tient pas, car une étape ultérieure ne peut pas compenser une lacune antérieure.

Étape un : décidez si la règle commence avant l'ouverture de session

Always-On établit le tunnel après l'ouverture de session de l'utilisateur, et la documentation du fournisseur dit clairement qu'il n'établit pas de connexion lorsque personne ne se connecte. Si votre exigence est un tunnel qui existe avant l'écran d'ouverture de session Windows, c'est la mauvaise fonctionnalité et aucun réglage du profil n'y change rien. Déployer le profil à l'avance ne transforme pas le comportement après ouverture de session en comportement avant.

Écrivez l'exigence comme l'un de quatre comportements distincts, puis testez chacun séparément. Une seule connexion réussie ne démontre que le cas ordinaire, et les trois autres sont d'où viennent les tickets de support. Marquez la ligne dont votre exigence a réellement besoin, car une équipe qui n'a besoin que du comportement après ouverture de session peut sauter l'argument du avant. Le tableau est une liste d'acceptation, pas une liste de souhaits.

Si l'exigence n'est que la deuxième ligne, le reste de cette page s'applique toujours, mais le test d'acceptation est moins coûteux.

Étape deux : confirmez que le profil est déjà sur le poste

L'application lit un profil local, donc la première question est de savoir si ce fichier existe avant que l'utilisateur ne se connecte. Un profil téléchargé lors de la première connexion réussie arrive trop tard pour une machine qui doit être protégée dès sa première ouverture de session. Livrez-le avec l'installateur ou avec la gestion des postes, et traitez la présence du fichier comme une vérification de build plutôt qu'un espoir.

Get-Service vpnagent | Select-Object Status, StartType
Get-ChildItem 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile'
Get-Content 'C:\ProgramData\Cisco\Cisco Secure Client\VPN\Profile\profile.xml' | Select-String -Pattern AlwaysOn

Les anciennes installations d'AnyConnect conservent le même fichier dans un dossier au nom différent, donc confirmez le chemin pour la version de client que vous déployez au lieu de copier un chemin d'un ancien runbook. Le service doit être en cours d'exécution et configuré pour démarrer automatiquement, car un agent arrêté est un poste sans application, quoi que dise le profil.

Si le profil manque, arrêtez-vous ici. Corriger la politique d'échec ou la liste des réseaux de confiance pour une machine sans profil, c'est travailler sur un chemin qui ne s'exécute jamais.

Étape trois : choisissez délibérément le comportement en cas d'échec

Ce qui se passe lorsque le tunnel ne peut pas monter est une décision distincte de celle de savoir si le tunnel démarre automatiquement. La politique d'échec de connexion décide si le poste peut utiliser Internet pendant que l'établissement continue d'échouer, et les deux réglages sont souvent confondus parce que tous deux se trouvent près des options Always-On. Choisissez-en un exprès et notez la raison.

Bloquer toute connectivité semble strict et crée sa propre classe d'incidents : un utilisateur sur un réseau où la passerelle est injoignable ne peut pas télécharger le correctif qui rétablirait le service. Autoriser l'accès à Internet garde la machine utilisable et affaiblit la garantie que le trafic est protégé. L'une ou l'autre réponse peut être correcte, mais aucune n'est une valeur par défaut que vous devriez découvrir pendant une panne.

Le comportement de nouvelle tentative relève de la même décision. Un client qui réessaie indéfiniment cache une passerelle défaillante à la supervision, tandis qu'un client qui abandonne après une tentative semble défaillant à l'utilisateur. Décidez combien de temps le poste doit continuer à essayer avant que la politique d'échec prenne le relais, et testez ce délai au lieu de le supposer.

Étape quatre : définissez ce qui compte comme de confiance

La détection de réseau de confiance utilise les critères du profil client, comme les domaines DNS configurés ou les serveurs DNS de confiance, pour décider que le poste est déjà sur un réseau où le tunnel est inutile. Cette liste est toute la politique, donc une liste vide ou héritée rend la fonctionnalité soit inerte, soit imprévisible.

Ne la remplacez pas par une supposition sur la catégorie de réseau du pare-feu Windows. Une machine peut être sur un réseau étiqueté domaine et se trouver malgré tout dans un lieu auquel vous ne faites pas confiance, et une machine avec un profil public peut être à l'intérieur de votre propre bâtiment. Les critères de détection doivent décrire directement vos réseaux, pas un substitut.

Testez la transition dans les deux sens, y compris le cas où le poste passe d'un réseau de confiance à un réseau non fiable alors qu'une session est ouverte. La déconnexion et la reconnexion sont des événements distincts, et une politique qui ne gère que le premier laisse une fenêtre où le tunnel est absent.

Étape cinq : rendez la politique du poste difficile à annuler

L'application sur le poste n'est aussi solide que les contrôles propres au poste. Les droits d'administrateur local permettent à un utilisateur d'arrêter le service de l'agent, de remplacer le profil ou de désinstaller le client, et un répertoire de profil où les utilisateurs ordinaires peuvent écrire est une politique que quiconque peut modifier. Les deux sont des problèmes de gestion des postes que la tête de VPN ne peut pas résoudre à votre place. Demandez à l'équipe poste de travail laquelle de ces deux conditions s'applique avant de promettre l'application, et écrivez la réponse dans le plan de déploiement.

Décidez le niveau de verrouillage en gardant à l'esprit le chemin de récupération. Un profil qui empêche l'utilisateur d'atteindre Internet et l'empêche aussi de réparer le client transforme un appel au support en visite sur site, donc gardez un chemin de récupération documenté qui ne dépend pas du fait que le tunnel soit actif.

Gardez la validation du certificat de la passerelle activée et ne distribuez le profil que par un canal auquel vous faites confiance. Un client verrouillé qui accepte un profil d'une source inattendue a déplacé la frontière de confiance plutôt que de l'appliquer.