1.1.6 xlat :- broken
I have a freeradius box (version 1.1.0) with the following (working) group
lookup.. On updating to 1.1.6 it appears the
%{Stripped-User-Name:-%{User-Name}} part is broken.. I see in cvs there is
an update to head, radiusd/src/main/xlat.c (1.115): make ':-' work again.. I
have not had luck trying to merge relevant changes to the 1.1 branch.. Could
this be fixed in stable?
-- radiusd.conf:
ldap {
...
gid =
%{ldap:ldap:///dc=domain,dc=com?gidNumber?sub?((uid=%{Stripped-User-Name:-%{User-Name}})(objectClass=%{Realm}))}
groupname_attribute = cn
groupmembership_filter =
((objectClass=posixGroup)(|(gidNumber=${gid})(memberUid=%{Stripped-User-Name:-%{User-Name}})))
do_xlat = yes
...
}
Debugging output:
rlm_ldap: Entering ldap_groupcmp()
radius_xlat: 'dc=domain,dc=com'
radius_xlat: Running registered xlat function of module ldap for string
'ldap:///dc=domain,dc=com?gidNumber?sub?((uid=%{Stripped-User-Name'
rlm_ldap: - ldap_xlat
radius_xlat: 'ldap:///dc=domain,dc=com?gidNumber?sub?((uid='
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in dc=domain,dc=com, with filter ((uid=
rlm_ldap: ldap_search() failed: Bad search filter: ((uid=
rlm_ldap: Search returned error
rlm_ldap: ldap_release_conn: Release Id: 0
radius_xlat:
'((objectClass=posixGroup)(|(gidNumber=mike)(objectClass=dialdomain)))(memberUid=mike)))'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in dc=domain,dc=com, with filter
((cn=dial1)((objectClass=posixGroup)(|(gidNumber=mike)(objectClass=dialdomain)))(memberUid=mike
rlm_ldap: ldap_search() failed: Bad search filter:
((cn=dial1)((objectClass=posixGroup)(|(gidNumber=mike)(objectClass=dialdomain)))(memberUid=mike
rlm_ldap: ldap_release_conn: Release Id: 0
rlm_ldap::ldap_groupcmp: Search returned error
Thanks,
-Mike
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
variable problem
In part of my ldap config section, I obtain the gid with an ldap lookup,
then use my ${gid} variable in the groupmembership_filter. Up until
recently I had simply been using %{User-Name}, but now have the need to
use the check for Stripped-User-Name before using User-Name. That works in
everywhere but my gid ldap lookup. I included my groupmembership_filter
line just to show the context of the ${gid} use.
Any pointers to what I may need to do differently is appreciated.
--
FreeRADIUS Version 1.1.0-pre0, for host i386-unknown-freebsd5.3, built on
Dec 17 2004 at 12:56:19
--
# radiusd.conf
gid = %{ldap1:ldap:///dc=domain,dc=com?gidNumber?sub?\
((uid=%{Stripped-User-Name:-%{User-Name}})(objectClass=%{Realm}))}
groupname_attribute = cn
groupmembership_filter =
((objectClass=posixGroup)(|(gidNumber=${gid})(memberUid=%{Stripped-User-Name:-%{User-Name}})))
--
# debugging output
--snip--
rlm_ldap: Entering ldap_groupcmp()
radius_xlat: 'dc=domain,dc=com'
radius_xlat: Running registered xlat function of module ldap1 for string
'ldap:///dc=domain,dc=com?gidNumber?sub?((uid=%{Stripped-User-Name'
rlm_ldap: - ldap_xlat
radius_xlat: 'ldap:///dc=domain,dc=com?gidNumber?sub?((uid=mike'
rlm_ldap: ldap_get_conn: Checking Id: 0
rlm_ldap: ldap_get_conn: Got Id: 0
rlm_ldap: performing search in dc=domain,dc=com, with filter
((uid=mike
rlm_ldap: ldap_search() failed: Bad search filter: ((uid=mike
rlm_ldap: Search returned error
--snip--
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: [BUG] NAS-IP-Address being resolved
In hints, NAS-IP-Address is IP. In sql.conf NAS-IP-Address is IP. When a SELECT query from sql.conf gets NASIPAdrress from an sql row, it resolves it to a hostname before using it to perform an UPDATE or INSERT for accounting stop when called by the zap function. When an accounting stop packet comes from the nas, NAS-IP-Address is an IP. On Tue, 27 Jul 2004, Alan DeKok wrote: Mike Sturdee [EMAIL PROTECTED] wrote: I am trying to use sql for the Simultaneous-Use check. I am seeing that the NAS-IP-Address is being resolved in some places, and used as IP in others. (I am thinking it should stay IP regardless). Hmm... all of the printing of IP addresses should go through one routine, which should obey the hostname_lookups configuration entry. Can you say *which* lookups return addresses, and which return names? In some places thoughout the config, the NAS-IP-Address is an IP address, and in other places it is a hostname. What config? There's a lot of configuration things in the server. Hostnames in clients.conf or proxy.conf shouldn't matter, as they don't affect the NAS-IP-Address attribute. I do have hostname_lookups = yes, but this should still not affect an IP variable (ie: remote_addr vs. remote_host). Uh, no. It's *intended* to affect the printing of ipaddr attributes, and not much else. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -Mike == Network Engineer Pathway Internet Services 616.774.3131 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
[BUG] NAS-IP-Address being resolved
I am trying to use sql for the Simultaneous-Use check. I am seeing that the NAS-IP-Address is being resolved in some places, and used as IP in others. (I am thinking it should stay IP regardless). Here's how it goes: -SQL query for UserName with AccountSessionTime of 0. |--Rows returned -Run checkrad to verify |--Stale session -Update SQL where Username AcctSessionId NASIPAddress |--At this point, the NASIPAddress returned from the initial select query has been resolved, so it will try and update where NASIPAddress='my.host.name' instead of NASIPAddress='1.2.3.4' as received from SQL. -Update query fails, so now it inserts a new session, with NASIPAddress being a truncated version of a host name. -Stale session still remains, so this process is repeated each and every time the user logs on. In some places thoughout the config, the NAS-IP-Address is an IP address, and in other places it is a hostname. I do have hostname_lookups = yes, but this should still not affect an IP variable (ie: remote_addr vs. remote_host). Having hostname_lookups on in 0.9.3 does not produce this result. -Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Feeding accounting logs into mysql
I just happen to have such a script.. it's based of something I found a year or so back, and modified quite a bit. It does the job for me. Unless you use USR/3com/name_of_the_week Total Control, you'll probably need to do some modifications. On Fri, 9 Jul 2004, Stephan von Krawczynski wrote: Hello all, has anybody a script at hand for feeding some (old) freeradius accounting log files into a mySQL db? I know I read somewhere about such a script... Thanks for any hints Stephan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -Mike == Network Engineer Pathway Internet Services 616.774.3131 parse_radius_detail.pl Description: Perl program
Re: Question about Freeradius and LDAP
how about setting up 2 ldap modules?
ldap people {
...
}
ldap students {
...
}
Not sure if this would do it, just a suggestion.
On Wed, 7 Jul 2004, Alexander M. Pravking wrote:
On Wed, Jul 07, 2004 at 09:00:00PM +0200, Arthur EBEL wrote:
Hi everybody,
My freeradius operate very well with an openldap directory
All ldap users stored in my basedn=ou=people,ou=personnels,dc=utt,dc=fr
can be authenticated.
I would like to add another basedn=ou=students,ou=personnels,dc=utt,dc=fr
BUT I don't want to give an access to all my tree dc=utt,dc=fr
How can I set up the LDAP module to do this ?
AFAIK, rlm_ldap cannot work with multiple basedn's.
However, you can use OpenLDAP own ACLs. E.g. in slapd.conf (assuming
you have identity=cn=radius,ou=robots,dc=utt,dc=fr):
access to dn ou=people,ou=personnels,dc=utt,dc=fr
...
by dn=cn=radius,ou=robots,dc=utt,dc=fr read
access to dn ou=students,ou=personnels,dc=utt,dc=fr
...
by dn=cn=radius,ou=robots,dc=utt,dc=fr read
access to *
by dn=cn=radius,ou=robots,dc=utt,dc=fr none
(I'm not sure this is totally correct so you should test it yourself.)
Then you can safely use basedn=ou=personnels,dc=utt,dc=fr for radius.
--
Fduch M. Pravking
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-Mike
==
Network Engineer
Pathway Internet Services
616.774.3131
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
mysql query log only.
Is it possible to have mysql accounting log the query statement (yes i know this part is possible) but NOT connect to the sql server? I need to take the mysql box down for maint and was thinking this would be the best possible way to not lose any records. -Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
accounting to mysql database
I have radius set up to log accounting to a MySQL database. It currently holds a couple years worth of logging from several thousand users, so it's quite large.. Problem I'm having is if I do a select that will return a couple hundred entries, or anything other than the simplest of queries, radius will freeze until the query is sql complete, resulting in any auth requests essentially to be rejected. FreeRadius 0.9.3 MySQL Server 4.0.17 (MyISAM tables) What might be causing this, or what could I do to resolve this? Thanks, -Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: add realm to user
I am doing: # match number ending in 123 DEFAULT Called-Station-Id =~ ^.*123$ Realm = realm1 # otherwise make it realm2 DEFAULT Realm = realm2 And _ALL_ are being assigned realm1 -Mike On Tue, 27 Jan 2004, Alan DeKok wrote: Mike Sturdee [EMAIL PROTECTED] wrote: I am trying to set the Realm attribute based on the Called-Station-Id. Doesn't look to work in users (not done soon enough). The users file updates the reply, and the check items. The Realm is usually a property of the request list, so the users file can't add it there. Does the hints file support regex comparisons? It supports attributes and operators, which includes regexes. I am needing the realm set before radiusd reaches the authentication / authorization modules. Uh... the preprocess module is in authorize, and is the module which handles hints. In the hints file, you should be able to do: DEFAULTCalled-Station-Id =~ foo.*bar Realm = foo Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: add realm to user
Alan, It works as I want it. Thanks! -Mike On Wed, 28 Jan 2004, Alan DeKok wrote: Mike Sturdee [EMAIL PROTECTED] wrote: I am doing: # match number ending in 123 DEFAULT Called-Station-Id =~ ^.*123$ You don't need the ^.* piece. Realm = realm1 # otherwise make it realm2 DEFAULT Realm = realm2 And _ALL_ are being assigned realm1 Cute. On closer inspection of the source, the hints file does little other than prefix and suffix comparisons. Hmm... it shouldn't be too hard to change that. It will probably even be less code. See: http://www.striker.ottawa.on.ca/~aland/rlm_preprocess.c It contains changes which shouldn't break the old functionality, but should also add the functionality you want (and which makes sense) If it works and doesn't change the way it processes old hints files, mail the list, and I'll commit the changes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
add realm to user
I am trying to set the Realm attribute based on the Called-Station-Id. Doesn't look to work in users (not done soon enough). Does the hints file support regex comparisons? I am needing the realm set before radiusd reaches the authentication / authorization modules. thanks -Mike - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
multiple module lookups when only one should be used
users that dial into a number ending in 195 get the correct Auth-Type
Autz-Type, as do other calls that need to auth off of LDAP1. Problem is,
when I have the LDAP2 instances in authorize {} authenticate {}, users
authing off of LDAP1 do not get the correct group attributes per the group
lookup in module instance ldap1. when radiusd is in debug mode, it shows
the LDAP1 users going through both the ldap1 and ldap2 module instances..
Am I right in thinking it should only go through one or the other when
Auth-Type is set as such?
-Mike
#radiusd.conf
-
modules {
ldap ldap1 {
...
}
ldap ldap2 {
...
}
}
authorize {
Autz-Type LDAP1 {
ldap1
}
Autz-Type LDAP2 {
ldap2
}
}
authenticate {
Auth-Type LDAP1 {
ldap1
}
Auth-Type LDAP2 {
ldap2
}
}
-
# users
-
DEFAULT Called-Station-Id =~ 195$, Auth-Type := LDAP2, Autz-Type :=
LDAP2
etc
DEFAULT Auth-Type := LDAP1, Autz-Type := LDAP1
Fall-Through = Yes
DEFAULT Auth-Type := LDAP1, Autz-Type := LDAP1, Ldap-Group == dial1
...etc
DEFAULT Auth-Type := LDAP1, Autz-Type := LDAP1, Ldap-Group == dial2
etc
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
