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: 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
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
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
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[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
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
