Additional conditions seems not to be working

Question
1

(privacyIDEA 3.6.3 on Ubuntu 20.04)
Hi all, I’m a newbie In Privacyidea, but I eventually made up to put all working fine.
On my setup PrivacyIdea is integrated with a freeradius to authenticate Cisco Routers and the Active Directory as IDP. I have a authentication policy that make push tokens to work and an authorization policy that send the privilege level back to the Radius server and then to the Router.
Up to here all is good, now I would like to limit (authentication policy) the access only for users belonging to certain AD groups (memberOf). I’ve follow the PrivacyIdea example in here 7.9. Policy conditions — privacyIDEA 3.6.2 documentation , but for authentication policy instead of webui policy and I can see that PrivacyIdea sees the users belonging to the group but the mach never happens. I’ve also try it to do it to the webui policy, exactly as in the example, but still not working. Is there a matching problem in the Policies Additional Conditions?

I got this when tailing privacyidea.log:

[2022-03-01 11:43:06,477][8012][140403842049792][INFO][privacyidea.lib.user:236] user 'su6900093' found in resolver 'axians.dc'
[2022-03-01 11:43:06,477][8012][140403842049792][INFO][privacyidea.lib.user:238] userid resolved to '2e5e096c-b152-480f-bc9e-665bfd26c292'
[2022-03-01 11:43:06,483][8012][140403842049792][ERROR][privacyidea.lib.policy:922] Policy 'webui' has condition on userinfo, but the according object is not available - possible programming error   File "/opt/privacyidea/lib/python3.8/site-packages/flask/app.py", line 2464, in __call__
    return self.wsgi_app(environ, start_response)
  File "/opt/privacyidea/lib/python3.8/site-packages/flask/app.py", line 2447, in wsgi_app
    response = self.full_dispatch_request()
  File "/opt/privacyidea/lib/python3.8/site-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/opt/privacyidea/lib/python3.8/site-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/api/lib/prepolicy.py", line 154, in policy_wrapper
    return wrapped_function(*args, **kwds)
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/api/lib/prepolicy.py", line 154, in policy_wrapper
    return wrapped_function(*args, **kwds)
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/api/lib/prepolicy.py", line 154, in policy_wrapper
    return wrapped_function(*args, **kwds)
  [Previous line repeated 1 more time]
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/api/lib/postpolicy.py", line 109, in policy_wrapper
    return self.function(self.request, response, *args, **kwds)
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/api/lib/postpolicy.py", line 526, in get_webui_settings
    hide_welcome = Match.generic(g, scope=SCOPE.WEBUI, action=ACTION.HIDE_WELCOME,
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/lib/policy.py", line 2580, in any
    return bool(self.policies(write_to_audit_log=write_to_audit_log))
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/lib/policy.py", line 2569, in policies
    return self._g.policy_object.match_policies(audit_data=audit_data, request_headers=request_headers,
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/lib/log.py", line 155, in log_wrapper
    return func(*args, **kwds)
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/lib/policy.py", line 750, in match_policies
    reduced_policies = self.filter_policies_by_conditions(reduced_policies, user_object, request_headers,
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/lib/policy.py", line 785, in filter_policies_by_conditions
    if not self._policy_matches_info_condition(policy, key, comparator, value,
  File "/opt/privacyidea/lib/python3.8/site-packages/privacyidea/lib/policy.py", line 924, in _policy_matches_info_condition
    u"{!s}.".format(policy['name'], type, ''.join(traceback.format_stack()))
2

Did someone had a similar problem with the matching rules in the Policy conditions on PI3.6.3, or am I doing something wrong. I 'm just trying to compare userinfo “groups” (memberOf) with the AD group “cn=admin,cn=groups,dc=domain”.

Regards.

3

Your group is obviously a multivalue attribute.
I.e. this is a list.

I think you need to use the comparator contains (See 7.9. Policy conditions — privacyIDEA 3.6.2 documentation)

But if you do not post your configuration, your policy with the condition and the resolver configuration it is all poking in the dark.

Please read Is privacyIDEA an open source or a commercial solution

4

Hi Cornelinux, thanks for the feedback.
Fair enough, let me share the configuration

In the LDAP resolver I’ve the following:

image

If I go to the Users, I can see that PI was able to fetch this AD field:

image

In the authentication Policy I’ve the following:

image

And that’s it. Am I missing something?

RG

5

Hi Cornelinux, I’ve just read the Is privacyIDEA an open source or a commercial solution and I full agree with the vision posted there.

I understand that OpenSource has to do with sharing (to share code, applications, ideas, solutions, problems …) and Free/Commercial is related with business which provides SLA’s, responsibility, Costs money …

Having said that and after re-reading my first post, I just felt that it fitted exactly in what you describe that should not be expected from each and every one of us.

In this case I can assure you that I didn’t spend half an hour looking for the problem. Since I’m new to PI (as for anything else I’m new to) I always assume that I’m doing something wrong and I did spend some hours looking for the documentation, googling and working on different ways to achieve my goals.

Besides, I fully agree with the bottom line of what you mean on your post, please understand that posts like “I get this error messages … What am I doing wrong?” or “The system responds with… Is this a bug?”, might also be the result of many frustrating hours looking for a solutions.

Thanks, and by the way, up to now and as far I could work on it, PI seems to be a very well design platform that makes more and more sense in the current days.

6

The extended condition looks correct to me.

However, the question is, if the policy matches at all in your request.
I.e. if there is a user with the value.

Note! The user extended conditions refer to a user on whom it is acted.
It does not refer to an administrator!

PS: This is ment when the documentation says “the handled user”. 7.9. Policy conditions — privacyIDEA 3.6.2 documentation

7

I don’t know if I fully understood your question, nevertheless the user I’m using to test the login on the device (router) is definitely not the same as the PI admin user.

We have the PI users, that are something from inside PI (superusers I believe) which are created by the command “sudo pi-manage admin add …"

We have also the users that come from the resolver, in this case is an LDAP/AD user, and the user I’m using for testing belongs to this realm.

The steps I’ve done, were following:

  • I created the user “test_user” in the AD
  • I created the group “test_group” in de AD
  • I made test_user member of test_group in the AD
  • I created the resolver in PI for this AD
  • In this resolver in the attributes mapping, I mapped “groups” with “memberOf” (and sure is a multivalue)
  • If I go to the USERS Tab I can see the user there and I can also see that the field “groups” is mapped and got the correct multivalue from the AD (as you can see in the screenshot of previous post)
  • Then I add a Push Token to this user;
  • And then lets test:
    • No Additional condition added on Authentication policy
      • Username – check
      • Password – check
      • Received Notification on PI APP – check
      • Doing “Accept” – check
      • privacyIDEA access granted – as expected
    • Additional condition added on Authentication policy (a condition that not match with the user. Basically I select “ not (!)contain the group test_group ”
      • Username – check
      • Password – check
      • Received Notification on PI APP – not check
      • Wrong OTP PIN – as expected (if the authentication policy do not match the user, there is no other authentication policy to match)
    • Additional condition added on Authentication policy (a condition that should match with the user. Basically I select “ contain the group test_group ”
      • Username – check
      • Password – check
      • Received Notification on PI APP – not check
      • privacyIDEA request failed: 500 read timeout – not expected.

I hope I could detailed enough the use case.

RG

8

Hi all,

Since Additional conditions in Policies are not working (at least I cannot make them to work), no matter what, I always received the error which I don’t know where to start looking for “Policy ‘xxxx’ has condition on userinfo, but an according object is not available”.
One workaround I tried to implement with success, is to create a new LdapResolver with search-filter to filter users from specific AD group, then create a Realm for that Resolver and finally create a Policy that applies to that Realm. Although this works it is not scalable and it makes no sense to replicate as many Resolvers and Realms, as groups we want to look for in the same LDAP server and apply a policy to, nevertheless is workaround that might be applied in some cases.

Thanks

9

The challenge with privacyIDEA is that it does not implement hidden logic. This is great, since it means flexibility, but the side effect is, that you logially need to understand what you are doing.

The error you get “Polilcy… has condition on userinfo but no user in request”, means what it says.

You need to look closely at the request, where this error occurs. Maybe in the audit log.
Then you will realize, that there is a request, where not user object is contained.
In the policy with the extended condition you most probably have an action, that is applied on this request.
Like your policy contains a user group, but it also containes the action “delete token”, and you are deleting the token by a serial number. Then this request, does not contain a user object.

You have to remove these disturbing actions from your policy.

10

Hi Cornelinux, I’m felling really dumb and I’m pretty sure I’m missing some detail, but let’s look for a supposedly strait forward example where I get the same error.

I’ve created a WEBUI policy, I choose no User-Realm or User-Resolver (which make that this policy fits on every user) and then applied the following “Additional conditions”:

(Active) check – (Section) userinfo – (Key) group – (Comparator) contains – (Value) CN=Admins,OU=Groups,DC=domain,DC=net

The key “group” : “memberOf” is mapped in the resolver “Attributes mapping” and “group” is also in “Multivalue Attributes”.

In “Users” Tab I can see that “group” is correctly mapped and contains all the AD groups that one user is member of.

This recipe seems very strait forward (by the way is exactly what is documented in PI documentation) and I cannot see anything in the audit logs that might help identifying the problem.

Thanks

11

ACTION! Which ACTION!!!

The action defines in which situation, in which request a policy is evaluated. And thus it defines, if a user object is available or not.
I think I said before, that it depends on your action. The Policy-ACTION.

12

Sorry but I don’t understand what you mean with “Action”…
Correct me if I’m wrong, when a policy is created we are defining 3 things, a scope where that policy is applied, the conditions when that policy is applied inside that scope and the actions that define what is done, the behavior.

In my previous example I created a policy that applied to the WEBUI scope, which means the policy is used when a user do the login in PI portal. Then it was defined a condition that allows every user to login if belongs to an AD group. Finally it was defined an action that is applied in that scope, for instance stop showing welcome info (hide_welcome_info).

Seeing it like that and for this case, I can’t understand what you mean when you referred the “Actions”. Where can the Actions in WEBUI policy might help us here?

13

I do not understand, what you do not understand. You are using the word actions yourself.

actions == ACTION

You either have other actions in your policy (besides hide_welcome_info) or you are trying to log in with an internal admin. But how can I know this.

14

Hi all,

Well, after giving a couple more hours trying to understand how to build the logic in PI, that could apply a policy if there was a match for some AD group, I finally got it to work.

Let me leave here what I’ve learned, it might be useful for others.

When we use an extended condition in the Policy, on the action side, only some actions are “compatible” with the extended condition, i.e if we have an extended condition in our policy we can only pick the action that works with that condition.

For instance, the way I did it for allowing only a user to login in PI if it belongs to a certain group (there is other ways to do it without using extended conditions).

I’ve created a policy “webui_default”, that match all users with no restrictions, which on the actions side I choose all the behaviors I would like to see when a user do the login (hide_welcome_info, dialog_no_token, admin_dashboard and so on) and most importantly login_mode: disabled (by default nobody can login with this policy).

Then, for the AD group I would like to login in the PI, I created a new policy “webui_groupA” with higher priority and the extended condition set to the AD group. In this case I would chose on the actions side, only login_mode: usertore that will override login_mode: disabled from the “webui_default.

That’s it, hope it is useful.

2 Likes