LDAP group checking stopping before the whole group list is checked
I'm having an issue with ldap group checking where FreeRADIUS appears to bail out early if it encounters a group DN it can't resolve. The LDAP server (FreeIPA) has a very restrictive set of ACL's; the group which cannot be resolved (Replication Administrators) is not readable by standard accounts. I'd like to avoid messing with the ACL's, or granting FreeRADIUS more privileges if possible. If I run ldapsearch, the group I'm looking for is definitely in the memberOf list. Can I get it to continue reading the list of groups if it fails to resolve one, or is this intended (or something I've screwed up in the config)? Adam Bishop gpg: E75B 1F92 6407 DFDF 9F1C BF10 C993 2504 6609 D460 jisc.ac.uk --- # raddebug (3) Debug: Received Access-Request Id 154 from [1:2:3:4:5::6]:55794 to [1:2:3:4:5::7]:1812 length 93 (3) Debug: User-Name = "adam" (3) Debug: User-Password = "asdf" (3) Debug: NAS-Identifier = "esw-001" (3) Debug: Calling-Station-Id = "8.8.8.8" (3) Debug: NAS-IPv6-Address = 1:2:3:4:5::6 (3) Debug: # Executing section authorize from file /etc/raddb/sites-enabled/infrastructure (3) Debug: authorize { (3) Debug: update request { (3) Debug: } # update request = noop (3) Debug: ldap: EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}}) (3) Debug: ldap: --> (uid=adam) (3) Debug: ldap: Performing search in "cn=users,cn=accounts,dc=example,dc=org" with filter "(uid=adam)", scope "sub" (3) Debug: ldap: Waiting for search result... (3) Debug: ldap: User object found at DN "uid=adam,cn=users,cn=accounts,dc=example,dc=org" (3) Debug: ldap: Processing user attributes (3) Debug: [ldap] = ok (3) Debug: if ((ok || updated) && User-Password) { (3) Debug: if ((ok || updated) && User-Password) -> TRUE (3) Debug: if ((ok || updated) && User-Password) { (3) Debug: update { (3) Debug: } # update = noop (3) Debug: } # if ((ok || updated) && User-Password) = noop (3) Debug: if (&LDAP-Group[*] == "%{client:ldap_group}") { (3) Debug: EXPAND %{client:ldap_group} (3) Debug: --> switching-admins (3) Debug: Searching for user in group "switching-admins" (3) Debug: Using user DN from request "uid=adam,cn=users,cn=accounts,dc=example,dc=org" (3) Debug: Checking user object's memberOf attributes (3) Debug: Performing unfiltered search in "uid=adam,cn=users,cn=accounts,dc=example,dc=org", scope "base" (3) Debug: Waiting for search result... (3) Debug: Processing memberOf value "cn=servicea-admins,cn=groups,cn=accounts,dc=example,dc=org" as a DN (3) Debug: Resolving group DN "cn=servicea-admins,cn=groups,cn=accounts,dc=example,dc=org" to group name (3) Debug: Performing unfiltered search in "cn=servicea-admins,cn=groups,cn=accounts,dc=example,dc=org", scope "base" (3) Debug: Waiting for search result... (3) Debug: Group DN "cn=servicea-admins,cn=groups,cn=accounts,dc=example,dc=org" resolves to name "servicea-admins" (3) Debug: Processing memberOf value "cn=serviceb-admins,cn=groups,cn=accounts,dc=example,dc=org" as a DN (3) Debug: Resolving group DN "cn=serviceb-admins,cn=groups,cn=accounts,dc=example,dc=org" to group name (3) Debug: Performing unfiltered search in "cn=serviceb-admins,cn=groups,cn=accounts,dc=example,dc=org", scope "base" (3) Debug: Waiting for search result... (3) Debug: Group DN "cn=serviceb-admins,cn=groups,cn=accounts,dc=example,dc=org" resolves to name "serviceb-admins" <snip 10+ other groups> (3) Debug: Processing memberOf value "cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=org" as a DN (3) Debug: Resolving group DN "cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=org" to group name (3) Debug: Performing unfiltered search in "cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=org", scope "base" (3) Debug: Waiting for search result... (3) Debug: Search returned no results (3) ERROR: Group DN "cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=org" did not resolve to an object (3) Debug: User is not a member of "switching-admins" (3) Debug: if (&LDAP-Group[*] == "%{client:ldap_group}") -> FALSE (3) Debug: else { (3) Debug: update reply { (3) Debug: } # update reply = noop (3) Debug: [reject] = reject (3) Debug: } # else = reject (3) Debug: } # authorize = reject (3) Debug: Using Post-Auth-Type Reject (3) Debug: # Executing group from file /etc/raddb/sites-enabled/infrastructure (3) Debug: Post-Auth-Type REJECT { (3) Debug: attr_filter.access_reject: EXPAND %{User-Name} (3) Debug: attr_filter.access_reject: --> adam (3) Debug: attr_filter.access_reject: Matched entry DEFAULT at line 11 (3) Debug: [attr_filter.access_reject] = updated (3) Debug: [eap] = noop (3) Debug: rp_log: EXPAND rp_log.%{%{reply:Packet-Type}:-format} (3) Debug: rp_log: --> rp_log.Access-Reject (3) Debug: rp_log: EXPAND radiusd-rp-log#DOMAIN=VIRT#LOCATION=ATL#SERVICE=%{%{Service-Class}:-NONE}#ORG=%{%{request:operator-name}:-%{request:Stripped-User-Domain}}#USER=%{User-Name}#CSI=%{Calling-Station-Id}#NAS=%{Called-Station-Id}#CUI=%{reply:Chargeable-User-Identity}#RESULT=FAIL#VLAN=%{%{reply:Tunnel-Private-Group-ID}:-NONE}#CLIENT=%{client:shortname}#REPLY_MESSAGE=%{%{reply:reply-message}:-NONE}#MODULE_MESSAGE=%{%{%{request:Module-Failure-Message}:-%{session-state:Module-Failure-Message}}:-NONE}# (3) Mon Jun 10 01:17:34 2019: Debug: rp_log: --> radiusd-rp-log#DOMAIN=VIRT#LOCATION=ATL#SERVICE=infrastructure#ORG=#USER=adam#CSI=8.8.8.8#NAS=#CUI=#RESULT=FAIL#VLAN=NONE#CLIENT=esw-001.inf#REPLY_MESSAGE=Not Authorised#MODULE_MESSAGE=Group DN "cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=org" did not resolve to an object# (3) Debug: [rp_log] = ok (3) Debug: policy remove_reply_message_if_eap { (3) Debug: if (&reply:EAP-Message && &reply:Reply-Message) { (3) Debug: if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (3) Debug: else { (3) Debug: [noop] = noop (3) Debug: } # else = noop (3) Debug: } # policy remove_reply_message_if_eap = noop (3) Debug: } # Post-Auth-Type REJECT = updated (3) Debug: Delaying response for 1.000000 seconds (3) Debug: Sending delayed response (3) Debug: Sent Access-Reject Id 154 from [1:2:3:4:5::7]:1812 to [1:2:3:4:5::6]:55794 length 36 (3) Debug: Reply-Message := "Not Authorised" (3) Debug: Cleaning up request packet ID 154 with timestamp +1036 Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800. Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited by guarantee which is registered in England under company number 2881024, VAT number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, Bristol BS2 0JA. T 0203 697 5800.
On Jun 10, 2019, at 8:20 AM, Adam Bishop <Adam.Bishop@jisc.ac.uk> wrote:
I'm having an issue with ldap group checking where FreeRADIUS appears to bail out early if it encounters a group DN it can't resolve.
The LDAP server (FreeIPA) has a very restrictive set of ACL's; the group which cannot be resolved (Replication Administrators) is not readable by standard accounts. I'd like to avoid messing with the ACL's, or granting FreeRADIUS more privileges if possible.
That makes sense.
If I run ldapsearch, the group I'm looking for is definitely in the memberOf list.
If you run ldapsearch with the right set of permissions.
Can I get it to continue reading the list of groups if it fails to resolve one, or is this intended (or something I've screwed up in the config)?
You'll have to hack the source. It's difficult to tell that this error:
... (3) ERROR: Group DN "cn=Replication Administrators,cn=privileges,cn=pbac,dc=example,dc=org" did not resolve to an object
is a permissions error, and not a "database broken" error. A *sane* database would check the ACLs, and simply not return that DN as a list of valid group DNs. It's not clear how to work around this issue. We could simply skip that group DN, but doing so may have other side effects. I'll have to check with Arran on this. The preferable solution would be for the DB to not lie to FreeRADIUS. :( Alan DeKok.
On 6/10/19 7:20 AM, Adam Bishop wrote:
I'm having an issue with ldap group checking where FreeRADIUS appears to bail out early if it encounters a group DN it can't resolve.
I ran into this exact issue.
Can I get it to continue reading the list of groups if it fails to resolve one, or is this intended (or something I've screwed up in the config)?
Check the comments for group/membership_attribute in mods-available/ldap: # Unless a conversion between group name and group DN is # needed, there's no requirement for the group objects # referenced to actually exist. I was able to prevent radiusd from trying to resolve the group by using the group's complete DN in sites-available/default, rather than just the group name. So instead of: if (LDAP-Group == "lab_admins") { update reply { Cisco-AVPair := "shell:priv-lvl=15" } } I have: if (LDAP-Group == "cn=lab_admins,cn=groups,cn=accounts,dc=...") { update reply { Cisco-AVPair := "shell:priv-lvl=15" } }
(3) Debug: if (&LDAP-Group[*] == "%{client:ldap_group}") { (3) Debug: EXPAND %{client:ldap_group} (3) Debug: --> switching-admins
If you can get %{client:ldap_group} to expand to the group's full DN (or even manually "munge" it) radiusd shouldn't try to resolve the group. HTH -- ======================================================================== Ian Pilcher arequipeno@gmail.com -------- "I grew up before Mark Zuckerberg invented friendship" -------- ========================================================================
participants (3)
-
Adam Bishop -
Alan DeKok -
Ian Pilcher