Skip to Content.

cat-users - Re: [[cat-users]] Eduroam : Password Update

cat-users AT lists.geant.org

Subject: The mailing list for users of the eduroam Configuration Assistant Tool (CAT)

List archive


Re: [[cat-users]] Eduroam : Password Update


Chronological Thread 
  • From: Paul Dekkers <paul.dekkers AT surf.nl>
  • To: Philippe Taurines <Philippe.Taurines AT crous-toulouse.fr>, ALBRIZIO DANIELE <albrizio AT units.it>, "cat-users AT lists.geant.org" <cat-users AT lists.geant.org>
  • Subject: Re: [[cat-users]] Eduroam : Password Update
  • Date: Wed, 24 Jan 2024 16:17:43 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=surf.nl; dmarc=pass action=none header.from=surf.nl; dkim=pass header.d=surf.nl; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=jNtvbAuMAQQVq0tNotigmAAAc0OmXrmfeAj/AGja+Ik=; b=YbuacoDZYbqBnaQXZSpoc8DBw0uxV75DHMIW60boy6Swi8EUBd6luiZUbZb96HpuQvf0/pJbVUk3V8vhVR25UHKPCNnQ9FXX954NnupyYgpH+u8qTnWFhCXSMoCbk32ofVgQF8rpQrmvK41dpJ8sCan31gytg+BWPCJyvyIzZzMhM1B6kjSupEg+hhHoDAiG1tV+j2L9iWEkAG/yi1Wn3nbGFNT3OJpF/x4unLnOvz0HW5VMYXslFbpwPIwYNciILvMm76RKHjkQYyaDT4r+Eiv2TEnZvUv4ZV9tC+nw0bmsPpKssqlB3fG5GKW62FBWqmv6Hz6dBqrfG9BXTC70Tg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gSJCdV/KTcPIkknIZyybx70WRbzMW6CzCDpL3hhK5zo9WPTyd+vhVranItyJtNsCzKBwEUf8WbfvUlkaWN+XAoxSvSbzjJljuqftb16P64fNHfSyL67g4jiJiVoCZJPxxJie67ZNtDq0oWiaAAza28/5jer5n3WCwmoSqNs8pPJ/r6Q40bKH+3LJMepv2mm6mAj4/+xAQ5YldUWT4w02NyD10a7h0B4F39V6adSUPP8xcmQGQXrieyaY13r6e7eFLzyIQrqZFb8FS6S0F/X8gNiuqojvbwSnFr3rmfKoGfuoS5rfmvtCsw8nRTeRtXA2frqcri/BFgSWtxbgQAGziw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=surf.nl;
  • Autocrypt: addr=paul.dekkers AT surf.nl; keydata= xsDNBFzP6HIBDADK8Wn7ods1w4ysf5c/GeUkDm2doxOZRUU3ZSMM0aG9aN2jqpZB11xoTuAv k+J3kOpRY542rbHTxkbdiIYFiKS5ff9bAPfn1MUOy+XErLPUzZ/Z3GO6kCpTkcHYKVN2Iehd QCdn7UbNRRzygiVHiRWi8jkhutBWBHHy7hcVWXtHfxb5Ot7I6Z9F2Aso6sB543UrQVxEl0h1 AuNN2HXVW536LaGh+ZRTPPPj99nR8UvNnJ4Q/Jh9a6/C9TB1vGm/4oTWG2gnFcq9CBQB9+E0 GZ7S9ddyKzXE97wziJdhC4e14s9aSiG9Du98C62ilTzOk4muOV6XU0JZOy3jwIt6bS2m9zGf yUxhKs5mNwrCUeBqt5uKgUXAG0MnQ70lMmiGyMNwUkCXuHiScvzB7rdXM0h2pvfrMMsQ1BA5 +0Zb1hkkq5eYVUE+e9xJID82ShdMOTievgSdc4JP4lJuUAjVf30u5uUe/uxsDxc1zfnZsp30 ezTIhp2SxszZcWjzTnn7tSEAEQEAAc0jUGF1bCBEZWtrZXJzIDxwYXVsLmRla2tlcnNAc3Vy Zi5ubD7CwQ4EEwEIADgWIQQ3Xw/6ofYHVAb73o89O9GpKK14OgUCXM/ocgIbIwULCQgHAgYV CgkICwIEFgIDAQIeAQIXgAAKCRA9O9GpKK14OsHaDACFjL2wGvcSxecAVjShtnOwHgi5iO+r MUQiplP7/dD8awcBxuj1ihv/kZoatI0tSxsXs6OqYqG/ivJfCaXX51dYANDfDI4E8FLN+eCj v3ndVJHEWdixNrVH+sdS4itZt0omQ28dbMpJc7opOw42o5xMmypMMzo4enHZcaYr4fktAu5B 2E3eekw8aXOHPSrTmIAZjhaKCdZ5CtOotgoUGnrQbHIVlPh7PJBCUTlNXDynjLdznhYJjvBN GnT9B+PPfJ0TQMBv0gqWlfJA+GSKl//pz+Jqh1ByyRFXZaG0imE4eLaODSb+3aoD36pWMrdV 31m+qeEzB2V6I40vdBmZEtpX+01l3kuIPa/ZpJ3MCaeVlQ2ADkZwz1DVEV4aasOkKL2hAlMz bSChFnSA6OhOS+2L+7HAtI62OPj0VkXERqeFPpOWFG0OzqJUCBB5x/OdhoMiVjI2KNtMDxoD Y4L+u1MeNwm7fPYrdQn8aDN0Lc5tEdw29mwWwBLjiu+u8jCEyGnOwM0EXM/ocgEMALdymAvx UsfhoNnNR+SaJCUVwmBMjt9spGs1E27yqHMs7jDnZ87uh2B220GmZGKFkf4SbRHUJhPGX+rg Ez2vvlBwZonBKDY1SyCPRI6ffaivoz9hw+GXpQYQwIZ1gJWN7MvhzIbG+b+Y6pRMRsWSjThA ImieLS2+K2oR6XenxKG/dZg8qO/Uv5Qvb66rWtFM9D48iurcUu3ndotJPAkKetUg3dny4nzp D1wT26RcqEh8huJfZK8JdML+9Q1dHoMhtwRzTTWQ4rxwEr2X1ymaF4QaG8LbuT4/Owrp5vGd YI7Wh2Lwjwn6tJE715eePcoahQwgBBwsKBCkRDOQ3dA8bUO/G8p7SRTj/CAymx5unis3H6O/ jQmi3cgVLNg6CYwPGptFRrLxqT/eWsNy/2Dpd8VHajjVKQ6bC0MNz+lHoFkNMc/CaTY8BQix xM4mtm5rbbogX9pBPSUx5vVgd1Vbw8sQT2wFxUI3Q3r4KaKD5MVucDTg3OxcMNQxRTLDdonI owARAQABwsD2BBgBCAAgFiEEN18P+qH2B1QG+96PPTvRqSiteDoFAlzP6HICGwwACgkQPTvR qSiteDqo6gwAqIpD/D4lNkUehSf+U8l9lTpkWNAEfB9PgAMIFrFQ3YUuEmhFlv8uKi6Y7apX 89tmrVUgc5RLglf7e4geYv69wLY4R7jMIUs0g9cv/g71rhfszjDJGe/4ppa+qHTk69Uq556d B9nMtFF2YWvq77Y1WBKv/r3hmJLQYNZBaCBSPI9OpZ0UCw3hp0ip/LUejVXLRkU+ZAb6jeEt gd2zoIiXOHCazaGD6EGvLQxzuwPVPXPLU6kahtJoJAa/OOWyzSnd+Ipio6Vi6tdDVLEXbTVn AjnVOlEnGc6dhh1TOxPv/lHslYxfSTrCoBRIKcXS/5bkxvTOZpgSRyKsksh1fgD1IIPjLqs2 K7KOXgocNG+iIOMcLbSsp8R7GRUMmzeTIPHnW1xC9OIgU16KSxaDWa6tX6NOcY5iHRlRXw5Q 9WVGgnHIbfR/2hoyXzbVMzM2uiTEJ9qG4+GtMUBeLdEo8DsbX+QdP71NgcCcBUtUe9LfDEJ+ yZ0Nj/dbF6RX3MTEJRiy

Hi,

In principle the geteduroam clients support the concept of "credential expiration". We use this in the pseudo-accounts, because the certificates have a limited lifespan. We know exactly what their lifespan is though. So after this time, we can remove the profile, and in advance we can ask the client to reconfigure.

For username/passwords we don't know how long the credentials are (still) valid. Also, the feature isn't built into CAT: but we could consider it. Assuming the credentials are "at most" valid for 6 months, you could use the timer.

Regards,
Paul

P.S. Personally I like the new NIST advise to no longer work with password expiration I must say. I don't think it adds a lot to the security to change a password periodically, unless you're certain there was a compromise.


On 24/01/2024 14:06, Philippe Taurines (via cat-users Mailing List) wrote:
PR1P264MB3830E56B09360434E89C9881A77B2 AT PR1P264MB3830.FRAP264.PROD.OUTLOOK.COM">

Thank you for this explanation.

 

Our problem is that with this operation, when a user changes their password, it locks the accounts in our directory, because it does not systematically restart "eduroamcat".

 

However, we do not have an aggressive policy regarding account locking (account locking after 10 attempts within 15 minutes). What we see in the logs of our freeradius servers by the following messages:

 

  • Auth: (1664815252)   Incorrect login (mschap: Program returned code (1) and output 'The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested. (0xc0000234)'

 

We are therefore looking for a method (server configuration, clients, etc.) which would allow us to maintain our locking policy and which would not block access to other services, because the account is locked in the directory.

 

Hence the question of how to force the Windows client to re-request the user's password. If you have any ideas?

 

 

De : ALBRIZIO DANIELE <albrizio AT units.it>
Envoyé : mercredi 24 janvier 2024 12:00
À : Philippe Taurines <Philippe.Taurines AT crous-toulouse.fr>; cat-users AT lists.geant.org
Objet : Re: [[cat-users]] Eduroam : Password Update

 


Vous ne recevez pas souvent de courriers de la part de albrizio AT units.it. Découvrez pourquoi cela est important


 

Normally, in the chain of directories, password repositories, authentication middleware, etc. you lose the information about the reason the authentication fails.

This results in a 0 or 1 condition of authentication success or authenticatio fail. There are some radius attributes you can use out-of-standards to report about reasons, but since is an out of standardization use, this will not be grabbed by clients (supplicants).

 

This scenario is typically a lot different from a simple WPA passphrase authentication.

 

What I assume as an oversemplification (that means complication) of the scenario is also the operating system behaviour of re-requesting for secrets when something goes wrong such as:

 

- Temporary Timeouts (backends, radius hierarchy, ...)

- Errors in wifi (low signal and subsequents retransmission and timeouts)

- Wrong/unsupported authentication mechanisms

- TLS version mismatch and implementation issues

- ...

 

All those reasons should not lead to re-asking the user for password (default behaviour on windows and other os).

 

Users forget and unknowingly mistype their passwords. This leads to a worse user experience perception (think about retyping password due to a home server temporary unreachability).

 

The profile re-installation is a safer and better solution for what I understand.

 

 

 

On Wed, 2024-01-24 at 08:17 +0000, Philippe Taurines wrote:

Why would this be specific to the operation of Windows and not eduroam?

 

Because when connecting to an access point with a simple SSID such as “WPA2 PSK”, Window asks you to re-enter the password security key.

 

Which would suggest that in WPA2-Enterprise / AES / PEAP mode it behaves differently?

 

This could not be due to the fact that the Freeradius server does not indicate to the Windows client that the password is invalid?

 

Good day

 

De : Tomasz Wolniewicz <twoln AT umk.pl>
Envoyé : mardi 23 janvier 2024 16:43
À : Philippe Taurines <Philippe.Taurines AT crous-toulouse.fr>; cat-users AT lists.geant.org
Objet : Re: [[cat-users]] Eduroam : Password Update

 

Unfortunately this is how Windows works now, if you run the installer again it will remove the profile and install everything again. You could also "forget" the eduroam network, but this would result in the same thing - the need to run the installer again.

Yours

Tomasz Wolniewicz

 

W dniu 23.01.2024 o 16:07, Philippe Taurines (via cat-users Mailing List) pisze:

Good morning,

 

After eduroam configuration of the Windows machine (10/11) via “eduroamCAT” or “geteduroam”, the connection works.

 

On the other hand, when our users change the password in our directory, they are refused the connection.

 

But the Windows client never offers to enter the new password, so there are two questions belows:

 

• Why this behavior?

• How to force Windows clients to ask for the new password?

 

Sincerely,

 

 

-- 

 


Daniele Albrizio

Ufficio Reti e telefonia | ICT - Phone and Network Management
Università degli Studi di Trieste | University of Trieste
Via Alfonso Valerio 12 - 34127 Trieste (Italy)
daniele.albrizio AT units.it
Tel. | Ph. +39 040 558 3319

Ufficio Reti e telefonia | ICT - Phone and Network Management
Tel. | Ph. +39 040 558 3331

To unsubscribe, send this message: mailto:sympa AT lists.geant.org?subject=unsubscribe%20cat-users
Or use the following link: https://lists.geant.org/sympa/sigrequest/cat-users



Archive powered by MHonArc 2.6.24.

Top of Page