Anyconnect VPN authen fail

I installed PrivacyIDEA + Radius following https://www.privacyidea.org/two-factor-authentication-with-otp-on-centos-7/ . Everything almost done, WebUi, Radius…, I used FreeRADIUS-master to test radius work ok.
But after config VPN on cisco firepower, i use Anyconnect tool to connect and it is fail to authen.

Check log on Privacy :" wrong otp pin" , even i still can not login by user.

1
2
3
4

Anyone can help me, thanks !

Test by Radius tool, get error wrong OTP while i dont see any screen OTP show up
1

The PIN value goes in front of the OTP value.
Combined they constitute the password…

1 Like

I need to login by user then have screen OTP show up for pin. How we do it ?

I dont want use pin code, only password and OTP, so can we do it ?

Once again: the password is the PIN and OTP…

When assigning an OTP to a user, you can add a PIN that goes in front of the OTP value.
If you don’t want to use PINs, leave it empty (that’s a bad idea).
In this case the password will be the OTP value only…

The message in your post above - wrong otp pin - means assignment and usage of the PIN was screwed up…

I know, but even when i use pin code too fail to login. And i want to ask more, why dont we use password of user ldap, then OTP instead of PIN ,

The LDAP brings users to PI, not passwords.
The purpose of PI is to add an additional layer of security - one time password (TOTP in your case).
What is the point in using LDAP credentials - username and password - when logging into PI?

1 Like

Username sure, but i mean when use VPN, the fist authen by User & Password Ldap instead of User & PIN then 2nd authen is OTP. Anyway in Policy i seen option otppin (Either use the Token PIN , use the Userstore Password or use no fixed password component.) but it can not work or how it work ?

The policy otppin=userstore is probably exactly what you want. But given your sparse information noone can tell, why it does not “work out”.

If the token is assigned to a user found in LDAP, the LDAP password is required with the OTP.
So if you are only authenticating against RADIUS and the user hans had the LDAP password secret and the the token would generate the OTP value 123456, the user would have to login like that:

Username: hans
Password: secret1243456

The LDAP password takes the function of the PIN. Note, that even when using the token pin, the “pin” can be a “password” (i.e. not only numbers)

Read these:
https://privacyidea.readthedocs.io/en/latest/policies/authentication.html#otppin
https://privacyidea.readthedocs.io/en/latest/configuration/authentication_modes.html
https://privacyidea.readthedocs.io/en/latest/configuration/system_config.html#prepend-pin

Ok i almost completed it. Thanks for help guys.

Presumably, AnyConnect has been working all along with an LDAP AAA server and attribute map? This is what validates the initial username & password. (Note that these same exact LDAP parameters should be used to define the PI Realm.)

On top of that, a RADIUS-based AAA server should be defined, pointing to the FreeRADIUS plugin and using otppin=tokenpin. The AnyConnect login policy is then extended with a secondary authenticator, which expects the original username and the OTP value:

secondary-authentication-server-group PrivacyIDEA use-primary-username

If the user is assigned an OTP token with a PIN, then for the secondary AnyConnect prompt the user would enter <pin><token>. If the OTP was configured without a PIN, then the user would just use <otp> in the 2nd password field.

It was helpful for us to use passthru=userstore for initial onboarding, allowing the user without an assigned token to login with their password (entered twice). Once everyone had their tokens, passthru was disabled.

1 Like

thank you so much @bhoule

I’m new and can’t get anyconnect to authenticate on the freeradius server–can you help me understand when the otppin=tokenpin config needs to take place?

on my vpn logs, I receive error [AAA unable to complete the request Error : reason = Invalid response received from server : user = r***]

testing the freeradius server using ntradping returns the expected response Access-Accept with a reply message of privacyIDEA access granted

Is the VPN server allowed (whitelisted) to talk to the PI server?

Henry–yes they were able to communicate. ACL wasn’t a problem for me as the PrivacyIDEA server was located on the same inside interface as the Cisco FTD. Our issue actually came from a “password-management” option that was selected on the firewall. The PI server would send the access-accept message back to the firewall, but the firewall was looking for additional password attributes that the PI server wasn’t handing out.

On our main radius server (MS NPS connected to our MS AD), the app automatically detects the authentication method so enabling password-management on the FTD (the default setting) wasn’t an issue. We are using PI as the secondary radius server, so I assume that removing the password-management option disables MS-CHAPv2 on the FTD. This is important as it’s my understanding that privacyidea doesn’t support MS-CHAPv2.

that is correct, we need the plaintext password to correctly split the OTP from the PIN. See also:

I’ve never run into those issues.
But we use PI with Cisco ASA and there PAP is the default (I understand).

Also, we most of the time keep the PI server behind the ASA (secure subnet).
This prevents us from using Firebase push, but is sniffing-proof…