Can Authentication Proxy insert an attribute, not just 'pass thru'

Our scenario is we have network devices that we do DUO authentication for administrative access to the devices. This is generally accomplished via RADIUS by way of the DUO Authentication Proxy (DAP).

The simplest configuration is to configure DAP with a LDAP for primary authentication and a series of radius clients for our various devices.

This works great except for those devices that require the indication of an access level/role by way of a RADIUS-provided attribute (such as ‘priv=15’ or ‘role=sysadmin’). I can accomplish this when doing attribute pass-thru with RADIUS as the primary authentication but then I need to setup (in our Windows environment) NPS for RADIUS which is basically yet another proxy not unlike DAP itself. This creates another point of failure just to facilitate inserting the attribute required by network devices to assign the appropriate access.

What I perceive as being ideal is the ability to have DAP insert/inject these attributes directly by way of some additional attribute for each device/group of RADIUS clients (like an ‘insert_attribute_1’ and ‘insert_attribute_2’ corresponding to a ‘radius_ip_1’ and ‘radius_ip_2’ so each client/group can receive the response independently of others as each device requires).

Since there could be multiple attributes required, the value could perhaps be a delimited list (eg. insert_attribute=cisco-avpair= ”shell:priv-lvl=15“, cisco-avpair= ”shell:role=sysadmin“ ). I don’t have a complete understanding of all the possible options/variations on a RADIUS attribute so I’m not sure if this solution would work for all possible uses but I’m hoping smarter people could fill in gaps with relative ease.

Is there another way to accomplish getting these attributes communicated to RADIUS clients when using LDAP as the primary authentication that I’m missing?


Bueller… Bueller…

Would love to hear from someone at Duo on this topic.

I am someone at Duo!

No, you cannot configure the Duo Authentication Proxy to insert your own attributes. Also, the RADIUS pass-through options have no effect when primary authentication is LDAP (ad_client).

Our recommendation, as you observed, is to add VSAs at the upstream primary authenticating RADIUS server (deploying NPS is something we often suggest in this use case).

Feel free to contact your account exec, customer success manager, or Duo support to submit a feature request for the ability to define RADIUS attributes at the Duo Authentication proxy.

Thanks Kristina. So sounds like I am indeed correct on this. The question that remains is, how do I distinguish different clients on the upstream RADIUS server when all the requests to it are from the DUO Authentication Proxy? Without DAP, I’d identify different devices by their IP so I could then tailor the VSAs appropriately. I don’t see how I can do that in this situation.

Do you have any suggestions for this?

Thanks again.

Does your client application not return the IP address in calling-station-id? That information would get passed through intact (while the Duo Authentication Proxy sets itself as the nas-ip-address).