[RADIATOR] UNS: Basic Question on 802.1X
Ullfig, Roberto Alfredo
rullfig at uic.edu
Thu Aug 24 18:44:24 UTC 2023
That's not always the case though - for example (log chopped).
Aug 24 07:59:46 802.1X OK
Aug 24 08:01:30 802.1X FAILED
Aug 24 09:15:44 802.1X OK
139983 failed
357509 ok
19714 different mac addresses both had a failure and a success. If it's the same device that's misconfigured it should always fail
---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: Ullfig, Roberto Alfredo <rullfig at uic.edu>
Sent: Thursday, August 24, 2023 1:19 PM
To: Dubravko Penezic <dpenezic at srce.hr>; radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: UNS: [RADIATOR] Basic Question on 802.1X
Yes, I think you're right, I spot checked several of them and they never succeed.
---
Roberto Ullfig - rullfig at uic.edu
Systems Administrator
Enterprise Applications & Services | Technology Solutions
University of Illinois - Chicago
________________________________
From: Dubravko Penezic <dpenezic at srce.hr>
Sent: Thursday, August 24, 2023 8:34 AM
To: Ullfig, Roberto Alfredo <rullfig at uic.edu>; radiator at lists.open.com.au <radiator at lists.open.com.au>
Subject: Re: UNS: [RADIATOR] Basic Question on 802.1X
Hi Roberto,
if you "only" see FAILD no error or something elese, in you log, it is
normal and just reflact fact that is more and more devices which try to
connect to eduroam, but doesnt have proper configuration.
Some time on national level logs FAIL to OK may be 70:30%.
Regards,
Dubravko
On 8/24/23 15:28, Ullfig, Roberto Alfredo via radiator wrote:
> My knowledge of our 802.1X configuration is barebones and we inherited
> this configuration from ~20 years ago. We are seeing lots of failures in
> this part for a long time most likely (omitted some more sensitive details):
>
> <Handler Client-Identifier=n8021x>
> #
> # The rock8021x block and 8021x blocks are identical. The rock8021x
> block is needed as it acts
> # differently than the WISMs in that it does a login-user rather than a
> access-request. This
> # interferes with the 8021x clause that we have for uic-guest support
> #
> <AuthBy FILE>
> # Users must be in this file to get anywhere. In this
> example,
> # it reques an entry for 'anonymous' which is the
> standard username
> # in the outer requests, and it also requires an entry
> for the
> # actual user name who is trying to connect (ie the
> 'Login name' entered
> # in the Funk Odyssey 'Edit Profile Properties' page
> Filename %D/users
>
> EAPAnonymous %0 at uic.wireless
> EAPType PEAP, TTLS
> EAPTLS_PEAPVersion 0
> EAPTLS_CAFile /etc/radiator/certificatechain.crt
> EAPTLS_CertificateFile /etc/radiator/wireless.crt
> EAPTLS_CertificateType PEM
> EAPTLS_PrivateKeyFile /etc/radiator/wireless.key
> EAPTLS_MaxFragmentSize 1000
> AutoMPPEKeys
> EAPTLS_SessionResumption 0
> </AuthBy>
>
> RewriteUsername s/^([^@]+).*/$1/
> RewriteUsername s/\s+//g
> RewriteUsername s/^.*\\(.*)/$1/
> RewriteUsername tr/[A-Z]/[a-z]/
>
> <AuthBy SUSPEND>
> Dir /mnt/...
> </AuthBy>
>
> <AuthBy SUSPEND>
> Dir /mnt/...
> </AuthBy>
>
> <AuthBy WIRELESS>
> Dir /mnt/...
> </AuthBy>
>
> AcctLogFileName %L/wireless-detail
>
> <AuthLog SYSLOG>
> LogSuccess 1
> LogFailure 1
> Facility local0
> SuccessFormat %T : '%U' from %C
> mac=%{Calling-Station-Id} NAS-Id=%{Called-Station-Id}
> PEAP-SSID=%{NAS-Identifier} -- 802.1X OK
> FailureFormat %T : '%u' from %C
> mac=%{Calling-Station-Id} NAS-Id=%{Called-Station-Id}
> PEAP-SSID=%{NAS-Identifier} -- 802.1X FAILED
> </AuthLog>
>
> The failure rate is about 1 out of 3! But this does not to appear to be
> impacting anyone. The file "users" does not exist so I assume that
> entire Authby is ignored.
>
> What could be causing these failures? Filesystem access?
>
> ---
> Roberto Ullfig - rullfig at uic.edu
> Systems Administrator
> Enterprise Applications & Services | Technology Solutions
> University of Illinois - Chicago
>
> _______________________________________________
> radiator mailing list
> radiator at lists.open.com.au
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.open.com.au%2Fmailman%2Flistinfo%2Fradiator&data=05%7C01%7Crullfig%40uic.edu%7Ccd24dab7e4a1484609e308dba4a6e17f%7Ce202cd477a564baa99e3e3b71a7c77dd%7C0%7C0%7C638284808887330321%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=QrJdmONwpJpUafGHsjuf4BsGRurB4rcd56JOd4D3%2Fvo%3D&reserved=0<https://lists.open.com.au/mailman/listinfo/radiator>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.open.com.au/pipermail/radiator/attachments/20230824/d4fe3b45/attachment.html>
More information about the radiator
mailing list