Release privacyIDEA 3.7.2

News
1

Hello community,

we release today a patch release of privacyIDEA

You can find the complete changelog at Github

Thank you for using privacyIDEA

1 Like
2

Hi there,

It seems that passthru got broken on 3.7.2
On 3.7.1, I had a working policy with with passthru that’s not working anymore in 3.7.2.
I always received the message " The user as no token assigned", but the police has exactly that purpose, for users with no token.

tkx

3

Thank you for reaching out.
I can not confirm, that passthru is broken. It basically works as expected.

However, user comparison has changed (see privacyidea/Changelog at master · privacyidea/privacyidea · GitHub). So it might be that you have a rare scenario where you have two users, that previously looked like on object, but are no recognized as two different user objects. And maybe your policy has certain conditions, that do not match anymore.

4

The Policy is very simple… the user from certain “User-Resolver” will always be passthru, there’s nothing else in the Policy. If for instance I change the the “Action” from passthru to passOnNoToken, I can see in the audit that the user match the Policy and go through, with passthru option, in the audit the user does not even match the Policy.

5

Do you mind to share it? The Policy?

Also: You might want to take a look at your privacyidea.log in debug level and observe which user objects are identified. The log output will also contain information about user comparison (which is the only relevant code, that was changed)

6

Sorry, my bad… The test user password changed and I was always insisting in the old one. The error message “The user as no token assigned” took me to the wrong conclusions. After a coffee brake, everything got cleared. PASSTHRU works like a charm. Tkx

7

Thanks a lot for sharing this clarification.

So the first thing that happens is, that privacyIDEA realizes, “that the user has no tokens assigned”.
It then tries, if passthru would be possible, while it is not (with wrong credentials)
So it sticks with the initial error message, which was misleading it this case.

Interesting enough we only add the passthru policy to the audit log, if passthru was successful.
Which is misleading in this case. I think the idea behind this was, that in case of a wrong password “passthru” did not happen, so we did not add it.
I need to check with the behaviour in other cases.