NetExtender se connecte mais aucun accès : SonicWall local + LDAP

La connexion réussit, le tunnel monte, et rien derrière le pare-feu ne répond. Ce schéma sur un SonicWall SSL VPN signifie généralement que le compte a passé l'authentification et s'est arrêté à l'une des deux autorisations ultérieures : l'admission au service SSL VPN, ou l'autorisation d'atteindre une ressource. Des comptes locaux et LDAP mélangés aggravent la situation, car les deux magasins atteignent ces autorisations par des chemins différents. Le symptôme est identique côté client, et c'est pourquoi les couches doivent être séparées délibérément.

Le symptôme et les trois autorisations derrière

Trois décisions indépendantes séparent un nom d'utilisateur d'un serveur joignable. La méthode d'authentification décide si l'identifiant est accepté et par quel magasin. L'appartenance au service SSL VPN décide si cette identité peut utiliser le SSL VPN tout court. La liste d'accès VPN décide quelles destinations privées la session peut atteindre. En passer une ne dit rien des deux suivantes.

Un utilisateur qui s'authentifie mais n'est pas dans le groupe du service SSL VPN voit une connexion qui s'établit puis ne transporte rien, et le journal du pare-feu montre une connexion acceptée plutôt qu'un échec. C'est le cas qu'il vaut la peine de reconnaître vite, car le correctif est une appartenance à un groupe, pas une réinitialisation de mot de passe.

Un utilisateur admis mais sans ressources voit une session qui se connecte et ne route nulle part utile. Les deux ressemblent à un tunnel cassé depuis le support, et les deux relèvent de la configuration, pas de la connectivité.

Le champ de domaine n'est pas l'annuaire

NetExtender demande un domaine, et ce champ n'est pas une base de recherche pour Active Directory. Dans la disposition par défaut, le champ doit être égal au domaine utilisateur SSL VPN configuré sur le pare-feu, et la valeur par défaut documentée est LocalDomain. La comparaison est sensible à la casse, donc une valeur saisie avec une casse différente échoue même lorsque le compte est correct.

Lorsque le partitionnement d'authentification est configuré, les noms de partition sélectionnent le contexte d'authentification externe à la place, et la valeur par défaut configurée conserve son propre rôle. Dans les deux dispositions, l'étiquette de domaine côté client n'est pas transmise à LDAP ou RADIUS comme partie du nom d'utilisateur, elle ne peut donc pas orienter une recherche d'annuaire.

Gardez les trois chaînes séparées dans vos notes : le suffixe DNS de l'entreprise, la base de recherche LDAP et l'étiquette de domaine NetExtender. Elles se ressemblent et aucune ne remplace l'autre. Copiez la valeur de l'exploitant pour cette installation plutôt qu'une valeur tirée d'un message de forum sur une autre version de firmware.

L'admission et l'accès aux ressources sont des autorisations distinctes

Les comptes locaux doivent appartenir au groupe du service SSL VPN avant que le service ne les accepte. Les comptes d'annuaire atteignent le même groupe via le flux de travail de mappage de groupes pris en charge, ce qui signifie que la relation de groupe LDAP doit être configurée puis vérifiée comme une appartenance effective plutôt que supposée côté annuaire.

L'accès aux ressources vient ensuite, sous Accès VPN sur l'utilisateur ou le groupe. Accordez les sous-réseaux et services précis dont le rôle a besoin, et résistez au raccourci d'accorder tout le LAN parce qu'une application est nécessaire. Les routes de la session, les règles d'accès et les permissions du service de destination doivent tous s'accorder avec cette portée.

Une route sur le client rend une destination sélectionnable et ne l'autorise pas. L'appartenance au groupe SSL VPN ne fait pas non plus du compte un administrateur du pare-feu, et elle ne doit pas être traitée comme une attribution générale de privilèges.

Deux identités, quatre contrôles chacune

Testez avec un compte local et un compte d'annuaire, tous deux étroitement autorisés et tous deux documentés comme comptes de test. Pour chacun, consignez la source d'authentification qui a accepté la connexion, les groupes effectifs, l'accès aux ressources attribué et une opération applicative autorisée. Quatre contrôles, deux magasins et un résultat écrit pour chaque combinaison.

Testez ensuite les cas négatifs : une ressource que le compte ne doit pas atteindre, et un compte qui doit être rejeté d'emblée. Une conception qui ne prouve que le chemin positif a tendance à laisser une seconde entrée ouverte, surtout lorsque le même nom d'utilisateur court existe dans les deux magasins. Désactivez le compte d'annuaire et confirmez que le local ne continue pas de fonctionner en silence.

Examinez les noms en double dans le cadre du déploiement plutôt qu'après un incident. La même personne dans deux magasins est à la fois une commodité pour le support et un problème d'audit, et le pare-feu authentifiera volontiers celui que vous avez configuré.

Gardez le chemin de récupération étroit

Conservez la politique MFA pour chaque classe de compte au lieu d'en exempter les comptes locaux. Si les comptes locaux offrent un chemin de récupération approuvé pour une panne d'annuaire, limitez ce chemin à des administrateurs nommés et exploitez-le délibérément, car un compte d'urgence local pour chaque employé est un second système d'authentification moins surveillé.

Écrivez le domaine du client, la source d'authentification et l'accès effectif dans le même enregistrement. L'administrateur suivant pourra alors reproduire une conception de comptes mixtes qui fonctionne au lieu d'essayer des chaînes de domaine jusqu'à ce qu'une connexion réussisse.