Mappage des groupes LDAP dans ASA face à DAP pour la stratégie de groupe VPN

Deux enregistrements distincts décident quelle stratégie de groupe une session AnyConnect reçoit, et ils vivent à des endroits différents de la configuration avec des modes de défaillance différents. Une table d'attributs LDAP traduit une valeur de l'annuaire en attribut d'autorisation ASA pendant l'authentification ; un enregistrement DAP évalue ensuite des conditions et peut ajouter ou remplacer des attributs. Les deux peuvent aboutir au même nom de stratégie, donc une connexion qui fonctionne ne vous dit rien du mécanisme qui l'a produite. L'intérêt de les comparer est d'en choisir un délibérément au lieu de laisser le second supplanter silencieusement le premier.

Deux mécanismes, deux points de décision

Le choix se résume à trois questions. La décision dépend-elle d'une seule valeur d'attribut de l'annuaire, a-t-elle besoin de plus que cette valeur, et quel mécanisme est autorisé à l'emporter quand les deux correspondent ?

Si la seule entrée est l'appartenance à un groupe, la table d'attributs est l'outil le plus petit et le plus facile à auditer : une table, rattachée à un serveur AAA, avec une ligne par groupe. Si la sélection doit tenir compte de la posture, de l'identité du point de terminaison, d'un second attribut ou d'une fenêtre temporelle, la table manque d'entrées et DAP est le mécanisme capable d'exprimer la règle. Si les deux sont en jeu, apprenez la précédence de votre version avant d'écrire l'un ou l'autre, car une session qui correspond à un enregistrement DAP peut ne pas conserver la stratégie renvoyée par la table. Tout le reste est de la comptabilité.

Le chemin de la table d'attributs, dans l'ordre de configuration

Le chemin de la table commence à la définition du serveur AAA. La table d'attributs doit être rattachée à l'entrée de serveur LDAP que le profil de connexion utilise réellement ; une table qui existe dans la configuration en cours mais n'est pas référencée par ce serveur ne change rien. C'est cette ligne de rattachement qui rend le reste de la configuration actif. Le guide de mappage LDAP d'ASA est la référence pour la syntaxe de la table dans les versions 9.x.

À l'intérieur de la table, une instruction nomme l'attribut de l'annuaire et l'attribut ASA qu'il alimente, et d'autres instructions traduisent des valeurs précises. map-name memberOf Group-Policy suivi de map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly en est la forme : la partie gauche est ce que l'annuaire a renvoyé, la partie droite est le nom d'une stratégie de groupe qui doit déjà exister. Un nom distinctif et un nom d'affichage de stratégie ne sont pas interchangeables, et une quasi-correspondance dans l'une ou l'autre chaîne ne produit aucune erreur à la connexion.

Deux détails mordent ici : memberOf renvoie chaque groupe auquel le compte appartient, donc un utilisateur membre de deux groupes mappés donne à la table deux valeurs candidates, et la règle alphabétique du guide est le seul départage sur lequel vous pouvez compter plutôt que votre propre ordre de priorité. Une valeur non mappée ne donne rien, ce qui retombe silencieusement sur la stratégie par défaut du profil.

Le chemin DAP, et ce qu'il ajoute

DAP évalue des conditions et applique des attributs par-dessus le résultat AAA. Un enregistrement porte une priorité, une action et un ensemble de conditions ; les enregistrements sont évalués par ordre de priorité et l'action décide si l'évaluation continue ou s'arrête. C'est un modèle d'exécution différent de celui d'une recherche de valeur, et c'est précisément pourquoi il peut exprimer des règles que la table ne peut pas.

Ce que DAP ajoute, ce sont des entrées. Les conditions peuvent référencer des attributs de l'annuaire, des attributs du point de terminaison et l'état de posture, et un enregistrement correspondant peut porter des ACL, des listes d'URL ou des filtres pour cette session. Ainsi, une règle telle que le personnel de support sur un portable géré recevant la stratégie en lecture seule tandis que ce même personnel sur un appareil non géré en reçoit une restreinte est exprimable en DAP et non dans une table d'attributs. La table a exactement une entrée : la valeur que l'annuaire a renvoyée pour l'attribut que vous avez nommé.

DAP ajoute aussi un second endroit où regarder quand une session aboutit à la mauvaise stratégie. Un enregistrement qui correspond avec une action de continuer ne termine pas l'évaluation, et un enregistrement ultérieur peut encore changer le résultat, donc ce que vous observez est le produit d'une séquence plutôt que d'une seule recherche. Lisez les numéros de priorité dans l'ordre, et rappelez-vous que l'enregistrement de secours peut être celui qui fait le travail. La table, en revanche, n'a pas de séquence : un attribut, une valeur, une réponse.

Là où les deux divergent

La précédence est la partie qui casse les conceptions. Quand une session correspond à la fois à une entrée de la table et à un enregistrement DAP, le résultat dépend de la version et de l'action de l'enregistrement, alors vérifiez-le sur votre propre ASA au lieu de supposer qu'un des mécanismes possède le résultat.

Trois modes de défaillance expliquent l'essentiel de la confusion. Une table définie mais jamais rattachée à l'étiquette de serveur qu'utilise le profil produit la stratégie par défaut sans aucune erreur nulle part. Une chaîne de condition DAP qui diffère de la valeur de l'annuaire par la casse ou les espaces ne correspond jamais, et l'enregistrement de secours s'applique silencieusement. Et une stratégie de groupe qui n'existe pas encore est acceptée par la table, car la table ne renvoie qu'un nom, donc la session n'obtient aucune des permissions prévues et rien dans le journal ne pointe vers l'objet manquant. Vérifiez les trois avant de toucher à l'appartenance aux groupes.

Lire les preuves sur une session active

Lisez la réponse sur une session neuve plutôt que sur la configuration. show vpn-sessiondb detail anyconnect filter name jdoe imprime la stratégie de groupe que la session a réellement reçue, et show running-config ldap attribute-map confirme quelles valeurs la table aurait pu renvoyer. Côté annuaire, test aaa-server authentication LDAP-AD username jdoe password <password> montre les attributs que l'ASA a reçus en retour, et debug ldap 255 montre l'échange quand le test ne correspond pas à ce que vous attendiez.

Réconciliez ensuite quatre enregistrements par écrit : la valeur de l'annuaire, la table ou la condition DAP configurée, la stratégie de groupe locale et la ressource à laquelle l'utilisateur a réellement pu accéder. Si les trois premiers concordent et pas le quatrième, le problème est dans le corps de la stratégie et non dans la sélection. Si la session affiche le bon nom de stratégie mais la mauvaise ACL, cessez complètement de regarder LDAP. Changez un enregistrement à la fois et revérifiez une nouvelle session, car une session reconnectée est la seule preuve qui reflète la configuration que vous venez d'écrire.