Re: Troube with matching LDAP group membership in authorize
Richard Hesse wrote: Nevermind I found the problem. There's a limitation in ldap_groupcmp() such that only the last LDAP module instantiated is actually checked -- ignoring whatever you specify. I found this info from http://lists.cistron.nl/pipermail/freeradius-users/2004-June/033220.html. That's for the attribute "Ldap-Group". The module-name-prefixed version, "ldap_enable-Ldap-Group" should work fine. Your original mail listed: Hint file: DEFAULT NAS-Port-Type == Virtual, Service-Type == NAS-Prompt-User, ldap_enable-Ldap-Group := "operations", Autz-Type := ldap_enable, Auth-Type := LDAP You are using := to compare ldap_enable-Ldap-Group - use == Try setting the Autz-Type in the "users" file - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Troube with matching LDAP group membership in authorize
Richard Hesse wrote: > > Yes, that's what I ended up doing. However, I lose the ability > to do load-balance and redunancy constructs. Why? > rlm_ldap indicates > that I can list multiple LDAP servers for the host in > radius.conf. How exactly does that work compared to redundancy > or load-balance? Does it try the first, then the second, etc > every time? Does it round-robin? doc/configurable_failover doc/load-balance.txt Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Troube with matching LDAP group membership in authorize
> In any case, if you carefully read the text you quoted, you'll see a > solution that doesn't require patches: List ALL ldap modules in the >"instantiate" section, and list "ldap_enable" last. > Alan DeKok. Yes, that's what I ended up doing. However, I lose the ability to do load-balance and redunancy constructs. rlm_ldap indicates that I can list multiple LDAP servers for the host in radius.conf. How exactly does that work compared to redundancy or load-balance? Does it try the first, then the second, etc every time? Does it round-robin? Thanks, -richard Want to start your own business? Learn how on Yahoo! Small Business. http://smallbusiness.yahoo.com/r-index - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Troube with matching LDAP group membership in authorize
Richard Hesse wrote: > Rather disappointing that this limitation still exists from 2 years ago. As always, patches are welcome. > Does FR2.0 have some sort of object-based virtualization that would support > this? > Like, a "LDAP group" object which you could tie LDAP instances to and make > the check there? No, but we'd welcome patches. In any case, if you carefully read the text you quoted, you'll see a solution that doesn't require patches: List ALL ldap modules in the "instantiate" section, and list "ldap_enable" last. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Troube with matching LDAP group membership in authorize
Nevermind I found the problem. There's a limitation in ldap_groupcmp() such that only the last LDAP module instantiated is actually checked -- ignoring whatever you specify. I found this info from http://lists.cistron.nl/pipermail/freeradius-users/2004-June/033220.html. "In any case the ldap module which will be instantiated last will be the one that will handle ldap-group comparisons. If we add a check that will change to the first ldap module which is instantiated. I think it's more or less a matter of personal taste, which module we 'd like to handle ldap-group comparisons. Is it really worth the effort. Users can just change the order in which the ldap modules are instantiated in order to achieve what they want." Rather disappointing that this limitation still exists from 2 years ago. Does FR2.0 have some sort of object-based virtualization that would support this? Like, a "LDAP group" object which you could tie LDAP instances to and make the check there? -richard - Original Message From: Richard Hesse <[EMAIL PROTECTED]> To: freeradius-users@lists.freeradius.org Sent: Tuesday, January 30, 2007 12:40:36 PM Subject: Troube with matching LDAP group membership in authorize I'm trying to setup radius authentication for enable access on our networking gear and having a tough time getting a working config. I'd like to have FR check a group in LDAP for membership before authorizing. That is, I only want user's listed in the "uniquemember" attribute of the Operations group object to be granted access. Reading the FR docs this is possible -- I must be missing something. First, here are the relevant portions of my configs: Hint file: DEFAULT NAS-Port-Type == Virtual, Service-Type == NAS-Prompt-User, ldap_enable-Ldap-Group := "operations", Autz-Type := ldap_enable, Auth-Type := LDAP radius.conf: ldap ldap_enable{ server = "fds1.hq.powerset.com" basedn = "dc=powerset,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = yes tls_cacertfile = /opt/fedora-ds/alias/starfield.pem tls_require_cert= "demand" # Mapping of RADIUS dictionary attributes to LDAP # directory attributes. dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 # ldap_debug = 1 #groupname_attribute = cn groupmembership_filter = "(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))" timeout = 4 timelimit = 3 net_timeout = 3 # compare_check_items = yes # do_xlat = yes access_attr_used_for_allow = no set_auth_type = no } I have several LDAP instances defined in radius.config, but this is the one I want to use. I instantiate it first in radius.config so that hints can use it: instantiate { ldap_enable exec expr } And a corresponsing Autz-Type in radius.config: authorize { preprocess suffix ntdomain eap autztype ldap{ redundant { fds1 #fds2 } } autztype ldap_enable{ ldap_enable } files pap } Here's the debug output from when I try and connect: rad_recv: Access-Request packet from host 64.13.145.238:1024, id=96, length=71 User-Name = "dick" User-Password = "" NAS-IP-Address = 64.13.145.238 NAS-Identifier = "h2848-1" NAS-Port-Type = Virtual Service-Type = NAS-Prompt-User Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 hints: Matched DEFAULT at 35 <--- This is the correct entry modcall[authorize]: module "preprocess" returns ok for request 0 rlm_realm: No '@' in User-Name = "dick", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_realm: No '\' in User-Name = "dick", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "ntdomain" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 modcall[authorize]: module "files" returns notfound for request 0 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[aut
Troube with matching LDAP group membership in authorize
I'm trying to setup radius authentication for enable access on our networking gear and having a tough time getting a working config. I'd like to have FR check a group in LDAP for membership before authorizing. That is, I only want user's listed in the "uniquemember" attribute of the Operations group object to be granted access. Reading the FR docs this is possible -- I must be missing something. First, here are the relevant portions of my configs: Hint file: DEFAULT NAS-Port-Type == Virtual, Service-Type == NAS-Prompt-User, ldap_enable-Ldap-Group := "operations", Autz-Type := ldap_enable, Auth-Type := LDAP radius.conf: ldap ldap_enable{ server = "fds1.hq.powerset.com" basedn = "dc=powerset,dc=com" filter = "(uid=%{Stripped-User-Name:-%{User-Name}})" start_tls = yes tls_cacertfile = /opt/fedora-ds/alias/starfield.pem tls_require_cert= "demand" # Mapping of RADIUS dictionary attributes to LDAP # directory attributes. dictionary_mapping = ${raddbdir}/ldap.attrmap ldap_connections_number = 5 # ldap_debug = 1 #groupname_attribute = cn groupmembership_filter = "(&(objectClass=GroupOfUniqueNames)(uniquemember=%{Ldap-UserDn}))" timeout = 4 timelimit = 3 net_timeout = 3 # compare_check_items = yes # do_xlat = yes access_attr_used_for_allow = no set_auth_type = no } I have several LDAP instances defined in radius.config, but this is the one I want to use. I instantiate it first in radius.config so that hints can use it: instantiate { ldap_enable exec expr } And a corresponsing Autz-Type in radius.config: authorize { preprocess suffix ntdomain eap autztype ldap{ redundant { fds1 #fds2 } } autztype ldap_enable{ ldap_enable } files pap } Here's the debug output from when I try and connect: rad_recv: Access-Request packet from host 64.13.145.238:1024, id=96, length=71 User-Name = "dick" User-Password = "" NAS-IP-Address = 64.13.145.238 NAS-Identifier = "h2848-1" NAS-Port-Type = Virtual Service-Type = NAS-Prompt-User Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 hints: Matched DEFAULT at 35 <--- This is the correct entry modcall[authorize]: module "preprocess" returns ok for request 0 rlm_realm: No '@' in User-Name = "dick", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_realm: No '\' in User-Name = "dick", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "ntdomain" returns noop for request 0 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 0 modcall[authorize]: module "files" returns notfound for request 0 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 0 modcall: leaving group authorize (returns ok) for request 0 It appears that FR is ignoring the Autz-Type I set in hints and just processes the entries in authorize in sequential order. This is the default behavior unless an Autz-Type is explicitly set (which I do in hints). How do I get the Autz-Type to kick-in and have FR send the request to the proper LDAP entry? Thanks in advance, -richard Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html