Strange Behavior during Token autoassignment


We are currently introducing PrivacyIdea for the 2fa. We would like to use the autoassign function to roll out the system. We are currently encountering strange problems.

To the Background:
Currently, we have integrated our VPN (Fortigate) and the Radius.
For the autoassigment we have enrolled some tokens (Yubikey) for testing in PrivacyIdea but have not assigned them to the users. The aim is for them to carry out this job themselves.

For that we have create 2 policies:
1.) scope: authentication

2.) scope: enrollment
autoassignment: userstore
max_active_token_per_user :1
max_token_per_user: 2
yubikey_max_active_token_per_user: 1
yubikey_max_token_per_user: 1

Currently, I don’t know why, but the assignment doesn’t always work. I also cannot determine what the problem is. But some users could assign their token and the login/authentication worked and others not.

  • The error message appears on the FortiClient: Incorrect user name or password
  • In PrivacyIdea the attempt cannot be found at all. I would have thought that at least PIN and OTP values should be separated here, but there are no logs (not in the audit log and not in the PrivacyIdea debug log).

Are we missing something? Where can I get more information about the error?

Thanks in Advanced

Unfortunately, a day of further research did not help me. The autoassignment works now and then.

Looking the the logs of Freeradius I found chap-request and chap-response. But we are using any Windows clients. If the autoassignment is successful then these chap entries are missing.

below the logs of a failed autoassigment authentication

(1) perl: $RAD_REQUEST{‘User-Name’} = &request:User-Name → ‘piamit3’
(1) perl: $RAD_REQUEST{‘Framed-IP-Address’} = &request:Framed-IP-Address → ‘’
(1) perl: $RAD_REQUEST{‘Calling-Station-Id’} = &request:Calling-Station-Id → ‘’
(1) perl: $RAD_REQUEST{‘NAS-Identifier’} = &request:NAS-Identifier → ‘THB’
(1) perl: $RAD_REQUEST{‘NAS-Port-Type’} = &request:NAS-Port-Type → ‘Virtual’
(1) perl: $RAD_REQUEST{‘Acct-Session-Id’} = &request:Acct-Session-Id → ‘44c2586c’
(1) perl: $RAD_REQUEST{‘Connect-Info’} = &request:Connect-Info → ‘vpn-ssl’
(1) perl: $RAD_REQUEST{‘Fortinet-Vdom-Name’} = &request:Fortinet-Vdom-Name → ‘root’
(1) perl: $RAD_REQUEST{‘MS-CHAP-Challenge’} = &request:MS-CHAP-Challenge → ‘0x7481e72f7d509b7df1acce8720d2c36d’
(1) perl: $RAD_REQUEST{‘MS-CHAP2-Response’} = &request:MS-CHAP2-Response → ‘0x2800e951995821de04c91a39badc7c07a44e00000000000000007cf6203c33e415b948b38eee61c0f5e3b1ece56a5829bf41’
(1) perl: $RAD_REQUEST{‘Packet-Src-IP-Address’} = &request:Packet-Src-IP-Address → ‘’
(1) perl: $RAD_CHECK{‘Auth-Type’} = &control:Auth-Type → ‘Perl’
(1) perl: $RAD_CONFIG{‘Auth-Type’} = &control:Auth-Type → ‘Perl’
rlm_perl: Config File /etc/privacyidea/rlm_perl.ini found!
rlm_perl: Debugging config: true
rlm_perl: Default URL https://localhost/validate/check
rlm_perl: Looking for config for auth-type Perl
rlm_perl: RAD_REQUEST: Packet-Src-IP-Address =
rlm_perl: RAD_REQUEST: NAS-Identifier = THB
rlm_perl: RAD_REQUEST: MS-CHAP2-Response = 0x2800e951995821de04c91a39badc7c07a44e00000000000000007cf6203c33e415b948b38eee61c0f5e3b1ece56a5829bf41
rlm_perl: RAD_REQUEST: Connect-Info = vpn-ssl
rlm_perl: RAD_REQUEST: User-Name = piamit3
rlm_perl: RAD_REQUEST: Framed-IP-Address =
rlm_perl: RAD_REQUEST: MS-CHAP-Challenge = 0x7481e72f7d509b7df1acce8720d2c36d
rlm_perl: RAD_REQUEST: Calling-Station-Id =
rlm_perl: RAD_REQUEST: NAS-Port-Type = Virtual
rlm_perl: RAD_REQUEST: Acct-Session-Id = 44c2586c
rlm_perl: RAD_REQUEST: Fortinet-Vdom-Name = root
rlm_perl: Setting client IP to

Another issue that I have found in the logs is, that the fortigate is sending multiple requests for 1 authentication.

Do we have a misconfiguration at out fortigate or need we more power for the privacy/freeradius system? Currently both application are running on a vm with 2 vCPU und 4GB Ram

The privacyIDEA FreeRADIUS Plugin does not support MS-CHAP.
So it looks like as if your “THB” is misconfigured.