Open nqb opened 3 years ago
It also depends how the equipment expects the answer. Some of them needs to have a Access-Accept so we can´t reject them in freeradius.
If think i will adapt this PR https://github.com/inverse-inc/packetfence/pull/6772 to take care of that.
My workaround:
profiles.conf
[catch_dummy_automate_tester]
locale=
description=Reject dummy user
advanced_filter=last_dot1x_username =~ "^dummy"
filter=
sources=reject_dummy_user
top_op=and
authentication.conf
[reject_dummy_user]
realms=
description=Reject dummy user (used by Cisco automated-tester)
type=Authorization
set_access_durations_action=
[reject_dummy_user rule reject_dummy_user]
action0=set_role=REJECT
condition0=username,equals,dummy
status=enabled
match=all
class=authentication
action1=set_access_duration=1h
Is your feature request related to a problem? Please describe. When you configure switchs with an automatic mechanism to check if a RADIUS server is alive (automate-tester on Cisco), each switch send a bad authentication to RADIUS servers with a username like "dummy".
It looks like these RADIUS requests are handled by PacketFence in post-authentication.
It creates a lot of lines in
radius.log
andpacketfence.log
. On top of that, it can generate useless LDAP traffic when you use AD sources.Describe the solution you'd like Reject dummy user during authentication phase (don't send request to PacketFence).
Describe alternatives you've considered Create a default RADIUS filter that reject early these requests.
Additional context I don't think all vendors use "dummy" as value of
User-Name
(RADIUS attribute). In that case, it will be more pratical to use a RADIUS filter which can be edited from GUI.