Utilisateur Mac standard avec un VPN géré : ce que l’informatique doit assumer
Choisissez entre un profil géré, un installateur en libre-service et une connexion créée par l’utilisateur sur macOS, puis remettez le compte sans droits d’administrateur.
Les comptes macOS standard peuvent faire tourner un VPN d’entreprise toute la journée pendant que l’informatique conserve chaque opération privilégiée. Y arriver est une décision de livraison, pas un débat sur les droits : choisissez qui installe le client, qui rédige la connexion et ce que l’utilisateur est autorisé à modifier. Trois voies couvrent presque tous les cas, et chacune échoue différemment. Choisissez la voie selon la propriété de l’appareil et le type d’identifiant, puis testez-la en tant qu’utilisateur standard plutôt qu’en tant que vous-même.
Trois voies de livraison et ce que chacune règle
La première voie est un profil de configuration géré, livré par la gestion des appareils de l’organisation. La charge VPN transporte la passerelle, la méthode d’authentification, les routes et le DNS, et elle s’installe par le canal de l’appareil ou de l’utilisateur selon la façon dont le Mac est enrôlé. La deuxième voie est un installateur en libre-service : l’utilisateur exécute un paquet approuvé qui place le client et rédige la connexion à sa place. Elle fonctionne quand aucun enrôlement de gestion n’existe, mais que l’organisation veut tout de même une configuration reproductible et vérifiable. La troisième voie est que l’utilisateur crée la connexion à la main dans Réglages Système, en suivant des valeurs publiées. C’est la moins chère à démarrer et la plus coûteuse à soutenir, car chaque erreur côté client devient un appel au centre d’assistance et chaque changement une note.
scutil --nc list
sudo profiles show -type configuration
system_profiler SPConfigurationProfileDataType
Lisez la première liste pour voir quelles connexions existent et à qui elles appartiennent, et les deux autres pour voir ce qui a été installé comme stratégie. Un profil absent des deux listes n’est pas arrivé, quoi qu’on ait dit à l’utilisateur.
Décidez selon la propriété de l’appareil, pas selon l’ancienneté
Un Mac appartenant à l’organisation justifie normalement la première voie, car le même canal qui livre le VPN peut le retirer, et l’utilisateur ne peut pas modifier la connexion en silence. Choisissez le canal de l’appareil quand le tunnel doit exister avant qu’un utilisateur se connecte, et le canal de l’utilisateur quand la connexion appartient à la personne. Un Mac personnel avec un service d’entreprise pointe généralement vers la deuxième voie. L’organisation ne peut pas gérer l’appareil, donc l’installateur doit être petit, réversible et suffisamment documenté pour que l’utilisateur puisse l’annuler.
La troisième voie reste raisonnable pour une poignée d’utilisateurs techniques à configuration stable, et pour quiconque teste une passerelle avant son déploiement. En dessous de cette échelle, elle devient un ensemble non audité de réglages saisis à la main que personne ne peut inventorier.
Séparez le profil du compte
Un profil de connexion local indique comment joindre la passerelle. Un compte autorisé sur la passerelle indique si l’appelant peut entrer. Ils sont fournis par des personnes différentes et révoqués pour des raisons différentes, alors ne traitez jamais le profil comme l’autorisation. Les certificats se situent entre les deux. Un certificat livré avec le profil authentifie l’appareil ou l’utilisateur, et sa révocation sur la passerelle met fin à l’accès même si le profil reste sur le disque. Une conception fondée uniquement sur un mot de passe s’appuie plutôt sur le cycle de vie du compte, c’est pourquoi la note de remise doit dire lequel des deux est en jeu.
Décidez aussi si le client est un VPN système ou un tunnel par application. Une conception par application n’achemine que les applications choisies, et elle dépend de la prise en charge de ce modèle par le client sur la version de macOS utilisée, alors vérifiez-le sur une machine pilote au lieu de supposer que le réglage suit.
Remettez sans mot de passe administrateur
L’utilisateur doit démarrer la connexion, se connecter et se remettre d’un changement de mot de passe. Rien de tout cela n’exige un compte administrateur, et rien ne justifie d’intégrer des identifiants dans un script, une action Automator ou une étape post-installation d’un paquet signé.
scutil --nc start "Acme VPN"
scutil --nc status "Acme VPN"
log show --predicate 'subsystem == "com.apple.networkextension"' --last 10m
Les deux premières commandes sont des opérations de niveau utilisateur qu’un centre d’assistance peut faire suivre à quelqu’un. La troisième lit l’activité récente du tunnel lorsqu’une connexion échoue, et c’est l’artefact à demander plutôt qu’une capture d’écran d’une boîte d’erreur.
Si une étape exige encore l’approbation d’un administrateur, c’est un défaut de livraison : renvoyez l’invite exacte au propriétaire du profil au lieu de distribuer un compte plus autorisé que la tâche ne le demande.
Connectez-vous comme utilisateur standard, puis écrivez la sortie
Connectez-vous avec le compte standard, établissez la connexion, atteignez l’hôte interne prévu, laissez le Mac dormir, réveillez-le et confirmez la reconnexion. Répétez après un changement de mot de passe, car c’est précisément là que la moitié de ces déploiements échouent réellement. Écrivez le chemin de récupération avant que le premier utilisateur n’en ait besoin : quoi faire quand le profil manque, quand le certificat a expiré et quand la passerelle refuse une connexion par ailleurs valide. Gardez ces trois réponses là où le centre d’assistance peut les trouver.
Enfin, planifiez le retrait. Un VPN qui ne peut pas être retiré du Mac d’un utilisateur qui part en une seule opération est une constatation d’audit d’accès sur le point de se produire.