Kerberos SSO et VPN sur Mac : comparez les deux chemins de connexion

Deux mécanismes produisent le même résultat agréable sur un Mac et se comportent de façon entièrement différente sous le capot. L’un obtient des tickets Kerberos via une extension SSO et les remet aux applications participantes. L’autre maintient une session de navigateur auprès d’un fournisseur d’identité et laisse les applications web l’honorer. Ils diffèrent par ce qu’ils exigent sur le réseau, par la durée de vie de leurs identifiants et par ce qui se passe à l’instant où le tunnel tombe.

Deux mécanismes, un écran de connexion

Le chemin fondé sur les tickets dépend d’un domaine Kerberos, d’un centre de distribution de clés et d’une horloge qui s’accorde avec lui. Le chemin du navigateur dépend d’un fournisseur d’identité joignable, d’un cookie ou d’un jeton et d’une application qui fait confiance à cet émetteur. Les deux peuvent être configurés pour démarrer à la connexion, ce qui explique qu’on les confonde avec la même fonction. Les applications décident lequel des deux elles acceptent, et un Mac peut légitimement exécuter les deux à la fois.

Comparez-les en demandant ce que l’application vérifie lorsqu’un utilisateur l’ouvre. Un service de fichiers joint au domaine Kerberos veut un ticket de service, et aucune quantité de session de navigateur ne le satisfera. Une application web derrière un fournisseur d’identité moderne veut le jeton de ce fournisseur et ignore entièrement le ticket Kerberos. Une fois que vous savez quelle vérification a lieu, les questions de déploiement deviennent précises plutôt que générales.

Ce dont l’extension Kerberos a besoin sur le réseau

Le guide de l’extension Kerberos SSO d’Apple décrit l’authentification native Active Directory avec acquisition proactive de tickets, associée à des comptes locaux plutôt qu’à une liaison au domaine. Ce qu’elle ne peut pas faire, c’est inventer un chemin vers les contrôleurs de domaine. Le Mac a besoin d’un résolveur qui répond aux enregistrements de service Kerberos et d’une route qui les atteint par le tunnel approuvé. Un profil qui s’installe proprement ne prouve rien tant que le domaine ne peut pas réellement être découvert depuis le client.

Vérifiez la découverte avant de vérifier les identifiants : les enregistrements SRV du domaine Kerberos doivent se résoudre, et les adresses qu’ils renvoient doivent être joignables une fois le VPN monté. Le temps compte autant que la joignabilité, car Kerberos rejette les requêtes d’une horloge qui a dérivé au-delà de sa tolérance, et l’erreur produite ressemble à un échec d’authentification. Un Mac qui ne peut pas joindre une source de temps pendant que le tunnel est coupé échouera de nouveau à l’instant où il revient. Corrigez la source de temps dans le cadre du déploiement, et non en réaction à un incident.

klist
sudo sntp -sS time.apple.com

Le VPN par application décide si l’extension peut fonctionner

Un tunnel complet achemine tout et masque ce problème. Une configuration par application n’achemine que les applications nommées dans le profil VPN, et l’extension SSO est elle-même un processus qui a besoin du réseau pour obtenir des tickets. Si elle n’est pas dans le mappage, la connexion locale réussit, le tunnel monte pour le navigateur et l’obtention des tickets échoue quand même.

Lisez la configuration du VPN et listez chaque application qu’il est censé couvrir, puis ajoutez le composant SSO via le mécanisme de mappage documenté plutôt qu’en devinant un identifiant de bundle. Mapper le client visible et non le composant derrière lui est la version classique de cette erreur. Gardez le mappage dans le même profil géré que l’extension, afin qu’un changement de l’un ne puisse pas invalider silencieusement l’autre. Testez avec un utilisateur qui ne s’est jamais connecté sur ce Mac, car un ticket en cache peut faire paraître sain un chemin cassé, puis testez de nouveau après un changement de mot de passe.

Une session d’identité dans le navigateur est un autre contrat

Une session de navigateur n’a pas de domaine Kerberos, pas de ticket de service et pas de tolérance d’horloge au sens de Kerberos. Elle a un émetteur, une durée de vie de jeton et un chemin de rafraîchissement, et ses modes de défaillance sont des redirections qui ne se terminent jamais et des cookies qu’une fenêtre privée rejette. La traiter comme un substitut du chemin des tickets n’est sûr que là où l’application elle-même accepte cet émetteur. Copier une réponse d’authentification du portail VPN vers un service sans rapport n’est pas de l’intégration, aussi pratique que le raccourci paraisse.

Lorsque les deux mécanismes sont déployés, documentez quelles applications utilisent lequel, car la conversation de support en dépend. Un utilisateur qui signale être connecté mais ne pas pouvoir ouvrir un partage de fichiers décrit deux systèmes, et la réponse est que le chemin des tickets ne s’est jamais exécuté. Un utilisateur qui peut ouvrir le partage mais pas le portail intranet décrit l’inverse, et nommer le mécanisme dans le ticket épargne une série de questions.

Parcourez la séquence, pas les pièces

Parcourez toute la chaîne avec un compte enrôlé ordinaire : connexion locale, tunnel, acquisition de tickets, puis une opération réelle contre un service. Répétez après la reconnexion du tunnel et après un changement de mot de passe délibéré, car chacun de ces cas exerce une partie différente de la logique de durée de vie. Que chaque étape réussisse isolément n’est pas la même chose que la chaîne qui fonctionne. La chaîne est ce que l’utilisateur vit, et c’est ce que le cas d’acceptation doit couvrir.

Consignez le propriétaire du profil, la méthode d’authentification VPN, le chemin de découverte du domaine et le mappage des applications de l’extension au même endroit. C’est cet enregistrement qui rend le flux reproductible par quelqu’un qui ne l’a pas construit. Vérifiez ensuite la défaillance que vous rencontrerez le plus probablement, un ticket expiré pendant que le tunnel est coupé, et confirmez que le client se rétablit sans redémarrage, car un déploiement qui ne fonctionne qu’à froid n’est pas terminé.

Notez aussi le propriétaire de chaque étape, car un domaine Kerberos que personne ne maintient devient obsolète. Une chaîne que personne ne peut décrire est une chaîne que personne ne peut déboguer.