Update:
I was able to do a little more searching on what I wanted to achieve and although I did not find the specific answer here in the forum it did put me on the right track to finding it.
So here is how I resolved my issue.
I first found a post that mentioned the DAP debug trace command (debug DAP trace) that allowed me to see what was being passed to the DAP during the user login. Once I had the debug running, I could then see what was being passed to the DAP. I found that I was seeing radius entries, but nothing that corresponded to what is in any of the Cisco documentation.
Cisco's ASA built in Help docs say this when setting up AAA authentication checking for a DAP "
- RADIUS—The RADIUS client stores all native RADIUS response attribute value pairs in a database associated with the AAA session for the user. The RADIUS client writes the response attributes to the database in the order in which it receives them. It discards all subsequent attributes with that name. This scenario might occur when a user record and a group record are both read from the RADIUS server. The user record attributes are read first, and always have priority over group record attributes.
RADIUS attributes consist of an attribute number and attribute value pair in the DAP record. See Security Appliance Supported RADIUS Attributes and Values for a table that lists RADIUS attributes that the security appliance supports.
Note For RADIUS attributes, DAP defines the Attribute ID = 4096 + RADIUS ID.
For example:
The RADIUS attribute "Access Hours" has a Radius ID = 1, therefore DAP attribute value = 4096 + 1 = 4097.
The RADIUS attribute "Member Of" has a Radius ID = 146, therefore DAP attribute value = 4096 + 146 = 4242."
Well, this just does not work. What I was seeing was this:
DAP_TRACE: Username: rodtest, aaa.radius["7"]["1"] = 1
DAP_TRACE: Username: rodtest, aaa.radius["28"]["1"] = 3600
DAP_TRACE: Username: rodtest, aaa.radius["6"]["1"] = 2
DAP_TRACE: Username: rodtest, aaa.radius["27"]["1"] = 43200
DAP_TRACE: Username: rodtest, aaa.radius["25"]["1"] = F...
Where entry aaa.radius["28"]["1"] corresponded to a numeric descriptor for the "First Active Directory Group" in the user account's Group member list. Entry aaa.radius["27"]["1"] directly corresponds to the second group in the member group list as seen from an Active Directory user properties page. With this information I was able to define a DAP policy that would apply to the login based off of the group membership pulled from the radius. Now for what ever reason, the trace only shows the first two groups and from the user membership, no matter how many the account is a member of. So if you were wanting to do this with a "normal" user account which is typically a member of MANY groups, you would have to appropriately name your VPN access group so that it would be at the top of your user's group list. I am sure that the DAP is actually processing the rest of the group memberships as well, but since I am using the radius IDs that I pulled from the trace 28 & 27 (since I can not identify the rest), it does not matter. The only caveat is by using the radius ID in this manner the DAP association seems to be based of of the group membership order as much as the group association, it would not work well if your VPN access group was part of a normal user account in a list that could easily change by adding a group to the user account.
This configuration works for our environment due to the users having a VPN account that is seperate from their Domain login account.
Well, all for now,
Rod
