Prevent unnecessary checks with Ldap-Group in FR3
Hi there, we are doing an Ldap-Group-Check for every login. The Group contains people who are not allowed to use radius-services. So 98% of the Users are NOT in the Group. FR3 first searches in the Group for the Login-User, if he finds nothing he then checks all the groups a user is member of in reverse, which can be a lot at our site. I know, there are directories who do not impelement backreferences for user-groups, but e.g. with eDirectory it's just not necessary. So I wonder if there is a way to prevent this behavior with a config param I missed until know in FR3 ldap module config, so FR just stops after not finding the user in the group? Thu Aug 27 17:08:20 2015 : Debug: (7) policy rzur.radiusrejectcheckinner { Thu Aug 27 17:08:20 2015 : Debug: (7) if (Stripped-User-Name =~ /^[a-zA-Z]{3}[0-9]{5}$/ ) { Thu Aug 27 17:08:20 2015 : Debug: No matches Thu Aug 27 17:08:20 2015 : Debug: Adding 1 matches Thu Aug 27 17:08:20 2015 : Debug: (7) if (Stripped-User-Name =~ /^[a-zA-Z]{3}[0-9]{5}$/ ) -> TRUE Thu Aug 27 17:08:20 2015 : Debug: (7) if (Stripped-User-Name =~ /^[a-zA-Z]{3}[0-9]{5}$/ ) { Thu Aug 27 17:08:20 2015 : Debug: (7) if (Ldap-Group == "cn=radiusreject,ou=myou,o=myo,c=de") { Thu Aug 27 17:08:20 2015 : Debug: (7) Searching for user in group "cn=radiusreject,ou=myou,o=myo,c=de" Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Connecting to ldap://ldap.example.com.de:389 Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): New libldap handle 0x7f0e35c87c50 Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Waiting for bind result... Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Bind successful Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Reserved connection (0) Thu Aug 27 17:08:20 2015 : Debug: (7) EXPAND TMPL XLAT Thu Aug 27 17:08:20 2015 : Debug: (&(objectClass=inetOrgPerson)(uid=%{%{Stripped-User-Name}:-%{User-Name}})) Thu Aug 27 17:08:20 2015 : Debug: Parsed xlat tree: Thu Aug 27 17:08:20 2015 : Debug: literal --> (&(objectClass=inetOrgPerson)(uid= Thu Aug 27 17:08:20 2015 : Debug: if { Thu Aug 27 17:08:20 2015 : Debug: attribute --> Stripped-User-Name Thu Aug 27 17:08:20 2015 : Debug: } Thu Aug 27 17:08:20 2015 : Debug: else { Thu Aug 27 17:08:20 2015 : Debug: attribute --> User-Name Thu Aug 27 17:08:20 2015 : Debug: } Thu Aug 27 17:08:20 2015 : Debug: literal --> )) Thu Aug 27 17:08:20 2015 : Debug: (7) EXPAND (&(objectClass=inetOrgPerson)(uid=%{%{Stripped-User-Name}:-%{User-Name}})) Thu Aug 27 17:08:20 2015 : Debug: (7) --> (&(objectClass=inetOrgPerson)(uid=xxx12345)) Thu Aug 27 17:08:20 2015 : Debug: (7) EXPAND TMPL LITERAL Thu Aug 27 17:08:20 2015 : Debug: (7) Performing search in "c=de" with filter "(&(objectClass=inetOrgPerson)(uid=xxx12345))", scope "sub" Thu Aug 27 17:08:20 2015 : Debug: (7) Waiting for search result... Thu Aug 27 17:08:20 2015 : Debug: (7) User object found at DN "cn=xxx12345,ou=myou,o=myo,c=de" Thu Aug 27 17:08:20 2015 : Debug: (7) Checking for user in group objects Thu Aug 27 17:08:20 2015 : Debug: (&(objectClass=Group)(member=%{control:LDAP-UserDn})) Thu Aug 27 17:08:20 2015 : Debug: Parsed xlat tree: Thu Aug 27 17:08:20 2015 : Debug: literal --> (&(objectClass=Group)(member= Thu Aug 27 17:08:20 2015 : Debug: attribute --> LDAP-UserDN Thu Aug 27 17:08:20 2015 : Debug: literal --> )) Thu Aug 27 17:08:20 2015 : Debug: (7) EXPAND (&(objectClass=Group)(member=%{control:LDAP-UserDn})) Thu Aug 27 17:08:20 2015 : Debug: (7) --> (&(objectClass=Group)(member=cn\3dxxx12345\2cou\3dmyou\2co\3dmyo\2cc\3dde)) Thu Aug 27 17:08:20 2015 : Debug: (7) Performing search in "cn=radiusreject,ou=myou,o=myo,c=de" with filter "(&(objectClass=Group)(member=cn\3dxxx12345\2cou\3dmyou\2co\3dmyo\2cc\3dde))", scope "sub" Thu Aug 27 17:08:20 2015 : Debug: (7) Waiting for search result... Thu Aug 27 17:08:20 2015 : Debug: (7) Search returned no results Thu Aug 27 17:08:20 2015 : Debug: (7) Checking user object's groupMembership attributes Thu Aug 27 17:08:20 2015 : Debug: (7) Performing unfiltered search in "cn=xxx12345,ou=myou,o=myo,c=de", scope "base" Thu Aug 27 17:08:20 2015 : Debug: (7) Waiting for search result... Thu Aug 27 17:08:20 2015 : Debug: (7) Processing groupMembership value "cn=mygroup1,ou=myou,o=myo,c=de" as a DN Thu Aug 27 17:08:20 2015 : Debug: (7) Processing groupMembership value "cn=mygroup2,ou=myou,o=myo,c=de" as a DN ... about 50 Groups .... Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Released connection (0) Thu Aug 27 17:08:20 2015 : Info: rlm_ldap (ldap): 0 of 1 connections in use. Need more spares Thu Aug 27 17:08:20 2015 : Info: rlm_ldap (ldap): Opening additional connection (1), 1 of 127 pending slots used Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Connecting to ldap://ldap.example.com:389 Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): New libldap handle 0x7f0e35caa700 Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Waiting for bind result... Thu Aug 27 17:08:20 2015 : Debug: rlm_ldap (ldap): Bind successful Thu Aug 27 17:08:20 2015 : Debug: (7) User is not a member of "cn=radiusreject,ou=myou,o=myo,c=de" Thu Aug 27 17:08:20 2015 : Debug: (7) if (Ldap-Group == "cn=radiusreject,ou=myou,o=myo,c=de") -> FALSE Thu Aug 27 17:08:20 2015 : Debug: (7) } # if (Stripped-User-Name =~ /^[a-zA-Z]{3}[0-9]{5}$/ ) = updated Thu Aug 27 17:08:20 2015 : Debug: (7) } # policy rzur.radiusrejectcheckinner = updated Thank you for your time, Anja
On Aug 27, 2015, at 11:29 AM, Anja Ruckdaeschel <Anja.Ruckdaeschel@rz.uni-regensburg.de> wrote:
Hi there,
we are doing an Ldap-Group-Check for every login. The Group contains people who are not allowed to use radius-services. So 98% of the Users are NOT in the Group.
FR3 first searches in the Group for the Login-User, if he finds nothing he then checks all the groups a user is member of in reverse, which can be a lot at our site.
If you gave the ldap module a value for group.membership_attribute, it's going to check all the values of that attribute found in the user object. If you don't want it to check membership attributes comment out group.membership_attribute. If the format of the group you're trying to find is the same as the membership_attribute value i.e. your group is a DN and the value is a DN, then rlm_ldap will not hit the LDAP directory for each of these checks, so it just ends up being a memcmp (very fast even for 50 groups). The only time this is an issue is is one is a DN and the other is a name, then each group membership requires a search to get both operands in the same format. -Arran
Commenting out the attribute did the trick. Thank you very much. Have a nice day. Ciao Anja
Arran Cudbard-Bell <a.cudbardb@freeradius.org> 27.08.2015 17:56 >>>
On Aug 27, 2015, at 11:29 AM, Anja Ruckdaeschel <Anja.Ruckdaeschel@rz.uni-regensburg.de> wrote:
Hi there,
we are doing an Ldap-Group-Check for every login. The Group contains people who are not allowed to use radius-services. So 98% of the Users are NOT in the Group.
FR3 first searches in the Group for the Login-User, if he finds nothing he then checks all the groups a user is member of in reverse, which can be a lot at our site.
If you gave the ldap module a value for group.membership_attribute, it's going to check all the values of that attribute found in the user object. If you don't want it to check membership attributes comment out group.membership_attribute. If the format of the group you're trying to find is the same as the membership_attribute value i.e. your group is a DN and the value is a DN, then rlm_ldap will not hit the LDAP directory for each of these checks, so it just ends up being a memcmp (very fast even for 50 groups). The only time this is an issue is is one is a DN and the other is a name, then each group membership requires a search to get both operands in the same format. -Arran
participants (2)
-
Anja Ruckdaeschel -
Arran Cudbard-Bell