ASA LDAP Group Mapping vs DAP for VPN Group Policy

Two separate records decide which group policy an AnyConnect session receives, and they live in different parts of the configuration with different failure modes. An LDAP attribute map translates a directory value into an ASA authorization attribute during authentication; a DAP record evaluates conditions afterwards and can add or override attributes. Both can end at the same policy name, so a login that works tells you nothing about which mechanism produced it. The point of comparing them is to pick one deliberately instead of letting the second quietly overrule the first.

Two mechanisms, two decision points

The choice comes down to three questions. Does the decision depend on a single directory attribute value, does it need more than that value, and which mechanism is allowed to win when both match?

If the only input is group membership, the attribute map is the smaller tool and the easier one to audit: one map, attached to one AAA server, with one line per group. If selection has to consider posture, endpoint identity, a second attribute or a time window, the map runs out of inputs and DAP is the mechanism that can express the rule. If both are in play, learn the precedence on your release before you write either one, because a session that matches a DAP record may not keep the policy the map returned. Everything else is bookkeeping.

The attribute map path, in config order

The map path starts at the AAA server definition. The attribute map has to be attached to the LDAP server entry that the connection profile actually uses; a map that exists in the running configuration but is not referenced by that server changes nothing. That attachment line is what makes the rest of the configuration live. The ASA LDAP mapping guide is the reference for the map syntax on 9.x releases.

Inside the map, one statement names the directory attribute and the ASA attribute it feeds, and further statements translate specific values. map-name memberOf Group-Policy followed by map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly is the shape: the left side is what the directory returned, the right side is the name of a group policy that must already exist. A distinguished name and a policy display name are not interchangeable, and a near miss in either string produces no error at login.

Two details bite here: memberOf returns every group the account belongs to, so a user in two mapped groups hands the map two candidate values, and the alphabetical rule in the guide is the only tie-break you can rely on rather than your own priority order. An unmapped value yields nothing at all, which silently falls back to the profile's default policy.

The DAP path, and what it adds

DAP evaluates conditions and applies attributes on top of the AAA result. A record carries a priority, an action and a set of conditions; records are evaluated in priority order and the action decides whether evaluation continues or stops. That is a different execution model from a value lookup, which is exactly why it can express rules the map cannot.

What DAP adds is inputs. Conditions can reference directory attributes, endpoint attributes and posture state, and a matching record can carry ACLs, URL lists or filters for that session. So a rule like support staff on a managed laptop getting the read-only policy while the same staff on an unmanaged device get a restricted one is expressible in DAP and not in an attribute map. The map has exactly one input: the value the directory returned for the attribute you named.

DAP also adds a second place to look when a session lands in the wrong policy. A record that matches with an action of continue does not end evaluation, and a later record can still change the outcome, so what you observe is the product of a sequence rather than a single lookup. Read the priority numbers in order, and remember that a fallback record may be the one doing the work. The map, by contrast, has no sequence: one attribute, one value, one answer.

Where the two disagree

Precedence is the part that breaks designs. When a session matches both a map entry and a DAP record, the result depends on the release and on the record action, so verify it on your own ASA instead of assuming either mechanism owns the outcome.

Three failure modes account for most of the confusion. A map that is defined but never attached to the server tag used by the profile produces the default policy with no error anywhere. A DAP condition string that differs from the directory value by case or whitespace never matches, and the fallback record quietly applies. And a group policy that does not exist yet is accepted by the map, because the map only returns a name, so the session gets none of the intended permissions with nothing in the log pointing at the missing object. Check all three before touching group membership.

Reading the evidence off a live session

Read the answer off a fresh session rather than off the configuration. show vpn-sessiondb detail anyconnect filter name jdoe prints the group policy the session actually received, and show running-config ldap attribute-map confirms which values the map could have returned. On the directory side, test aaa-server authentication LDAP-AD username jdoe password <password> shows the attributes the ASA got back, and debug ldap 255 shows the exchange when the test disagrees with what you expected.

Then reconcile four records in writing: the directory value, the configured map or DAP condition, the local group policy, and the resource the user could actually reach. If the first three line up and the fourth does not, the problem is in the policy body rather than in selection. If the session shows the right policy name but the wrong ACL, stop looking at LDAP entirely. Change one record at a time and re-check a new session, because a reconnected session is the only evidence that reflects the configuration you just wrote.