Handle passwordless Authorize-Only coa-push requests in Radius Perl-module


first i want to thank you for this great 2FA system, it’s awesome.
But during implementation i realized the following Problem and have no idea to handle it.

We use cisco anyconnect on FTD managed by FMC for RA VPN.
The ftd sends 2 separate requests to the radius server, the first is a second authentication request (first goes to LDAP for regular User/Pass auth) which works fine with the perl module and authenticates against the users TOTP as well as Push Tokens.

(0) Sent Access-Accept Id 38 from to length 67
(0) Reply-Message = “privacyIDEA access granted”
(0) Class += 0x477270506f6c4d69746172626569746572
(0) Finished request

But then the FTD sends a second Access-Request to the Radius Server with the attributes:

Service-Type = Authorize-Only
Cisco-AVPair = “coa-push=true”
… and no Password.

The perl module rejects.

rlm_perl: urlparam pass =
rlm_perl: urlparam user = user1
rlm_perl: Content {“detail”: {“message”: “wrong otp value”…
rlm_perl: privacyIDEA Result status is true!
rlm_perl: privacyIDEA access denied for machauer realm=‘’
rlm_perl: return RLM_MODULE_REJECT

As a workaround i did:

if (&request:Service-Type == “Authorize-Only”) {
update control {
Auth-Type := Accept
# Auth-Type := Perl
if (&request:ASA-TunnelGroupName == “ConnProfilexxx”) {
update {
reply:Class := “GrpPolxxx”

to bypass the perl module, Accept and send back a VPN-Policygroup.
This works.

The problem with this solution is, i need to hardcode the Class Attribute in the Radius configuration and can’t use the [Attribute Class] mapping feature from privacy idea for the requesting user.

Any idea how i could solve this with Privacyidea or is the only way a separate radius ldap connection via the freeradius-ldap module?

Thank you for your help.


Hello @Patrick_Machauer

welcome to privacyIDEA.

This in fact is an interesting question.

What is the 2nd request there for? What is it supposed to do?

Service-Type = Authorize-Only
Cisco-AVPair = “coa-push=true”

I would also have recommended to take a look at unlang as you did.
So obviously it is mento to provide a Class Attribute for authorization purposes.

There is no way to handle such second request with privacyIDEA, since privacyIDEA handles authentication requests and can somehow do a bit of authorization in it, but privacyIDEA can not handle requests that are solely authorization.

To me this looks like an unusual way of using RADIUS by the RADIUS client(VPN).

Here is another idea you might try without any knowledge of your VPN. You could try to already return the Class Attribute directly in the response to the first request. Maybe the VPN is happy with that and will not need ot issue a 2nd request anymore.

Hm, but wait, you did, right?

Which is GrpPolMitarbeiter. Strange that the VPN does not use this response and asks a 2nd time.


Hello @cornelinux ,

yes. I already send a reply with the Class Attribute via privacyIDeas Attribute Mapping as an Answer to the Authentication request but the NAS doesn’t seem to care. It separates the Authentication from Authorization and asks for an update via the coa-push Authorize-Only request. In the configuration dialog you can use separate sources for Authentication and Authorization. I guess that’s the reason why they handle it in two requests. Otherwise the Authentication Server would always do the Authorization even if it’s unintended.


I guess Cisco wants me to use ISE and Duo.


OK, I understand.
However, it is not the intention of privacyIDEA as mentioned to do sole authorization.

Can you leave the “Authorization Server” empty?

As you already worked-around of course it is the purpose of FreeRADIUS to handle the authorization. And FreeRADIUS might need to get this information from somewhere.

privacyIDEA can currently not easily provide this.
But maybe you can fetch this information from LDAP direcly by using rlm_ldap in some way?

Just out of curiosity:

Does the first request contain

Service-Type == "Authenticate Only"

?? Since the NAS is ignoring the Authorization information.


No, the first doesn’t contain any kind of Service-Type request attribute.

But both requests contain the same attribute Cisco-AVPair = “audit-session-id=”. I guess that’s the link between the Authentication and the Authorization request.

Regards Patrick

As mentioned, currently privacyIDEA does not have a way to check for authorization.
This could maybe be done by evil policy tweaking.

HOwever, we plan such things in the future: