Hi Louis, Thanks for this clear explanation..!
However, reading through it, I mostly see disadvantages to radius, but probably only due to my misunderstanding of things... I understand now, that each time a device boots, the complete authentication sequence you explained is followed, and also the 802.1x authentication is done using the credentials of the _enduser_? This would mean that on each boot, they are required to provide credentials twice? First to 'activate' the switch port, then to logon to their OS..? This would mean that we would no longer be able to send a WOL packet at night to the workstations, make it boot, update stuff, and then shutdown again, right? (as the switch port would remain closed) Also, many people here startup their workstation, get a coffee while it boots and updates software (using GPO policies configured to run at system startup). But since the switch port would still be closed, they would come back with coffee, to find a logon request for the 802.1x authentication... Logon..and only THEN the updates would take place. And, if I understand port security/mac addresses correctly: as long as we (domain admins) have 'allowed' a workstation on a port, and nothing else changes, on each boot there would be immediate connectivity, because the mac address remains the same: * WOL updates would work, * the get-coffee-while-system-boots-and-updates sequence works Only when a unknown mac address appears on a port, packetfence would come in with the captive portal. Or am I missing something..? Thanks again for your patience, and kind explanation of this (for me) new world, Louis! :-) MJ On 05/04/2015 04:29 PM, Louis Munro wrote: > On May 3, 2015, at 11:37 , mourik jan heupink <heup...@gmail.com > <mailto:heup...@gmail.com>> wrote: > >> Is this all approximately correct? > > Hi Mourik, > I would call it approximately fanciful. > > Assuming 802.1x with PEAP — which is the most common deployment — the > actual workflow is something like this (gross handwaving and > simplifications follow): > > * You connect a device to a switch (assume for the purpose of this > post that we are connecting to a wired switch, but the general > principle is the same on wireless). > * The switch probes your device with 802.1x frames. > * The supplicant on your device replies with it’s credentials > (username/password). In the case of PEAP these are not the password > itself but a response to a challenge derived from it. > * The switch turns that reply into a radius request which it sends to > the RADIUS server. > * The radius server checks those credentials against whatever > authentication source it is configured for (e.g. an Active-Directory > server). > * If authentication is successful, it proceeds with authorization > (e.g. assigning a VLAN, an ACL or role). In the case of PacketFence > authorization is done through a call from FreeRADIUS to a webservice > where most of the business logic is implemented. That webservice > adds the proper attributes to the radius reply depending on the > configuration you entered in PacketFence and based on the knowledge > each switch modules has of what attributes it (the switch) expects > in reply for a given configuration. > * RADIUS receives the reply from the webservice and returns it in the > RADIUS reply to the original request from the switch. > * The switch allows or denies the access request and applies the > authorization specified in the radius reply, i.e. it will either > switch VLANs, apply an ACL or a role depending on what was returned. > > > > What you need to understand is the nature of the RADIUS protocol. > RADIUS is a request/reply over UDP protocol where everything is > specified as a set of key-values pair called attributes. > These attributes contain information like the user or device > credentials, the IP of the originating switch and anything else that > might be relevant. > Attributes are also used to convey information in the reply like the > VLAN, ACL or even QoS to apply to the connecting device. > > While 802.1x is a layer 2 protocol, RADIUS is level 4 (UDP) and happens > before your device is allowed on the network. > Therefore things like dns or dhcp cannot be relied upon during > 802.1x/RADIUS (e.g. no name resolution from the point of view of the > supplicant). > > Furthermore, this authentication/authorization happens every time you > connect a device or reauthenticate. > There is no such thing as checking if authorization has changed. > Everything starts over from scratch, every time. > > So the following is incorrect: >> - procurve confirms that the mac address is the same as last time, no >> further dialogue with freeradius: the client is granted the same access. > > And finally, 802.1x does not rely on MAC addresses. It relies on > authentication credentials provided by the supplicant, usually a > username/password. > > > Hope that is clearer. > Cheers, > -- > Louis Munro > lmu...@inverse.ca <mailto:lmu...@inverse.ca> :: www.inverse.ca > <http://www.inverse.ca> > +1.514.447.4918 x125 :: +1 (866) 353-6153 x125 > Inverse inc. :: Leaders behind SOGo (www.sogo.nu <http://www.sogo.nu>) > and PacketFence (www.packetfence.org <http://www.packetfence.org>) > > > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > > _______________________________________________ > PacketFence-users mailing list > PacketFence-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/packetfence-users > ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ PacketFence-users mailing list PacketFence-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/packetfence-users
