we are using privacyidea to offer 2FA for the VPN-Service. In our configuration, users are authenticated againt ActiveDirectory and have to manage their own Tokens on the PrivacyIdea self-service-portal. Every thing is working fine when the user has no Token and also when the user has an activated token. But if the user disables his own token on the self-service-portal, he is unable to authenticate anymore the VPN-Service. The Access is rejected and the radius answer contains the following “no active challenge reponse token found”.
Deleting the token makes the Authentication possible again.
Why does the disabling of the token not have the same effect as deleting it?
I would expect that the authentication succeeds against the ActiveDirectory also when the token is deactivated.
Thank you in advance and best regards
I assume you are using a passthru policy? You missed this one.
Thank you for your otherwise detailed description. But everyting is fine, works as designed and as documented. You should adapt your expectations to the documentation:
thank you for the quick reply.
I am really using a passthru policy and I set the passthru action to “userstore”. That means, if the user does not have an assigned token, he will be authenticated against the configured radius-server.
My test case is a little bit different since the user has an assigned token, but this token is disabled. In this case the Authentication fails with the mentioned error.
Sure I missed something, but unfortunately I can’t see it yet…
Thank you for your support
No, against the userstore. - not the radius server.
If the user does NOT have a token ASSIGNED. Also a disabled token is an assigned token. It is still assigned to the user. Sry. Everything works like documented and highly logically.
sure against the userstore…in my configuration I defined an LDAP-Resolver (ActiveDirectory) where the user credentials are stored.
OK, even a disabled token remains an assaigned token…makes sense.
I thought that disabling the token has the same effect as deleting it…but it seems not to be the case.
Thanks again for the reply.