Re: Username with spaces (MySQL)
On Wed, 2013-04-17 at 22:03 -0500, Andres Gomez Ruiz wrote: So I have many users using the same username putting one, two, three, ...etc., spaces after the username. How can I solve this situation? May be with a SQL query that ignores the spaces in the username? (talking about the sql counters) Not really a RADIUS question, but this is default behaviour for MySQL. Convert the VARCHAR Field to binary or use TRIM() for the counters. Regards, Wilco Baan Hofman - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Username with spaces (MySQL)
You can add
if (%{User-Name} =~ / /) {
reject
}
at the start of the authorize section.
This rule will reject user(s) in case they add blank spaces before or after the
username...
On 18.4.2013 9:47, Wilco Baan Hofman wrote:
On Wed, 2013-04-17 at 22:03 -0500, Andres Gomez Ruiz wrote:
So I have many users using the same username putting one, two,
three, ...etc., spaces after the username.
How can I solve this situation?
May be with a SQL query that ignores the spaces in the username?
(talking about the sql counters)
Not really a RADIUS question, but this is default behaviour for MySQL.
Convert the VARCHAR Field to binary or use TRIM() for the counters.
Regards,
Wilco Baan Hofman
-
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: Username with spaces (MySQL)
Hi,
You can add
if (%{User-Name} =~ / /) {
reject
}
at the start of the authorize section.
This rule will reject user(s) in case they add blank spaces before or after
the username...
invoke a policy. there are examples and usable methods already in
policy.conf (2.x) and policy.d/* (3.x) - eg filter_username
that you can use/modify.
note that the above example quoted wont do what you expect...it will
reject ANY user-name that contains a space anywhere - you may need to
use some more regex to match whether space is at the END or BEGINNING
of the attribute eg (quick, nasty example)
if ( (%{User-Name} =~ / $/) || (%{User-Name} =~ /^ /) ){
reject
}
note...i said quick nasty example. this isnt the best regex. ;-)
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: captive portal auth with freeradius
What I found from wiki that we don't require to set Auth-Type freeradius will determine from request automatically , so I removed DEFAULT Auth-Type = Reject from users file , is that OK ? With this at-least radtest starts working but still request from captive portal didnt worked , What I found from radius logs this looks to be the difference *radtest* [mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap' *captive portal * ++[mschap] returns noop What could be missing ? On Wed, Apr 17, 2013 at 8:37 PM, Chitrang Srivastava chitrang.srivast...@gmail.com wrote: But its working fine with wifi authentication ( I am using ntlm auth for MSCHAPv2 with LDAP) only issue is with when request come from captive portal ..I needto see why PAP request comes On Wed, Apr 17, 2013 at 7:28 PM, Olivier Beytrison oliv...@heliosnet.orgwrote: On 17.04.2013 15:37, Chitrang Srivastava wrote: Thanks , I am trying to MSCHAPv2 (TTLS or PEAP ) or GTC with LDAP MSCHAPv2 with EAP-TTLS or PEAP will NOT work with LDAP. as explained almost everywhere, and especially here : http://deployingradius.com/documents/protocols/compatibility.html You need a cleartext password or a NT_Hash to authenticate with MSCHAPv2. Only EAP-GTC will work with LDAP if I'm not mistaken. And by the way, your debug output show a request using PAP. PAP and EAP are two completly different things, which different requirements. I see that rlm_ldap.c will set Auth-Type as ldap based on set_auth_type =yes and 3 other flags, tried but it didn't worked , I will try from scratch This won't change that you can't authenticate with EAP-TTLS/PEAP and MSCHAPv2 against a LDAP directory. (Well, except if you're using Novell eDirectory with the Central Password management, but that's another story). Olivier -- Olivier Beytrison Network Security Engineer, HES-SO Fribourg Mail: oliv...@heliosnet.org - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
pptpd+freeradius+ldap ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user
Hi everybody,
I'm having some problems with freeradius and ldap authentication.
I need to authenticate an user connecting in vpn to my pptpd daemon,
which will ask permission to freeradius.
I installed freeradius and configured it to use ldap in this way (i
stripped comments to shorten the config files):
sites-available/default:
authorize {
ldap
preprocess
chap
mschap
digest
suffix
eap {
ok = return
}
expiration
logintime
pap
}
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
Auth-Type LDAP {
ldap
}
}
preacct {
preprocess
acct_unique
suffix
files
}
accounting {
detail
unix
radutmp
exec
}
session {
radutmp
}
post-auth {
ldap
exec
Post-Auth-Type REJECT {
attr_filter.access_reject
}
}
pre-proxy {
}
post-proxy {
eap
}
modules/ldap:
ldap {
server = 10.1.98.50
identity = cn=admin,dc=domain,dc=private
password = password
basedn = dc=domain,dc=private
filter = (uid=%{%{Stripped-User-Name}:-%{User-Name}})
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
tls {
start_tls = no
}
dictionary_mapping = ${confdir}/ldap.attrmap
password_attribute = userPassword
edir_account_policy_check = no
}
radiusd.conf
prefix = /usr
exec_prefix = /usr
sysconfdir = /etc
localstatedir = /var
sbindir = ${exec_prefix}/sbin
logdir = /var/log/freeradius
raddbdir = /etc/freeradius
radacctdir = ${logdir}/radacct
name = freeradius
confdir = ${raddbdir}
run_dir = ${localstatedir}/run/${name}
db_dir = ${raddbdir}
libdir = /usr/lib/freeradius
pidfile = ${run_dir}/${name}.pid
user = freerad
group = freerad
max_request_time = 30
cleanup_delay = 5
max_requests = 1024
listen {
type = auth
ipaddr = *
port = 0
}
listen {
ipaddr = *
port = 0
type = acct
}
hostname_lookups = no
allow_core_dumps = no
regular_expressions= yes
extended_expressions= yes
log {
destination = files
file = ${logdir}/radius.log
syslog_facility = daemon
stripped_names = no
auth = no
auth_badpass = no
auth_goodpass = no
}
checkrad = ${sbindir}/checkrad
security {
max_attributes = 200
reject_delay = 1
status_server = yes
}
proxy_requests = yes
$INCLUDE proxy.conf
$INCLUDE clients.conf
thread pool {
start_servers = 5
max_servers = 32
min_spare_servers = 3
max_spare_servers = 10
max_requests_per_server = 0
}
modules {
$INCLUDE ${confdir}/modules/
$INCLUDE eap.conf
}
instantiate {
exec
expr
expiration
logintime
}
$INCLUDE policy.conf
$INCLUDE sites-enabled/
When I run freeradius -X this is what I get:
FreeRADIUS Version 2.1.10, for host x86_64-pc-linux-gnu, built on Sep 24
2012 at 17:58:57
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/passwd
including configuration file
/etc/freeradius/modules/sqlcounter_expire_on_login
including configuration file /etc/freeradius/modules/linelog
including configuration file /etc/freeradius/modules/policy
including configuration file /etc/freeradius/modules/counter
including configuration file /etc/freeradius/modules/realm
including configuration file /etc/freeradius/modules/expiration
including configuration file /etc/freeradius/modules/mac2ip
including configuration file /etc/freeradius/modules/dynamic_clients
including configuration file /etc/freeradius/modules/mac2vlan
including configuration file /etc/freeradius/modules/smsotp
including configuration file /etc/freeradius/modules/cui
including configuration file /etc/freeradius/modules/chap
including configuration file /etc/freeradius/modules/detail.example.com
including configuration file /etc/freeradius/modules/smbpasswd
including configuration file /etc/freeradius/modules/sradutmp
including configuration file /etc/freeradius/modules/etc_group
including configuration file /etc/freeradius/modules/attr_rewrite
including configuration file /etc/freeradius/modules/pap
including configuration file /etc/freeradius/modules/radutmp
including configuration file /etc/freeradius/modules/echo
including configuration file /etc/freeradius/modules/ippool
including configuration file /etc/freeradius/modules/attr_filter
including configuration file /etc/freeradius/modules/otp
including configuration file
Re: pptpd+freeradius+ldap ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user
On 18 Apr 2013, at 11:43, Alberto Aldrigo aaldr...@ca-tron.com wrote: rad_recv: Access-Request packet from host 10.1.98.52 port 45105, id=139, length=77 Service-Type = Framed-User Framed-Protocol = PPP User-Name = user Calling-Station-Id = 10.1.0.136 NAS-IP-Address = 127.0.1.1 NAS-Port = 0 PPPD isn't sending a password. The hash is being found by LDAP fine, but there is no password in the radius request for it to validate. You need to fix PPPD, then it should work. Thanks, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending a disconnect message when replying with an access reject.
On Thu, Apr 18, 2013 at 05:52:16PM +1200, Peter Lambrechtsen wrote: When I setup the post-auth policy to send a update disconnect it works fine if the response is an access accept. But if I update the control to access reject the disconnect module gives me a noop. As a guess: The Post-Auth-Type REJECT section in the inner-tunnel is never called. This is fixed in v2.x.x HEAD and master. Post-Auth-Type REJECT in the outer tunnel is fine. This might be your problem. Or perhaps I am just doing something wrong. You didn't send output from radiusd -X. Matthew -- Matthew Newton, Ph.D. m...@le.ac.uk Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, ith...@le.ac.uk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Username with spaces (MySQL)
Hi
I had same trouble.. in version 1.x of radius.. and had to did queries like
above with regex... but for luck in the new version 2.x just have to enable
the policy.conf in the authorization module.. and your problem will be solve
regards.
2013/4/18 a.l.m.bu...@lboro.ac.uk
Hi,
You can add
if (%{User-Name} =~ / /) {
reject
}
at the start of the authorize section.
This rule will reject user(s) in case they add blank spaces before or
after the username...
invoke a policy. there are examples and usable methods already in
policy.conf (2.x) and policy.d/* (3.x) - eg filter_username
that you can use/modify.
note that the above example quoted wont do what you expect...it will
reject ANY user-name that contains a space anywhere - you may need to
use some more regex to match whether space is at the END or BEGINNING
of the attribute eg (quick, nasty example)
if ( (%{User-Name} =~ / $/) || (%{User-Name} =~ /^ /) ){
reject
}
note...i said quick nasty example. this isnt the best regex. ;-)
alan
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
--
Antonio Peña
Secure email with PGP 0x8B021001 available at http://pgp.mit.edu
Fingerprint: 74E6 2974 B090 366D CE71 7BB2 6476 FA09 8B02 1001
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: captive portal auth with freeradius
Chitrang Srivastava wrote: What I found from wiki that we don't require to set Auth-Type freeradius will determine from request automatically , so I removed DEFAULT Auth-Type = Reject from users file , is that OK ? With this at-least radtest starts working but still request from captive portal didnt worked , What I found from radius logs this looks to be the difference *radtest* [mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap' *captive portal * ++[mschap] returns noop What could be missing ? The debug log as suggested in the FAQ, man pages, web pages, and daily on this list. If you're not going to follow instructions, you shouldn't be on this list. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: captive portal auth with freeradius
debug log are attched in earlier reply, Please see On Thu, Apr 18, 2013 at 6:49 PM, Alan DeKok al...@deployingradius.comwrote: Chitrang Srivastava wrote: What I found from wiki that we don't require to set Auth-Type freeradius will determine from request automatically , so I removed DEFAULT Auth-Type = Reject from users file , is that OK ? With this at-least radtest starts working but still request from captive portal didnt worked , What I found from radius logs this looks to be the difference *radtest* [mschap] Found MS-CHAP attributes. Setting 'Auth-Type = mschap' *captive portal * ++[mschap] returns noop What could be missing ? The debug log as suggested in the FAQ, man pages, web pages, and daily on this list. If you're not going to follow instructions, you shouldn't be on this list. 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: Profile-Name attribute
Hi Alan, On 04/17/2013 05:50 PM, Alan DeKok wrote: John Center wrote: I see this isn't defined in the v2.2 FreeRADIUS internal dictionary, though there is a gap in the numbering where it would be. If I understand it correctly, it looks like one could have a profiles file with individual named profiles defined containing NAS-specific text that would be sent back to the NAS as is upon successful authentication. Is anything like this still supported? Can the User-Profile attribute be used in a similar way? I'm not sure what Merit meant by profiles. So no, FreeRADIUS doesn't do that. It looks like it was just a way to pass back a relatively large block of text that had some significance to the NAS, but was opaque to the RADIUS server. There are FreeRADIUS ways of defining profiles. You *can* do NAS-specific rules. See recent messages on this list. Thanks for the pointer, I guess my timing was good. :-) -John -- John Center Villanova University - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Normalising the User-Name AVP in an Access-Accept
Dear All, I am curious if it is possible today with FreeRADIUS to normalise the identity that is returned in the User-Name AVP in an Access-Accept? Hypothetically, lets say that a client uses the PEAP EAP type and logs in successfully using an inner-identity of its choosing in a valid format. For example, it could be of any of the following forms: foo@example f...@example.com example\foo example.com\foo foo (where the default domain is configured) What I want to achieve is that the value returned in the User-Name AVP in the Access-Accept always be sent in lower case and in a fully qualified, normalised format in the form f...@example.com back to the NAS. RFC 2865 states in Section 5.1: [The User-Name AVP] MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session. RFC 3579 states in Section 3: The User-Name attribute within the Access-Accept packet need not be the same as the User-Name attribute in the Access-Request. So, a compliant NAS that is able to treat the User-Name AVP as being authoritative would get to see the real, inner identity and in a normalised form. Is this possible? Thanks, Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: captive portal auth with freeradius
Chitrang Srivastava wrote: debug log are attched in earlier reply, Please see No, they're not. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
Nick Lowe wrote: I am curious if it is possible today with FreeRADIUS to normalise the identity that is returned in the User-Name AVP in an Access-Accept? Yes. You can do pretty much anything you want. RFC 2865 states in Section 5.1: [The User-Name AVP] MAY be sent in an Access-Accept packet, in which case the client SHOULD use the name returned in the Access-Accept packet in all Accounting-Request packets for this session. Well... not all NASes do that, of course. So, a compliant NAS that is able to treat the User-Name AVP as being authoritative would get to see the real, inner identity and in a normalised form. Is this possible? Yes. I suggest writing down all possible *input* variants of the User-Name. Then, determine what you want as output. And figure out how to get from one to the other. i.e. foo - f...@example.com, foo\EXAMPLE -- f...@example.com. Once you have all of those mappings, just write unlang policies to check one after the other, and do the re-writing. Most of the time, you can write policies down in plain English, and convert them to unlang. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Profile-Name attribute
Hi Matthew,
On 04/17/2013 05:53 PM, Matthew Newton wrote:
On Wed, Apr 17, 2013 at 05:04:11PM -0400, John Center wrote:
it correctly, it looks like one could have a profiles file with
individual named profiles defined containing NAS-specific text that
would be sent back to the NAS as is upon successful authentication.
Is anything like this still supported? Can the User-Profile
There are many ways of sending attributes back based on incoming
attributes (such as which NAS the request came from). One way
would be to just use an instantiation of the files module that
keys off the NAS-IP-Address:
files nasprofile {
key = %{NAS-IP-Address}
usersfile = ${confdir}/nas-profile
...
}
in the nas-profile file:
10.0.0.1
Reply-Message := Welcome to NAS 1
10.0.0.2
Reply-Message := Welcome to NAS 2
then call nasprofile in your sites-enabled/default authorize
section.
...or use one of the other multitude of methods just discussed in
the Idle-Timeout thread :-)
Matthew
It was just serendipity that I asked this question at the right time!
I'll check this out the Idle-timeout thread. Seems like a good topic
for the Wiki...
Thanks.
-John
--
John Center
Villanova University
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
Thanks, Alan! I have got a feature request with Aerohive, our wireless vendor, to support treating the User-Name AVP as being authoritative which they are being pretty receptive and responsive to. (I think RADIUS clients need to stop treating the outer identity as being authoritative if and where a User-Name is returned in the Access-Accept now that TLS based EAPs are the norm and we should have far more of an aggressive push to get vendors to implement this.) It would be great if, rather than manually having to create mappings and rewrite the identity, having successfully performed authentication FreeRADIUS were able to inherently spit out the identity in a normalised form knowing the username and the realm. (Perhaps I am not thinking things through here properly though for the general case though...) Regards, Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
On 18/04/13 16:06, Nick Lowe wrote: Thanks, Alan! I have got a feature request with Aerohive, our wireless vendor, to support treating the User-Name AVP as being authoritative which they are being pretty receptive and responsive to. (I think RADIUS clients need to stop treating the outer identity as being authoritative if and where a User-Name is returned in the Access-Accept now that TLS based EAPs are the norm and we should have far more of an aggressive push to get vendors to implement this.) IME it's fairly widely supported (but not exclusively, of course) It would be great if, rather than manually having to create mappings and rewrite the identity, having successfully performed authentication FreeRADIUS were able to inherently spit out the identity in a normalised form knowing the username and the realm. (Perhaps I am not thinking things through here properly though for the general case though...) I think the problem is that there's no generally right answer. For example: if you are part of a roaming federation and your users use anonymous outer ID, you want to preserve that anonymity (or possibly fall foul of data protection legislation, depending on whether a username is personal data). - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
Nick Lowe wrote: It would be great if, rather than manually having to create mappings and rewrite the identity, having successfully performed authentication FreeRADIUS were able to inherently spit out the identity in a normalised form knowing the username and the realm. (Perhaps I am not thinking things through here properly though for the general case though...) What *is* the general case? We could supply examples, but we can't *enable* them. Everyone's case is different. Different inputs, different domains, and possibly different outputs. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
I would have thought that it is perfectly reasonable to return the identity back in the case you have roaming federations as long as it was an agreed requirement beforehand. I am of the opinion that this -should- be mandated as part of Eduroam, for example. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Normalising the User-Name AVP in an Access-Accept
Nick Lowe wrote: So, a compliant NAS that is able to treat the User-Name AVP as being authoritative would get to see the real, inner identity and in a normalised form. As an aside to the mechanics of this, if you do this, test your NAS under simulated user load. We found that our Cisco WLC equipment didn't like that and leaked internal resources, which eventually ran out. We were adding some additional information to the username, so we had many more differences between the outer and inner IDs, and even so it took a few days for the problem to come to a head. This should be fixed in latest software, but we haven't re-tested that yet. It also wouldn't hurt to sniff the resulting EAPOL and any associated packets to ensure the NAS hasn't figured out some vendor-specific way to leak that inner identity to the wire/wifi, and of course review your security expectations between the AS and NAS. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
I would default the behaviour to not send the User-Name attribute in the Access-Accept but give the ability to have it trivially enabled with a toggle. And where it is enabled, by default, send it in the normalised user@realm format unless configured otherwise. (That would be the general case as far as I can see.) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Normalising the User-Name AVP in an Access-Accept
Nick Lowe wrote: I would have thought that it is perfectly reasonable to return the identity back in the case you have roaming federations as long as it was an agreed requirement beforehand. I am of the opinion that this -should- be mandated as part of Eduroam, for example. I'd have to disagree. We don't want to know anything about eduroam guest users other than an ID which to hand authorities which they can use to investigate with the home institution. The less we know, the less work we have to do when we get a subpoena. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
What 'I'm doing at the moment. For our outward facing radius servers, with any inbound auth requests from york users elsewhere, I normalise the username in the Access-Accept packet to have the york.ac.uk realm appended if its not there A On 18 Apr 2013, at 16:43, Nick Lowe nick.l...@gmail.com wrote: I would default the behaviour to not send the User-Name attribute in the Access-Accept but give the ability to have it trivially enabled with a toggle. And where it is enabled, by default, send it in the normalised user@realm format unless configured otherwise. (That would be the general case as far as I can see.) - 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: Normalising the User-Name AVP in an Access-Accept
On 18/04/13 16:29, Nick Lowe wrote: I would have thought that it is perfectly reasonable to return the identity back in the case you have roaming federations as long as it was an agreed requirement beforehand. Maybe, maybe not. If the home site were in a jurisdiction with data protection legislation (most of Europe) and User-Name were personal data (particularly email-formatted usernames) then I think this would be problematic at best - particularly if the visited site were in a jurisdiction *without* DP legislation (e.g. EU person roaming to the USA). I am of the opinion that this -should- be mandated as part of Eduroam, for example. Shrug. I disagree. I honestly don't see what the problem is with writing it yourself - it's not rocket science - but OTOH a set of examples in the default config would be a good thing too. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
As an aside to the mechanics of this, if you do this, test your NAS under simulated user load. We found that our Cisco WLC equipment didn't like that and leaked internal resources, which eventually ran out. We were adding some additional information to the username, so we had many more differences between the outer and inner IDs, and even so it took a few days for the problem to come to a head. Interesting! Thanks for the heads up. This should be fixed in latest software, but we haven't re-tested that yet. It also wouldn't hurt to sniff the resulting EAPOL and any associated packets to ensure the NAS hasn't figured out some vendor-specific way to leak that inner identity to the wire/wifi, and of course review your security expectations between the AS and NAS. Agreed, the main concern for me would be leakage via wireless. I see the main purpose of identity privacy with PKI EAPs being to protect the identity from being trivially snooped by an outsider. With federations, I think it would be perfectly reasonable to expect and require the real identity be returned back to the host institution. (I expect others will, perhaps, disagree here though!? :P) Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
That's a very fair point. A problem with anonymous identities though also comes where you have features at the edge that 'do things' based on the identity. Often you will just want an anonymised unique identity for each discrete user, but not necessarily their real identity. Food for thought... Would there be a way to achieve this with federations that maintains anonymity? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
So which id are you talking about? if its the outer and the user has configured the machine correctly, all you're going to see is @realm - not much use other than it's that institution if its the inner then o.k. you've got a realm from the outer user-name and a userid from the inner but any accounting will be dumped locally. if its the inner and you've got a realm then you've got your userid to hand over and all the accounting should go back to the home institution … or have I got that wrong? Rgds A On 18 Apr 2013, at 16:47, Brian Julin bju...@clarku.edu wrote: Nick Lowe wrote: I would have thought that it is perfectly reasonable to return the identity back in the case you have roaming federations as long as it was an agreed requirement beforehand. I am of the opinion that this -should- be mandated as part of Eduroam, for example. I'd have to disagree. We don't want to know anything about eduroam guest users other than an ID which to hand authorities which they can use to investigate with the home institution. The less we know, the less work we have to do when we get a subpoena. - 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: captive portal auth with freeradius
Attaching
Auth Type is MSCHAPv2 (TTLS)
Data source is on LDAP
radtest is working
wifi authentication is also working ( configured the access point to use
TTLS-MSCHAPv2)
open wifi with captive portal (lightttpd) is *not * working
What I found is captive portal server is sending a non-EAP message and as
suggested in wiki I am not using setting auth type anywhere (EAP message
will determine automatically)
On Thu, Apr 18, 2013 at 8:03 PM, Alan DeKok al...@deployingradius.comwrote:
Chitrang Srivastava wrote:
debug log are attched in earlier reply, Please see
No, they're not.
Alan DeKok.
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
FreeRADIUS Version 2.1.12, for host mips64-octeon-linux-gnu, built on Apr 15
2013 at 15:20:23
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/proxy.conf
including configuration file /etc/raddb/clients.conf
including configuration file /etc/raddb/eap.conf
main {
allow_core_dumps = yes
}
Core dumps are enabled.
including dictionary file /etc/raddb/dictionary
main {
name = radiusd
prefix = /usr
localstatedir = /var
sbindir = /usr/sbin
logdir = syslog
run_dir = /var/run
libdir = /usr/lib/radius
radacctdir = /var/radius/radacct
hostname_lookups = no
max_request_time = 120
cleanup_delay = 5
max_requests = 1024
pidfile = /var/run/radiusd.pid
checkrad = /usr/sbin/checkrad
debug_level = 0
proxy_requests = yes
log {
stripped_names = yes
auth = yes
auth_badpass = no
auth_goodpass = no
}
security {
max_attributes = 200
reject_delay = 0
status_server = no
}
}
radiusd: Loading Realms and Home Servers
proxy server {
retry_delay = 5
retry_count = 3
default_fallback = yes
dead_time = 120
wake_all_if_all_dead = no
}
radiusd: Loading Clients
client 127.0.0.1 {
require_message_authenticator = no
secret =
bQEFAwRBkhBnOJefZN0UarGAiYiK0nwzw2y3n7sm89l2nXHzTM+3i60rVoTpMbjh
shortname = localhost
}
client 192.168.10.101/24 {
require_message_authenticator = no
secret = testing123
shortname = private-network-1
}
radiusd: Instantiating modules
instantiate {
Module: Linked to module rlm_ldap
Module: Instantiating module ldap_secondary from file /etc/raddb/radiusd.conf
ldap ldap_secondary {
server = 192.168.4.11
port = 389
password = Symb0l@123
identity = cn=symbol,cn=users,DC=MotorolaSymbol,dc=local
net_timeout = 3
timeout = 6
timelimit = 6
tls_mode = no
start_tls = no
tls_require_cert = allow
basedn = cn=Users,DC=MotorolaSymbol,dc=local
filter = (sAMAccountName=%{Stripped-User-Name})
base_filter = (objectclass=radiusprofile)
password_attribute = userPassword
auto_header = no
access_attr = dialupacces
access_attr_used_for_allow = no
chase_referrals = yes
rebind = yes
groupname_attribute = cn
groupmembership_filter =
((objectClass=Group)(member=%{control:Ldap-UserDn}))
groupmembership_attribute = radiusGroupName
dictionary_mapping = /var/etc/raddb/ldap.attrmap
ldap_debug = 0
ldap_connections_number = 5
compare_check_items = no
do_xlat = yes
set_auth_type = yes
group_verification = yes
dead_period = 120
}
rlm_ldap: Registering ldap_groupcmp for Ldap-Group
rlm_ldap: Creating new attribute ldap_secondary-Ldap-Group
rlm_ldap: Registering ldap_groupcmp for ldap_secondary-Ldap-Group
rlm_ldap: Registering ldap_xlat with xlat_name ldap_secondary
rlm_ldap: Over-riding set_auth_type, as there is no module ldap_secondary
listed in the authenticate section.
rlm_ldap: reading ldap-radius mappings from file /var/etc/raddb/ldap.attrmap
rlm_ldap: LDAP radiusCheckItem mapped to RADIUS $GENERIC$
rlm_ldap: LDAP radiusReplyItem mapped to RADIUS $GENERIC$
rlm_ldap: LDAP radiusAuthType mapped to RADIUS Auth-Type
rlm_ldap: LDAP radiusSimultaneousUse mapped to RADIUS Simultaneous-Use
rlm_ldap: LDAP radiusCalledStationId mapped to RADIUS Called-Station-Id
rlm_ldap: LDAP radiusCallingStationId mapped to RADIUS Calling-Station-Id
rlm_ldap: LDAP lmPassword mapped to RADIUS LM-Password
rlm_ldap: LDAP ntPassword mapped to RADIUS NT-Password
rlm_ldap: LDAP sambaLmPassword mapped to RADIUS LM-Password
rlm_ldap: LDAP sambaNtPassword mapped to RADIUS NT-Password
rlm_ldap: LDAP dBCSPwd
Re: Normalising the User-Name AVP in an Access-Accept
I honestly don't see what the problem is with writing it yourself - it's not rocket science - but OTOH a set of examples in the default config would be a good thing too. No problem at all, rather, I would have simply thought that it lowers the barrier to entry, requiring less concious thought on behalf of the person configuring the RADIUS server if it is an option that can just be toggled on and hey presto, it works. It also makes it more discoverable as desirable behaviour. In my limited scope testing, many NASes will ignore the User-Name attribute and making more of a first class, default behaviour in the most popular RADIUS server might start to change that... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
Agreed, the main concern for me would be leakage via wireless. I see the main purpose of identity privacy with PKI EAPs being to protect the identity from being trivially snooped by an outsider. With federations, I think it would be perfectly reasonable to expect and require the real identity be returned back to the host institution. (I expect others will, perhaps, disagree here though!? :P) Eduroam visited ORPS and home server ORPS should support CUI. Where the NAS at the visited site lacks support for CUI, and the NAS supports setting values for attributes associated with a session, a globally and temporarily unique identifier should be set (via Access-Accept/COA/SNMP) and then associated with the CUI provided by the home server. Some NAS include the Acct-Session-ID in Access-Requests, in which case the Acct-Session-ID can be associated with the CUI instead. For support calls the ID on the NAS can be mapped to the CUI, which can in turn be provided to the home institution. -Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
On 18/04/13 16:59, Nick Lowe wrote: That's a very fair point. A problem with anonymous identities though also comes where you have features at the edge that 'do things' based on the identity. Often you will just want an anonymised unique identity for each discrete user, but not necessarily their real identity. Food for thought... Would there be a way to achieve this with federations that maintains anonymity? Yes. This is what Charged-User-Identity is for. The server comes with examples for CUI. Sadly it's not widely supported :o( - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
So which id are you talking about? if its the outer and the user has configured the machine correctly, all you're going to see is @realm - not much use other than it's that institution if its the inner then o.k. you've got a realm from the outer user-name and a userid from the inner but any accounting will be dumped locally. if its the inner and you've got a realm then you've got your userid to hand over and all the accounting should go back to the home institution … or have I got that wrong? Rgds A I am primarily interested in returning the inner identity normalised as username@realm in the User-Name AVP in Access-Accepts for authentication performed internally so that the Aerohive APs we have are able to work with the real identity rather than the anonymous outer. This is important for us to get the new L7 application visibility features in HiveOS 6.0 working properly and have some value. Additionally, for internal authentication, users can get away with simply using username, realm\username or username@realm in the inner and, at present, the Aerohive APs treat the same user as being discrete users where the identity is supplied in a different format. I want to sort this somehow... (I am, however, loathed to mandate that the identity be supplied as username@realm to begin with as it will break existing configuration. This for authentication not on an eduroam SSID.) For eduroam in general, it would be far less of an issue as users are always forced to use the fully qualified username@realm (often anonymous@realm) but I would be interested in a method to get an anonymised unique id for the user from the home institution. (Is that personal data at that point? In the case of abuse, you would still have to go back to the home institution and know nothing about the user as you do not have their real identity.) Thinking about things, I think an appropriate compromise for Eduroam, therefore, would be to mandate the return an anonymised unique id with realm for each user in the User-Name AVP in the Access-Accept. Thoughts? Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
Eduroam visited ORPS and home server ORPS should support CUI. Where the NAS at the visited site lacks support for CUI, and the NAS supports setting values for attributes associated with a session, a globally and temporarily unique identifier should be set (via Access-Accept/COA/SNMP) and then associated with the CUI provided by the home server. Some NAS include the Acct-Session-ID in Access-Requests, in which case the Acct-Session-ID can be associated with the CUI instead. For support calls the ID on the NAS can be mapped to the CUI, which can in turn be provided to the home institution. https://community.ja.net/blogs/scotts-eduroam-blog/article/eduroam-and-cui Aha, thanks! (Feels stupid...) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Normalising the User-Name AVP in an Access-Accept
Hi, in latest 2.x and 3.x code check out the canonicalisation policy - this sorts out the MAC format. you could do the same for the User-Name. note that there are data protection issues in play - for example, if a user has chosen (and is allowed) to use anonymous outerid, then why are you suddenly releasing their ID to the remote site after the 'soft innards' of the innerID are known to you? might the user have an issue with that? also note that the main issue that has been at play here is accounting packets - the innerID is not realmed so accounting becomes local. well, thats okay too as accounting traffic in eduroam is going bye bye in the not too distant future so you wont be proxying accounting through the national proxies anyway...so either take it locally or drop it. alan - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Comware 3 Switches (3Com 4500, 5500, 5500G - H3C S3600, S5600) - EAPOL v2 and v3 being dropped.
Dear All, If anybody still uses any Comware v3 switches anywhere with 802.1X, they had a bug until recently where they would drop and not respond to all EAPOL v2 and v3 in flagrant violation to the 802.1X-2001 specification. These are switches such as: 3Com 4500, 5500 or 5500G series H3C S3600, S5600. Upgrade to 03.03.02p19 (3Com) / R1702P39 (H3C) or later to resolve this. (As of writing, 03.03.02p21 / R1702P42 are the latest.) If you are using any 4210Gs or 4200G still, then you are SOL as there has been no update for them to correct the issue. I had a battle mid last year getting HP to get this fixed. (We are seeing supplicants now using v2 by default so it was causing pain, and in the case of Cisco's AnyConnect, v3.) Regards, Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Comware 3 Switches (3Com 4500, 5500, 5500G - H3C S3600, S5600) - EAPOL v2 and v3 being dropped.
In response to a private email I had asking for clarification, sorry, I meant the 10/100 4210s which run Comware v3, not 4210Gs which run Comware v5... The actual error you will see on such switched with terminal debugging enabled along with debugging dot1x all you'll see on afflicted devices is: 8021X/8/PACKET:- 1 -Port:2,Received a EAPOL packet. 8021X/8/Error::- 1 -Port:2,Failed to cut ethernet head. Thanks, Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Comware 3 Switches (3Com 4500, 5500, 5500G - H3C S3600, S5600) - EAPOL v2 and v3 being dropped.
Great, hit send by accident with a sentence half constructed. Hopefully you'll get the gist! - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Sending a disconnect message when replying with an access reject.
On Thu, Apr 18, 2013 at 11:35 PM, Matthew Newton m...@leicester.ac.uk wrote:
On Thu, Apr 18, 2013 at 05:52:16PM +1200, Peter Lambrechtsen wrote:
When I setup the post-auth policy to send a update disconnect it works fine
if the response is an access accept. But if I update the control to access
reject the disconnect module gives me a noop.
As a guess:
The Post-Auth-Type REJECT section in the inner-tunnel is never
called. This is fixed in v2.x.x HEAD and master.
Post-Auth-Type REJECT in the outer tunnel is fine.
This might be your problem.
Under the authorize section I have:
if (ADSL-Agent-Remote-Id !~ /COMP/ ) {
update disconnect {
Acct-Session-Id = 7444
}
#update control {
#Auth-Type := Reject
# }
}
This was just for testing to see if I could send a Disconnect from
within the Authorize section.
In the trace I see:
+++? if (ADSL-Agent-Remote-Id !~ xxx ) - TRUE
+++- entering if (ADSL-Agent-Remote-Id !~ xxx ) {...}
[disconnect] returns ok
Then at the end of the log I see:
Sending Access-Accept of id 161 to 172.25.1.1 port 62037
ERX-Virtual-Router-Name = default:voiplm1
WARNING: Empty pre-proxy section. Using default return values.
Sending Disconnect-Request of id 206 to 172.25.1.1 port 3799
Acct-Session-Id = 7444
Finished request 3.
Going to the next request
Waking up in 1.2 seconds.
rad_recv: Disconnect-NAK packet from host 172.25.1.1 port 3799,
id=206, length=20
# Executing section post-proxy from file /etc/raddb/sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
Finished request 3.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 3 ID 161 with timestamp +163
So in this case I see I get a NAK back (since I sent the wrong session ID).
Whereas if I have the Auth-Type := Reject then that rejects the
current packet, but I expected the Disconnect to still go through, but
this is what I see:
+++? if (ADSL-Agent-Remote-Id !~ xxx ) - TRUE
+++- entering if (ADSL-Agent-Remote-Id !~ xxx ) {...}
[control] returns ok
[disconnect] returns ok
- entering policy do_not_respond {...}
+[control] returns ok
+[handled] returns handled
- policy do_not_respond returns handled
+++- if (ADSL-Agent-Remote-Id !~ xxx ) returns handled
Whereas all I send back is:
Sending Access-Reject of id 165 to 172.25.1.1 port 62037
ERX-Virtual-Router-Name = default:voiplm1
Waking up in 4.9 seconds.
The Disconnect never get sent.
I even tried adding it into post-auth as well under the Post-Auth-Type REJECT:
Post-Auth-Type REJECT {
update disconnect {
Acct-Session-Id = 7444
}
}
And the module returns a noop:
Auth-Type = Reject, rejecting user
Failed to authenticate the user.
Using Post-Auth-Type Reject
# Executing group from file /etc/raddb/sites-enabled/default
+- entering group REJECT {...}
++[disconnect] returns noop
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 186 to 172.25.1.1 port 62037
ERX-Virtual-Router-Name = default:voiplm1
Waking up in 4.9 seconds.
Any ideas?
Cheers
Peter
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Comware 3 Switches (3Com 4500, 5500, 5500G - H3C S3600, S5600) - EAPOL v2 and v3 being dropped.
Thanks for the heads up on this. We use some of these with dot1x. For reference to others, if you still have any 5500-SIs, that were discontinued years back, they do today run 5500-EI code with all features. Many folks still run these with old software because they do not know that this is the case. Original 3Com announcement: http://web.archive.org/web/20101009093205/http://3com.com/products/en_US/end_of_life.jsp?sku=3CR17151-91 Paul - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: captive portal auth with freeradius
On Thu, Apr 18, 2013 at 09:37:06PM +0530, Chitrang Srivastava wrote:
radtest is working
wifi authentication is also working ( configured the access point to use
TTLS-MSCHAPv2)
ok.
open wifi with captive portal (lightttpd) is *not * working
right.
What I found is captive portal server is sending a non-EAP message and as
suggested in wiki I am not using setting auth type anywhere (EAP message
will determine automatically)
Captive portal is doing PAP. I guess you want to try and auth this
by binding to the ldap server. I've not done this recently, but I
think the following might work.
For some reason, even though
Module: Instantiating module ldap_secondary from file
/etc/raddb/radiusd.conf
ldap ldap_secondary {
...
set_auth_type = yes
...
}
is set, it's not setting auth_type. That's clear from
ERROR: No authenticate method (Auth-Type) found for the request: Rejecting
the user
Try this at the bottom of the authorize {} section:
authorize {
...
# not EAP, is PAP, and no other Auth-Type set, so assume ldap
if (!EAP-Message User-Password) {
update control {
Auth-Type = ldap_secondary
}
}
}
and then in the authenticate section:
authenticate {
Auth-Type ldap_secondary {
ldap_secondary
}
}
and see what you get. Again, post output of radiusd -X if there
are still problems (new output, not the same as last time :) ).
I don't know enough about the ldap module to know why it's not
setting Auth-Type (and too ill at present to go digging to find
out).
Cheers,
Matthew
--
Matthew Newton, Ph.D. m...@le.ac.uk
Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom
For IT help contact helpdesk extn. 2253, ith...@le.ac.uk
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
