Re: EAP logging
On 28 Aug 2013, at 23:39, Andrej andrej.gro...@gmail.com wrote:
I would like f_ticks to write out a single line into syslog that
contains the inner and outer
identity of an authentication request, the station ID and MAC address.
In case of a successful authentication or rejection I'd like to have
the inner identity and a status on a line,
We do this by using lots of custom linelog instances. In linelog.conf (just a
few examples):
linelog acceptlog {
filename = /var/log/radius/auth-%D.log
format = %S (%l) id %I ACCEPT %{User-Name} (station %{%{Calling-Station
-Id}:--}) auth-type %{control:Auth-Type}/%{EAP-Type} realm %{%{Realm}:--} nas %{
%{NAS-IP-Address}:-%{%{NAS-IPv6-Address}:--}-}/%{%{NAS-Port}:--} (operator %{%{O
perator-Name}:--}) client %{%{Packet-Src-IP-Address}:-%{%{Packet-Src-IPv6-Addres
s}:--}} (%{Client-Shortname}) ap '%{%{UCam-AP-Name}:--}' essid '%{%{UCam-Essid-N
ame}:--}' = %{%{reply:User-Name}:--} reply-msg '%{reply:Reply-Message}'
}
linelog inner-acceptlog {
filename = /var/log/radius/auth-%D.log
format = %S (%l) id %I INNER-TUNNEL ACCEPT %{User-Name} (station %{%{ou
ter.request:Calling-Station-Id}:--}) outer-id %{outer.request:User-Name} auth-ty
pe %{outer.control:Auth-Type}/%{outer.request:EAP-Type}/%{control:Auth-Type} rea
lm %{%{Realm}:--} nas %{%{outer.request:NAS-IP-Address}:-%{%{outer.request:NAS-I
Pv6-Address}:--}}/%{%{outer.request:NAS-Port}:--} (operator %{%{outer.request:Op
erator-Name}:--}) client %{%{Packet-Src-IP-Address}:-%{%{Packet-Src-IPv6-Address
}:--}} (%{Client-Shortname}) ap '%{%{outer.request:UCam-AP-Name}:--}' essid '%{%
{outer.request:UCam-Essid-Name}:--}' = %{%{reply:User-Name}:--} reply-msg '%{re
ply:Reply-Message}'
}
linelog proxy-replylog {
filename = /var/log/radius/auth-%D.log
format = %S (%l) id %I PROXY REPLY %{User-Name} (station %{%{Calling-St
ation-Id}:--}) auth-type /%{EAP-Type} realm %{%{Realm}:--} nas %{%{NAS-IP-Addres
s}:-%{%{NAS-IPv6-Address}:--}-}/%{%{NAS-Port}:--} (operator %{%{Operator-Name}:-
-}) client %{%{Packet-Src-IP-Address}:-%{%{Packet-Src-IPv6-Address}:--}} (%{Clie
nt-Shortname}) proxy %{%{proxy-reply:Packet-Src-IP-Address}:-%{%{proxy-reply:Pac
ket-Src-IPv6-Address}:--}} proxy-reply-type %{proxy-reply:Packet-Type} proxy-rep
ly-msg '%{proxy-reply:Reply-Message}' = %{%{proxy-reply:User-Name}:--}
}
We call them as follows:
[default]
post-proxy {
...
proxy-replylog
...
}
post-auth {
...
acceptlog
...
}
[inner-tunnel]
post-auth {
...
inner-acceptlog
...
}
There are some references to %{UCam-AP-Name} and things in there -- we set
these with things like:
if (%{Aruba-Location-Id}) {
update request {
UCam-AP-Name := %{Aruba-Location-Id}
UCam-Essid-Name := %{Aruba-Essid-Name}
}
}
... they let us not refer to the direct Aruba attributes and would allow us to
more easily add another wireless system (we used to have Cisco but migrated
away) - if we had to move again, we don't have lots of Cisco-specific bits all
over the place. Note that the attributes are defined in 'dictionary'.
The above stuff will give lines like:
2013-08-29 10:53:02 (1377769982) id 175 INNER-TUNNEL ACCEPT rc...@cam.ac.uk
(station 0015AF81CEB3) outer-id @cam.ac.uk auth-type EAP/PEAP/EAP realm LOCAL
nas 131.111.1.20/0 (operator 1lapwing.cam.ac.uk) client 131.111.1.20
(erri...@lapwing.cam.ac.uk) ap '00:24:6c:c3:24:fd' essid 'eduroam' = rcf34
reply-msg '[cam.ac.uk] Successful authentication ACCEPT'
[example from inner-acceptlog.]
Hope this helps,
- Bob
--
Bob Franklin rc...@cam.ac.uk +44 1223 748479
Network Division, University of Cambridge Computing Service
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Checking TLS-Cert-* and and accept/reject based on them
Dear all, 1-2 years ago this topic was discussed and there was a patch by Matthew Newton that was approved for the master branch. I'm now facing the difficulty of accepting/rejecting requests based on the contents of the TLS-Client-Cert for 2.1.12 which does not contain this patch. This is done in an exec module script in the authorize section which needs to decide on the request information and the certificate data whether to allow or disallow access. Other than applying this patch to 2.1.12 or switching to master, is there any other way to use the binaries of 2.1.12 and still be able to use the client cerficate date in the exec script? The reason I'm not simply applying the patch is that this system is covered by support by Red Hat and replacing the vendor shipped freeradius (2.1.12) with a self-compiled one voids the support. So any other solution that would allow me to keep the system under support and still be able to check the certs Subject/CN would be great! Some more details for anyone interested: The RADIUS client is an AP and the devices are Wifi clients like Android, iPads, laptops etc with Client certificates. Some devices should be allowed to access some SSIDs and others are not. freeradius gets the certificate and needs to extract the embedded username (which is just the device's serial number and displayed in the logs as BUF-name) for checking whether this device is allowed to connect to this SSID. The decision is made in an exec module in the authorize section, but I cannot pass any certificate information to it for checking. Thanks, Axel. -- Axel.Thimm at ATrpms.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On 29/08/13 13:21, Axel Thimm wrote:
The reason I'm not simply applying the patch is that this system is
covered by support by Red Hat and replacing the vendor shipped
freeradius (2.1.12) with a self-compiled one voids the support. So any
other solution that would allow me to keep the system under support
and still be able to check the certs Subject/CN would be great!
Ask RedHat? Since it's supported...
Otherwise, you could look at the verify { } stanza of the tls { }
block in eap.conf; this allows you to run an external script once you've
got the client cert, and there you can write any code you want to access
the various issuer/subject fields.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP logging
Andrej wrote: This brings me back to my earlier question: what values are available where, and when, via which mechanism? This was asked and answered. I suggest reading responses to your messages. Asking what values are available is wrong. There are no magic values in the server. There are just attributes in a packet. If you want to know what attributes are available, look at the debug output. That REALLY is it. It's not hard. It's not rocket science. There's no magic. I think I still don't fully understand how modules hang together, how I pass information from e.g. an EAP request into line-log, Read doc/aaa.rst You don't passd information into a module. The incoming packet (and associated data) is given to the module. The module then decides what to do. sites-enabled/eap-inner-tunnel, how I tell f_ticks (or linelog, or any other modules for that matter) which values I'd like to work with. Have you tried reading the debug output? It's *telling you* what it's doing. The f_ticks module is telling you what it's doing. Have you tried reading the default configuration for the linelog module? It has LOTS of documentation describing how it works. Ask *specific* questions about what's confusing you. I would like f_ticks to write out a single line into syslog that contains the inner and outer identity of an authentication request, the station ID and MAC address. So... do you see that data in the debug output? If so, read man unlang for how to reference attributes. See the default linelog configuration for how the module works. Put the two together, and you'll have it. Can anyone point me at a walk-through or how-to? I've now spent days flicking from one wiki-page to the next, and reading mailing list archives w/o find anything that helps me understand. There are NO examples which document exactly what you're trying to do. Most deployments are unique. Creating documentation for every possible deployment is impossible. It sounds like you're not understanding basic concepts, and reading random web pages, looking for a magic solution. This isn't the best approach. Read doc/aaa.rst. Read man unlang. Read the debug output. Read the default linelogconfiguration. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote:
Otherwise, you could look at the verify { } stanza of the tls {
} block in eap.conf; this allows you to run an external script once
you've got the client cert, and there you can write any code you
want to access the various issuer/subject fields.
Thanks, I'm already using it for other purposes. But do I have the
request data at hand to check for the requested SSID?
Or is there a way to set variables in this script to check later in
the authorize section's modules (with an exec script)?
--
Axel.Thimm at ATrpms.net
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-Peap-MSchapv2 proxy from innertunnel
I'm trying to do a proxy from the inner-tunnel over to another radius server. The primary reason for this is that we need to strip off the realm before passing to the proxy. I'm getting an EAP error response from the other server about it not liking the id number Supplicant sent unmatched EAP response packet identifier ( This is an EAP-PEAP-MSCHAPv2 scenerio) The EAP.conf file is configured with: proxy_tunneled_request_as_eap = yes I've included a TCP dump of the main freeradius server below WC -- Wireless controller FR-2.10 -- Freeradius server ISE-proxy -- The server FR-2.10 is sending proxy requests to: It does appear that FR-2.10 is beginning a conversation with ISE-proxy and id: 0xde It seem that ISE-proxy responds ok, but then the next message from FR-2.10 to ISE-proxy has id: 0xa8, but I'm thinking that ISE-proxy is expecting 0xdf ?.. I'll admit I'm still pretty confused about much of the EAP, stuff.. but maybe I'm missing something simple in the config ? Any ideas would be greatly appreciated.. Thanks, Robert 07:03:51.286831 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x82 length: 227 07:03:51.287639 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x82 length: 64 07:03:51.289921 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x83 length: 354 07:03:51.300931 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x83 length: 1090 07:03:51.304143 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x84 length: 238 07:03:51.304640 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x84 length: 1086 07:03:51.307583 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x85 length: 238 07:03:51.314568 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x85 length: 1086 07:03:51.317658 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x86 length: 238 07:03:51.324409 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x86 length: 923 07:03:51.335322 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x87 length: 440 07:03:51.337658 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x87 length: 123 07:03:51.339867 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x88 length: 238 07:03:51.344424 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x88 length: 101 07:03:51.346564 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x89 length: 328 --- Begin proxy ? 07:03:51.354527 IP FR-2.10.1814 ISE-proxy.radius: RADIUS, Access Request (1), id: 0xde length: 246 07:03:51.371848 IP ISE-proxy.radius FR-2.10.1814: RADIUS, Access Challenge (11), id: 0xde length: 132 07:03:51.372108 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x89 length: 101 07:03:51.374137 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x8a length: 312 07:03:51.384449 IP FR-2.10.1814 ISE-proxy.radius: RADIUS, Access Request (1), id: 0xa8 length: 306 07:03:51.386386 IP ISE-proxy.radius FR-2.10.1814: RADIUS, Access Reject (3), id: 0xa8 length: 49 07:03:52.387589 IP FR-2.10.radius WC.32769: RADIUS, Access Reject (3), id: 0x8a length: 101 --End proxy - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On 29/08/13 14:25, Axel Thimm wrote:
On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote:
Otherwise, you could look at the verify { } stanza of the tls {
} block in eap.conf; this allows you to run an external script once
you've got the client cert, and there you can write any code you
want to access the various issuer/subject fields.
Thanks, I'm already using it for other purposes. But do I have the
request data at hand to check for the requested SSID?
It's run using the standard exec helper, so it has access to all the
stuff that a normal exec module has; specifically there should be
environment variables matching each request attribute, mangled into
upper-case + underscores.
e.g.
Calling-Station-Id
...should appear as:
CALLING_STATION_ID
Suggest you try it and see.
Or is there a way to set variables in this script to check later in
the authorize section's modules (with an exec script)?
No. The output of the verify script is thrown away, so in that respect
it's not like a normal exec. It's a binary yes/no.
Obviously you could work around this; you could set a request variable
to a unique value e.g. timestamp+random, have your verify{} script use
that as the basis of a filename to dump the info to, then read it with
*another* exec module lower down.
Or you could abandon the prejudice against upgrading because it's
supported (support you're not taking advantage of, I might add, since
you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
On 29/08/13 14:35, Robert Roll wrote: I'm trying to do a proxy from the inner-tunnel over to another radius server. The primary reason for this is that we need to strip off the realm before passing to the proxy. I'm getting an EAP error response from the other server about it not liking the id number Supplicant sent unmatched EAP response packet identifier ( This is an EAP-PEAP-MSCHAPv2 scenerio) The EAP.conf file is configured with: proxy_tunneled_request_as_eap = yes I've included a TCP dump of the main freeradius server below But not a debug gathered with radiusd -X which is the only thing anyone ever wants to see. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote: Or you could abandon the prejudice against upgrading because it's supported (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in. I don't think it's in 2.2.0 - it is in 2.x HEAD, though, so should be in 2.2.1. Agreed on the support contract thing. If something is apparently unsupported when it's broken, just run the supported version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you just did. If the support is worth anything, of course, then I'm sure they'll be delighted to build later packages for you that include the patch. :-) 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
Re: EAP-Peap-MSchapv2 proxy from innertunnel
On Thu, Aug 29, 2013 at 01:35:25PM +, Robert Roll wrote: I'm getting an EAP error response from the other server about it not liking the id number Supplicant sent unmatched EAP response packet identifier EAP Response identifier sent by the client has to match EAP Request identifier sent by the server which would be ISE. can you see the EAP-Message AVPs sent and received by freeradius? identifier is the second byte. mk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: Checking TLS-Cert-* and and accept/reject based on them
Agreed on the support contract thing. If something is apparently unsupported when it's broken, just run the supported version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you just did. If the support is worth anything, of course, then I'm sure they'll be delighted to build later packages for you that include the patch. :-) RedHat does follow this list, so perhaps it is worth contacting them to point out that this patch would really be appreciated, even if it ends up in an EPEL package (which should still be acceptable). That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do. Regards Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On 29/08/13 15:09, Matthew Newton wrote: On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote: Or you could abandon the prejudice against upgrading because it's supported (support you're not taking advantage of, I might add, since you're asking here) and upgrade to 2.2.0 which, IIRC, has those patches in. I don't think it's in 2.2.0 - it is in 2.x HEAD, though, so should be in 2.2.1. Ah, my mistake. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-Peap-MSchapv2 proxy from innertunnel
I guess I assumed the id: in the TCP dump below was the EAP Response Identifier maybe not ? Is there a different EAP response identifier ? I actually have been running with debug radius -X. Obviously a lot longer output than just the TCP dump. That is why I first tried just the TCP dump. I guess I was also hoping somebody might have just had a thought about a common configuration issue... I just went back to run another test and the proxy server now seems to be down. This server is run by our network group and I don't know when it might be back.. As soon as it comes back, I will run and capture the debug and see if I can see the EAP-message AVP's ? I will also post the debug Thanks, Robert 07:03:51.354527 IP FR-2.10.1814 ISE-proxy.radius: RADIUS, Access Request (1), id: 0xde length: 246 07:03:51.371848 IP ISE-proxy.radius FR-2.10.1814: RADIUS, Access Challenge (11), id: 0xde length: 132 07:03:51.384449 IP FR-2.10.1814 ISE-proxy.radius: RADIUS, Access Request (1), id: 0xa8 length: 306 07:03:51.386386 IP ISE-proxy.radius FR-2.10.1814: RADIUS, Access Reject (3), id: 0xa8 length: 49 From: freeradius-users-bounces+robert.roll=utah@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah@lists.freeradius.org] on behalf of Martin Kraus [lists...@wujiman.net] Sent: Thursday, August 29, 2013 8:11 AM To: FreeRadius users mailing list Subject: Re: EAP-Peap-MSchapv2 proxy from innertunnel On Thu, Aug 29, 2013 at 01:35:25PM +, Robert Roll wrote: I'm getting an EAP error response from the other server about it not liking the id number Supplicant sent unmatched EAP response packet identifier EAP Response identifier sent by the client has to match EAP Request identifier sent by the server which would be ISE. can you see the EAP-Message AVPs sent and received by freeradius? identifier is the second byte. mk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
eap-tls ignore client cert expiry check - crazy idea?
Hi All, Is there a way if I had 10 clients in my home lab and all the certs expire tomorrow, that rather than re-provide all the certs to my clients, I can frigg the radius server time, to still accpet them. Im guessing this is a no, but from what I see, the client cert is presented, and check against the server time. Would this be correct? Many thanks in advanced Ken Ken Farrington Director CCIE #12651 802 Limited International House, 221 Bow Road, London, E3 2SJ, United Kingdom Direct: +44 (0)7500 802802 ken.farring...@802.co.uk http://www.802.co.uk Disclaimer This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Any views or opinions presented are solely those of the author and do not necessarily represent those of 802 Limited or any subsidiary company of 802 Limited. This email may relate to or be sent from other members of the 802 Group. All rights reserved. 802 Limited. Registered in the UK. Company Number. 7962864.- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On Thu, Aug 29, 2013 at 02:48:59PM +0100, Phil Mayers wrote:
On 29/08/13 14:25, Axel Thimm wrote:
On Thu, Aug 29, 2013 at 02:12:35PM +0100, Phil Mayers wrote:
Otherwise, you could look at the verify { } stanza of the tls {
} block in eap.conf; this allows you to run an external script once
you've got the client cert, and there you can write any code you
want to access the various issuer/subject fields.
Thanks, I'm already using it for other purposes. But do I have the
request data at hand to check for the requested SSID?
It's run using the standard exec helper, so it has access to all the
stuff that a normal exec module has; specifically there should be
environment variables matching each request attribute, mangled into
upper-case + underscores.
e.g.
Calling-Station-Id
...should appear as:
CALLING_STATION_ID
Suggest you try it and see.
Thank you, that looks very promising!
Or is there a way to set variables in this script to check later in
the authorize section's modules (with an exec script)?
No. The output of the verify script is thrown away, so in that
respect it's not like a normal exec. It's a binary yes/no.
Obviously you could work around this; you could set a request
variable to a unique value e.g. timestamp+random, have your verify{}
script use that as the basis of a filename to dump the info to, then
read it with *another* exec module lower down.
That is very nasty! I love it! :)
I'll try to go with the verify for now.
Or you could abandon the prejudice against upgrading because it's
supported (support you're not taking advantage of, I might add,
since you're asking here) and upgrade to 2.2.0 which, IIRC, has
those patches in.
For systems I know I will be the long term support I can talk to the
customer and he will agree to have me patch up specific binaries, but
in this case I'm just setting this up.
--
Axel.Thimm at ATrpms.net
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
On Thu, Aug 29, 2013 at 02:56:44PM +, Robert Roll wrote: I guess I assumed the id: in the TCP dump below was the EAP Response Identifier maybe not ? Is there a different EAP response identifier ? That is the id of the radius packet. EAP lives insided radius packet AVPs called EAP-Message. You can see the AVPs when you run tcpdump -vv. What is worth noting is that radius Access-Request carries EAP-Response from the client to the server and Access-Challenge carries EAP-Request from the server to the client. mk - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On 29/08/13 15:49, stefan.pae...@diamond.ac.uk wrote: That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do. Failing to direct these queries towards your paid support option creates moral hazard, as it generates a positive externality for the paid vendor (they get to charge you for the easy stuff, but don't pay the cost for their unwillingness to forward-port features). You ABSOLUTELY should be opening tickets with your paid vendor every time something like this comes up. Not maybe. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
On 29/08/13 15:56, Robert Roll wrote: I guess I assumed the id: in the TCP dump below was the EAP Response Identifier maybe not ? Is there a different EAP response identifier ? Yes, in the EAP-Message attribute (EAP packet) I actually have been running with debug radius -X. Obviously a lot longer output than just the TCP dump. That is why I first tried just the TCP dump. I guess I was also hoping somebody might have just had a thought about a common configuration issue... TBH proxying EAP inner is not common at all; there have been bugs in that area in the past. Re-reading I notice that you're running 2.10 - upgrade. I'm pretty certain that version has inner-eap proxy bugs. Go to 2.2.0. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Checking TLS-Cert-* and and accept/reject based on them
On Thu, Aug 29, 2013 at 02:49:17PM +, stefan.pae...@diamond.ac.uk wrote: Agreed on the support contract thing. If something is apparently unsupported when it's broken, just run the supported version on a test system, reproduce the problem, and go from there. If you know the problem is to do with the newer features, forget the paid support and ask here like you just did. If the support is worth anything, of course, then I'm sure they'll be delighted to build later packages for you that include the patch. :-) I'm discussing this within Red Hat already. They are not that upgrade-shy (if it doesn't change the API/ABI), but it takes longer to get approvals from all people involved. RedHat does follow this list, so perhaps it is worth contacting them to point out that this patch would really be appreciated, even if it ends up in an EPEL package (which should still be acceptable). freeradius belongs to the core group of technologies in Red Hat, so it's unlikely to allow a replacing package in EPEL (unless it is called freeradius3 or freeradius221 or similar). That said, I commiserate with the original poster that yes, when the policy is that you're only allowed to use vendor packages, you're limited in what you can and cannot do. Thanks! -- Axel.Thimm at ATrpms.net - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-Peap-MSchapv2 proxy from innertunnel
Ok, Below is the TCP dump. I have attached the Freeradius Debug output beginning near the start of the proxy.. WC-- is the wirless controller (155.99.193.24) FR-2.10 -- Freeradius 2.10 (155.97.182.175) ISE-proxy -- ISE proxy server (155.97.185.76) Again, any help would be much appreciated.. Thanks, Robert 09:31:25.451223 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x72 length: 229 09:31:25.452467 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x72 length: 64 09:31:25.454469 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x73 length: 355 09:31:25.461847 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x73 length: 1090 09:31:25.465436 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x74 length: 239 09:31:25.465779 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x74 length: 1086 09:31:25.469322 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x75 length: 239 09:31:25.469644 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x75 length: 1086 09:31:25.472928 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x76 length: 239 09:31:25.473199 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x76 length: 923 09:31:25.482815 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x77 length: 441 09:31:25.485315 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x77 length: 123 09:31:25.488059 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x78 length: 239 09:31:25.488362 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x78 length: 101 09:31:25.490724 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x79 length: 329 --Begin Proxy 09:31:25.491570 IP FR-2.10.1814 ISE-proxy.radius: RADIUS, Access Request (1), id: 0xd8 length: 242 09:31:25.497310 IP ISE-proxy.radius FR-2.10.1814: RADIUS, Access Challenge (11), id: 0xd8 length: 128 09:31:25.497504 IP FR-2.10.radius WC.32769: RADIUS, Access Challenge (11), id: 0x79 length: 101 09:31:25.499645 IP WC.32769 FR-2.10.radius: RADIUS, Access Request (1), id: 0x7a length: 313 09:31:25.500528 IP FR-2.10.1814 ISE-proxy.radius: RADIUS, Access Request (1), id: 0x47 length: 300 09:31:25.502871 IP ISE-proxy.radius FR-2.10.1814: RADIUS, Access Reject (3), id: 0x47 length: 49 09:31:26.504148 IP FR-2.10.radius WC.32769: RADIUS, Access Reject (3), id: 0x7a length: 101 From: freeradius-users-bounces+robert.roll=utah@lists.freeradius.org [freeradius-users-bounces+robert.roll=utah@lists.freeradius.org] on behalf of Phil Mayers [p.may...@imperial.ac.uk] Sent: Thursday, August 29, 2013 7:58 AM To: freeradius-users@lists.freeradius.org Subject: Re: EAP-Peap-MSchapv2 proxy from innertunnel On 29/08/13 14:35, Robert Roll wrote: I'm trying to do a proxy from the inner-tunnel over to another radius server. The primary reason for this is that we need to strip off the realm before passing to the proxy. I'm getting an EAP error response from the other server about it not liking the id number Supplicant sent unmatched EAP response packet identifier ( This is an EAP-PEAP-MSCHAPv2 scenerio) The EAP.conf file is configured with: proxy_tunneled_request_as_eap = yes I've included a TCP dump of the main freeradius server below But not a debug gathered with radiusd -X which is the only thing anyone ever wants to see. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html rdebug.out Description: rdebug.out - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Different groups to access services.
I installed FreeRADIUS Version 2.1.12 on a centos 6.4 and configured the ldap module for authentication of my users. Also configured my users files with 2 specific groups where only the users who are in these groups can authenticate. Until there alright. What I need your help and the following: There are two groups in Active Directory: CISCO and WIRELESS. I'm using freeradius to authenticate my switches and my wireless network with these groups. All users in the group CISCO will authenticate in my swiths ALL users in the group WIRELESS will authenticate on my wireless base. What this happening and that all users of the group CISCO E group wirelless are accessing in my switchs and at the base wireless. How do I configure this restriction? Thanks. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: EAP-Peap-MSchapv2 proxy from innertunnel
Ok, I've tried this with 2.2 and still get the same behavior..
If I actually look at the proxy-inner-tunnel I see the following for
post-proxy..
post-proxy {
#
# This is necessary for LEAP, or if you set:
#
# proxy_tunneled_request_as_eap = no
#
eap
I see that eap needs be invoked if using
proxy_tunneled_request_as_eap = no
Does it actually need to NOT be there for
proxy_tunneled_request_as_eap = no
I should say I'm actually NOT using the proxy-inner-tunnel server, but
rather the default inner-tunnl with:
# If you want the inner tunnel request to be proxied, delete
# the next few lines.
#
# update control {
# Proxy-To-Realm := LOCAL
# }
Thanks,
Robert
From: freeradius-users-bounces+robert.roll=utah@lists.freeradius.org
[freeradius-users-bounces+robert.roll=utah@lists.freeradius.org] on behalf
of Phil Mayers [p.may...@imperial.ac.uk]
Sent: Thursday, August 29, 2013 9:38 AM
To: freeradius-users@lists.freeradius.org
Subject: Re: EAP-Peap-MSchapv2 proxy from innertunnel
On 29/08/13 15:56, Robert Roll wrote:
I guess I assumed the id: in the TCP dump below was the EAP Response
Identifier maybe not ? Is there a different
EAP response identifier ?
Yes, in the EAP-Message attribute (EAP packet)
I actually have been running with debug radius -X. Obviously a lot longer
output than just the TCP dump.
That is why I first tried just the TCP dump. I guess I was also hoping
somebody might have just
had a thought about a common configuration issue...
TBH proxying EAP inner is not common at all; there have been bugs in
that area in the past.
Re-reading I notice that you're running 2.10 - upgrade. I'm pretty
certain that version has inner-eap proxy bugs. Go to 2.2.0.
-
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: EAP-Peap-MSchapv2 proxy from innertunnel
On 29/08/13 17:01, Robert Roll wrote: Ok, Below is the TCP dump. I have attached the Freeradius Debug output beginning near the start of the proxy.. The problem here is pretty straightforward, but not obvious from the debugs since FR is just proxying. Basically, the client sends the inner EAP-identity, and the proxy server responds with an EAP-TLS start i.e. you would be doing EAP-TLS inside PEAP, if this worked: rad_recv: Access-Challenge packet from host 155.97.185.76 port 1812, id=216, length=128 State = ... Proxy-State = 0x313231 EAP-Message = 0x010900060d20 0x0d == 13 == EAP-TLS. This is encrypted and sent down the tunnel. The client then sends an EAP-NAK, listing 26 as the only supported EAP type (which is weird - is it a Windows machines set to some odd combo like cryptobinding enabled?): [peap] Got tunneled request EAP-Message = 0x02090006031a 0x03 == 3 = NAK, 0x1a == 26 == MS-EAP (SoH, I think?) ...which the proxy server then rejects: rad_recv: Access-Reject packet from host 155.97.185.76 port 1812, id=71, length=49 Proxy-State = 0x313232 EAP-Message = 0x04090004 So the solution is simple - if you're going to proxy the inner auth, ensure the client inner auth method and upstream proxy auth method are mutually compatible. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
Phil Mayers wrote: [peap] Got tunneled request EAP-Message = 0x02090006031a 0x03 == 3 = NAK, 0x1a == 26 == MS-EAP (SoH, I think?) That's EAP-MSCHAP-v2. ...which the proxy server then rejects: rad_recv: Access-Reject packet from host 155.97.185.76 port 1812, id=71, length=49 Proxy-State = 0x313232 EAP-Message = 0x04090004 So the solution is simple - if you're going to proxy the inner auth, ensure the client inner auth method and upstream proxy auth method are mutually compatible. i.e. set proxy_tunneled_request_as_eap = no Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
Robert Roll wrote:
If I actually look at the proxy-inner-tunnel I see the following for
post-proxy..
The post-proxy stage has NOTHING to do with the home server. If the
home server rejects the request, the issue is WAY before the
post-process stage.
I see that eap needs be invoked if using
proxy_tunneled_request_as_eap = no
Does it actually need to NOT be there for
proxy_tunneled_request_as_eap = no
No.
See my reply to Phil. You need to set:
proxy_tunneled_request_as_eap = no
in eap.conf, peap{} subsection.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Different groups to access services.
Luiz Alberto Avelino wrote: There are two groups in Active Directory: CISCO and WIRELESS. I'm using freeradius to authenticate my switches and my wireless network with these groups. All users in the group CISCO will authenticate in my swiths ALL users in the group WIRELESS will authenticate on my wireless base. What this happening and that all users of the group CISCO E group wirelless are accessing in my switchs and at the base wireless. How do I configure this restriction? By doing group checks. See the FAQ for examples of how to do group checks with LDAP (e.g. Active Directory) Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
On 29/08/13 18:16, Alan DeKok wrote: Phil Mayers wrote: [peap] Got tunneled request EAP-Message = 0x02090006031a 0x03 == 3 = NAK, 0x1a == 26 == MS-EAP (SoH, I think?) That's EAP-MSCHAP-v2. Doh, yes, brain fade. TBH this page could be clearer: http://www.iana.org/assignments/eap-numbers/eap-numbers.xhtml ;o) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
On 29/08/13 18:16, Alan DeKok wrote: i.e. set proxy_tunneled_request_as_eap = no Although IIRC that *definitely* had issues in 2.1.10, right? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
range of mac addresses
If you wanted to do mac authentication, is there a way to add a range of mac addresses to the users list. eg: #Normal mac username: 002710de63a4 Cleartext-Password := 002710de63a4 e806882925ce Cleartext-Password := e806882925ce #Range of mac addresses: 94ebcd** Cleartext-Password := 94ebcd** Dan. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-Peap-MSchapv2 proxy from innertunnel
Phil Mayers wrote: On 29/08/13 18:16, Alan DeKok wrote: i.e. set proxy_tunneled_request_as_eap = no Although IIRC that *definitely* had issues in 2.1.10, right? I don't recall... that was a long time ago, and I'm trying to get 3.0 out the door. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: range of mac addresses
On 29 Aug 2013, at 23:13, Dan Letkeman danletke...@gmail.com wrote:
If you wanted to do mac authentication, is there a way to add a range of mac
addresses to the users list. eg:
#Normal mac username:
002710de63a4 Cleartext-Password := 002710de63a4
e806882925ce Cleartext-Password := e806882925ce
#Range of mac addresses:
94ebcd** Cleartext-Password := 94ebcd**
DEFAULT User-Password =~ '^94ebcd[0-9a-f]{6}$', Auth-Type := Accept
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: range of mac addresses
On Thu, Aug 29, 2013 at 05:13:54PM -0500, Dan Letkeman wrote:
#Range of mac addresses:
94ebcd** Cleartext-Password := 94ebcd**
If you're using PAP (which I guess is most likely if it's MAC
auth), you should be able to do something like
DEFAULT User-Name =~ ^94ebcd, User-Password =~ ^94ebcd, Auth-Type :=
Accept
Or, depending on the number of prefixes, forget the users file and
just write it in unlang; maybe something like.
if ( User-Name =~ /^94ebcd..$/ ) {
update control {
Cleartext-Password := %{User-Name}
}
}
Be very careful with that one for obvious reasons...
If you're doing CHAP (or something that needs the full cleartext
password) then you're probably limited anyway, as the only way
you're going to get the right cleartext password from a username
in a range when you don't list them all is to refer to said
username.
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: FreeRADIUS / PostgreSQL?
( cc-ing you directly since it seems you have trouble receiving mails from
the list )
Apologies! My comcast.net account was bouncing mail from the list for
reasons unknown. I saw the bounce rating jump from 1 to 3 over the course
of this week, so I resubscribed with a proper e-mail address.
Did you read Phil's excellent reply?
http://lists.freeradius.org/pipermail/freeradius-users/2013-August/067991.html
After Fajar kindly forwarding the link to me, I was able to see the reply.
Thanks you, Fajar, and Dan as well.
In reviewing your directions, I noticed one configuration missing from my
setup:
/etc/raddb/sql.conf, $INCLUDE sql/${database}/dialup.conf was commented!
I uncommented, re-ran radiusd -X, and saw much more information:
# radiusd -X
FreeRADIUS Version 2.1.12, for host i386-redhat-linux-gnu, built on Oct 3
2012 at 01:20:08
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 files in directory /etc/raddb/modules/
including configuration file /etc/raddb/modules/expr
including configuration file /etc/raddb/modules/expiration
including configuration file /etc/raddb/modules/soh
including configuration file /etc/raddb/modules/pam
including configuration file /etc/raddb/modules/acct_unique
including configuration file /etc/raddb/modules/rediswho
including configuration file /etc/raddb/modules/detail.log
including configuration file /etc/raddb/modules/unix
including configuration file /etc/raddb/modules/sqlcounter_expire_on_login
including configuration file /etc/raddb/modules/smbpasswd
including configuration file /etc/raddb/modules/attr_filter
including configuration file /etc/raddb/modules/passwd
including configuration file /etc/raddb/modules/policy
including configuration file /etc/raddb/modules/pap
including configuration file /etc/raddb/modules/counter
including configuration file /etc/raddb/modules/logintime
including configuration file /etc/raddb/modules/radutmp
including configuration file /etc/raddb/modules/detail
including configuration file /etc/raddb/modules/files
including configuration file /etc/raddb/modules/mac2vlan
including configuration file /etc/raddb/modules/mschap
including configuration file /etc/raddb/modules/chap
including configuration file /etc/raddb/modules/checkval
including configuration file /etc/raddb/modules/cui
including configuration file /etc/raddb/modules/opendirectory
including configuration file /etc/raddb/modules/realm
including configuration file /etc/raddb/modules/ippool
including configuration file /etc/raddb/modules/digest
including configuration file /etc/raddb/modules/echo
including configuration file /etc/raddb/modules/attr_rewrite
including configuration file /etc/raddb/modules/wimax
including configuration file /etc/raddb/modules/otp
including configuration file /etc/raddb/modules/preprocess
including configuration file /etc/raddb/modules/inner-eap
including configuration file /etc/raddb/modules/ntlm_auth
including configuration file /etc/raddb/modules/linelog
including configuration file /etc/raddb/modules/always
including configuration file /etc/raddb/modules/replicate
including configuration file /etc/raddb/modules/sradutmp
including configuration file /etc/raddb/modules/perl
including configuration file /etc/raddb/modules/smsotp
including configuration file /etc/raddb/modules/detail.example.com
including configuration file /etc/raddb/modules/mac2ip
including configuration file /etc/raddb/modules/redis
including configuration file /etc/raddb/modules/exec
including configuration file /etc/raddb/modules/sql_log
including configuration file /etc/raddb/modules/dynamic_clients
including configuration file /etc/raddb/modules/etc_group
including configuration file /etc/raddb/eap.conf
including configuration file /etc/raddb/sql.conf
including configuration file /etc/raddb/sql/postgresql/dialup.conf
including configuration file /etc/raddb/policy.conf
including files in directory /etc/raddb/sites-enabled/
including configuration file /etc/raddb/sites-enabled/default
including configuration file /etc/raddb/sites-enabled/control-socket
including configuration file /etc/raddb/sites-enabled/inner-tunnel
main {
user = radiusd
group = radiusd
allow_core_dumps = no
}
including dictionary file /etc/raddb/dictionary
main {
name = radiusd
prefix = /usr
localstatedir = /var
sbindir = /usr/sbin
logdir = /var/log/radius
run_dir = /var/run/radiusd
libdir = /usr/lib/freeradius
radacctdir = /var/log/radius/radacct
hostname_lookups = no
max_request_time =
Re: range of mac addresses
Excellent. Thank you.
On Thu, Aug 29, 2013 at 5:32 PM, Arran Cudbard-Bell
a.cudba...@freeradius.org wrote:
On 29 Aug 2013, at 23:13, Dan Letkeman danletke...@gmail.com wrote:
If you wanted to do mac authentication, is there a way to add a range of
mac addresses to the users list. eg:
#Normal mac username:
002710de63a4 Cleartext-Password := 002710de63a4
e806882925ce Cleartext-Password := e806882925ce
#Range of mac addresses:
94ebcd** Cleartext-Password := 94ebcd**
DEFAULT User-Password =~ '^94ebcd[0-9a-f]{6}$', Auth-Type := Accept
Arran Cudbard-Bell a.cudba...@freeradius.org
FreeRADIUS Development Team
-
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: FreeRADIUS / PostgreSQL?
Did you read Phil's excellent reply? http://lists.freeradius.org/pipermail/freeradius-users/2013-August/067991.html After Fajar kindly forwarding the link to me, I was able to see the reply. Thanks you, Fajar, and Dan as well. s/Dan/Phil/ Please place my head in a vice and crank it shut until I stop typing. :) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
