authentication sources: Do not "match" a rule if "requested" action if not configured in it

[dwlfrth]

Authentication sources works on a first hit match. Same for the rules in the source.
We should not match a rule in an authentication if we look for a specific action and that this specific action is not part of the rule.

ie.

• I have 3 rules in my authentication source
• 2 of them are "administration" class, the other one "authentication" class
  • First rule condition is pretty large (almost all employees) and give access to admin interface GUI
  • Second rule condition is also pretty large (but not the same) and allow sponsor
  • Third is not important
• A user is matching first and second rule conditions. When trying to check for sponsor, we match the first and since the "mark_as_sponsor" is not an available action, we bail out.

Need to add the ability of specifying the action we are looking for when trying to match and do not match a rule not containing that action.

[jrouzierinverse]

This is how it works now.

[dwlfrth]

Not as per a test I just did

[jrouzierinverse]

can you attach the authentication.conf that created that problem.

[jrouzierinverse]

If this is the case then you are right it is a bug.

[dwlfrth]

[NAME]
description=foobar.local
password=menotsecure
scope=sub
binddn=CN=PFServiceAccount,OU=Service Accounts,OU=Users and Groups,DC=foobar,DC=local
basedn=OU=Users and Groups,DC=foobar,DC=local
email_attribute=mail
usernameattribute=sAMAccountName
connection_timeout=5
stripped_user_name=yes
encryption=ssl
cache_match=1
dynamic_routing_module=AuthModule
port=636
type=LDAP
host=ldap.foobar.local

[NAME rule Admins]
description=Access to administration interface
class=administration
match=all
action0=set_access_level=ALL
condition0=memberOf,equals,CN=Group1,OU=Security Groups,OU=Users and Groups,DC=foobar,DC=local

[NAME rule Sponsors]
description=Ability to sponsor access
class=administration
match=all
action0=mark_as_sponsor=1
condition0=memberOf,equals,CN=Group2 (Default group),OU=Security Groups,OU=Users and Groups,DC=foobar,DC=local

[NAME rule Supervisors]
description=Supervisors for users access
class=administration
match=all
action0=set_access_level=User Manager
condition0=memberOf,equals,CN=Group3,OU=Distribution Groups,OU=Users and Groups,DC=foobar,DC=local

[julsemaan]

I'm pretty sure it always behaved that way and we put administration/authentication rules to handle cases like these.

The one you gave where you have two big groups with a partial union for two different actions isn't covered in the way it works (at least I believe)

That needs to be added as I agree that at least for administration rules that makes perfect sense that it behaves that way

[jrouzierinverse]

Can you also check in your logs to make sure there was not an error that might caused the problem.