Ldap Huntgroup 'Reject' issue

Kaya Saman kayasaman at optiplex-networks.com
Wed Nov 25 21:12:52 CET 2020


Hi,

I've just noticed that there is a little difference in functionality 
between FR 2.x and 3.21. The config I have, worked fine in v2 but now in 
v3 it is not doing what I intend.


I'm using an Openldap backend which consists of users and groups and I 
would like to restrict access based on the user-group association in ldap.

eg. any user belonging to the Guest group should only be given 
authenticated access to guest areas (currently restricted to Wifi) while 
'normal' users should get standard Wifi access but not access to NAS 
config shells etc; admin group gets all access with no restrictions


My current FR config takes the Huntgroup name and looks at the 'l' 
values in ldap for a match. This is the tail end of my Authorize file: 
*I've used <> to indicate comments  and it is not part of the config file*

DEFAULT Huntgroup-Name == Huntgroup1, Ldap-Group == "<PPP Dialin group>"
         Service-Type = "Framed-User"


DEFAULT Huntgroup-Name == Huntgroup2 <this is the Guest group>, 
Ldap-Group == "<Guest ldap group>"
         NAS-Port-Type = "Wireless-802.11",
     Airespace-QOS-Level = 3


DEFAULT Huntgroup-Name == Huntgroup3, Ldap-Group == "<Regular Wifi group>"
         NAS-Port-Type = "Wireless-802.11"


DEFAULT    Huntgroup-Name == Huntgroup4, Ldap-Group == "<Full Admin group>"
         Service-Type = "NAS-Prompt-User",
         Idle-Timeout = 600,
         Cisco-AVPair = "shell:priv-lvl=15"

DEFAULT Huntgroup-Name == Huntgroup4, Ldap-Group == "<Net Admin group>"
         Service-Type = "NAS-Prompt-User",
         Idle-Timeout = 600,
         Cisco-AVPair = "shell:priv-lvl=15"


DEFAULT Huntgroup-Name == Huntgroup5, Ldap-Group == "<Net Admin group>"
         Service-Type = "NAS-Prompt-User",
         Idle-Timeout = 600,
     STI-Access-Level = 1,
     APC-Service-Type = 1


DEFAULT Huntgroup-Name == Huntgroup6, Ldap-Group == "<Net Admin group>"
         Service-Type = "Administrative-User",
         Idle-Timeout = 600,
         Cisco-AVPair = "shell:priv-lvl=15"



DEFAULT Auth-Type := Reject



The Outer-tunnel (default) file contains the following under the 
Authorize section:

authorize {

         update request {
                 Huntgroup-Name ="%{ldap:ldap:///<ldap path 
1>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name +="%{ldap:ldap:///<ldap path 
2>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name +="%{ldap:ldap:///<ldap path 
3>l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name +="%{ldap:ldap:///<ldap path 
4>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name +="%{ldap:ldap:///<ldap path 
5>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name +="%{ldap:ldap:///<ldap path 
6>?l?sub?cn=%{Packet-Src-IP-Address}}"
         }

         #
         #  Take a User-Name, and perform some checks on it, for spaces 
and other
         #  invalid characters.  If the User-Name appears invalid, 
reject the
         #  request.
         #
         #  See policy.d/filter for the definition of the 
filter_username policy.
         #
         filter_username

         ...


The Inner-tunnel file contains this, it's slightly different from the 
'Outer' tunnel due to various matching issues I found when there are 
multiple 'l' values attached to the NAS lookup in ldap -
To clarify what I mean is that example:- a Wireless Controller has 
Huntgroup2, Huntgroup3 and Huntgroup4 set in the 'l' value under 
different ldap paths, so if it matches <ldap path 3> then look the user 
up and authenticate
- if the huntgroup does not match then try a different path using 
attributes based on the unlang operators:

authorize {
                 update request {
                 Huntgroup-Name ="%{ldap:ldap:///<ldap path 
1>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name ="%{ldap:ldap:///<ldap path 
2>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name ="%{ldap:ldap:///<ldap path 
3>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name :="%{ldap:ldap:///<ldap path 
4>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name ="%{ldap:ldap:///<ldap path 
5>?l?sub?cn=%{Packet-Src-IP-Address}}"
                 Huntgroup-Name :="%{ldap:ldap:///<ldap path 
6>?l?sub?cn=%{Packet-Src-IP-Address}}"
         }
         #
         #  Take a User-Name, and perform some checks on it, for spaces 
and other
         #  invalid characters.  If the User-Name appears invalid, 
reject the
         #  request.
         #
         #  See policy.d/filter for the definition of the 
filter_username policy.
         #
         filter_username

         ...


This is a partial output from radiusd -X - the user is not found in any 
of the administrative ldap paths and then hits line 314 which is the 
line "DEFAULT Auth-Type := Reject" in the authorize file, but then it 
proceeds to the ldap module and is granted access:


(946) auth_log: EXPAND %t
(946) auth_log:    --> Wed Nov 25 02:26:21 2020
(946)     [auth_log] = ok
(946)     [chap] = noop
(946)     [mschap] = noop
(946)     [digest] = noop
(946) suffix: Checking for suffix after "@"
(946) suffix: No '@' in User-Name = "<guest user>", looking up realm NULL
(946) suffix: No such realm "NULL"
(946)     [suffix] = noop
(946) eap: No EAP-Message, not doing EAP
(946)     [eap] = noop
(946) files: Searching for user in group "<Full Admin group>"
rlm_ldap (ldap): Reserved connection (204)
(946) files: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
(946) files:    --> (uid=<guest user>)
(946) files: Performing search in "<Base DN>" with filter "(uid=<guest 
user>)", scope "sub"
(946) files: Waiting for search result...
(946) files: User object found at DN "uid=<guest user>,<Guest user path>"
(946) files: Checking user object's memberOf attributes
(946) files:   Performing unfiltered search in "uid=<guest user>,<Guest 
user path>", scope "base"
(946) files:   Waiting for search result...
(946) files: Processing memberOf value "<Guest ldap group>" as a DN
rlm_ldap (ldap): Released connection (204)
(946) files: User is not a member of "<Full Admin group>"
(946) files: Searching for user in group "<Net Admin group>"
rlm_ldap (ldap): Reserved connection (202)
(946) files: Using user DN from request "uid=<guest user>,<Guest user path>"
(946) files: Checking user object's memberOf attributes
(946) files:   Performing unfiltered search in "uid=<guest user>,<Guest 
user path>", scope "base"
(946) files:   Waiting for search result...
(946) files: Processing memberOf value "<Guest ldap group>" as a DN
rlm_ldap (ldap): Released connection (202)
(946) files: User is not a member of "<Net Admin group>"
(946) files: users: Matched entry DEFAULT at line 314
(946)     [files] = ok
rlm_ldap (ldap): Reserved connection (203)
(946) ldap: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
(946) ldap:    --> (uid=<guest user>)
(946) ldap: Performing search in "<Base DN>" with filter "(uid=<guest 
user>)", scope "sub"
(946) ldap: Waiting for search result...
(946) ldap: User object found at DN "uid=<guest user>,<Guest user path>"
(946) ldap: Processing user attributes
(946) ldap: control:Password-With-Header += 'Wifi<guest user>'
rlm_ldap (ldap): Released connection (203)
(946)     [ldap] = updated
(946)     [expiration] = noop
(946)     [logintime] = noop
(946) pap: No {...} in Password-With-Header, re-writing to 
Cleartext-Password
(946) pap: Removing &control:Password-With-Header
(946) pap: WARNING: Auth-Type already set.  Not setting to PAP
(946)     [pap] = noop
(946)     if (User-Password) {
(946)     if (User-Password)  -> TRUE
(946)     if (User-Password)  {
(946)       update control {
(946)         Auth-Type := ldap
(946)       } # update control = noop
(946)     } # if (User-Password)  = noop
(946)   } # authorize = updated
(946) Found Auth-Type = ldap
(946) # Executing group from file /usr/local/etc/raddb/sites-enabled/default
(946)   authenticate {
rlm_ldap (ldap): Reserved connection (204)
(946) ldap: Login attempt by "<guest user>"
(946) ldap: Using user DN from request "uid=<guest user>,<Guest user path>"
(946) ldap: Waiting for bind result...
(946) ldap: Bind successful



What needs to be done in order for FR to make a decision based on the 
evaluation of the authorize file and 'accept' or 'reject' accordingly?

Currently I'm going through the 'unlang' and 'SQL-Huntgroup-Howto' in 
the FR Wiki but I'm unable to work this one out. Perhaps a 'Post-auth' 
statement is necessary? - currently this is in the 'inner-tunnel' file:

         #
         #  Access-Reject packets are sent through the REJECT 
sub-section of the
         #  post-auth section.
         #
         #  Add the ldap module name (or instance) if you have set
         #  'edir_account_policy_check = yes' in the ldap module 
configuration
         #
         Post-Auth-Type REJECT {
                 # log failed authentications in SQL, too.
                 -sql
                 attr_filter.access_reject

                 #
                 #  Let the outer session know which module failed, and why.
                 #
                 update outer.session-state {
                         &Module-Failure-Message := 
&request:Module-Failure-Message
                 }
         }
}


and this is in the 'default' file:

         Post-Auth-Type REJECT {
                 # log failed authentications in SQL, too.
                 -sql
                 attr_filter.access_reject

                 # Insert EAP-Failure message if the request was
                 # rejected by policy instead of because of an
                 # authentication failure
                 eap

                 #  Remove reply message if the response contains an 
EAP-Message
                 remove_reply_message_if_eap
         }



Would anyone be able to give me some advice? Many Thanks!


Kaya





More information about the Freeradius-Users mailing list