Help with chap

Franks Andy (RLZ) IT Systems Engineer Andy.Franks at sath.nhs.uk
Thu May 23 10:52:15 CEST 2013


Hi,

  Yes that makes sense, although the mac address was already being reported on the switch. It’s not having any negative effect anyway, so I’m happy.

Thanks

Andy

 

From: freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradius.org [mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradius.org] On Behalf Of Matthias Nagel
Sent: 21 May 2013 23:23
To: freeradius-users at lists.freeradius.org
Subject: AW: RE: Help with chap

 

Hello,

actually this behaviour is totally correct. The switch tries to authenticate a client, when the switch learns the clients MAC address. As the MAC address is extracted from the ethernet header there must be some packages sent from the client in order to do so. If the client is quiet, the switch cannot do anything about it.

Matthias

 

 

Matthias Nagel
Willy-Andreas-Allee 1, Zimmer 506
76131 Karlsruhe

Telefon: +49-721-8695-1506
Mobil: +49-151-15998774
ICQ: 499797758
Skype: nagmat84


"Franks Andy (RLZ) IT Systems Engineer" <Andy.Franks at sath.nhs.uk> hat geschrieben:
..Just an update.. might be interesting for people - rebooted the switch
and not all clients were authenticated, but it seems all those that
weren't have 0 bytes for all statistics, tx, rx etc. So I guess they are
switched off and the switch seems to need some packets to flow for it to
"detect" that the client needs authenticating. 
Otherwise it looks like it will sit with the port in an up state
unathenticated all day long. I guess this sort of makes sense, but in my
simple view of how things this isn't intuitive. Also HP manuals don't
seem to mention it..
Thanks
Andy

-----Original Message-----
From:
freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradius.org
[mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradiu
s.org] On Behalf Of Franks Andy (RLZ) IT Systems Engineer
Sent: 21 May 2013 22:27
To: FreeRadius users mailing list
Subject: RE: Help with chap

Thanks Phil. I'll keep that up my sleeve for future use. We tend to
separate admin / wireless / mac-based auth off on to different radius
boxes. Keeps things a bit easier. Not sure what cisco do, but a lot of
their stuff tends to be pap or eap. HP doing chap here seems to limit
quite a lot of backend options. 
It's still also the only protocol, or so it seems, chosen for iscsi
authentication which is an interesting choice consider it's
vulnerabilites. Guess ipsec gets used instead where it needs to be
secure.
Now to work out the useraccountcontrol setting. Seems to be different in
users and computers than in an ldap viewer, but the ldap is probably a
decimal conversion or something.
Thanks again
  Andy

-----Original Message-----
From:
freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradius.org
[mailto:freeradius-users-bounces+andy.franks=sath.nhs.uk at lists.freeradiu
s.org] On Behalf Of Phil Mayers
Sent: 21 May 2013 08:06
To: freeradius-users at lists.freeradius.org
Subject: Re: Help with chap

On 05/21/2013 07:55 AM, Franks Andy (RLZ) IT Systems Engineer wrote:

> Can I just use the authorize section to set the password to be the 
> same as the username, i.e. the mac address, after checking some basics

> like whether the user exists in ldap and perhaps the 
> useraccountcontrol value, then in the authorize section just let the 
> chap bit work on the assigned password?

Yes. In fact that's the best approach. Something like:

authorize {
   ...
   if (some condition) {
     update control {
       Cleartext-Password := "%{User-Name}"
     }
   }
   ...
}

"some condition" would normally be some sort of check to ensure it was a
macauth-via-CHAP request - obviously you wouldn't want to force
password==username for a PPP/EAP/other "real" user request. On the other
hand if your server / virtual server only receives this traffic, you can
omit the condition.

I really dislike vendors who do macauth as CHAP. It seems to completely
lack value, and adds complexity. Le sigh..
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20130523/0abe2b64/attachment-0001.html>


More information about the Freeradius-Users mailing list