authentication sources: matching rules for admin and sponsored access

[nqb]

If you use administration rules in sources to give sponsored and/or admin access, you will notice following results:

Admin access

• if an AD source match for an admin user but they are no admin rule specified, PF will not try other sources.
• if an AD source match for an admin user with a "mark as sponsor" (only) rule specified, PF will not try other sources and other rules.

Sponsored access

• if an AD source match for a sponsor user but they are no admin rule specified, PF will not try other sources.
• if an AD source match for a sponsor user with a "access level" (only) rule specified, PF will not try other sources and other rules.

Expected results

Depending on context (admin or portal) and rule_class, PF should try to use only relevant sources:

• doesn't use sources with no administration rules
• use only sources with Mark as sponsor actions for sponsored access
• use only sources with Access level actions for admin access

Some work has been already done see #1858.

In these contexts, PF should try to use other sources if administration rule(s) for a maching source return no results.

I didn't test CLI access but I assume same behavior.

Workaround if you have Sponsored and Admin access on your setup

Notes:

• Create a general authentication source with all the admin rules in it
• This source need to be on top of the list due to current matching on AD source without administratio
  rules.
• If an admin rule failed in the selected source, PF will try next admin rules.

Example with AD sources:

[AD_meta]
cache_match=0
read_timeout=10
realms=
password=**removed**
scope=sub
binddn=**removed**
port=389
description=Meta
write_timeout=5
type=AD
basedn=**removed**
monitor=1
set_access_level_action=
shuffle=0
email_attribute=mail
usernameattribute=sAMAccountName
connection_timeout=1
encryption=none
host=**removed**

[AD_meta rule sponsor_and_admin]
action0=set_access_level=ALL
condition0=memberOf,equals,CN=test_sponsor,CN=Users,DC=example,DC=lan
condition1=memberOf,equals,CN=test_itstaff,CN=Users,DC=example,DC=lan
match=all
class=administration
action1=mark_as_sponsor=1
description=Sponsor and admin access

[AD_meta rule sponsor_only]
action0=mark_as_sponsor=1
condition0=memberOf,equals,CN=test_sponsor,CN=Users,DC=example,DC=lan
match=all
class=administration
description=Only sponsor access

[AD_meta rule admin_only]
action0=set_access_level=ALL
condition0=memberOf,equals,CN=test_itstaff,CN=Users,DC=example,DC=lan
match=all
class=administration
description=Only admin access

[nqb]

My workaround is not perfect.

If you put AD_meta source on top of the authentication sources list and you have connection profiles or portal modules that use all available sources, they will match AD_meta source and 0 authentication rule. Consequently, users won't get role and access duration. You can bypass these behavior by using a closed list of sources in connection profiles or portal modules.

It means that when PF can authenticate a user on an authentication source, it will use only that authentication source to get:

• authentication rules results
• administration rules results

for all access.

In my opinion, this is not really a first win match algorithm and we should change that behavior.

[jrouzierinverse]

I not sure this is a bug but a limitation of authentication rule matching.
I will move this to the 8.3 milestone.

[jrouzierinverse]

Can be partially addressed by #4061

[nqb]

I can confirm that this bug is partially addressed by #4061.

Now when you used "Associated sources" on a sponsor source, sources will be used to find sponsor on captive portal.
However, when sponsor clicks on link received by mail and try to authenticate, PF still uses all authentication sources to check for a sponsor right.

It will be really nice if we can limit sponsor authentication to "Associated sources" to be consistent with what have been done on captive portal.

[nqb]

I did several deployments recently and this bug is very annoying. You have to create different rules to deal with several use cases like:

• admin user only
• sponsor user only
• sponsor and admin only

If you have to handle case of CLI login, it's a nightmare.

I changed priority of this issue in order to have this one fixed for v11.

[extrafu]

@nqb Make sure this is still relevant and if you still have a problem, please provide an example.

[nqb]

This bug is still present on devel.

Description

If a user has two roles:

• Access Level: ALL
• Mark as sponsor

which are provided through two different rules in one authentication source, only one rule can match when:

• user login on web admin interface
• user login on captive portal to activate access of a sponsored user

Steps to reproduce

1. Create an AD source with following rules (in this specific order):
   1. Access Level ALL in one rule
   2. Mark as sponsor in another rule
2. Create a sponsor source with:
   • Associated sources equals to AD source created at previous step.
   • Sponsor validation enabled (to force authentication on captive portal by sponsor)
   • Assign guest role
3. As a guest, request a sponsor access on captive portal

=> PacketFence will use second rule of AD source to find sponsor: that's what we expect

1. As a sponsor, connect on captive portal to activate access

=> You got: "does not have permission to sponsor a user". If you looks at logs, you match first rule of AD source

=> If you switch order of rules in AD source, sponsor permission will work but you will break web admin access because PacketFence will match first rule of AD source when user log on web admin.

Configuration to replicate:

### Sponsor source
[sponsor_ad]
local_account_expiration=0s
lang=en_US
set_access_durations_action=
local_account_logins=0
allow_localdomain=yes
hash_passwords=bcrypt
type=SponsorEmail
sources=dot1x_eap_peap_user_auth
email_activation_timeout=30m
description=sponsor_ad
register_on_activation=disabled
validate_sponsor=yes
create_local_account=no
password_length=8
activation_domain=172.18.140.15

[sponsor_ad rule catchall]
class=authentication
match=all
action1=set_access_duration=5m
status=enabled
action0=set_role=guest

### AD source
[dot1x_eap_peap_user_auth]
email_attribute=mail
password=VagrantPass1
type=AD
set_access_durations_action=
verify=none
usernameattribute=sAMAccountName
scope=sub
realms=
binddn=vagrant-domain@example.lan
read_timeout=10
description=172.18.140.100 user authentication
searchattributes=
encryption=starttls
host=172.18.140.100
basedn=dc=example,dc=lan
write_timeout=5
connection_timeout=1
port=389
monitor=1
cache_match=0
shuffle=0
dead_duration=60

[dot1x_eap_peap_user_auth rule assign_admin_access]
status=enabled
action0=set_access_level=ALL
condition0=memberOf,equals,CN=IT,CN=Users,dc=example,dc=lan
match=all
class=administration

[dot1x_eap_peap_user_auth rule assign_sponsor_access]
class=administration
match=all
condition0=memberOf,equals,CN=sponsor,CN=Users,dc=example,dc=lan
action0=mark_as_sponsor=1
status=enabled

[dot1x_eap_peap_user_auth rule catchall]
class=authentication
match=all
action0=set_role=user_employee
status=enabled
action1=set_access_duration=5m

Let me know if you need some clarification.

[julsemaan]

Found the origin of the issue:
https://github.com/inverse-inc/packetfence/blob/devel/html/captive-portal/lib/captiveportal/PacketFence/Controller/Activate/Email.pm#L184

This needs to filter not only on the rule_class but also on the rule action it wants so that the appropriate rule is matched.

I'll work on a fix and post back here when it's done

[nqb]

Thanks @julsemaan.

Just to make sure you have the big picture: this is also an issue on web admin if sponsor rule is the first in the AD source.

In that specific case, user lost its admin access in favor of sponsor access which mean he is not able to authenticate on web admin.

[julsemaan]

I've pushed a fix for each (sponsor login and admin login) and tested the appropriate additional actions are sent back (SET_ACCESS_DURATIONS for sponsor login and SET_TENANT_ID for admin login) so there should be no regressions at all

@nqb, please retest and close

[nqb]

Works as expected. Thanks a lot, it will really simplify rules.