Re: restricting users using huntgroup
Alan Kong wrote: > I want to use huntgroup to restrict users connecting. If the user is > added in huntgroup and login and clear password was entered in users > file, the user has no problem in accessing. When I add another user in > huntgroup but using Unix password file to authenticate, I keep getting > invalid user in radius log. Could you please advise on possible solution. Run the server in debugging mode to see what's going on. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
restricting users using huntgroup
Hi, I want to use huntgroup to restrict users connecting. If the user is added in huntgroup and login and clear password was entered in users file, the user has no problem in accessing. When I add another user in huntgroup but using Unix password file to authenticate, I keep getting invalid user in radius log. Could you please advise on possible solution. "huntgroups" file: erg-rbs NAS-Identifier == ERG-RBS User-Name == csetest, (No problem) User-Name == akong "users" file: csetest NAS-Identifier == "ERG-RBS", Cleartext-Password := "test" Fall-Through = No #DEFAULT Auth-Type == PAP, Huntgroup-Name == "erg-rbs" DEFAULT Auth-Type == System, Huntgroup-Name == "erg-rbs" Thank you. Regards Alan -- "Happy people say Thank You! They Live with a Feeling of Gratitude." - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: errors when check with huntgroup
hi, add 'preprocess' to top of your authorize section in inner-tunnel ? alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: errors when check with huntgroup
Hi, > Subject: Re: errors when check with huntgroup > > > hi, > > you've edited a whole lot of stuff out of your debug log...including > the stuff which actually matters where the failure actually occurs > (you just kept the part where the end result was recorded). > > alan > Below the full output (radiusd -X) when user access is rejected. I compared with the output when successed and it differs from the one below with"++[files] returns noop " I put the words " <<<=== FIRST DIFFERENCE" to find it easily. users file contains : bp3 Cleartext-Password := "test" , Calling-Station-Id == "844b.f5b8.d423" , Cisco-AVPair == "ssid=ipl_dsi" , Huntgroup-Name == "wifi" with : , Huntgroup-Name == "wifi" when the reject occurs. huntgroup file contains : wifiNAS-IP-Address == 172.20.100.53 Thanks for any help. Bertrand. radiusd -X FreeRADIUS Version 2.2.0, for host i686-pc-linux-gnu, built on Mar 11 2013 at 13:51:19 Copyright (C) 1999-2012 The FreeRADIUS server project and contributors. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. You may redistribute copies of FreeRADIUS under the terms of the GNU General Public License v2. Starting - reading configuration files ... including configuration file /usr/local/etc/raddb/radiusd.conf including configuration file /usr/local/etc/raddb/proxy.conf including configuration file /usr/local/etc/raddb/clients.conf including files in directory /usr/local/etc/raddb/modules/ including configuration file /usr/local/etc/raddb/modules/mac2ip including configuration file /usr/local/etc/raddb/modules/smbpasswd including configuration file /usr/local/etc/raddb/modules/preprocess including configuration file /usr/local/etc/raddb/modules/mschap including configuration file /usr/local/etc/raddb/modules/dhcp_sqlippool including configuration file /usr/local/etc/raddb/sql/mysql/ippool-dhcp.conf including configuration file /usr/local/etc/raddb/modules/always including configuration file /usr/local/etc/raddb/modules/passwd including configuration file /usr/local/etc/raddb/modules/ntlm_auth including configuration file /usr/local/etc/raddb/modules/cache including configuration file /usr/local/etc/raddb/modules/detail.example.com including configuration file /usr/local/etc/raddb/modules/pam including configuration file /usr/local/etc/raddb/modules/ippool including configuration file /usr/local/etc/raddb/modules/expr including configuration file /usr/local/etc/raddb/modules/realm including configuration file /usr/local/etc/raddb/modules/files including configuration file /usr/local/etc/raddb/modules/radrelay including configuration file /usr/local/etc/raddb/modules/radutmp including configuration file /usr/local/etc/raddb/modules/mac2vlan including configuration file /usr/local/etc/raddb/modules/attr_filter including configuration file /usr/local/etc/raddb/modules/detail.log including configuration file /usr/local/etc/raddb/modules/sql_log including configuration file /usr/local/etc/raddb/modules/perl including configuration file /usr/local/etc/raddb/modules/replicate including configuration file /usr/local/etc/raddb/modules/wimax including configuration file /usr/local/etc/raddb/modules/linelog including configuration file /usr/local/etc/raddb/modules/sqlcounter_expire_on_login including configuration file /usr/local/etc/raddb/modules/expiration including configuration file /usr/local/etc/raddb/modules/checkval including configuration file /usr/local/etc/raddb/modules/otp including configuration file /usr/local/etc/raddb/modules/inner-eap including configuration file /usr/local/etc/raddb/modules/sradutmp including configuration file /usr/local/etc/raddb/modules/etc_group including configuration file /usr/local/etc/raddb/modules/digest including configuration file /usr/local/etc/raddb/modules/counter including configuration file /usr/local/etc/raddb/modules/attr_rewrite including configuration file /usr/local/etc/raddb/modules/ldap including configuration file /usr/local/etc/raddb/modules/chap including configuration file /usr/local/etc/raddb/modules/acct_unique including configuration file /usr/local/etc/raddb/modules/redis including configuration file /usr/local/etc/raddb/modules/unix including configuration file /usr/local/etc/raddb/modules/echo including configuration file /usr/local/etc/raddb/modules/exec including configuration file /usr/local/etc/raddb/modules/dynamic_clients including configuration file /usr/local/etc/raddb/modules/soh including configuration file /usr/local/etc/raddb/modules/pap including configuration file /usr/local/etc/raddb/modules/krb5 including configuration file /usr/local/etc/raddb/modules/rediswho including configuration file /usr/local/etc/raddb/modules/logintime including configuration file /usr/local/etc/raddb/modules/policy including configuration file /usr/local/
Re: errors when check with huntgroup
hi, you've edited a whole lot of stuff out of your debug log...including the stuff which actually matters where the failure actually occurs (you just kept the part where the end result was recorded). alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
errors when check with huntgroup
Hi all,
I' ve a problem when i want to check user with huntgroup :
bp3 User-Password := "test" , Calling-Station-Id ==
"844b.f5b8.d423" is Ok
but not :
bp3 User-Password := "test" , Calling-Station-Id == "844b.f5b8.d423"
, Huntgroup-Name == "wifi"
I read something like that in mailing list and it said that it could be :
"as Alan said, inside the TLS tunnel the huntgroup check was failing.
As the users file is checked on the first requests received, and the
wrong huntgroup filtered out, it is not necessary to check it again
inside the tunnel. I have removed it from my configuration and it is
working ok now."
What has been removed from the configuration ?
partial ooutput :
root@maxwell:/usr/local/etc/raddb# radiusd -X
FreeRADIUS Version 2.2.0, for host i686-pc-linux-gnu, built on Mar 11
2013 at 13:51:19
...
Module: Instantiating module "preprocess" from file
/usr/local/etc/raddb/modules/preprocess
preprocess {
huntgroups = "/usr/local/etc/raddb/huntgroups"
hints = "/usr/local/etc/raddb/hints"
with_ascend_hack = no
ascend_channels_per_line = 23
with_ntdomain_hack = no
with_specialix_jetstream_hack = no
with_cisco_vsa_hack = no
with_alvarion_vsa_hack = no
}
reading pairlist file /usr/local/etc/raddb/huntgroups
reading pairlist file /usr/local/etc/raddb/hints
...
Listening on authentication address 127.0.0.1 port 18120 as server
inner-tunnel
Listening on proxy address * port 1814
Ready to process requests.
rad_recv: Access-Request packet from host 172.20.100.53 port 1645,
id=199, length=162
User-Name = "bp3"
Framed-MTU = 1400
Called-Station-Id = "0014.1bb6.4be0"
Calling-Station-Id = "844b.f5b8.d423"
Cisco-AVPair = "ssid=ipl_dsi"
Service-Type = Login-User
Message-Authenticator = 0xab5216a12cd14981035afde9d25910ae
EAP-Message = 0x0202000801627033
NAS-Port-Type = Wireless-802.11
Cisco-NAS-Port = "748"
NAS-Port = 748
NAS-IP-Address = 172.20.100.53
NAS-Identifier = "net-ap-A1-1-53"
# Executing section authorize from file
/usr/local/etc/raddb/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "bp3", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] EAP packet type response id 2 length 8
[eap] No EAP Start, assuming it's an on-going EAP conversation
++[eap] returns updated
[files] users: Matched entry bp3 at line 213
...
[peap] EAPTLS_OK
[peap] Session established. Decoding tunneled attributes.
[peap] Peap state WAITING FOR INNER IDENTITY
[peap] Identity - bp3
[peap] Got inner identity 'bp3'
++[eap] returns reject
Failed to authenticate the user.
} # server inner-tunnel
...
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup Checking
I'm having the very same issue, and can't understand why.
If the Huntgroup-Name value is in radcheck the limitation is done correctly,
but it is not when the Huntgroup-Name is in radgroupcheck, while the example
here [1] is exactly with radgroupcheck.
The proposed change doesn't work, also because it's not relevant.
As per the example in the url:
example user is in group site_a_admins (radusergroup)
site_a is in radhuntgroup
have in radgroupcheck:
site_a_admins Huntgroup-Name == site_a
access is allowed anywhere.
If you move the check in radcheck, like:
example user Huntgroup-Name == site_a
then the check is performed correctly.
The proposed modification to the group check query just adds huntgroup's
properties to the request.
thanks
[1] http://wiki.freeradius.org/guide/SQL_Huntgroup_HOWTO
- Messaggio originale -
> Da: "Ben West"
> A: "FreeRadius users mailing list"
> Inviato: Mercoledì, 2 novembre 2011 15:22:25
> Oggetto: Huntgroup Checking
>
> You may need to inspect whether the groupcheck query in
> mysql/dailup.conf (if you are using MySQL) looks in the huntgroup
> table.
>
> For example, this is the default query in my copy of freeRADIUS
> provided by Debian:
>
> authorize_group_check_query = "SELECT id, groupname, attribute, \
> Value, op \
> FROM ${groupcheck_table} \
> WHERE groupname = '%{Sql-Group}' \
> ORDER BY id"
>
> Try modifying it as such:
>
> authorize_group_check_query = "SELECT id, groupname, attribute, \
> value, op \
> FROM ${groupcheck_table} \
> WHERE ( groupname = '%{Sql-Group}' \
> OR groupname = '%{Huntgroup-Name}' ) \
> ORDER BY id"
>
>
> On Wed, Nov 2, 2011 at 9:07 AM, simonm123 wrote:
> > Can anyone tell me if hungroup checking can be made to work on the group
> > level, not just the user level?
> >
> > Thanks
> >
> > --
> > View this message in context:
> > http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-tp4950385p4958155.html
> > Sent from the FreeRadius - User mailing list archive at Nabble.com.
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
> >
>
>
>
> --
> Ben West
> westbyw...@gmail.com
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
>
--
--
Lorenzo Milesi - lorenzo.mil...@yetopen.it
YetOpen S.r.l. - http://www.yetopen.it/
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HuntGroup check in radgroupcheck
Summarizing:
Nas:
4 109.70.200.xyop101 other NULLSECRET NULLNULL
YetOpen NAS 01 TEST
5 109.69.131.xufficyo01 other NULLSECRET NULLNULL
RADIUS Client
6 1.2.3.4 hg01other NULLyetopen-radsecret
NULLNULLRADIUS Client
7 1.2.3.5 hg02other NULLyetopen-radsecret
NULLNULLRADIUS Client
RadHuntgroup:
1 ufficyohg 109.69.131.xNULL
2 maxxerhg109.70.200.xNULL
3 hg011.2.3.4 NULL
4 hg021.2.3.5 NULL
Radgroupcheck:
10 federazione Huntgroup-Name =~ ufficyohg|maxxerhg
11 federazione2Huntgroup-Name =~ hg02|hg01
Radusergroup:
34 F0073404federazione210
full debug of a test login from 1.2.3.5 and a second from 109.70.200.x, they
are both accepted :(
FreeRADIUS Version 2.1.10, for host x86_64-pc-linux-gnu, built on Sep 11 2012
at 17:06:46
Copyright (C) 1999-2009 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License v2.
Starting - reading configuration files ...
including configuration file /etc/freeradius/radiusd.conf
including configuration file /etc/freeradius/proxy.conf
including configuration file /etc/freeradius/clients.conf
including files in directory /etc/freeradius/modules/
including configuration file /etc/freeradius/modules/exec
including configuration file /etc/freeradius/modules/radutmp
including configuration file /etc/freeradius/modules/krb5
including configuration file /etc/freeradius/modules/detail.log
including configuration file /etc/freeradius/modules/smbpasswd
including configuration file /etc/freeradius/modules/checkval
including configuration file /etc/freeradius/modules/ntlm_auth
including configuration file /etc/freeradius/modules/smsotp
including configuration file /etc/freeradius/modules/sradutmp
including configuration file /etc/freeradius/modules/preprocess
including configuration file /etc/freeradius/modules/attr_rewrite
including configuration file /etc/freeradius/modules/ippool
including configuration file /etc/freeradius/modules/sql_log
including configuration file /etc/freeradius/modules/chap
including configuration file /etc/freeradius/modules/etc_group
including configuration file /etc/freeradius/modules/cui
including configuration file /etc/freeradius/modules/unix
including configuration file /etc/freeradius/modules/mac2ip
including configuration file /etc/freeradius/modules/logintime
including configuration file /etc/freeradius/modules/sqlcounter_expire_on_login
including configuration file /etc/freeradius/modules/realm
including configuration file /etc/freeradius/modules/opendirectory
including configuration file /etc/freeradius/modules/acct_unique
including configuration file /etc/freeradius/modules/counter
including configuration file /etc/freeradius/modules/attr_filter
including configuration file /etc/freeradius/modules/always
including configuration file /etc/freeradius/modules/files
including configuration file /etc/freeradius/modules/inner-eap
including configuration file /etc/freeradius/modules/perl
including configuration file /etc/freeradius/modules/pap
including configuration file /etc/freeradius/modules/passwd
including configuration file /etc/freeradius/modules/echo
including configuration file /etc/freeradius/modules/dynamic_clients
including configuration file /etc/freeradius/modules/detail.example.com
including configuration file /etc/freeradius/modules/policy
including configuration file /etc/freeradius/modules/pam
including configuration file /etc/freeradius/modules/expiration
including configuration file /etc/freeradius/modules/mschap
including configuration file /etc/freeradius/modules/mac2vlan
including configuration file /etc/freeradius/modules/linelog
including configuration file /etc/freeradius/modules/expr
including configuration file /etc/freeradius/modules/otp
including configuration file /etc/freeradius/modules/ldap
including configuration file /etc/freeradius/modules/wimax
including configuration file /etc/freeradius/modules/digest
including configuration file /etc/freeradius/modules/detail
including configuration file /etc/freeradius/eap.conf
including configuration file /etc/freeradius/sql.conf
including configuration file /etc/freeradius/sql/mysql/dialup.conf
including configuration file /etc/freeradius/sql/mysql/counter.conf
including configuration file /etc/freeradius/policy.conf
including files in directory /etc/freeradius/sites-enabled/
including configuration file /etc/freeradius/sites-enabled/default
main {
user = "freerad"
group = "freerad"
allow_core_dumps = no
}
including dictionary file /etc/freeradius/dictionary
main {
Re: HuntGroup check in radgroupcheck
> The debug output should be posted here. There's no reason put a
> zipped version on a separate web site.
I just wanted to write a more "clean" email. Here it is...
Listening on authentication address * port 1812
Listening on accounting address * port 1813
Listening on proxy address * port 1814
Ready to process requests.
rad_recv: Access-Request packet from host 127.0.0.1 port 50056, id=46, length=66
User-Name = "F001"
User-Password = "002784226600"
NAS-IP-Address = 109.70.200.xxx
NAS-Port = 0
Framed-Protocol = PPP
# Executing section authorize from file /etc/freeradius/sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
sql_xlat
expand: %{User-Name} -> F001
sql_set_user escaped user --> 'F001'
expand: SELECT groupname FROM radhuntgroup WHERE
nasipaddress='%{NAS-IP-Address}' -> SELECT groupname FROM radhuntgroup WHERE
nasipaddress='109.70.200.xxx'
rlm_sql (sql): Reserving sql socket id: 3
sql_xlat finished
rlm_sql (sql): Released sql socket id: 3
expand: %{sql:SELECT groupname FROM radhuntgroup WHERE
nasipaddress='%{NAS-IP-Address}'} -> nas04
++[request] returns ok
++? if (Huntgroup-Name == '')
? Evaluating (Huntgroup-Name == '') -> FALSE
++? if (Huntgroup-Name == '') -> FALSE
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "F001", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 172
++[files] returns ok
[sql] expand: %{User-Name} -> F001
[sql] sql_set_user escaped user --> 'F001'
rlm_sql (sql): Reserving sql socket id: 2
[sql] expand: SELECT id, username, attribute, value, op FROM
radcheck WHERE username = '%{SQL-User-Name}' ORDER BY id ->
SELECT id, username, attribute, value, op FROM radcheck
WHERE username = 'F001' ORDER BY id
[sql] User found in radcheck table
[sql] expand: SELECT id, username, attribute, value, op FROM
radreply WHERE username = '%{SQL-User-Name}' ORDER BY id ->
SELECT id, username, attribute, value, op FROM radreply
WHERE username = 'F001' ORDER BY id
[sql] expand: SELECT groupname FROM radusergroup WHERE
username = '%{SQL-User-Name}' ORDER BY priority -> SELECT groupname
FROM radusergroup WHERE username = 'F001' ORDER
BY priority
[sql] expand: SELECT id, groupname, attribute, Value, op
FROM radgroupcheck WHERE groupname = '%{Sql-Group}' OR
groupname = '%{Huntgroup-Name}' ORDER BY id -> SELECT id, groupname,
attribute, Value, op FROM radgroupcheck WHERE
groupname = 'huntgroup01' OR groupname = 'nas04' ORDER BY
id
[sql] expand: %{Huntgroup-Name} -> nas04
rlm_sql (sql): Released sql socket id: 2
++[sql] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing MD5-Password from hex encoding
++[pap] returns updated
rlm_sqlcounter: Entering module authorize code
rlm_sqlcounter: Could not find Check item value pair
++[noresetcounter] returns noop
rlm_sqlcounter: Entering module authorize code
rlm_sqlcounter: Could not find Check item value pair
++[dailycounter] returns noop
rlm_sqlcounter: Entering module authorize code
rlm_sqlcounter: Could not find Check item value pair
++[monthlycounter] returns noop
Found Auth-Type = PAP
# Executing group from file /etc/freeradius/sites-enabled/default
+- entering group PAP {...}
[pap] login attempt with password "002784226600"
[pap] Using MD5 encryption.
[pap] User authenticated successfully
++[pap] returns ok
# Executing section post-auth from file /etc/freeradius/sites-enabled/default
+- entering group post-auth {...}
[sql] expand: %{User-Name} -> F001
[sql] sql_set_user escaped user --> 'F001'
[sql] expand: %{User-Password} -> 002784226600
[sql] expand: INSERT INTO radpostauth (username,
pass, reply, authdate) VALUES (
'%{User-Name}',
'%{%{User-Password}:-%{Chap-Password}}',
'%{reply:Packet-Type}', '%S') -> INSERT INTO radpostauth
(username, pass, reply, authdate) VALUES (
'F001', '002784226600',
Re: HuntGroup check in radgroupcheck
Lorenzo Milesi wrote: >> Post the debug output, as suggested in the FAQ, "man" page, web >> pages, and daily on this list. > > I posted the freeradius -X output into the linked file... Aren't you > referring to that? The debug output should be posted here. There's no reason put a zipped version on a separate web site. > According to [1] huntgroups can be checked via SQL as well... > From the debug output i posted here [2] you can see the huntgroup is > correctly identified from SQL... > > [1] http://wiki.freeradius.org/guide/SQL_Huntgroup_HOWTO That works, too. > [2] https://dl.dropbox.com/u/706934/check01.gz Please post the relevant bits here. If you make it hard for me to help you, I'll just ignore your messages. > I omitted to say that in my radhuntgroup table I defined HG with the same > names as nases in the nas table. Can this be a problem? No. It helps to state *accurately* what you're doing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HuntGroup check in radgroupcheck
Lorenzo Milesi wrote: > I'm trying to manage Huntgroup checking into radgroupcheck table, but doesn't > seem to work. Post the debug output, as suggested in the FAQ, "man" page, web pages, and daily on this list. > Given the following properties: > radcheck: > F01 MD5-Password := somemd5hash > radusergroup > F01 HuntGroup01 > radgroupcheck > F01 Huntgroup-Name =~ nas04|nas05 > > the user is always authenticated, even if the connection comes from a nas > which is not nas04 or nas05. I think you're confused about huntgroups. NASes are placed into huntgroups via the "huntgroups" file. Not SQL. When you check group membership, you check for the huntgroup name, not the NAS name. You're using Huntgroup-Name to check the *nas* name. It won't work. > In addition to that, can I set a certain property (i.e. > WISPr-Session-Terminate-Time) only if the user connects to a specific > huntgroup? Yes. Do a huntgroup check (correctly), and set the reply attribute if it matches. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HuntGroup check in radgroupcheck
> Post the debug output, as suggested in the FAQ, "man" page, web > pages, and daily on this list. I posted the freeradius -X output into the linked file... Aren't you referring to that? > > > Given the following properties: > > radcheck: > > F01 MD5-Password := somemd5hash > > radusergroup > > F01 HuntGroup01 > > radgroupcheck > > F01 Huntgroup-Name =~ nas04|nas05 > > > > the user is always authenticated, even if the connection comes from > > a nas which is not nas04 or nas05. > > I think you're confused about huntgroups. NASes are placed into > huntgroups via the "huntgroups" file. Not SQL. When you check group > membership, you check for the huntgroup name, not the NAS name. According to [1] huntgroups can be checked via SQL as well... >From the debug output i posted here [2] you can see the huntgroup is correctly >identified from SQL... [1] http://wiki.freeradius.org/guide/SQL_Huntgroup_HOWTO [2] https://dl.dropbox.com/u/706934/check01.gz > You're using Huntgroup-Name to check the *nas* name. It won't > work. I omitted to say that in my radhuntgroup table I defined HG with the same names as nases in the nas table. Can this be a problem? thanks -- Lorenzo Milesi - lorenzo.mil...@yetopen.it GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
HuntGroup check in radgroupcheck
Hi. I'm trying to manage Huntgroup checking into radgroupcheck table, but doesn't seem to work. Given the following properties: radcheck: F01 MD5-Password := somemd5hash radusergroup F01 HuntGroup01 radgroupcheck F01 Huntgroup-Name =~ nas04|nas05 the user is always authenticated, even if the connection comes from a nas which is not nas04 or nas05. If I place the Huntgroup-Name property in the radcheck the user is correctly limited to the selected NASes. Output of the accounting session of "freeradius -X" attached here: https://dl.dropbox.com/u/706934/check01.gz The results of the ran queries: SELECT id, username, attribute, value, op FROM radcheck WHERE username = 'F001' ORDER BY id F01 Md5-Password := xxx SELECT id, username, attribute, value, op FROM radreply WHERE username = 'F001' ORDER BY id (empty) SELECT groupname FROM usergroup WHERE username = 'F001' ORDER BY id huntgroup01 SELECT id, groupname, attribute, Value, op FROM radgroupcheck WHERE groupname = 'huntgroup01' OR groupname = 'nas04' ORDER BY id huntgroup01 Huntgroup-Name nas01|nas02 =~ The final query correctly returns the list of nases the user is allowed to login to, but apparently it's not considered. Why this? what am I missing? In addition to that, can I set a certain property (i.e. WISPr-Session-Terminate-Time) only if the user connects to a specific huntgroup? thanks -- Lorenzo Milesi - lorenzo.mil...@yetopen.it GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Replace NAS-Identifier with Huntgroup
Hi, > I was wondering, is it possible to replace the NAS-Identifier features by > playing with Huntgroups? > The idea is to have one user which can access in several NAS with customized > params, and this is what HG are for. But how to Reject the user, if it has no > associated HG? its an attribute so just use it. add your NAS'es to the huntgroup and then use the huntgroup in comparisons alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Replace NAS-Identifier with Huntgroup
> customized params, and this is what HG are for. But how to Reject
> the user, if it has no associated HG?
Ok I found searching more that I can achieve this by adding:
if (Huntgroup-Name == ''){
reject
}
--
Lorenzo Milesi - lorenzo.mil...@yetopen.it
GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Replace NAS-Identifier with Huntgroup
Hi. I was wondering, is it possible to replace the NAS-Identifier features by playing with Huntgroups? The idea is to have one user which can access in several NAS with customized params, and this is what HG are for. But how to Reject the user, if it has no associated HG? I'm having some troubles in fully understanding HuntGroups, as the wiki pages looks only partial. Is there any other documentation source? thanks -- Lorenzo Milesi - lorenzo.mil...@yetopen.it GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HuntGroup in FR1
Lorenzo Milesi wrote: >> You defined the huntgroup. You didn't *use* it to limit sessions. >> >> In the "users" file: >> >> DEFAULT Huntgroup-Name == maxxer, Max-Daily-Session := 60 > > Can I use SQL to define HG properties? No. Huntgroups are defined in the huntgroup file. You use the SQL-Group attribute to check groups in SQL. > I.e. setting Max-Daily-Session in radgroupcheck? Or should it be radcheck? See the group configurations && schema in SQL. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HuntGroup in FR1
> You defined the huntgroup. You didn't *use* it to limit sessions. > > In the "users" file: > > DEFAULT Huntgroup-Name == maxxer, Max-Daily-Session := 60 Can I use SQL to define HG properties? I.e. setting Max-Daily-Session in radgroupcheck? Or should it be radcheck? thanks! -- Lorenzo Milesi - lorenzo.mil...@yetopen.it GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: HuntGroup in FR1
Lorenzo Milesi wrote:
> I need to give user specific limitation based on where they connect to.
> I.e. I have two nas where the user can roam to, but when he logs into hs A he
> gets Max-Daily-Session := 60, while on B has no daily limit.
>
> Based on research, this should be done with Huntgroup. Current wiki page [1]
> doesn't eplain very much...
> I appended
> maxxer NAS-IP-Address == 87.24.AA.BB
> to /etc/freeradius/huntgroups
>
> In radiusd.conf, preprocess section, I have
> huntgroups = ${confdir}/huntgroups
>
> Running freeradius -x I see it reads huntgroups file, but if I try logging in
> to the NAS at ip 87.24.AA.BB the user doesn't get any special property.
You defined the huntgroup. You didn't *use* it to limit sessions.
In the "users" file:
DEFAULT Huntgroup-Name == maxxer, Max-Daily-Session := 60
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
HuntGroup in FR1
Hi.
I need to give user specific limitation based on where they connect to.
I.e. I have two nas where the user can roam to, but when he logs into hs A he
gets Max-Daily-Session := 60, while on B has no daily limit.
Based on research, this should be done with Huntgroup. Current wiki page [1]
doesn't eplain very much...
I appended
maxxer NAS-IP-Address == 87.24.AA.BB
to /etc/freeradius/huntgroups
In radiusd.conf, preprocess section, I have
huntgroups = ${confdir}/huntgroups
Running freeradius -x I see it reads huntgroups file, but if I try logging in
to the NAS at ip 87.24.AA.BB the user doesn't get any special property.
(Sadly) I'm (still) using FreeRadius 1.1.x.
What did I do wrong?
thanks
[1] http://wiki.freeradius.org/config/Huntgroups
--
Lorenzo Milesi - lorenzo.mil...@yetopen.it
GPG/PGP Key-Id: 0xE704E230 - http://keyserver.linux.it
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Authenticating users checking Huntgroup-Name in unlang
Hi,
I have set FreeRadius 2.1.12 Server, and configured it to authorize and
authenticate users that are in Active Directory and users file. I have tested
in real wireless environment to authenticate users from Active Directory &
users file and it is successful. But according to our organization's
requirement I need to authenticate users to allow or reject users for wireless
or VPN access checking huntgroups and attribute in AD or users file accordingly
so, I have configured huntgroup name in huntgroups "wirelesstest" and have
configured my NAS-IP-Address as: (Some names & IP Address are edited for
privacy)
/usr/local/etc/raddb/huntgroups
wirelesstestNAS-IP-Address == IP Address
wirelesstestNAS-IP-Address == IP Address
wirelesstestNAS-IP-Address == IP Address
Clients are configured in clients.conf file as:
/usr/local/etc/raddb/clients.conf
client Primary_controller{
ipaddr = IP Address
secret = password
shortname = primary
nastype = enterasys
}
In default & inner_tunnel files configurations, unlang conditional checking are
done under ldap & files sub-sections of "authorize" section
/usr/local/etc/raddb/sites-enabled/default and
/usr/local/etc/raddb/sites-enabled/inner-tunnel
authorize {
.
ldap
if ("%{Huntgroup-Name}" == "wirelesstest"){
if (control:Connect-Type == wireless){
update control {
Auth-Type := "Accept"
}
}
else {
update control {
Auth-Type := "Reject"
}
}
}
files
if ("%{Huntgroup-Name}" == "wirelesstest"){
if (control:Connect-Type == wireless){
update control {
Auth-Type := "Accept"
}
}
else {
update control {
Auth-Type := "Reject"
}
}
}
While testing through radtest it works as expected. Unlang condition is
checked, and attribute is also checked against Active Directory or users file
and authenticate users if it matches and it rejects if it doesn't match.
But in Real wireless environment testing I don't get any response at Client
side, and after long time it says can't connect. But while checking at debug
log doing radiusd -X it shows it is checking the condition and sending
Access-Accept or Access-Reject accordingly.
I tried different conditional checkings in unlang; checking against shortname
as:
if ("%{client:shortname}" =~ /^primary/){
checking against huntgroup as:
if ("%{client:huntgroup}" == "wireless"){
But any of these setting gives me no response at client side although my debug
log shows the condition is being checked and Access-Accept ot Access-Reject is
sent.
Part of debug log is as follows:
Found Auth-Type = EAP
# Executing group from file /usr/local/etc/raddb/sites-enabled/default
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/ttls
[eap] processing type ttls
[ttls] Authenticate
[ttls] processing EAP-TLS
[ttls] eaptls_verify returned 7
[ttls] Done initial handshake
[ttls] eaptls_process returned 7
[ttls] Session established. Proceeding to decode tunneled attributes.
[ttls] Got tunneled request
User-Name = "test"
User-Password = "password"
FreeRADIUS-Proxied-To = 127.0.0.1
[ttls] Sending tunneled request
User-Name = "test"
User-Password = "password"
FreeRADIUS-Proxied-To = 127.0.0.1
NAS-IP-Address = IP Address
NAS-Port = 116
Framed-MTU = 1400
Called-Station-Id = "00:1e:35:7f:ec:35"
Calling-Station-Id = "00:35:5c:68:c0:08"
NAS-Port-Type = Wireless-802.11
NAS-Identifier = "Wireless_Test"
Service-Type = Framed-User
Siemens-AP-Serial = "0600010084050956"
Siemens-AP-Name = "TEST"
Siemens-VNS-Name = "Wireless_Test"
Siemens-SSID = "Wireless_Test"
Siemens-BSS-MAC = "00:1e:35:7f:ec:35"
server inner-tunnel {
# Executing section authorize from file
/usr/local/etc/raddb/sites-enabled/inner-tunnel
+- entering group authorize {...}
++[mschap] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[ldap] performing user authorization for test
[ldap] expand: %{Stripped-User-Name} ->
[ldap] ... expanding second conditional
[ldap] expand: %{User-Name} -> test
[ldap] expand: (sAMAccountName=%{%{Stripped-User-Name}:-%{User-Name}}) ->
(sAMAccountName=test)
[ldap] expand: dc=example,dc=com -> dc=example,dc=com
[ldap] ldap_get_conn: Checking Id: 0
[ldap] ldap_get_conn: Got Id: 0
[ldap] performing search in dc=example,dc=com, with filter
(sAMAccountName=test)
[ldap] looking for check items in directory...
[l
Re: Huntgroup Implementation with MySQL and Radgroupcheck
Hi Phil, thanks for the reply and help. Have been in a pickle with this for an age.Could you confirm that the query at the bottom should go in the sites-available/default file in the auth section?Huntgroups work with radcheck but understand I need a separate attr now (at last)!On Jul 26, 2012, at 10:07 AM, Phil Mayers wrote:On 07/26/2012 09:51 AM, Jenny Blunt wrote: > I'm looking for some help with the implementation of huntgroups. > > Am using mysql and have followed the following topic through: > > > http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-td4950385.html > > In sites-available/default I have this, (just after preprocess: > > update request { > Huntgroup-Name := "%{sql:SELECT `groupname` FROM > `radhuntgroup` WHERE nasipaddress='%{NAS-IP-Address}'}" > } Don't do this. Read the 2nd email in the thread you linked to. Huntgroup-Name is a special attribute; comparisons are executed dynamically. You can't just use it like an ordinary string attribute. Define another attribute in raddb/dictionary: ATTRIBUTE SQL-Location 3010 string ...and use that. > authorize_group_check_query = "SELECT id, groupname, attribute_name, \ > Value, op \ > FROM ${groupcheck_table} \ > WHERE ( groupname = '%{Sql-Group}' OR groupname = > '%{Huntgroup-Name}' ) \ > ORDER BY id" > > (Which doesn't make logical sense to me) It doesn't make sense to me either. So why do it? > > What I'm failing to get my head around is how to reject or allow access > based on the location their dialing in from? > > For example, a user from IP 1.x.x.x should be allowed access at location > 1 only. I don't know what this means. Write down the policy you want in plain english. Figure out what sources of data you need to execute that policy. Read those sources of data into attributes. Write a policy to check them. For example: authorize { update request { SQL-Location = "%{sql:select location from ...}" } if (NAS-IP-Address =~ /^1\./) { if (SQL-Location != "Location 1") { reject } } } - 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: Huntgroup Implementation with MySQL and Radgroupcheck
On 07/26/2012 09:51 AM, Jenny Blunt wrote:
I'm looking for some help with the implementation of huntgroups.
Am using mysql and have followed the following topic through:
http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-td4950385.html
In sites-available/default I have this, (just after preprocess:
update request {
Huntgroup-Name := "%{sql:SELECT `groupname` FROM
`radhuntgroup` WHERE nasipaddress='%{NAS-IP-Address}'}"
}
Don't do this.
Read the 2nd email in the thread you linked to.
Huntgroup-Name is a special attribute; comparisons are executed
dynamically. You can't just use it like an ordinary string attribute.
Define another attribute in raddb/dictionary:
ATTRIBUTE SQL-Location3010string
...and use that.
authorize_group_check_query = "SELECT id, groupname, attribute_name, \
Value, op \
FROM ${groupcheck_table} \
WHERE ( groupname = '%{Sql-Group}' OR groupname =
'%{Huntgroup-Name}' ) \
ORDER BY id"
(Which doesn't make logical sense to me)
It doesn't make sense to me either. So why do it?
What I'm failing to get my head around is how to reject or allow access
based on the location their dialing in from?
For example, a user from IP 1.x.x.x should be allowed access at location
1 only.
I don't know what this means.
Write down the policy you want in plain english. Figure out what sources
of data you need to execute that policy. Read those sources of data into
attributes. Write a policy to check them.
For example:
authorize {
update request {
SQL-Location = "%{sql:select location from ...}"
}
if (NAS-IP-Address =~ /^1\./) {
if (SQL-Location != "Location 1") {
reject
}
}
}
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup Implementation with MySQL and Radgroupcheck
I forgot to mention that the look up works if I enter the Huntgroup-Name in radcheck.For some reason, it's just failing in radgroupcheckOn Jul 26, 2012, at 09:51 AM, Jenny Blunt wrote:I'm looking for some help with the implementation of huntgroups. Am using mysql and have followed the following topic through: http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-td4950385.htmlIn sites-available/default I have this, (just after preprocess: update request { Huntgroup-Name := "%{sql:SELECT `groupname` FROM `radhuntgroup` WHERE nasipaddress='%{NAS-IP-Address}'}" }And the debug log show's this query's working: expand: %{sql:SELECT `groupname` FROM `radhuntgroup` WHERE nasipaddress='%{NAS-IP-Address}'} -> Location OneIn my radgroupcheck table, I've added Huntgroup-Name == Location OneI've also modified my authorize_group_check_query in dialup.conf as per a recommendationauthorize_group_check_query = "SELECT id, groupname, attribute_name, \ Value, op \ FROM ${groupcheck_table} \ WHERE ( groupname = '%{Sql-Group}' OR groupname = '%{Huntgroup-Name}' ) \ ORDER BY id"(Which doesn't make logical sense to me)What I'm failing to get my head around is how to reject or allow access based on the location their dialing in from?For example, a user from IP 1.x.x.x should be allowed access at location 1 only.- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroup Implementation with MySQL and Radgroupcheck
I'm looking for some help with the implementation of huntgroups. Am using mysql and have followed the following topic through: http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-td4950385.htmlIn sites-available/default I have this, (just after preprocess: update request { Huntgroup-Name := "%{sql:SELECT `groupname` FROM `radhuntgroup` WHERE nasipaddress='%{NAS-IP-Address}'}" }And the debug log show's this query's working: expand: %{sql:SELECT `groupname` FROM `radhuntgroup` WHERE nasipaddress='%{NAS-IP-Address}'} -> Location OneIn my radgroupcheck table, I've added Huntgroup-Name == Location OneI've also modified my authorize_group_check_query in dialup.conf as per a recommendationauthorize_group_check_query = "SELECT id, groupname, attribute_name, \ Value, op \ FROM ${groupcheck_table} \ WHERE ( groupname = '%{Sql-Group}' OR groupname = '%{Huntgroup-Name}' ) \ ORDER BY id"(Which doesn't make logical sense to me)What I'm failing to get my head around is how to reject or allow access based on the location their dialing in from?For example, a user from IP 1.x.x.x should be allowed access at location 1 only.-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
On Thu, Jun 07, 2012 at 12:59:24PM -0300, Sergio Belkin wrote:
> > I just chuck the raw data out with detail and leave it be. The
> > useful stuff is pristinely formatted with gentle loving care by
> > the linelog module, where it sits in a nice greppable format for
>
> Wow, linelog seems interesting, I've tried but only is logging
> Access-Request, why?
You didn't call it in the accounting{} section?
You won't get an EAP-Type in accounting, though. There's no EAP
involved there.
Matthew
> rad_recv: Accounting-Request packet from host 10.129.85.1 port 39402,
> id=192, length=199
>Acct-Session-Id = "0026-003A"
>Acct-Status-Type = Stop
>Acct-Authentic = RADIUS
>User-Name = "fsaze1"
>NAS-Identifier = "AP-PVIII-V"
>NAS-Port = 4
>Called-Station-Id = "00-23-69-49-06-2C:sarlanga-I"
>Calling-Station-Id = "60-FA-CD-42-C0-CE"
>NAS-Port-Type = Wireless-802.11
>Connect-Info = "CONNECT 54Mbps 802.11g"
>Acct-Session-Time = 30
>Acct-Input-Packets = 98
>Acct-Output-Packets = 26
>Acct-Input-Octets = 11164
>Acct-Output-Octets = 7989
>Event-Timestamp = "Jun 7 2012 10:37:44 ART"
>Acct-Terminate-Cause = User-Request
> # Executing section preacct from file /etc/raddb-testing/sites-enabled/default
> +- entering group preacct {...}
> ++[preprocess] returns ok
> [acct_unique] Hashing 'NAS-Port = 4,Client-IP-Address =
> 10.129.85.1,NAS-IP-Address = 10.129.85.1,Acct-Session-Id =
> "0026-003A",User-Name = "fsaze1"'
> [acct_unique] Acct-Unique-Session-ID = "66c3a7d6e3d79d1a".
> ++[acct_unique] returns ok
> [suffix] No '@' in User-Name = "fsaze1", looking up realm NULL
> [suffix] No such realm "NULL"
> ++[suffix] returns noop
> ++[files] returns noop
> # Executing section accounting from file
> /etc/raddb-testing/sites-enabled/default
> +- entering group accounting {...}
> [detail]expand:
> /usr/local-test/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d
> -> /usr/local-test/var/log/radius/radacct/10.129.85.1/detail-20120607
> [detail]
> /usr/local-test/var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d
> expands to /usr/local-test/var/log/radius/radacct/10.129.85.1/detail-20120607
> [detail]expand: %t -> Thu Jun 7 10:37:44 2012
> ++[detail] returns ok
> ++[unix] returns ok
> [radutmp] expand: /usr/local-test/var/log/radius/radutmp ->
> /usr/local-test/var/log/radius/radutmp
> [radutmp] expand: %{User-Name} -> fsaze1
> ++[radutmp] returns ok
> ++[exec] returns noop
> [attr_filter.accounting_response] expand: %{User-Name} -> fsaze1
> attr_filter: Matched entry DEFAULT at line 12
> ++[attr_filter.accounting_response] returns updated
> Sending Accounting-Response of id 192 to 10.129.85.1 port 39402
> Finished request 0.
>
> End of Output
--
Matthew Newton, Ph.D.
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
2012/6/6 Matthew Newton :
> On Wed, Jun 06, 2012 at 03:56:54PM -0300, Sergio Belkin wrote:
>> Good idea, I've tried appending %{EAP-Type) that to detail.log but
>> sending nothing
>> eg:
>>
>> auth-detail-AP-XXX-DEFAULT--20120606
>>
>> Between "-" and "-" is nothing (Neither TTLS nor PEAP appears)
>
> You've not really explained what you've done.
>
> However, I *guess* that you have added %{EAP-Type} to the filename
> (detailfile) in the detail config.
Yes, you guess well
>
> Look, though, where detail is getting called, and where eap is
> called, in the authorize section. It goes in order. The eap module
> sets EAP-Type, detail is called before.
>
> So you need to call the log after eap. But the gotcha is that eap
> will short circuit the return in the challenges, so you won't call
> the detail module if you put it after eap.
Nice to know it :)
>
> I'd suggest you let all the incoming logs go to a single location
> where they are, then you add a new detail (or linelog) module to
> post-auth. That can use %{EAP-Type}, as it's *after* EAP has
> happened.
I've tested it and works, nice! But please keep on reading:
>
> Alternatively, you can use my other suggestion anywhere you like.
> If you pick data out of EAP-Message yourself, you get to do what
> you want with it (and keep the shards when it shatters).
>
> Totally untested unlang.
>
> if (%{EAP-Message} =~ /^0x19/) {
> detail_log_peap
> }
> elsif (%{EAP-Message} =~ /^0x15/) {
> detail_log_ttls
> }
> else {
> detail_log_other
> }
>
> Note that things *will* hit detail_log_other. EAP Identity, for
> instance, before the eap type has been agreed. If you do this in
> the inner server, be prepared for unexpectedness. In short,
> understand EAP first.
Good, but it sounds somewhat complex :)
>
> I just chuck the raw data out with detail and leave it be. The
> useful stuff is pristinely formatted with gentle loving care by
> the linelog module, where it sits in a nice greppable format for
> me. One log entry, in post-auth, after the useful stuff happened.
> Any more detail needed? Just go to the dirty detail log and dig it
> out. Happens so rarely it wouldn't matter if it was in binary
> format and had to be read with a hex editor in Windows...
>
Wow, linelog seems interesting, I've tried but only is logging
Access-Request, why?
I add my debug (I plan to get rid out of inner-tunnel-peap file):
FreeRADIUS Version 2.1.12, for host x86_64-unknown-linux-gnu, built on
Jan 3 2012 at 16:18:16
Copyright (C) 1999-2009 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License v2.
Starting - reading configuration files ...
including configuration file /etc/raddb-testing/radiusd.conf
including configuration file /etc/raddb-testing/proxy.conf
including configuration file /etc/raddb-testing/clients.conf
including files in directory /etc/raddb-testing/modules/
including configuration file /etc/raddb-testing/modules/chap
including configuration file /etc/raddb-testing/modules/mschap
including configuration file
/etc/raddb-testing/modules/sqlcounter_expire_on_login
including configuration file /etc/raddb-testing/modules/exec
including configuration file /etc/raddb-testing/modules/realm
including configuration file /etc/raddb-testing/modules/checkval
including configuration file /etc/raddb-testing/modules/rediswho
including configuration file /etc/raddb-testing/modules/passwd
including configuration file /etc/raddb-testing/modules/attr_filter
including configuration file /etc/raddb-testing/modules/linelog
including configuration file /etc/raddb-testing/modules/wimax
including configuration file /etc/raddb-testing/modules/pam
including configuration file /etc/raddb-testing/modules/inner-eap
including configuration file /etc/raddb-testing/modules/echo
including configuration file /etc/raddb-testing/modules/soh
including configuration file /etc/raddb-testing/modules/replicate
including configuration file /etc/raddb-testing/modules/acct_unique
including configuration file /etc/raddb-testing/modules/etc_group
including configuration file /etc/raddb-testing/modules/pap
including configuration file /etc/raddb-testing/modules/expr
including configuration file /etc/raddb-testing/modules/smbpasswd
including configuration file /etc/raddb-testing/modules/attr_rewrite
including configuration file /etc/raddb-testing/modules/radutmp
including configuration file /etc/raddb-testing/modules/mac2ip
including configuration file /etc/raddb-testing/modules/logintime
including configuration file /etc/raddb-testing/modules/sql_log
including configuration file /etc/raddb-testing/modules/smsotp
including configuration file /etc/raddb-testing/modules/preprocess
including configuration file /etc/raddb-testing/modules/policy
including configuration file /etc/raddb-testing/modules/cui
including configurati
Re: Problems with Huntgroup
2012/6/6 Alan DeKok :
> Sergio Belkin wrote:
>> Good idea, I've tried appending %{EAP-Type) that to detail.log
>
> What does that mean?
>
>> but
>> sending nothing
>> eg:
>>
>> auth-detail-AP-XXX-DEFAULT--20120606
>>
>> Between "-" and "-" is nothing (Neither TTLS nor PEAP appears)
>
> As *ALWAYS*, read the debug output.
>
> You're very dedicated to giving as little information as possible. Why?
OK, you're right in my next message I will include it :)
>
> Alan DeKok.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
On Wed, Jun 06, 2012 at 03:56:54PM -0300, Sergio Belkin wrote:
> Good idea, I've tried appending %{EAP-Type) that to detail.log but
> sending nothing
> eg:
>
> auth-detail-AP-XXX-DEFAULT--20120606
>
> Between "-" and "-" is nothing (Neither TTLS nor PEAP appears)
You've not really explained what you've done.
However, I *guess* that you have added %{EAP-Type} to the filename
(detailfile) in the detail config.
Look, though, where detail is getting called, and where eap is
called, in the authorize section. It goes in order. The eap module
sets EAP-Type, detail is called before.
So you need to call the log after eap. But the gotcha is that eap
will short circuit the return in the challenges, so you won't call
the detail module if you put it after eap.
I'd suggest you let all the incoming logs go to a single location
where they are, then you add a new detail (or linelog) module to
post-auth. That can use %{EAP-Type}, as it's *after* EAP has
happened.
Alternatively, you can use my other suggestion anywhere you like.
If you pick data out of EAP-Message yourself, you get to do what
you want with it (and keep the shards when it shatters).
Totally untested unlang.
if (%{EAP-Message} =~ /^0x19/) {
detail_log_peap
}
elsif (%{EAP-Message} =~ /^0x15/) {
detail_log_ttls
}
else {
detail_log_other
}
Note that things *will* hit detail_log_other. EAP Identity, for
instance, before the eap type has been agreed. If you do this in
the inner server, be prepared for unexpectedness. In short,
understand EAP first.
I just chuck the raw data out with detail and leave it be. The
useful stuff is pristinely formatted with gentle loving care by
the linelog module, where it sits in a nice greppable format for
me. One log entry, in post-auth, after the useful stuff happened.
Any more detail needed? Just go to the dirty detail log and dig it
out. Happens so rarely it wouldn't matter if it was in binary
format and had to be read with a hex editor in Windows...
> > Add 'preprocess' to the top of the authorize{} section in your
> > inner-tunnel-peap / inner-tunnel files. That's the module that
> > checks huntgroups.
>
> Thanks guys it dit it! I just realize that modules must be appended in
> inner-tunnel files to load them :)
Yeah, that's why it's called a virtual server. It's treated the
same as the default server, the flow is the same. No module
listed there? It doesn't happen.
Matthew
--
Matthew Newton, Ph.D.
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
Sergio Belkin wrote:
> Good idea, I've tried appending %{EAP-Type) that to detail.log
What does that mean?
> but
> sending nothing
> eg:
>
> auth-detail-AP-XXX-DEFAULT--20120606
>
> Between "-" and "-" is nothing (Neither TTLS nor PEAP appears)
As *ALWAYS*, read the debug output.
You're very dedicated to giving as little information as possible. Why?
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
2012/6/6 Matthew Newton :
> On Wed, Jun 06, 2012 at 10:28:27AM -0300, Sergio Belkin wrote:
>> I've added this files because I like to separate logs when supplicants
>> are using PEAP or TTLS
>
> I'd still use just one file, and filter the logs instead.
>
>> Is there a better way of doing that?
>
> There may be several ways. The first one that comes to mind is
> just pulling the EAP type out of the EAP-Message attributes.
>
> PEAP connections will have an EAP-Message attribute that matches
> the regexp /^0x19/, whereas TTLS connections will match
> /^0x15/.
>
> Alternatively, and probably easier in the long run, add
> %{EAP-Type} to linelog, so you get the name directly in your logs.
> Add it in the outer, and you'll see TTLS or PEAP. Add it in the
> inner, and you'll see the inner EAP type, such as MS-CHAP-V2.
Good idea, I've tried appending %{EAP-Type) that to detail.log but
sending nothing
eg:
auth-detail-AP-XXX-DEFAULT--20120606
Between "-" and "-" is nothing (Neither TTLS nor PEAP appears)
>
>
>> I want to learn. Sorry but I repeat the question how a module is
>> added? because "files" is statament is present on both files
>> /etc/raddb-testing/sites-enabled/inner-tunnel-peap and
>> /etc/raddb-testing/sites-enabled/inner-tunnel
>
> Apologies - you're right, it is being called.
>
> ++[files] returns noop
:-)
>
> Add 'preprocess' to the top of the authorize{} section in your
> inner-tunnel-peap / inner-tunnel files. That's the module that
> checks huntgroups.
Thanks guys it dit it! I just realize that modules must be appended in
inner-tunnel files to load them :)
TIA
>
> Cheers,
>
> Matthew
>
>
>
> --
> Matthew Newton, Ph.D.
>
> Systems Architect (UNIX and Networks), Network Services,
> I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
>
> For IT help contact helpdesk extn. 2253,
> -
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
On Wed, Jun 06, 2012 at 10:28:27AM -0300, Sergio Belkin wrote:
> I've added this files because I like to separate logs when supplicants
> are using PEAP or TTLS
I'd still use just one file, and filter the logs instead.
> Is there a better way of doing that?
There may be several ways. The first one that comes to mind is
just pulling the EAP type out of the EAP-Message attributes.
PEAP connections will have an EAP-Message attribute that matches
the regexp /^0x19/, whereas TTLS connections will match
/^0x15/.
Alternatively, and probably easier in the long run, add
%{EAP-Type} to linelog, so you get the name directly in your logs.
Add it in the outer, and you'll see TTLS or PEAP. Add it in the
inner, and you'll see the inner EAP type, such as MS-CHAP-V2.
> I want to learn. Sorry but I repeat the question how a module is
> added? because "files" is statament is present on both files
> /etc/raddb-testing/sites-enabled/inner-tunnel-peap and
> /etc/raddb-testing/sites-enabled/inner-tunnel
Apologies - you're right, it is being called.
++[files] returns noop
Add 'preprocess' to the top of the authorize{} section in your
inner-tunnel-peap / inner-tunnel files. That's the module that
checks huntgroups.
Cheers,
Matthew
--
Matthew Newton, Ph.D.
Systems Architect (UNIX and Networks), Network Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253,
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
2012/6/5 Matthew Newton : > On Mon, Jun 04, 2012 at 11:43:07AM -0300, Sergio Belkin wrote: >> 2012/6/4 Alan DeKok : >> > The debug for the "inner-tunnel" *clearly* shows NOT using the "files" >> > module. >> >> So, sorry for the stupid questions but how can I do that >> >> It's true what you say about debug output, but I "files" is in >> inner-tunnel configuration, I tried putting "files" above of chap, but >> doesn't change anything. > > Look at /etc/raddb-testing/sites-enabled/inner-tunnel-peap > > You've changed the config, added this file, and not added the > files module to it. How a module is added? > > >> Mi current file is: > > That's probably /etc/raddb-testing/sites-enabled/inner-tunnel > instead. Yes it is > > Using different inner-tunnel configs for TTLS and PEAP is just > going to cause you pain, unless you REALLY know what you're > letting yourself in for. Go back to the default config and use the > same for both. I've added this files because I like to separate logs when supplicants are using PEAP or TTLS Is there a better way of doing that? > > The debug output doesn't lie. If it says the module isn't being > called when you've just added it, then the module is not being > called and you're configuring things in the wrong place. I don't blame debug :) I want to learn. Sorry but I repeat the question how a module is added? because "files" is statament is present on both files /etc/raddb-testing/sites-enabled/inner-tunnel-peap and /etc/raddb-testing/sites-enabled/inner-tunnel Thanks again > > Cheers, > > Matthew > > > -- > Matthew Newton, Ph.D. > > Systems Architect (UNIX and Networks), Network Services, > I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom > > For IT help contact helpdesk extn. 2253, > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- -- Sergio Belkin http://www.sergiobelkin.com Watch More TV http://sebelk.blogspot.com LPIC-2 Certified - http://www.lpi.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
On Mon, Jun 04, 2012 at 11:43:07AM -0300, Sergio Belkin wrote: > 2012/6/4 Alan DeKok : > > The debug for the "inner-tunnel" *clearly* shows NOT using the "files" > > module. > > So, sorry for the stupid questions but how can I do that > > It's true what you say about debug output, but I "files" is in > inner-tunnel configuration, I tried putting "files" above of chap, but > doesn't change anything. Look at /etc/raddb-testing/sites-enabled/inner-tunnel-peap You've changed the config, added this file, and not added the files module to it. > Mi current file is: That's probably /etc/raddb-testing/sites-enabled/inner-tunnel instead. Using different inner-tunnel configs for TTLS and PEAP is just going to cause you pain, unless you REALLY know what you're letting yourself in for. Go back to the default config and use the same for both. The debug output doesn't lie. If it says the module isn't being called when you've just added it, then the module is not being called and you're configuring things in the wrong place. Cheers, Matthew -- Matthew Newton, Ph.D. Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
Sergio Belkin wrote: > 2012/6/4 Alan DeKok : >> The debug for the "inner-tunnel" *clearly* shows NOT using the "files" >> module. > > So, sorry for the stupid questions but how can I do that If it's in the file, it's used. > It's true what you say about debug output, but I "files" is in > inner-tunnel configuration, I tried putting "files" above of chap, but > doesn't change anything. OK. > Please could you help me I've read the file and output, and also run > radtest, but I don't figure out what I should do ? Run radtest until it works. As input, use the packets the server prints out in debugging mode. Change the server configuration until it works. The whole *point* of debugging mode is to tell you what's going on. The point of printing out the packets is so that you can use them for testing. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
2012/6/4 Alan DeKok :
> The debug for the "inner-tunnel" *clearly* shows NOT using the "files"
> module.
So, sorry for the stupid questions but how can I do that
It's true what you say about debug output, but I "files" is in
inner-tunnel configuration, I tried putting "files" above of chap, but
doesn't change anything.
Please could you help me I've read the file and output, and also run
radtest, but I don't figure out what I should do
Mi current file is:
listen {
ipaddr = 127.0.0.1
port = 18121
type = auth
}
authorize {
chap
mschap
suffix
update control {
Proxy-To-Realm := LOCAL
}
eap {
ok = return
}
files
ldap
expiration
logintime
pap
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
unix
Auth-Type LDAP {
ldap
}
eap
}
session {
radutmp
}
post-auth {
reply_log
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}
pre-proxy {
}
post-proxy {
post_proxy_log
eap
}
EOF
Thanks in advance!
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
Sergio Belkin wrote: > I haven't deleted anything respect to configuration files per default: You can believe what you want, or you can believe the server output. > Did I missed something? The debug for the "inner-tunnel" *clearly* shows NOT using the "files" module. Go fix that. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
2012/6/4 Alan DeKok :
> Sergio Belkin wrote:
>> I've appended something like to huntgroups file
>>
>> mb NAS-IP-Address == 10.129.189.1
>> mb NAS-IP-Address == 10.129.84.1
>> mb Called-Station-Id == 00-1B-7E-DC-AB-1A:UP-PVIII-I
>>
>> And in users files:
>>
>> pruebita Huntgroup-Name == "mb",Cleartext-Password := "pruebon"
>>
>> But is not working user pruebita does not get an Access-Accept
>>
>> Please could you help me to solve it?
>
> You edited the default configuration and broke it. Don't do that.
>
> You've set "copy_request_to_tunnel", which is good. It means that the
> huntgroup check will work.
>
> You've deleted "files" from raddb/sites-available/inner-tunnel.
> That's why it doesn't work. Add it back, and it will work.
>
> In 2.1.12, read the comments at the top of
> raddb/sites-available/inner-tunnel. It tells you how to test the
> inner-tunnel configuration. It tells you what NOT to do.
>
> i.e. tested PEAP before testing that the inner-tunnel config works.
>
>
> Alan DeKok.
> -
Thanks Alan for you answer.
I haven't deleted anything respect to configuration files per default:
32,36c32,36
< listen {
<ipaddr = 127.0.0.1
<port = 18120
<type = auth
< }
---
> #listen {
> # ipaddr = 127.0.0.1
> # port = 18120
> # type = auth
> #}
142c142
< # ldap
---
> ldap
230,232c230,232
< # Auth-Type LDAP {
< # ldap
< # }
---
> Auth-Type LDAP {
> ldap
> }
271a272,274
> # Sergio
> reply_log
>
376a380,382
> # Sergio
> post_proxy_log
>
Did I missed something?
Thanks in advance
--
--
Sergio Belkin http://www.sergiobelkin.com
Watch More TV http://sebelk.blogspot.com
LPIC-2 Certified - http://www.lpi.org
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Problems with Huntgroup
Sergio Belkin wrote: > I've appended something like to huntgroups file > > mb NAS-IP-Address == 10.129.189.1 > mb NAS-IP-Address == 10.129.84.1 > mb Called-Station-Id == 00-1B-7E-DC-AB-1A:UP-PVIII-I > > And in users files: > > pruebita Huntgroup-Name == "mb",Cleartext-Password := "pruebon" > > But is not working user pruebita does not get an Access-Accept > > Please could you help me to solve it? You edited the default configuration and broke it. Don't do that. You've set "copy_request_to_tunnel", which is good. It means that the huntgroup check will work. You've deleted "files" from raddb/sites-available/inner-tunnel. That's why it doesn't work. Add it back, and it will work. In 2.1.12, read the comments at the top of raddb/sites-available/inner-tunnel. It tells you how to test the inner-tunnel configuration. It tells you what NOT to do. i.e. tested PEAP before testing that the inner-tunnel config works. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: huntgroup check problems
Good morning, I have been studying the configuration of the file sites-available/inner-tunnel and making some tests. I have found that the "files" check in the authorize section made my configuration not to work as desired because, as Alan said, inside the TLS tunnel the huntgroup check was failing. As the users file is checked on the first requests received, and the wrong huntgroup filtered out, it is not necessary to check it again inside the tunnel. I have removed it from my configuration and it is working ok now. Just wanted to update how my question got resolved. Thank you very much again for your help. Regards, * Oscar Remírez de Ganuza Satrústegui* Servicios Informáticos (Área de Infraestructuras) Universidad de Navarra Tel. +34 948425600 x3130 http://www.unav.es/SI/ On Fri, Jan 20, 2012 at 12:43 PM, Oscar Remírez de Ganuza Satrústegui < oscar...@unav.es> wrote: > On Fri, Jan 20, 2012 at 12:18 PM, Alan DeKok wrote: > >> Oscar Remírez de Ganuza Satrústegui wrote: >> >> > I can see in the "not working log" that on the first requests the >> > huntgroup is been recognised ok. I just do not understand why it tries >> > again to check it, until it fails (request #9). >> >> Because it's checking the user *inside* of the TLS tunnel. Go read >> raddb/sites-available/inner-tunnel. You will probably need to modify >> your huntgroup check. >> > > Ok, I will have a look at it and try to make it checking at the correct > order. > > >> >> > I also do not understand why it needs so many requests (12!) to work ok. >> >> That's how 802.1X works. It sends lots of packets. >> > > Thank you very much for your fast answer, I really appreciate it. > > >> >> Alan DeKok. >> <http://www.freeradius.org/list/users.html> >> > > *Oscar Remírez de Ganuza Satrústegui* > Servicios Informáticos (Área de Infraestructuras) > Universidad de Navarra > Tel. +34 948425600 x3130 > http://www.unav.es/SI/ > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: huntgroup check problems
On Fri, Jan 20, 2012 at 12:18 PM, Alan DeKok wrote: > Oscar Remírez de Ganuza Satrústegui wrote: > > > I am having some problems using huntgroups to identified the origin of a > > request. > > I have simplified the test trying to find out the problem, but I do not > > understand what it is happening: > > > (The "notworking log" is appended at the end of the message. I had to > > trim it to make it shorter) > > It would have been better to follow the instruction in the FAQ, > README, "man" page, web pages, and daily on this list: "radiusd -X". > Using "radiusd -xX" produces 2x the output, and is NOT needed. > My bad. Sorry about that. > > > I can see in the "not working log" that on the first requests the > > huntgroup is been recognised ok. I just do not understand why it tries > > again to check it, until it fails (request #9). > > Because it's checking the user *inside* of the TLS tunnel. Go read > raddb/sites-available/inner-tunnel. You will probably need to modify > your huntgroup check. > Ok, I will have a look at it and try to make it checking at the correct order. > > > I also do not understand why it needs so many requests (12!) to work ok. > > That's how 802.1X works. It sends lots of packets. > Thank you very much for your fast answer, I really appreciate it. > > Alan DeKok. > <http://www.freeradius.org/list/users.html> > *Oscar Remírez de Ganuza Satrústegui* Servicios Informáticos (Área de Infraestructuras) Universidad de Navarra Tel. +34 948425600 x3130 http://www.unav.es/SI/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: huntgroup check problems
Oscar Remírez de Ganuza Satrústegui wrote: > We are using freeradius (Version 2.1.9) to serve access requests for > 802.1x, using PEAP/EAP/MSCHAPv2 (windows7). We use LDAP for > authentication (user accounts) and authorization (Ldap-Groups). > We also tunneled the request to the same radius for our realm "unav.es That is a fairly common setup. > I am having some problems using huntgroups to identified the origin of a > request. > I have simplified the test trying to find out the problem, but I do not > understand what it is happening: > (The "notworking log" is appended at the end of the message. I had to > trim it to make it shorter) It would have been better to follow the instruction in the FAQ, README, "man" page, web pages, and daily on this list: "radiusd -X". Using "radiusd -xX" produces 2x the output, and is NOT needed. > I can see in the "not working log" that on the first requests the > huntgroup is been recognised ok. I just do not understand why it tries > again to check it, until it fails (request #9). Because it's checking the user *inside* of the TLS tunnel. Go read raddb/sites-available/inner-tunnel. You will probably need to modify your huntgroup check. > I also do not understand why it needs so many requests (12!) to work ok. That's how 802.1X works. It sends lots of packets. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup Checking
You may need to inspect whether the groupcheck query in
mysql/dailup.conf (if you are using MySQL) looks in the huntgroup
table.
For example, this is the default query in my copy of freeRADIUS
provided by Debian:
authorize_group_check_query = "SELECT id, groupname, attribute, \
Value, op \
FROM ${groupcheck_table} \
WHERE groupname = '%{Sql-Group}' \
ORDER BY id"
Try modifying it as such:
authorize_group_check_query = "SELECT id, groupname, attribute, \
value, op \
FROM ${groupcheck_table} \
WHERE ( groupname = '%{Sql-Group}' \
OR groupname = '%{Huntgroup-Name}' ) \
ORDER BY id"
On Wed, Nov 2, 2011 at 9:07 AM, simonm123 wrote:
> Can anyone tell me if hungroup checking can be made to work on the group
> level, not just the user level?
>
> Thanks
>
> --
> View this message in context:
> http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-tp4950385p4958155.html
> Sent from the FreeRadius - User mailing list archive at Nabble.com.
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
>
--
Ben West
westbyw...@gmail.com
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup Checking
Can anyone tell me if hungroup checking can be made to work on the group level, not just the user level? Thanks -- View this message in context: http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-tp4950385p4958155.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup Checking
On further investigation, I can see that the check works just fine if the
attribute huntgroup-name == xxx is added to radcheck
For what reason can't we add to radgroupcheck?
What's the logic required to modify so we can restrict on a group level?
On 30 Oct 2011, at 17:03, Alan DeKok wrote:
> simonm123 wrote:
>> Am new to freeradius but have it mainly set up just fine. It's a fantastic
>> tool and I'm enjoying using it :)
>
> That's good to hear.
>
>> Just one thing I'm struggling with is the huntgroups. I've followed the wiki
>> to the letter and can see the server checking in the debug log.
>>
>> What I basically want to do is restrict users to certain networks, as per
>> the wiki. If their huntgroup-name matches their huntgroup based on nasip,
>> they can get online, otherwise they're rejected.
>
> OK...
>
>> I've put Huntgroup-Name = NetworkA in my radgroupcheck folder.
>
> Use "==". It does comparisons.
>
>> In my radhuntgroup table, I have the nasip and groupname = NetworkA
>>
>> Then, in the authorize section of my default host, I put:
>>
>> update request {
>>Huntgroup-Name := "%{sql:SELECT `groupname` FROM `radhuntgroup` WHERE
>> nasipaddress='%{NAS-IP-Address}'}"
>> }
>
> No, that won't work. The huntgroups are defined by the "huntgroups"
> file. You can't change them like you're trying to do.
>
> Instead, use another attribute. Invent one. See raddb/dictionary.
>
> 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: Huntgroup Checking
I meant Huntgroup-Name == NetworkA in my radgroupcheck table. I'm not using the
huntgroups file - they're all in my db.
The wiki suggests using the query below restrict access per network. If that
query below is not going to work, it's a little misleading. Or is it just
incomplete?
On 30 Oct 2011, at 17:03, Alan DeKok wrote:
> simonm123 wrote:
>> Am new to freeradius but have it mainly set up just fine. It's a fantastic
>> tool and I'm enjoying using it :)
>
> That's good to hear.
>
>> Just one thing I'm struggling with is the huntgroups. I've followed the wiki
>> to the letter and can see the server checking in the debug log.
>>
>> What I basically want to do is restrict users to certain networks, as per
>> the wiki. If their huntgroup-name matches their huntgroup based on nasip,
>> they can get online, otherwise they're rejected.
>
> OK...
>
>> I've put Huntgroup-Name = NetworkA in my radgroupcheck folder.
>
> Use "==". It does comparisons.
>
>> In my radhuntgroup table, I have the nasip and groupname = NetworkA
>>
>> Then, in the authorize section of my default host, I put:
>>
>> update request {
>>Huntgroup-Name := "%{sql:SELECT `groupname` FROM `radhuntgroup` WHERE
>> nasipaddress='%{NAS-IP-Address}'}"
>> }
>
> No, that won't work. The huntgroups are defined by the "huntgroups"
> file. You can't change them like you're trying to do.
>
> Instead, use another attribute. Invent one. See raddb/dictionary.
>
> 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: Huntgroup Checking
simonm123 wrote:
> Am new to freeradius but have it mainly set up just fine. It's a fantastic
> tool and I'm enjoying using it :)
That's good to hear.
> Just one thing I'm struggling with is the huntgroups. I've followed the wiki
> to the letter and can see the server checking in the debug log.
>
> What I basically want to do is restrict users to certain networks, as per
> the wiki. If their huntgroup-name matches their huntgroup based on nasip,
> they can get online, otherwise they're rejected.
OK...
> I've put Huntgroup-Name = NetworkA in my radgroupcheck folder.
Use "==". It does comparisons.
> In my radhuntgroup table, I have the nasip and groupname = NetworkA
>
> Then, in the authorize section of my default host, I put:
>
> update request {
> Huntgroup-Name := "%{sql:SELECT `groupname` FROM `radhuntgroup` WHERE
> nasipaddress='%{NAS-IP-Address}'}"
> }
No, that won't work. The huntgroups are defined by the "huntgroups"
file. You can't change them like you're trying to do.
Instead, use another attribute. Invent one. See raddb/dictionary.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroup Checking
Am new to freeradius but have it mainly set up just fine. It's a fantastic
tool and I'm enjoying using it :)
Just one thing I'm struggling with is the huntgroups. I've followed the wiki
to the letter and can see the server checking in the debug log.
What I basically want to do is restrict users to certain networks, as per
the wiki. If their huntgroup-name matches their huntgroup based on nasip,
they can get online, otherwise they're rejected.
I've put Huntgroup-Name = NetworkA in my radgroupcheck folder.
In my radhuntgroup table, I have the nasip and groupname = NetworkA
Then, in the authorize section of my default host, I put:
update request {
Huntgroup-Name := "%{sql:SELECT `groupname` FROM `radhuntgroup` WHERE
nasipaddress='%{NAS-IP-Address}'}"
}
if (Huntgroup-Name == ''){
reject
}
All as per the tutorial
In my debug log, if there is no match by IP, Huntgroup-Name is blank and the
user is rejected.
However, if the nasip address match but the name is different, the user is
still allowed on.
Do I need a more advanced query in the if section and if so,could you please
advise what it should be
Simon
--
View this message in context:
http://freeradius.1045715.n5.nabble.com/Huntgroup-Checking-tp4950385p4950385.html
Sent from the FreeRadius - User mailing list archive at Nabble.com.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Using rlm_passwd as a substitute for hunt groups - was (Devices in more than one huntgroup)
On 31 Aug 2011, at 13:17, jan.we...@t-systems.com wrote:
>> Thanks for the answer!
>>
>> But there are several problems for me:
>> - i have no access to ldap, new groups are not as easy to implement as in
>> small environments
>> - i already have more than 20 DEFAULT-entries for different
>> huntgroup/ldap-group combinations
>> and splitting nexus to nexus_RO and nexus_RW means adding additional 5
>> entries minimum
>> I´m searching for a more scalable solution. If the next team should get
>> access to different
>> devices, and then the third team to a third group of devices, or other
>> rights...
>
> Hi,
>
> In this thread i found a hint for my config:
>
> http://freeradius.1045715.n5.nabble.com/huntgroups-question-td2756193.html
>
> "The huntgroups are a bit of a hack for backwards compatibility going
> back almost a decade. For 2000 machines, I would suggest using
> rlm_passwd. See the "man rlm_passwd" page for an example of setting up
> groups based on User-Name. The same method can be used to set up groups
> based on Client-IP-Address. You then have groups controlled by a flat
> text file, which is pretty easy to manage."
>
> passwd groups_local {
>filename = /etc/raddb/groups_local
>format = "~My-Device-Group:*NAS-IP-Address"
>hashsize = 50
>ignorenislike = no
>allowmultiplekeys = no
>delimiter = ":"
> }
>
> Groups_local:
> readonly:127.0.0.1
>
> Groups_local is called in section "authorize" just after "preprocess".
>
> I always got "returs notfound". If i add User-Name to the config, it´s
> working.
> But i didn´t want to check the username, i just want to add an other flag
> (My-Device-Group)
> additional to huntgroups.
>
Did you remember to actually define 'My-Device-Group' as an attribute?
-Arran
Arran Cudbard-Bell
a.cudba...@freeradius.org
RADIUS - Half the complexity of Diameter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
AW: Devices in more than one huntgroup
>Thanks for the answer!
>
>But there are several problems for me:
>- i have no access to ldap, new groups are not as easy to implement as in
>small environments
>- i already have more than 20 DEFAULT-entries for different
>huntgroup/ldap-group combinations
> and splitting nexus to nexus_RO and nexus_RW means adding additional 5
> entries minimum
> I´m searching for a more scalable solution. If the next team should get
> access to different
> devices, and then the third team to a third group of devices, or other
> rights...
Hi,
In this thread i found a hint for my config:
http://freeradius.1045715.n5.nabble.com/huntgroups-question-td2756193.html
"The huntgroups are a bit of a hack for backwards compatibility going
back almost a decade. For 2000 machines, I would suggest using
rlm_passwd. See the "man rlm_passwd" page for an example of setting up
groups based on User-Name. The same method can be used to set up groups
based on Client-IP-Address. You then have groups controlled by a flat
text file, which is pretty easy to manage."
passwd groups_local {
filename = /etc/raddb/groups_local
format = "~My-Device-Group:*NAS-IP-Address"
hashsize = 50
ignorenislike = no
allowmultiplekeys = no
delimiter = ":"
}
Groups_local:
readonly:127.0.0.1
Groups_local is called in section "authorize" just after "preprocess".
I always got "returs notfound". If i add User-Name to the config, it´s working.
But i didn´t want to check the username, i just want to add an other flag
(My-Device-Group)
additional to huntgroups.
So, how should it work?
Thanks!
Jan
[root@vm-test raddb]# radiusd -X
FreeRADIUS Version 2.1.7, for host i686-redhat-linux-gnu, built on Mar 31 2010
at 00:25:31
Copyright (C) 1999-2009 The FreeRADIUS server project and contributors.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
You may redistribute copies of FreeRADIUS under the terms of the
GNU General Public License v2.
Starting - reading configuration files ...
including configuration file /etc/raddb/radiusd.conf
including configuration file /etc/raddb/clients.conf
including files in directory /etc/raddb/modules/
including configuration file /etc/raddb/modules/linelog
including configuration file /etc/raddb/modules/sqlcounter_expire_on_login
including configuration file /etc/raddb/modules/sql_log
including configuration file /etc/raddb/modules/logintime
including configuration file /etc/raddb/modules/unix
including configuration file /etc/raddb/modules/ippool
including configuration file /etc/raddb/modules/expiration
including configuration file /etc/raddb/modules/chap
including configuration file /etc/raddb/modules/detail.log
including configuration file /etc/raddb/modules/checkval
including configuration file /etc/raddb/modules/attr_rewrite
including configuration file /etc/raddb/modules/mac2vlan
including configuration file /etc/raddb/modules/detail
including configuration file /etc/raddb/modules/pap
including configuration file /etc/raddb/modules/acct_unique
including configuration file /etc/raddb/modules/perl
including configuration file /etc/raddb/modules/ldap
including configuration file /etc/raddb/modules/realm
including configuration file /etc/raddb/modules/detail.example.com
including configuration file /etc/raddb/modules/digest
including configuration file /etc/raddb/modules/radutmp
including configuration file /etc/raddb/modules/pam
including configuration file /etc/raddb/modules/passwd
including configuration file /etc/raddb/modules/inner-eap
including configuration file /etc/raddb/modules/policy
including configuration file /etc/raddb/modules/counter
including configuration file /etc/raddb/modules/always
including configuration file /etc/raddb/modules/smbpasswd
including configuration file /etc/raddb/modules/echo
including configuration file /etc/raddb/modules/mac2ip
including configuration file /etc/raddb/modules/exec
including configuration file /etc/raddb/modules/cui
including configuration file /etc/raddb/modules/otp
including configuration file /etc/raddb/modules/etc_group
including configuration file /etc/raddb/modules/files
including configuration file /etc/raddb/modules/smsotp
including configuration file /etc/raddb/modules/attr_filter
including configuration file /etc/raddb/modules/mschap
including configuration file /etc/raddb/modules/expr
including configuration file /etc/raddb/modules/sradutmp
including configuration file /etc/raddb/modules/wimax
including configuration file /etc/raddb/modules/preprocess
including files in directory /etc/raddb/sites-enabled/
including configuration file /etc/raddb/sites-enabled/default
group = radiusd
user = radiusd
including dictionary file /etc/raddb/dictionary
main {
prefix = "/usr"
localstatedir = "/var"
logdir = &quo
Devices in more than one huntgroup
>DEFAULT. Huntgroup-Name == "nexus",LDAP-Group == "nexus_RO" >... > >DEFAULT.Huntgroup-Name == "nexus",LDAP-Group == "nexus_RW" >... > >Add your users to groups to suit. While devices can only be in one group, >users can be in many. Thanks for the answer! But there are several problems for me: - i have no access to ldap, new groups are not as easy to implement as in small environments - i already have more than 20 DEFAULT-entries for different huntgroup/ldap-group combinations and splitting nexus to nexus_RO and nexus_RW means adding additional 5 entries minimum I´m searching for a more scalable solution. If the next team should get access to different devices, and then the third team to a third group of devices, or other rights... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Devices in more than one huntgroup
On 19/08/2011, at 4:59 PM, jan.we...@t-systems.com wrote:
>> Hi,
>>
>> I have a little problem with devices in multiple huntgroups.
>> By now i kno that this is not possible (rtfm helped ;-)
>>
>> What i wanted to do is the following:
>>
>> Two Teams, but with diffenrent rights.
>>
>> Users:
>>
>> DEFAULT Auth-Type := LDAP, Huntgroup-Name == "nexus", LDAP-Group ==
>> ""
>> Login-Service = Telnet,
>> Cisco-AVPair = "shell:roles*\"network-admin\" \"vdc-admin\""
>>
>> DEFAULT Auth-Type := LDAP, Huntgroup-Name == "readonly-nexus", LDAP-Group ==
>> ""
>> Login-Service = Telnet,
>> Cisco-AVPair = "shell:roles*\"network-operator\" \"vdc-operator\""
>>
>> Huntgroups:
>>
>> readonly-nexus NAS-IP-Address == 192.168.11.123
>> Nexus NAS-IP-Address == 192.168.11.123
>>
>>
>> Since only the first match within the huntgroups is checked, team-2 always
>> gets "access-reject".
>>
>>
>> For checking only the NAS-IP-Adress makes sense in our environment.
>> I already found a hint to use rlm-passwd, but i can?t get this run.
>>
>> So i tried the following:
>>
>> ===
>> Users:
>> DEFAULT Auth-Type := LDAP, Huntgroup-Name == "nexus", My-Device-Group
>> "Nexus-readonly", LDAP-Group == ""
>> Login-Service = Telnet,
>> Cisco-AVPair = "shell:roles*\"network-operator\" \"vdc-operator\""
>>
>> modules/passwd:
>> passwd Groups_local {
>> filename = /etc/raddb/groups_local
>> format = "My-Device-Group:*NAS-IP-Address"
>> hashsize = 50
>> ignorenislike = no
>> allowmultiplekeys = no
>> delimiter = ":"
>> }
>>
>> groups_local:
>> Nexus-readonly:192.168.11.123
>>
>> dictionary:
>> ATTRIBUTE My-Device-Group 3000string
>>
>> ===
>>
>> Groups_local was placed in authorize section, after preprocess.
>>
>> Debug shows:
>>
>> Ready to process requests.
>> rad_recv: Access-Request packet from host 192.168.11.123 port 48910, id=20,
>> length=62
>> User-Name = "test"
>> User-Password = "test"
>> NAS-Port-Type = Virtual
>> NAS-Port = 3000
>> NAS-IP-Address = 192.168.11.123
>> +- entering group authorize {...}
>> ++[preprocess] returns ok
>> ++[groups_local] returns notfound
>>
>> Any Idea?
>> Or is there a big bug in my config (and my mind)?
>> Thanks!
>>
>> Jan
>
> Does nobody has an idea what i´m doing wrong?
> Or any idea how i could realize this?
>
> Thanks a lot!
>
> Jan
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
DEFAULT.Huntgroup-Name == "nexus",LDAP-Group == "nexus_RO"
...
DEFAULT.Huntgroup-Name == "nexus",LDAP-Group == "nexus_RW"
...
Add your users to groups to suit. While devices can only be in one group, users
can be in many.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Devices in more than one huntgroup
>Hi,
>
>I have a little problem with devices in multiple huntgroups.
>By now i kno that this is not possible (rtfm helped ;-)
>
>What i wanted to do is the following:
>
>Two Teams, but with diffenrent rights.
>
>Users:
>
>DEFAULT Auth-Type := LDAP, Huntgroup-Name == "nexus", LDAP-Group ==
>""
>Login-Service = Telnet,
>Cisco-AVPair = "shell:roles*\"network-admin\" \"vdc-admin\""
>
>DEFAULT Auth-Type := LDAP, Huntgroup-Name == "readonly-nexus", LDAP-Group ==
>""
>Login-Service = Telnet,
>Cisco-AVPair = "shell:roles*\"network-operator\" \"vdc-operator\""
>
>Huntgroups:
>
>readonly-nexus NAS-IP-Address == 192.168.11.123
>Nexus NAS-IP-Address == 192.168.11.123
>
>
>Since only the first match within the huntgroups is checked, team-2 always
>gets "access-reject".
>
>
>For checking only the NAS-IP-Adress makes sense in our environment.
>I already found a hint to use rlm-passwd, but i can?t get this run.
>
>So i tried the following:
>
>===
>Users:
>DEFAULT Auth-Type := LDAP, Huntgroup-Name == "nexus", My-Device-Group
>"Nexus-readonly", LDAP-Group == ""
>Login-Service = Telnet,
>Cisco-AVPair = "shell:roles*\"network-operator\" \"vdc-operator\""
>
>modules/passwd:
>passwd Groups_local {
>filename = /etc/raddb/groups_local
>format = "My-Device-Group:*NAS-IP-Address"
>hashsize = 50
>ignorenislike = no
>allowmultiplekeys = no
>delimiter = ":"
>}
>
>groups_local:
>Nexus-readonly:192.168.11.123
>
>dictionary:
>ATTRIBUTE My-Device-Group 3000string
>
>===
>
>Groups_local was placed in authorize section, after preprocess.
>
>Debug shows:
>
>Ready to process requests.
>rad_recv: Access-Request packet from host 192.168.11.123 port 48910, id=20,
>length=62
>User-Name = "test"
>User-Password = "test"
>NAS-Port-Type = Virtual
>NAS-Port = 3000
>NAS-IP-Address = 192.168.11.123
>+- entering group authorize {...}
>++[preprocess] returns ok
>++[groups_local] returns notfound
>
>Any Idea?
>Or is there a big bug in my config (and my mind)?
>Thanks!
>
>Jan
Does nobody has an idea what i´m doing wrong?
Or any idea how i could realize this?
Thanks a lot!
Jan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Devices in more than one huntgroup
Hi,
I have a little problem with devices in multiple huntgroups.
By now i kno that this is not possible (rtfm helped ;-)
What i wanted to do is the following:
Two Teams, but with diffenrent rights.
Users:
DEFAULT Auth-Type := LDAP, Huntgroup-Name == "nexus", LDAP-Group ==
""
Login-Service = Telnet,
Cisco-AVPair = "shell:roles*\"network-admin\" \"vdc-admin\""
DEFAULT Auth-Type := LDAP, Huntgroup-Name == "readonly-nexus", LDAP-Group ==
""
Login-Service = Telnet,
Cisco-AVPair = "shell:roles*\"network-operator\" \"vdc-operator\""
Huntgroups:
readonly-nexus NAS-IP-Address == 192.168.11.123
Nexus NAS-IP-Address == 192.168.11.123
Since only the first match within the huntgroups is checked, team-2 always gets
"access-reject".
For checking only the NAS-IP-Adress makes sense in our environment.
I already found a hint to use rlm-passwd, but i can´t get this run.
So i tried the following:
===
Users:
DEFAULT Auth-Type := LDAP, Huntgroup-Name == "nexus", My-Device-Group
"Nexus-readonly", LDAP-Group == ""
Login-Service = Telnet,
Cisco-AVPair = "shell:roles*\"network-operator\" \"vdc-operator\""
modules/passwd:
passwd Groups_local {
filename = /etc/raddb/groups_local
format = "My-Device-Group:*NAS-IP-Address"
hashsize = 50
ignorenislike = no
allowmultiplekeys = no
delimiter = ":"
}
groups_local:
Nexus-readonly:192.168.11.123
dictionary:
ATTRIBUTE My-Device-Group 3000string
===
Groups_local was placed in authorize section, after preprocess.
Debug shows:
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.11.123 port 48910, id=20,
length=62
User-Name = "test"
User-Password = "test"
NAS-Port-Type = Virtual
NAS-Port = 3000
NAS-IP-Address = 192.168.11.123
+- entering group authorize {...}
++[preprocess] returns ok
++[groups_local] returns notfound
Any Idea?
Or is there a big bug in my config (and my mind)?
Thanks!
Jan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ..::Huntgroup Issues::..
Thanks, now its working. I was trying to authenticate with the
localhost, when I tried to use the device everything works great.
Thanks for your help.
Regards.
Alfonso.
El 03/09/2010 06:18 a.m., Carlos Eduardo Tavares Terra escribió:
Maybe the problem is here:
rad_recv: Access-Request packet from host 127.0.0.1 port 6729, id=139,
length=58
User-Name = "steve2"
User-Password = "testing"
*NAS-IP-Address = 192.168.2.251*
NAS-Port = 10
2010/9/1 Alfonso Alejandro Reyes Jiménez <mailto:con...@gmail.com>>
Thanks for the advice to everyone.
As per your recomendation we changed the users file with the
following line:
steve2Cleartext-Password := "testing", Huntgroup-Name ==
"arcsight"
but we got the same result access-reject.
And we got the following output:
rad_recv: Access-Request packet from host 127.0.0.1 port 6729,
id=139, length=58
User-Name = "steve2"
User-Password = "testing"
NAS-IP-Address = 192.168.2.251
NAS-Port = 10
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "steve2", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns notfound
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user.
Authentication may fail because of this.
++[pap] returns noop
_/No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user/_
Failed to authenticate the user.
Using Post-Auth-Type Reject
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} -> steve2
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 139 to 127.0.0.1 port 6729
Waking up in 4.9 seconds.
Cleaning up request 0 ID 139 with timestamp +5
I have a question, we remove the autentication value and the debug
shows that it is looking for it, why is that?
May be someone that has the huntgroups running can send the
examples of the users and huntgroups files, that may help a lot.
Thanks in advance.
Regards
Alfonso.
El 24/08/2010 04:46 a.m., Alan DeKok escribió:
Alfonso Alejandro Reyes Jiménez wrote:
Hi, I'm trying to use the huntgroup feature on the freeradius software
with out luck. I think I'm missing something that's why I'm sending this
email maybe you can help me.
You should read the debug output of the server. The answer is in there.
users file at the end:
alfonso Auth-Type := Local, User-Password == "testing", Huntgroup-Name
== "squid"
Don't set Auth-Type. Use "Cleartext-Password := ...", and not
"User-Password == ..."
Here's the output of the debug, it seems that it doesn't find the config
file.
No. It finds the DEFAULT entry earlier in the file.
Why? This is documented. Read the comments at the top of the "users"
file. Read the "man users" page. Read the FAQ for an example of how to
configure a test user.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Carlos Eduardo Tavares Terra
Red Hat Certified Engineer
Consultor em Administração de Redes Linux
GNU/Linux #413291 [http://counter.li.org]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ..::Huntgroup Issues::..
Maybe the problem is here:
rad_recv: Access-Request packet from host 127.0.0.1 port 6729, id=139,
length=58
User-Name = "steve2"
User-Password = "testing"
*NAS-IP-Address = 192.168.2.251*
NAS-Port = 10
2010/9/1 Alfonso Alejandro Reyes Jiménez
> Thanks for the advice to everyone.
>
> As per your recomendation we changed the users file with the following
> line:
>
> steve2Cleartext-Password := "testing", Huntgroup-Name == "arcsight"
>
> but we got the same result access-reject.
>
> And we got the following output:
>
> rad_recv: Access-Request packet from host 127.0.0.1 port 6729, id=139,
> length=58
> User-Name = "steve2"
> User-Password = "testing"
> NAS-IP-Address = 192.168.2.251
> NAS-Port = 10
> +- entering group authorize {...}
> ++[preprocess] returns ok
> ++[chap] returns noop
> ++[mschap] returns noop
> [suffix] No '@' in User-Name = "steve2", looking up realm NULL
> [suffix] No such realm "NULL"
> ++[suffix] returns noop
>
> [eap] No EAP-Message, not doing EAP
> ++[eap] returns noop
> ++[unix] returns notfound
> ++[files] returns noop
> ++[expiration] returns noop
> ++[logintime] returns noop
> [pap] WARNING! No "known good" password found for the user. Authentication
> may fail because of this.
> ++[pap] returns noop
> *No authenticate method (Auth-Type) configuration found for the request:
> Rejecting the user*
> Failed to authenticate the user.
> Using Post-Auth-Type Reject
> +- entering group REJECT {...}
> [attr_filter.access_reject] expand: %{User-Name} -> steve2
> attr_filter: Matched entry DEFAULT at line 11
> ++[attr_filter.access_reject] returns updated
> Delaying reject of request 0 for 1 seconds
>
> Going to the next request
> Waking up in 0.9 seconds.
> Sending delayed reject for request 0
> Sending Access-Reject of id 139 to 127.0.0.1 port 6729
> Waking up in 4.9 seconds.
> Cleaning up request 0 ID 139 with timestamp +5
>
> I have a question, we remove the autentication value and the debug shows
> that it is looking for it, why is that?
>
> May be someone that has the huntgroups running can send the examples of the
> users and huntgroups files, that may help a lot.
>
> Thanks in advance.
>
> Regards
>
> Alfonso.
>
> El 24/08/2010 04:46 a.m., Alan DeKok escribió:
>
> Alfonso Alejandro Reyes Jiménez wrote:
>
> Hi, I'm trying to use the huntgroup feature on the freeradius software
> with out luck. I think I'm missing something that's why I'm sending this
> email maybe you can help me.
>
>You should read the debug output of the server. The answer is in there.
>
>
> users file at the end:
>
> alfonso Auth-Type := Local, User-Password == "testing", Huntgroup-Name
> == "squid"
>
> Don't set Auth-Type. Use "Cleartext-Password := ...", and not
> "User-Password == ..."
>
>
> Here's the output of the debug, it seems that it doesn't find the config
> file.
>
>No. It finds the DEFAULT entry earlier in the file.
>
> Why? This is documented. Read the comments at the top of the "users"
> file. Read the "man users" page. Read the FAQ for an example of how to
> configure a test user.
>
> Alan DeKok.
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
--
Carlos Eduardo Tavares Terra
Red Hat Certified Engineer
Consultor em Administração de Redes Linux
GNU/Linux #413291 [http://counter.li.org]
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ..::Huntgroup Issues::..
Thanks for the advice to everyone.
As per your recomendation we changed the users file with the following line:
steve2Cleartext-Password := "testing", Huntgroup-Name == "arcsight"
but we got the same result access-reject.
And we got the following output:
rad_recv: Access-Request packet from host 127.0.0.1 port 6729, id=139,
length=58
User-Name = "steve2"
User-Password = "testing"
NAS-IP-Address = 192.168.2.251
NAS-Port = 10
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
[suffix] No '@' in User-Name = "steve2", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
++[unix] returns notfound
++[files] returns noop
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user.
Authentication may fail because of this.
++[pap] returns noop
_/No authenticate method (Auth-Type) configuration found for the
request: Rejecting the user/_
Failed to authenticate the user.
Using Post-Auth-Type Reject
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} -> steve2
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 0 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 0
Sending Access-Reject of id 139 to 127.0.0.1 port 6729
Waking up in 4.9 seconds.
Cleaning up request 0 ID 139 with timestamp +5
I have a question, we remove the autentication value and the debug shows
that it is looking for it, why is that?
May be someone that has the huntgroups running can send the examples of
the users and huntgroups files, that may help a lot.
Thanks in advance.
Regards
Alfonso.
El 24/08/2010 04:46 a.m., Alan DeKok escribió:
Alfonso Alejandro Reyes Jiménez wrote:
Hi, I'm trying to use the huntgroup feature on the freeradius software
with out luck. I think I'm missing something that's why I'm sending this
email maybe you can help me.
You should read the debug output of the server. The answer is in there.
users file at the end:
alfonso Auth-Type := Local, User-Password == "testing", Huntgroup-Name
== "squid"
Don't set Auth-Type. Use "Cleartext-Password := ...", and not
"User-Password == ..."
Here's the output of the debug, it seems that it doesn't find the config
file.
No. It finds the DEFAULT entry earlier in the file.
Why? This is documented. Read the comments at the top of the "users"
file. Read the "man users" page. Read the FAQ for an example of how to
configure a test user.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: ..::Huntgroup Issues::..
Alfonso Alejandro Reyes Jiménez wrote: > Hi, I'm trying to use the huntgroup feature on the freeradius software > with out luck. I think I'm missing something that's why I'm sending this > email maybe you can help me. You should read the debug output of the server. The answer is in there. > users file at the end: > > alfonso Auth-Type := Local, User-Password == "testing", Huntgroup-Name > == "squid" Don't set Auth-Type. Use "Cleartext-Password := ...", and not "User-Password == ..." > Here's the output of the debug, it seems that it doesn't find the config > file. No. It finds the DEFAULT entry earlier in the file. Why? This is documented. Read the comments at the top of the "users" file. Read the "man users" page. Read the FAQ for an example of how to configure a test user. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
..::Huntgroup Issues::..
Hi, I'm trying to use the huntgroup feature on the freeradius software
with out luck. I think I'm missing something that's why I'm sending this
email maybe you can help me.
Right now I have the following files:
huntgroups file at the end:
squid NAS-IP-Address == 127.0.0.1
users file at the end:
alfonso Auth-Type := Local, User-Password == "testing", Huntgroup-Name
== "squid"
clients.conf at the end:
client 127.0.0.1 {
secret = xxx
shortname = squid
}
When I try with the radtest to log in, I get an access-reject.
Here's the client side response:
[r...@mscitum raddb]# radtest alfonso testing localhost 10 xxx
Sending Access-Request of id 134 to 127.0.0.1 port 1812
User-Name = "alfonso"
User-Password = "testing"
NAS-IP-Address = 255.255.255.255
NAS-Port = 10
rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=134,
length=20
Here's the output of the debug, it seems that it doesn't find the config
file.
rad_recv: Access-Request packet from host 127.0.0.1:36858, id=134,
length=59
User-Name = "alfonso"
User-Password = "testing"
NAS-IP-Address = 255.255.255.255
NAS-Port = 10
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 1
modcall[authorize]: module "preprocess" returns ok for request 1
modcall[authorize]: module "chap" returns noop for request 1
modcall[authorize]: module "mschap" returns noop for request 1
rlm_realm: No '@' in User-Name = "alfonso", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 1
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 1
users: Matched entry DEFAULT at line 152
modcall[authorize]: module "files" returns ok for request 1
modcall: leaving group authorize (returns ok) for request 1
rad_check_password: Found Auth-Type System
auth: type "System"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 1
modcall[authenticate]: module "unix" returns notfound for request 1
modcall: leaving group authenticate (returns notfound) for request 1
auth: Failed to validate the user.
Delaying request 1 for 1 seconds
Finished request 1
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 134 to 127.0.0.1 port 36858
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 1 ID 134 with timestamp 4c7319f1
Nothing to do. Sleeping until we see a request.
May be I'm missing to enable some feature, thanks in advance for your
help.
Regards
Alfonso.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
expiration linked to both huntgroup and user
Hi, So here's my hurdle. I have multiple groups and use hunt-groups plus expiration time on the users for authentication. Assuming I have groups 1 & 2 how is it possible to link the expiration time to a group and the user and not just for the user. The expiration time is set on a per user level (not per group) which means a given user will either have access or not have access. A user can not have access to hunt-group 1 with an expiration in 10 days as well as an access expiring in 2 hours on hunt-group B. I only want to have one user over the whole domain so do not want to create multiple users and then append to the name on the incoming request and authenticate against multiple users who are in fact the same. Is there any other way round this problem? Many thanks, Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Specifying sql instance to use for huntgroup group lookup
Doug Warner wrote: > I am specifying an Sql-Group required for one of my huntgroups and am finding > that when looking up the group info from my database that the wrong sql > instance is being used. I have an "sql_read" instance that's specified to be > used in my authorize section, but when the Sql-Group is evaluated for the > huntgroup my "sql_write" sql instance is used instead. > > Is there a way to specify which sql instance should be used in this situation? There's a fix in git v2.1x branch now. It adds -SQL-Group, just like for LDAP-Group. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Specifying sql instance to use for huntgroup group lookup
Doug Warner wrote: > I moved this thread over to the -devel list with a supplied patch. It appears > to me this isn't currently possible but might be trivial to fix. The fix is to copy the -LDAP-Group setup from the LDAP module, and change it to -SQL-Group. The fix should be in git tomorrow. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Specifying sql instance to use for huntgroup group lookup
On 06/21/2010 03:52 PM, Doug Warner wrote: > I am specifying an Sql-Group required for one of my huntgroups and am finding > that when looking up the group info from my database that the wrong sql > instance is being used. I have an "sql_read" instance that's specified to be > used in my authorize section, but when the Sql-Group is evaluated for the > huntgroup my "sql_write" sql instance is used instead. > > Is there a way to specify which sql instance should be used in this situation? > I moved this thread over to the -devel list with a supplied patch. It appears to me this isn't currently possible but might be trivial to fix. -Doug signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Specifying sql instance to use for huntgroup group lookup
I am specifying an Sql-Group required for one of my huntgroups and am finding that when looking up the group info from my database that the wrong sql instance is being used. I have an "sql_read" instance that's specified to be used in my authorize section, but when the Sql-Group is evaluated for the huntgroup my "sql_write" sql instance is used instead. Is there a way to specify which sql instance should be used in this situation? -Doug signature.asc Description: OpenPGP digital signature - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Using the NAS table for Huntgroup-Name
I thought I might share a configuration part that has proven useful for
us...
Based on the howto at http://wiki.freeradius.org/SQL_Huntgroup_HOWTO ,
we found that we might as well add the huntgroup name to the NAS table
when adding new NASes. No need to maintain two separate tables with the
NAS ip address as key... So we added a huntgroup field to the 'nas' sql
table and do
update request {
Huntgroup-Name := "%{sql:select huntgroup from nas where
nasname=\"%{NAS-IP-Address}\"}"
}
in the authorize section.
Not that this changes much, but at least it prevents the huntgroup SQL
lookup from failing due to missing NAS's
Bjørn
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQL Huntgroup only work with user check, not group check
On Thu, Sep 03, 2009 at 07:36:31AM -0300, Carlos Eduardo Tavares Terra wrote: > On Thu, Sep 3, 2009 at 6:30 AM, George Koulyabin wrote: > > > I wrote the rules for huntgroup here because the rules in groupcheck > didn't work. If I take this out, just keeping the groupcheck, 'jack' > will connect from any hardware. The groupcheck is ignoring the > huntgroups. You must to use huntgroups for consolidation of Your hardware by identical properties. For examle, You can create huntgroup for wireless hardware and huntgroup for access-servers. Groups, sql-groups (radusergroup/radgroupcheck/radgroupreply) are intended for consolidation of users. In Your 'sql-rules' You wrote: "User has 'wireless' sql-group membership. But user has this membership when he'll connected from the hardware (member of 'wireless' huntgroup)." See FreeRADIUS documentation, file rlm_sql. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQL Huntgroup only work with user check, not group check
> On Thu, Sep 3, 2009 at 6:30 AM, George Koulyabin wrote: >> >>> ++--+++--+ >>> | id | username | attribute | op | value | >>> ++--++----+------+ >>> | 5 | jack | Huntgroup-Name | == | wireless | >>> | 4 | jack | Cleartext-Password | := | foo | >>> ++--+++--+ >> You wrote rules for authorization/athentication of jack: Jack grants >> access from hardware of 'wireless' huntgroup with 'foo' password. > > I wrote the rules for huntgroup here because the rules in groupcheck > didn't work. If I take this out, just keeping the groupcheck, 'jack' > will connect from any hardware. The groupcheck is ignoring the > huntgroups. "Didn't work"? Sql groups emulate the way DEFAULT entries in users file work. The situation there is the same - if check doesn't match, entry is skipped. They do not emulate user entries - that's what radcheck/radreply entries do. That's why entries in radcheck "worked" and those in radgroupcheck "didn't". Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQL Huntgroup only work with user check, not group check
On Thu, Sep 3, 2009 at 6:30 AM, George Koulyabin wrote: > >> ++--+++--+ >> | id | username | attribute | op | value | >> ++--+++--+ >> | 5 | jack | Huntgroup-Name | == | wireless | >> | 4 | jack | Cleartext-Password | := | foo | >> ++--+++--+ > You wrote rules for authorization/athentication of jack: Jack grants access > from hardware of 'wireless' huntgroup with 'foo' password. I wrote the rules for huntgroup here because the rules in groupcheck didn't work. If I take this out, just keeping the groupcheck, 'jack' will connect from any hardware. The groupcheck is ignoring the huntgroups. > >> mysql> select * from radgroupcheck; >> ++---+++--+ >> | id | groupname | attribute | op | value | >> ++---+++--+ >> | 8 | wireless | Huntgroup-Name | == | wireless | >> ++---+++--+ > > But there is You wrote that You want to authorize the 'wireless' memebership > for jack. -- Carlos Eduardo Tavares Terra GNU/Linux #413291 [http://counter.li.org] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQL Huntgroup only work with user check, not group check
On Tue, Sep 01, 2009 at 09:49:20PM -0300, Carlos Eduardo Tavares Terra wrote: > ++---+--+---+ > | id | groupname | nasipaddress | nasportid | > ++---+--+---+ > | 5 | wireless | 192.168.2.5 | NULL | > | 4 | adsl | 192.168.2.6 | NULL | > ++---+--+---+ You described the huntgroups for Your hardware. > +--+---+--++ > | username | groupname | priority | id | > +--+---+--++ > | jack | wireless |1 | 1 | > +--+---+--++ User jack had got the 'wireless' membership. > ++--+++--+ > | id | username | attribute | op | value| > ++--+----++--+ > | 5 | jack | Huntgroup-Name | == | wireless | > | 4 | jack | Cleartext-Password | := | foo | > ++--+++--+ You wrote rules for authorization/athentication of jack: Jack grants access from hardware of 'wireless' huntgroup with 'foo' password. > mysql> select * from radgroupcheck; > ++---+++--+ > | id | groupname | attribute | op | value| > ++---+++--+ > | 8 | wireless | Huntgroup-Name | == | wireless | > ++---+++--+ But there is You wrote that You want to authorize the 'wireless' memebership for jack. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQL Huntgroup only work with user check, not group check
On Wed, Sep 2, 2009 at 5:13 AM, Ivan Kalik wrote: >> I am having trouble while trying to work with huntgroups. Maybe I >> misunderstand the way how huntgroups works. >> >> When I use 'Huntgroup-Name' into radcheck, everything works fine. But >> when I put the 'Huntgroup-Name' into radgroupcheck, the radius is just >> ignoring it. > > Nothing wrong with huntgroups. That's how sql groups work. If they don't > match they are ignored - user doesn't get rejected. > > Ivan Kalik > Kalik Informatika ISP > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > Is there anyway to reject if groupcheck fails? Thanks -- Carlos Eduardo Tavares Terra GNU/Linux #413291 [http://counter.li.org] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: SQL Huntgroup only work with user check, not group check
> I am having trouble while trying to work with huntgroups. Maybe I > misunderstand the way how huntgroups works. > > When I use 'Huntgroup-Name' into radcheck, everything works fine. But > when I put the 'Huntgroup-Name' into radgroupcheck, the radius is just > ignoring it. Nothing wrong with huntgroups. That's how sql groups work. If they don't match they are ignored - user doesn't get rejected. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
SQL Huntgroup only work with user check, not group check
Hello, I am having trouble while trying to work with huntgroups. Maybe I misunderstand the way how huntgroups works. I read another post about this issue, but I don't really understand why force the huntgroup name in confs. I have inserted two NAS' into radhuntgroup, as follow: mysql> select * from radhuntgroup; ++---+--+---+ | id | groupname | nasipaddress | nasportid | ++---+--+---+ | 5 | wireless | 192.168.2.5 | NULL | | 4 | adsl | 192.168.2.6 | NULL | ++---+--+---+ And associate the user 'jack' in group wireless: mysql> select * from radusergroup; +--+---+--++ | username | groupname | priority | id | +--+---+--++ | jack | wireless |1 | 1 | +--+---+--++ And created the rules to the user 'jack': mysql> select * from radcheck; ++--+++--+ | id | username | attribute | op | value| ++--+----++--+ | 5 | jack | Huntgroup-Name | == | wireless | | 4 | jack | Cleartext-Password | := | foo | ++--+++--+ When I use 'Huntgroup-Name' into radcheck, everything works fine. But when I put the 'Huntgroup-Name' into radgroupcheck, the radius is just ignoring it. mysql> select * from radgroupcheck; ++---+++--+ | id | groupname | attribute | op | value| ++---+++--+ | 8 | wireless | Huntgroup-Name | == | wireless | ++---+++--+ It only works in this way? Am I doing something wrong? Thanks -- Carlos Eduardo Tavares Terra GNU/Linux #413291 [http://counter.li.org] - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: huntgroup as an unlang check?
> hi,
>
> i've got a few virtual hosts that do checks on the NAS-IP-Address
> - all works fine - but those lists of NAS are now growing so
> in order to maintain sanity I thought 'heck, lets use a Huntgroup'
>
> however, I recall hu8ntgroups being very much tied to users
> and wasnt sure of their status in unlang.
With unlang you can use sql for hungroups as well.
http://wiki.freeradius.org/SQL_Huntgroup_HOWTO
> if i have
>
> raddb/hntgroups
>
> alphen NAS-IP-Address == 192.168.2.5
> alphen NAS-IP-Address == 192.168.2.6
> alphen NAS-IP-Address == 192.168.2.7
>
>
> and, in the virtual host i have
>
> if("%{HuntGroup}" == "alphen"){
It's Huntgroup-Name. And should be on request list.
> sql
> ok = return
> }
>
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroup as an unlang check?
hi,
i've got a few virtual hosts that do checks on the NAS-IP-Address
- all works fine - but those lists of NAS are now growing so
in order to maintain sanity I thought 'heck, lets use a Huntgroup'
however, I recall hu8ntgroups being very much tied to users
and wasnt sure of their status in unlang. if i have
raddb/hntgroups
alphen NAS-IP-Address == 192.168.2.5
alphen NAS-IP-Address == 192.168.2.6
alphen NAS-IP-Address == 192.168.2.7
and, in the virtual host i have
if("%{HuntGroup}" == "alphen"){
sql
ok = return
}
would this work as expected with unlang and this variable? ie
would the SQL only be hit if the NAS was 192.168.2.5, 192.168.2.6
or 192.168.2.7 - which in theory it looks like?
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP and Huntgroup-Name
Ivan Kalik wrote: > > Enable copy_request_to_tunnel in peap section of eap.conf. Hmmm... Now I feel stupid for not finding this myself... Thanks for showing me the right direction. Regards, -- Nicolas Boullis Ecole Centrale Paris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: PEAP and Huntgroup-Name
> Currently, the relevant part of my users file is: > > | DEFAULT Huntgroup-Name == ap, Prefix == "guest/", Autz-Type := GUEST > | Fall-Through = No > | > | DEFAULT Autz-Type := DEFAULT > > The trouble is the inner request has no NAS-IP-Address, so the > Huntgroup-Name is not set and does not match. > > Running freeradius -X shows that the Huntgroup-Name condition is > correctly verified for the outer request, but not for the inner one. Enable copy_request_to_tunnel in peap section of eap.conf. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
PEAP and Huntgroup-Name
Hello, I'm using Freeradius 2.0.4 from the package in Debian Lenny for WPA (for wifi) and 802.1x (for wired ethernet) authentication and authorization. They use PEAP/MSchapv2 for authentication. Most users are in LDAP and are allowed to connect either to wired ethernet or to wifi. But I also have to deal with some "guest" users, whose usernames all begin with the "guest/" prefix, who are in a SQL database, and who only should be allowed to connect to wifi. Currently, the relevant part of my users file is: | DEFAULT Huntgroup-Name == ap, Prefix == "guest/", Autz-Type := GUEST | Fall-Through = No | | DEFAULT Autz-Type := DEFAULT The trouble is the inner request has no NAS-IP-Address, so the Huntgroup-Name is not set and does not match. Running freeradius -X shows that the Huntgroup-Name condition is correctly verified for the outer request, but not for the inner one. And if I remove the Huntgroup-Name condition, everything works fine, but the guest users are allowed to connect to wired ethernet. Is there a way I can test the outer Huntgroup-Name in my users file? Regards, -- Nicolas Boullis Ecole Centrale Paris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup problem
> kmcuser Auth-Type = LDAP, Huntgroup-Name == "kmc1" > Fall-Through = Yes You probably don't need to force Auth-Type. What freeradius version is this? Why are you using version that is years out of date? > and following lines in /etc/raddb/huntgroup file: > > kmc1NAS-IP-Address == 172.16.0.150 > > After restarting radius server with radiusd -X, > Now if I am trying to logon to NAS device, it is unsuccessfull with > following messages: > > rad_recv: Access-Request packet from host 172.16.0.150:47715, id=31, > length=65 > NAS-IP-Address = 172.16.0.155 > Service-Type = Login-User > NAS-Port-Type = Virtual > User-Name = "kmcuser" > User-Password = "kmcnet" > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 0 > modcall[authorize]: module "preprocess" returns ok for request 0 > modcall[authorize]: module "chap" returns noop for request 0 > modcall[authorize]: module "mschap" returns noop for request 0 > rlm_realm: No '@' in User-Name = "kmcuser", looking up realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" 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 > modcall: leaving group authorize (returns ok) for request 0 > auth: No authenticate method (Auth-Type) configuration found for the > request: Re > jecting the user That's because you haven't listed ldap in authorize (and your password is in there). Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup problem
Parashar Singh wrote: > I am new to freeradius. You installed a *very* old version of the server. I suggest you upgrade to 2.1.6. > If I am doing following in /etc/raddb/users file: > > kmcuser Auth-Type = LDAP, Huntgroup-Name == "kmc1" > Fall-Through = Yes That says "use LDAP authentication for that huntgroup" > and following lines in /etc/raddb/huntgroup file: > > kmc1NAS-IP-Address == 172.16.0.150 ... > rad_recv: Access-Request packet from host 172.16.0.150:47715, id=31, length=65 > NAS-IP-Address = 172.16.0.155 And the user didn't log in from that huntgroup. > auth: No authenticate method (Auth-Type) configuration found for the > request: Rejecting the user So... no authentication was done. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroup problem
Hi I am new to freeradius. I want to implement huntgroup for associating a user name with particular NAS device. I am performing username authentication with Auth-Type = LDAP If my NAS devices are cisco routes, with IP A.B.C.D, and I want to authenticate this device with user1/* in LDAP, can some one pls provide what are configuration needed to modified in which files. If I am doing following in /etc/raddb/users file: kmcuser Auth-Type = LDAP, Huntgroup-Name == "kmc1" Fall-Through = Yes and following lines in /etc/raddb/huntgroup file: kmc1NAS-IP-Address == 172.16.0.150 After restarting radius server with radiusd -X, Now if I am trying to logon to NAS device, it is unsuccessfull with following messages: rad_recv: Access-Request packet from host 172.16.0.150:47715, id=31, length=65 NAS-IP-Address = 172.16.0.155 Service-Type = Login-User NAS-Port-Type = Virtual User-Name = "kmcuser" User-Password = "kmcnet" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "kmcuser", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" 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 modcall: leaving group authorize (returns ok) for request 0 auth: No authenticate method (Auth-Type) configuration found for the request: Re jecting the user auth: Failed to validate the user. Login incorrect: [kmcuser] (from client private-network-1 port 0) Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 31 to 172.16.0.150 port 47715 Waking up in 4 seconds... so pls tell me how shall I solve this problem?/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup replies using mysql
>In Freeradius 2.1.1 I've implemented the huntgroup table in the backend >which works well (using mysql and the guide provided below by John.) I need >to know how can I send the attributes above to the NAS based on the sql >huntgroup match which I get back from the SQL query? I've tried to add a >group in the radgroupreply table that sends back all necessary attributes >however that did not work as the huntgroup was not being checked against the >radgroupreply table. > No. It will be checked in radgroupcheck table. You should add Huntgroup-Name check there. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Huntgroup replies using mysql
Thanks Alan, I will look into that. Adrian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alan DeKok Sent: Monday, December 01, 2008 12:33 PM To: FreeRadius users mailing list Subject: Re: Huntgroup replies using mysql Adrian wrote: > The Users file would look like this: > > DEFAULT Huntgroup-Name == �Test_Group� > > Authentication-Type = Accept, (*** this > line no longer works in 2.1.1. It errors out with Invalid Octet string > �Accept� for attribute name �Authentication-Type�) Because that attribute doesn't exist. It has *never* existed. In 1.x, this invalid configuration would get silently ignored. In 2.x, you get an error. This tells you that the configuration doesn't do what you think it does. > In Freeradius 2.1.1 I�ve implemented the huntgroup table in the backend > which works well (using mysql and the guide provided below by John.) I > need to know how can I send the attributes above to the NAS based on the > sql huntgroup match which I get back from the SQL query? I�ve tried to > add a group in the radgroupreply table that sends back all necessary > attributes however that did not work as the huntgroup was not being > checked against the radgroupreply table. The SQL "radgroup" defaults to be for user groups, not huntgroups. > Running radiusd �X I can see that the huntgroup is identified correctly > and I get a ++ [request] returns ok from it however I�m not sure how to > send it the above attributes from sql instead of the users flatfile. See the "dialup.conf" file.The SQL queries for group queries are editable. You can change them to select based on huntgroups if you want. 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: Huntgroup replies using mysql
Adrian wrote: > The Users file would look like this: > > DEFAULT Huntgroup-Name == “Test_Group” > > Authentication-Type = Accept, (*** this > line no longer works in 2.1.1. It errors out with Invalid Octet string > “Accept” for attribute name “Authentication-Type”) Because that attribute doesn't exist. It has *never* existed. In 1.x, this invalid configuration would get silently ignored. In 2.x, you get an error. This tells you that the configuration doesn't do what you think it does. > In Freeradius 2.1.1 I’ve implemented the huntgroup table in the backend > which works well (using mysql and the guide provided below by John.) I > need to know how can I send the attributes above to the NAS based on the > sql huntgroup match which I get back from the SQL query? I’ve tried to > add a group in the radgroupreply table that sends back all necessary > attributes however that did not work as the huntgroup was not being > checked against the radgroupreply table. The SQL "radgroup" defaults to be for user groups, not huntgroups. > Running radiusd –X I can see that the huntgroup is identified correctly > and I get a ++ [request] returns ok from it however I’m not sure how to > send it the above attributes from sql instead of the users flatfile. See the "dialup.conf" file.The SQL queries for group queries are editable. You can change them to select based on huntgroups if you want. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroup replies using mysql
Hello John/All I'm moving from free-radius 1.1.7 to 2.1.1. In the old setup I was using the huntgroup file to tag a NAS and based on the IP address of that NAS assign it a huntgroup. Then, in the users file, I would send the huntgroup particular attributes. The Users file would look like this: DEFAULT Huntgroup-Name == "Test_Group" Authentication-Type = Accept, (*** this line no longer works in 2.1.1. It errors out with Invalid Octet string "Accept" for attribute name "Authentication-Type") Tunnel-Medium-Type = IP, Tunnel-Type = L2TP, etc.. In Freeradius 2.1.1 I've implemented the huntgroup table in the backend which works well (using mysql and the guide provided below by John.) I need to know how can I send the attributes above to the NAS based on the sql huntgroup match which I get back from the SQL query? I've tried to add a group in the radgroupreply table that sends back all necessary attributes however that did not work as the huntgroup was not being checked against the radgroupreply table. I can currently achieve what I need by enabling the users file (with the DEFAULT Entries in it) to be read in the preprocess module however I was hoping to keep all this in mysql. Running radiusd -X I can see that the huntgroup is identified correctly and I get a ++ [request] returns ok from it however I'm not sure how to send it the above attributes from sql instead of the users flatfile. Any help is appreciated, Adrian From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Dennis Sent: Tuesday, November 11, 2008 9:43 AM To: FreeRadius users mailing list Subject: Re: Restricting user to specific NAS Port Sean Preston wrote: Hi 2008/11/11 <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]>: I need to restrict a specifc user to say 2 specific NAS ports and then define a different account to some different specific NAS ports. Currently as long as an account is only ever going to use one NAS port I can restrict it by adding the entry to the radcheck table. So for example if I have 10 users, I have 10 entries with the NAS port and the == operator. However if I want to add some accounts with multiple entries then .. use huntgroups. Ok I think I understand what needs to be done. So the next question then is how do I setup huntgroups to be in the same database as everything else because as it stands it looks like it can only be a file and I am going to have hundreds of groups and it would be easier to manage in the database. Regards Sean I wrote documentation for how to implement huntgroups in SQL. It does require FreeRADIUS version 2.x because it depends on unlang. You won't need to modify FreeRADIUS 2.x, all you'll need to do is edit some config files and add a table to your database. The documentation is attached as a text file to this email. HTH, John -- John Dennis <mailto:[EMAIL PROTECTED]> <[EMAIL PROTECTED]> - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
huntgroup question
Hi, For some NAS i want to restrict the access for a single realm. For other NAS every realm is allowed. So I put in huntgroups: huntgroups: notebookNAS-IP-Address == 123.123.123.123, User-Name [EMAIL PROTECTED] This is only working, if the user has a Huntgroup-Name entry in the users file. users: bob Cleartext-Password := "hello", Huntgroup-Name =~note Is that correct? I understand the docs so, that the radius first looks into the hints file, than huntgroup and after that the realm is looked up. Hans -- Hans Bornemann Universitaet Dortmund - ITMC Tel. ++49 231 755 2132 Fax. ++49 231 755 2731 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Huntgroup and regular expression
Bill Shaver wrote: > I am running a fairly old version of FreeRADIUS (1.0.1). I would like > to define a regular expression (such as Guest\d+) for a set of users in > the huntgroup file for a specific NAS. Based on my reading of the docs, > this does not look like it is possible/supported, but I wanted to check > with the experts on the list in case I over had looked something obvious. Nope. You should really think about upgrading: http://freeradius.org/security.html Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroup and regular expression
I am running a fairly old version of FreeRADIUS (1.0.1). I would like to define a regular expression (such as Guest\d+) for a set of users in the huntgroup file for a specific NAS. Based on my reading of the docs, this does not look like it is possible/supported, but I wanted to check with the experts on the list in case I over had looked something obvious. Thanks for your time and wisdom. --Bill - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: wpa2 - huntgroup problems -fixed
I have Mike's spot under the carport in the A lot today, so he can be in
the shade. I'll come over after staff meeting.
-Original Message-
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
.org] On Behalf Of Hans Bornemann
Sent: Thursday, April 10, 2008 8:15 AM
To: FreeRadius users mailing list
Subject: Re: wpa2 - huntgroup problems -fixed
Hi,
huntgroups and PEAP works, if you set
copy_request_to_tunnel = yes
in eap.conf.
eap.conf:
...
peap {
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
default_eap_type = mschapv2
# the PEAP module also has these configuration
# items, which are the same as for TTLS.
copy_request_to_tunnel = yes
hans
On Thu, 2008-04-10 at 12:50 +0200, Hans Bornemann wrote:
> Hi,
>
> maybe a missunderstanding. The authentication with crypt-password
> works fine. The authentication with nt-passwords only works, if no
> huntgroup is defined in the database.
>
> if huntgroup is defined:
> rlm_sql (sql): No matching entry in the database for request from user
>
> if not:
> modcall[authorize]: module "sql" returns ok for request 0
>
> i have checked the debug - the nas-ip is the same as defined in the
> huntgroupsfile
>
> thanks
> Hans
>
>
>
>
> On Thu, 2008-04-10 at 10:49 +0100, Phil Mayers wrote:
> > Hans Bornemann wrote:
> > > Hi,
> > >
> > > did you mean the operator for the huntgroups?
> >
> > No. Crypt-Password
> >
> > >
> > > hans
> > >
> > >
> > > On Thu, 2008-04-10 at 10:29 +0100, Phil Mayers wrote:
> > >> Hans Bornemann wrote:
> > >>> Hi,
> > >>>
> > >>> I have a problem with huntgroups and wpa2. It concerns the
> > >>> following:
> > >>>
> > >>> First, huntgroups works with ntradping and crypt-passwd:
> > >>>
> > >>> mysql-db
> > >>>
> > >>> unzinn| NT-Password| := |
7C53CFA5EA7D0F9B3B968AA0FB51A3F5
> > >>> unzinn| crypt-password | == |
$1$7ftISFCW$xp.n8LMOxfPD7GqdSJqZC1
> > >> This is wrong; remove it, or set the operator to :=
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
--
Hans Bornemann
Universitaet Dortmund - ITMC
Tel. ++49 231 755 2132 Fax. ++49 231 755 2731
-
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: wpa2 - huntgroup problems -fixed
Hi,
huntgroups and PEAP works, if you set
copy_request_to_tunnel = yes
in eap.conf.
eap.conf:
...
peap {
# The tunneled EAP session needs a default
# EAP type which is separate from the one for
# the non-tunneled EAP module. Inside of the
# PEAP tunnel, we recommend using MS-CHAPv2,
# as that is the default type supported by
# Windows clients.
default_eap_type = mschapv2
# the PEAP module also has these configuration
# items, which are the same as for TTLS.
copy_request_to_tunnel = yes
hans
On Thu, 2008-04-10 at 12:50 +0200, Hans Bornemann wrote:
> Hi,
>
> maybe a missunderstanding. The authentication with crypt-password works
> fine. The authentication with nt-passwords only works, if no huntgroup
> is defined in the database.
>
> if huntgroup is defined:
> rlm_sql (sql): No matching entry in the database for request from user
>
> if not:
> modcall[authorize]: module "sql" returns ok for request 0
>
> i have checked the debug - the nas-ip is the same as defined in the
> huntgroupsfile
>
> thanks
> Hans
>
>
>
>
> On Thu, 2008-04-10 at 10:49 +0100, Phil Mayers wrote:
> > Hans Bornemann wrote:
> > > Hi,
> > >
> > > did you mean the operator for the huntgroups?
> >
> > No. Crypt-Password
> >
> > >
> > > hans
> > >
> > >
> > > On Thu, 2008-04-10 at 10:29 +0100, Phil Mayers wrote:
> > >> Hans Bornemann wrote:
> > >>> Hi,
> > >>>
> > >>> I have a problem with huntgroups and wpa2. It concerns the following:
> > >>>
> > >>> First, huntgroups works with ntradping and crypt-passwd:
> > >>>
> > >>> mysql-db
> > >>>
> > >>> unzinn| NT-Password| := | 7C53CFA5EA7D0F9B3B968AA0FB51A3F5
> > >>> unzinn| crypt-password | == | $1$7ftISFCW$xp.n8LMOxfPD7GqdSJqZC1
> > >> This is wrong; remove it, or set the operator to :=
> >
> > -
> > List info/subscribe/unsubscribe? See
> > http://www.freeradius.org/list/users.html
--
Hans Bornemann
Universitaet Dortmund - ITMC
Tel. ++49 231 755 2132 Fax. ++49 231 755 2731
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: wpa2 - huntgroup problems
Hi, maybe a missunderstanding. The authentication with crypt-password works fine. The authentication with nt-passwords only works, if no huntgroup is defined in the database. if huntgroup is defined: rlm_sql (sql): No matching entry in the database for request from user if not: modcall[authorize]: module "sql" returns ok for request 0 i have checked the debug - the nas-ip is the same as defined in the huntgroupsfile thanks Hans On Thu, 2008-04-10 at 10:49 +0100, Phil Mayers wrote: > Hans Bornemann wrote: > > Hi, > > > > did you mean the operator for the huntgroups? > > No. Crypt-Password > > > > > hans > > > > > > On Thu, 2008-04-10 at 10:29 +0100, Phil Mayers wrote: > >> Hans Bornemann wrote: > >>> Hi, > >>> > >>> I have a problem with huntgroups and wpa2. It concerns the following: > >>> > >>> First, huntgroups works with ntradping and crypt-passwd: > >>> > >>> mysql-db > >>> > >>> unzinn| NT-Password| := | 7C53CFA5EA7D0F9B3B968AA0FB51A3F5 > >>> unzinn| crypt-password | == | $1$7ftISFCW$xp.n8LMOxfPD7GqdSJqZC1 > >> This is wrong; remove it, or set the operator to := > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- Hans Bornemann Universitaet Dortmund - ITMC Tel. ++49 231 755 2132 Fax. ++49 231 755 2731 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: wpa2 - huntgroup problems
Hans Bornemann wrote: Hi, did you mean the operator for the huntgroups? No. Crypt-Password hans On Thu, 2008-04-10 at 10:29 +0100, Phil Mayers wrote: Hans Bornemann wrote: Hi, I have a problem with huntgroups and wpa2. It concerns the following: First, huntgroups works with ntradping and crypt-passwd: mysql-db unzinn| NT-Password| := | 7C53CFA5EA7D0F9B3B968AA0FB51A3F5 unzinn| crypt-password | == | $1$7ftISFCW$xp.n8LMOxfPD7GqdSJqZC1 This is wrong; remove it, or set the operator to := - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: wpa2 - huntgroup problems
Hi, did you mean the operator for the huntgroups? hans On Thu, 2008-04-10 at 10:29 +0100, Phil Mayers wrote: > Hans Bornemann wrote: > > Hi, > > > > I have a problem with huntgroups and wpa2. It concerns the following: > > > > First, huntgroups works with ntradping and crypt-passwd: > > > > mysql-db > > > > unzinn| NT-Password| := | 7C53CFA5EA7D0F9B3B968AA0FB51A3F5 > > unzinn| crypt-password | == | $1$7ftISFCW$xp.n8LMOxfPD7GqdSJqZC1 > > This is wrong; remove it, or set the operator to := -- Hans Bornemann Universitaet Dortmund - ITMC Tel. ++49 231 755 2132 Fax. ++49 231 755 2731 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: wpa2 - huntgroup problems
Hans Bornemann wrote: Hi, I have a problem with huntgroups and wpa2. It concerns the following: First, huntgroups works with ntradping and crypt-passwd: mysql-db unzinn| NT-Password| := | 7C53CFA5EA7D0F9B3B968AA0FB51A3F5 unzinn| crypt-password | == | $1$7ftISFCW$xp.n8LMOxfPD7GqdSJqZC1 This is wrong; remove it, or set the operator to := - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
wpa2 - huntgroup problems
Hi, I have a problem with huntgroups and wpa2. It concerns the following: First, huntgroups works with ntradping and crypt-passwd: mysql-db unzinn| NT-Password| := | 7C53CFA5EA7D0F9B3B968AA0FB51A3F5 unzinn| crypt-password | == | $1$7ftISFCW$xp.n8LMOxfPD7GqdSJqZC1 unzinn| Huntgroup-Name | == | hrzvpn with wpa2 (PEAP/MSCHAPv2) it works only without the huntgroup entry. Is this a problem because of different adresses? Access-Request packet from host 129.217.169.191 .. NAS-IP-Address = 129.217.157.246 ? huntgroups: hrzvpn NAS-IP-Address == 129.217.157.246 debug: rad_recv: :32769, id=33, length=176 User-Name = "unzinn" Calling-Station-Id = "00-19-D2-CF-E5-50" Called-Station-Id = "00-0B-85-9A-2D-30:ITMC-WPA2" NAS-Port = 29 NAS-IP-Address = 129.217.157.246 NAS-Identifier = "mh-wlc4" Airespace-Wlan-Id = 5 Service-Type = Framed-User Framed-MTU = 1300 NAS-Port-Type = Wireless-802.11 Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Private-Group-Id:0 = "3503" EAP-Message = 0x0201000b01756e7a696e6e Message-Authenticator = 0x2bf90a315bc202464b3819722bfef98e Processing the authorize section of radiusd.conf modcall: entering group authorize for request 9 modcall[authorize]: module "preprocess" returns ok for request 9 modcall[authorize]: module "chap" returns noop for request 9 modcall[authorize]: module "mschap" returns noop for request 9 rlm_realm: No '@' in User-Name = "unzinn", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 9 rlm_eap: EAP packet type response id 1 length 11 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 9 radius_xlat: 'unzinn' rlm_sql (sql): sql_set_user escaped user --> 'unzinn' radius_xlat: 'SELECT id, UserName, Attribute, Value, op FROM radcheck WHERE Username = 'unzinn' ORDER BY id' rlm_sql (sql): Reserving sql socket id: 2 radius_xlat: 'SELECT radgroupcheck.id,radgroupcheck.GroupName,radgroupcheck.Attribute,radgroupcheck.Value,radgroupcheck.op FROM radgroupcheck,usergroup WHERE usergroup.Username = 'unzinn' AND usergroup.GroupName = radgroupcheck.GroupName ORDER BY radgroupcheck.id' radius_xlat: 'SELECT id, UserName, Attribute, Value, op FROM radreply WHERE Username = 'unzinn' ORDER BY id' radius_xlat: 'SELECT radgroupreply.id,radgroupreply.GroupName,radgroupreply.Attribute,radgroupreply.Value,radgroupreply.op FROM radgroupreply,usergroup WHERE usergroup.Username = 'unzinn' AND usergroup.GroupName = radgroupreply.GroupName ORDER BY radgroupreply.id' rlm_sql (sql): Released sql socket id: 2 rlm_sql (sql): No matching entry in the database for request from user [unzinn] modcall[authorize]: module "sql" returns notfound for request 9 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 9 modcall: leaving group authorize (returns updated) for request 9 rad_check_password: Found Auth-Type EAP auth: type "EAP" Thanks Hans -- Hans Bornemann Universitaet Dortmund - ITMC Tel. ++49 231 755 2132 Fax. ++49 231 755 2731 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Example listed in huntgroup file does not work
Dana 13/12/2007, "Reynolds, Walter" <[EMAIL PROTECTED]> piše:
>
>I am looking at that option, but I should not have to. Per the
>huntgroups file:
>
>"# This file can also be used to define restricted access
># to certain huntgroups. The second and following lines
># define the access restrictions (based on username and
># UNIX usergroup) for the huntgroup.
>#"
>
>
>So I can create a huntgroup with multiple Nas, but the 'second and
>following lines' are only recognized by the last entry in the huntgroup.
>So If I go with groups, I should be able to add the following: (can
>someone tell me if this is the write syntax, or do I still have to add
>something to the dictionary have to leave right now to catch a
>flight. Thanks)
>
>File radiusd.conf
>
>passwd etc_group {
> filename = /usr/local/ett/raddb/grouplist
> format = "=Group-Name:*,User-Name"
> hashsize = 50
> ignorenislike = yes
> allowmultiplekeys = yes
> delimiter = ":"
>}
>
Yes, you can create groups through files with rlm_passwd module.
>File huntgroups:
>
>Limit1 NAS-IP-Address == 192.168.2.5
>Limit1 NAS-IP-Address == 192.168.2.6
> Group-Name == datacenter
>---
That's not going to work for the same reason as the list of usernames.
It is listed only for the last entry. You don't seem to comprehend that
it's totally irrelevant do the entries have same or different names
*inside* the huntgroups file. Grouping (giving entries the same name)
only has such effect *outside* the huntgroups file when you use
Huntgroup-Name attribute.
To save you some bother - don't group datacenter users. You don't want
to tie users to certain devices, you want to prevent some others to gain
access to those devices. Entry like this in users file will do that:
DEFAULT Group-Name == nopasaran, Huntgroup-Name == Limit1, Auth-Type :=
Reject
Ivan Kalik
Kalik Informatika ISP
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Example listed in huntgroup file does not work
Hi, > "# This file can also be used to define restricted access > # to certain huntgroups. The second and following lines > # define the access restrictions (based on username and > # UNIX usergroup) for the huntgroup. > #" so why not do as i suggest and define usergroups - then add the user to such groups? if you want this to scale then i'd have to say that SQL is the way to go. > So I can create a huntgroup with multiple Nas, but the 'second and > following lines' are only recognized by the last entry in the huntgroup. no, they become sub-group huntgroup entries - you need to enter the same 'following lines' on all members of the huntgroup alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Example listed in huntgroup file does not work
I am looking at that option, but I should not have to. Per the
huntgroups file:
"# This file can also be used to define restricted access
# to certain huntgroups. The second and following lines
# define the access restrictions (based on username and
# UNIX usergroup) for the huntgroup.
#"
So I can create a huntgroup with multiple Nas, but the 'second and
following lines' are only recognized by the last entry in the huntgroup.
So If I go with groups, I should be able to add the following: (can
someone tell me if this is the write syntax, or do I still have to add
something to the dictionary have to leave right now to catch a
flight. Thanks)
File radiusd.conf
passwd etc_group {
filename = /usr/local/ett/raddb/grouplist
format = "=Group-Name:*,User-Name"
hashsize = 50
ignorenislike = yes
allowmultiplekeys = yes
delimiter = ":"
}
=
File
/usr/local/etc/raddb/grouplist:
datacenter:user1,user2,usera
==
File huntgroups:
Limit1 NAS-IP-Address == 192.168.2.5
Limit1 NAS-IP-Address == 192.168.2.6
Group-Name == datacenter
---
Walt Reynolds
Principal Systems Security Development Engineer
Information Technology Central Services
University of Michigan
(734) 615-9438
>
> Message: 8
> Date: Thu, 13 Dec 2007 12:55:51 +
> From: [EMAIL PROTECTED]
> Subject: Re: Example listed in huntgroup file does not work
> To: FreeRadius users mailing list
>
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=us-ascii
>
> Hi,
>
> > I should say that I do not want to use an external solution.
> Creating a
> > huntgroup for each NAS with the exact same user list does work, but
> then
> > if I have to change a user I would then have to modify what could be
> > over 100 groups.
>
> i think, therein, lies your problem - you havent looked at the whole
> logical design - and are fixated on the singular huntgroups file.
>
> if you want to control users, in groups, with huntgroups etc then
> you should be using the huntgroup file to define NAS in groups, and
> then another config file eg users to tie users to those huntgroups.
>
> alan
>
>
> --
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
>
> End of Freeradius-Users Digest, Vol 32, Issue 37
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Example listed in huntgroup file does not work
>I did, but the user list is not being recognized by more than one. >How can I get that user list to be used for all NAS that are in that >huntgroup? Or is this a bug? > No, it's not a bug. It's a flat file entry. Every entry is matched separately. i.e. one entry doesn't "know" what's listed under another. > >I should say that I do not want to use an external solution. Creating a >huntgroup for each NAS with the exact same user list does work, but then >if I have to change a user I would then have to modify what could be >over 100 groups. > So, there is a very good case to use database in this case, then? Single entry vs. "over 100" of them to administrate? And why would the database be an "external solution"? Freeradius integrates very well and quite easily with several database servers. And you can leave your passwords where they are and use database just for group creation. Ivan Kalik Kalik Informatika ISP - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Example listed in huntgroup file does not work
Hi, > I should say that I do not want to use an external solution. Creating a > huntgroup for each NAS with the exact same user list does work, but then > if I have to change a user I would then have to modify what could be > over 100 groups. i think, therein, lies your problem - you havent looked at the whole logical design - and are fixated on the singular huntgroups file. if you want to control users, in groups, with huntgroups etc then you should be using the huntgroup file to define NAS in groups, and then another config file eg users to tie users to those huntgroups. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Example listed in huntgroup file does not work
> Message: 9 > Date: Wed, 12 Dec 2007 22:41:54 +0100 > From: <[EMAIL PROTECTED]> > Subject: RE: Example listed in huntgroup file does not work > To: "FreeRadius users mailing list" > > Message-ID: <[EMAIL PROTECTED]> > Content-Type: text/plain; charset=ISO-8859-2 > > >But I guess here is my problem. How do you assign more than one NAS > to > >a huntgroup? > > > The way it is shown in the huntgroups file. > I did, but the user list is not being recognized by more than one. How can I get that user list to be used for all NAS that are in that huntgroup? Or is this a bug? > >But this uses SQL which we are not using and would prefer not to. > > > Use LDAP then. Or feel free to list (same) users for every huntgroup > entry. I should say that I do not want to use an external solution. Creating a huntgroup for each NAS with the exact same user list does work, but then if I have to change a user I would then have to modify what could be over 100 groups. > > Ivan Kalik > Kalik Informatika ISP > > --- Walt Reynolds Principal Systems Security Development Engineer Information Technology Central Services University of Michigan (734) 615-9438 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
