I have been having fun implementing a SSO framework for Microsoft's NPS (when used as the EAP terminating RADIUS server)... but the project is on hold while I pester Microsoft for hotfixes: http://www.nicklowe.org/2013/08/nps-class-attribute-bug/ The generic requirements for your NASes are pretty high to do this properly. A few common pain points are: 1) The NAS MUST support RADIUS accounting for 802.1X authenticated sessions and sending interim updates. This should be obvious, but not all NASes that support 802.1X authentication via RADIUS support RADIUS accounting. 2) Where IPv4 is to be used, the NAS MUST support DHCPv4 snooping and use this information, and only from this source, to populate and include the Framed-IP-Address attribute with a client's IPv4 address in Interim-Update RADIUS accounting packets. A NAS must, of course, make a client's IPv4 address available for Single-Sign-On (SSO) to work in an environment where IPv4 has been deployed. For security reasons, it is imperative that only the information from the DHCPv4 snooping process be used as a source of address information. 3) Where IPv6 is to be used, the NAS MUST support DHCPv6 snooping and use this information, and only from this source, to populate and include Framed-IPv6-Address attributes with a client's IPv6 addresses in Interim-Update RADIUS accounting packets. A NAS must make a client's IPv6 addresses available for Single-Sign-On (SSO) to work in an environment where IPv6 has been deployed. For security reasons, it is imperative that only the information from the DHCPv6 snooping process be used as a source of address information. 4) Either the NAS MUST immediately send an RADIUS accounting Interim-Update packet when a client's IP address becomes known or changes after its DHCP process concludes. Or the NAS MUST send an Interim-Update RADIUS accounting packets at an interval that is sufficiently short that it ensures there is a minimal and acceptable delay before an Interim-Update packet is sent that contains the client's IP address. It is important that the client's IP address be made available in a timely manner. It is best where this is imperceptible to an end user and the load on a RADIUS server is kept to a minimum. It is best where the first approach is adopted. Conceptually, this is like polling vs. event based notification, the latter is nearly always better design where achievable. 5) The NAS SHOULD support sending Accounting-On and Accounting-Off RADIUS accounting packets. This allows expedient handling of stale sessions when a NAS is shutdown or restarted without requiring a timeout to kick in. 8) A NAS that supports handoff to another NAS MUST include an Acct-Multi-Session-Id attribute in the RADIUS accounting packets that are sent. The Acct-Multi-Session-Id attribute MAY be introduced within a session via an Interim-Update RADIUS accounting packet, but it MUST be sent before a handoff event occurs. Where roaming occurs, it is imperative that the connection can be tracked across the multiple RADIUS sessions that result. Otherwise, the previous session will be considered stale after a timeout and expunged. (The replacement session will usually be accounted without a corresponding authentication and authorisation exchange.) 8) A NAS SHOULD include the Event-Timestamp attribute and the Acct-Delay-Time attribute in all its RADIUS accounting packets. This allows determination to be made on the correct way to handle the event in context to the state of a session. 9) A NAS SHOULD support processing the User-Name attribute in RADIUS Access-Accept packets, overwriting the value used from the EAP outer identity if one is present. In Single-Sign-On systems, where the Authentication/Authorization process is opaque because there is no direct integration with it, it is necessary that the RADIUS server return the User-Name attribute with the client's real identity AND that the NAS support processing this in order to not end up with a deployment vulnerable to identity spoofing. Nick On Mon, Mar 24, 2014 at 11:12 PM, Bruce Richardson <bruce_m_richardson@unitedbiscuits.com> wrote:
Hi,
I have been using freeradius for many years now to authenticate WiFi users against active directory, and it all works perfectly.
I am now trying to integrate it with the identity awareness built into our Checkpoint firewall system, this is able to take radius authentication packets and build a list of users against IP addresses.
I understand that you can replicate the accounting data on from freeradius but for this to work obviously the WiFi client's IP address needs to be in the radius accounting data. At the moment it isn't because at the point when the accounting data is sent the client has not yet sent its DHCP request.
Am I correct that to get the IP address into the radius accounting the freeradius server needs to be configured to send out the IP addresses rather than different DHCP server.
If this is correct, could I create different IP pools to be used for each site, and have the correct IP data sent out for for different sets of wifi access points (NAS).
Many thanks for reading this, I just want know I am going in the correct direction.
Regards,
Bruce Richardson
This e-mail and any attachments are confidential and solely for the use of the intended recipient. They may contain material protected by legal professional or other privilege. If you receive it in error, please delete it from your system, make no copies of it, do not disclose its contents to any third party or use it for your own or any other person's benefit. Please advise the sender of its receipt as soon as possible. Although this email and its attachments are believed to be free of any virus or other defect, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by the company for any loss or damage arising from receipt or use thereof. Any opinions expressed that do not relate to the official business of the company are those of the author, not the United Biscuits group of companies.
United Biscuits (UK) Limited Registered in England number 2506007 Registered Office: Hayes Park, Hayes End Road, Hayes, Middlesex, UB4 8EE
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html