Authentication policy matching incorrect realm

privacyidea-apache2 3.0.2-2 Ubuntu 18.04

I have two realms set up, “domain” and “domain-2fonly”. There is a separate authentication policy applied to each realm. All TOTP tokens are assigned to both realms.

Priority: 1, Policy: domain, Scope: authentication, Action: { "otppin": "userstore"}, Realm: domain, User:[], Resolver: ["ActiveDirectory"], Client, []
Priority: 1, Policy: domain-2fonly, Scope: authentication, Action: { "otppin": "none"}, Realm: domain-2fonly, User:[], Resolver: ["ActiveDirectory"], Client, []

I am having an issue when trying to authenticate as a user from “domain-2fonly”, with just the token as the password, I can see in the audit logs it is matching on the “domain” policy and getting denied because the password format is not correct. Even if I give the “domain-2fonly” a lower priority number the “domain” policy still applies first.

5754     2019-08-20 15:27:46     POST /validate/check     0 aross domain-2fonly    ActiveDirectory     password_and_totp     ::1     wrong otp pin
5753     2019-08-20 15:27:04     POST /validate/check     1 aross domain             ActiveDirectory     password_and_totp     ::1 matching 1 tokens

Is this the expected behavior? I would have expected that because the realm on each policy are different, one would not apply apply to another.

The policy logic works a bit different. It is not exclusive and it is not firewall rules where the first matching rule wins and processing is stop.

Rather it is an addative logic where all matching policies are collected. In your case, if tokens are in both realms, both policy match. The ordering is only for contradicting policies.

Then the authentication policies are not checked in regards to to which realm a token is assigned, but in which realm a user authenticates. So if a user in realm “domain” authenticates this realm will be always used to match the policy.

So if I understood your setup correctly this is the expected behaviour.

But what do you want to achieve?

Yeah, it doesn’t seem like that is going to work for what I am trying to achieve.
I want a way to authenticate the same token in different ways depending on how the security device handles MFA tokens. For one device I want to send the users password appended with the OTP token, and for another device, just the OTP token without the password.

This is all on top of freeradius. So the source will always appear to be localhost.

What do you mean with “device”? You mean the computer, the client, where a user would authenticate?

This you would solve by using the client IP in the policies. The freeradius plugin forwards the IP of the RADIUS client.
Check this out: https://privacyidea.readthedocs.io/en/latest/configuration/system_config.html#override-authorization-client
(After all this is professional software :wink:

Sorry, by device I mean security appliance, what the user is authenticating to.
eg. Firewall1 doesn’t have any implementation for MFA so users have to send password+otp, while Firewall2 does understand MFA, so it prompts the user separately for password and the otp token and authenticates each separately.

Thanks for the quick reply. The setting the client IP seems to have got it working how I wanted.

1 Like