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

[Tomasz Wolniewicz <twoln AT umk.pl>]

W dniu 22.02.2017 o 22:10, Robin Breathe pisze:

Tomasz,

Thank you for the clarification. I hadn't found the GEANT/CAT repo before today, so I have no familiarity with the codebase.

We only serve our local CA to supplicants presenting the anonymous identity "eduroam AT brookes.ac.uk" (indicating correct configuration via CAT). All other users are assumed to have been configured either manually or with an older version of CAT that used the Comodo CA.

I see, CAT tests use their own outer username hence confusion.

The bug however does appear to be real. If the profile is configured to install a wired profile (as ours has been set to do recently), and the user has to elevate their privileges by entering credentials for a different account (as opposed to being an administrator and elevating with simple UAC), the certificate gets installed in that other account's certificate store, not in the active user's. As a result, subsequent authentication fails.

OK, I understand. Indeed this scenario has not been tested and it could indeed fail. I need to think how this could be overcome.

When privileges have already been raised to install the wired profile, would it be reasonable to install certificates into the System store rather than those of the user? Presumably, without this, local CAs won't work when the user is logged out, either…

This would be one possible way to go.

When a colleague attempted to install an updated Win7 installer earlier with the wired profile disabled, it still prompted to raise credentials. We'll test again tomorrow.

As far as I can tell your installers use PEAP, thus I do not see any reason why the installer should ask for admin privileges. Please do test and let me know the result. I will run a test with your installer as well.

Tomasz

Regards,

Robin

On 22 February 2017 at 20:24, Tomasz Wolniewicz <twoln AT umk.pl> wrote:

Hi Robin,

   to begin with, the move from Gareth's setEAPCred has not happened yet. It will be in CAT 1.1.4 yet to be released. The reason why we do this is that with WLANSetEAPUserData we can also pinpoint a user certificate to be used with EAP-TLS, so we have a single utility that can do both PEAP and EAP-TLS.

Still neither of these utilities has anything to do with storing server side certificates. This is done with done with certutil.

CAT installers are meant to be run with just the user privilege. Inly if we need to support TTLS on W7, we need to elevate the privileges just to install the library.

One other case when CAT installer runs with admin level is when you are installing wired profiles in addition to wireless ones.

The certificates are installed in the user store, but before this is done CAT tests if the certificates are already present in the system and for this it checks both user store and the machine store, so that it will not install anything unnecessarily.

I have never seen a problem with server certificate validation.

I have tested your realm brookes.ac.uk with CAT connectivity tests and they show that your server certificate is signed by Comodo, while the root cert that you distribute with CAT is this local CA. I believe this confusion is the cause of your problems.

Cheers

Tomasz

W dniu 22.02.2017 o 17:19, Robin Breathe pisze:

Hi all,

When you run the Windows CAT installer as a non-admin user, you have to raise your privilege with an admin user's credentials. Unfortunately, this appears to result in any bundled trusted certificates being installed in that admin user's Trusted Root certificate store rather than in either the active user's Trusted Root certificate store or in the system-wide Trusted Root certificate store. As a result, subsequent TLS validation fails as the active user doesn't trust the certificate presented by the ORPS.

Has anyone else seen this issue? Have a workaround?

I'm suspecting the new(?) behaviour may have been introduced by the move from Gareth Ayre's setEAPCred.exe to WLANSetEAPUserData in https://github.com/GEANT/CAT/commit/328a23ad01c39f18d1458a058fcf5901b39278ad, though we moved to a local Root CA around the same time, so it's possible that prior use of a widely trusted CA masked the issue previously.

Regards,

Robin

--

Robin Breathe
Chief Technology Officer, OBIS, Oxford Brookes University – 01865 483685

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

-- 
Tomasz Wolniewicz    
          twoln AT umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne       Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika         Nicolaus Copernicus University,
pl. Rapackiego 1, Torun                pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576

--

Robin Breathe
Chief Technology Officer, OBIS, Oxford Brookes University – 01865 483685

-- 
Tomasz Wolniewicz    
          twoln AT umk.pl        http://www.home.umk.pl/~twoln

Uczelniane Centrum Informatyczne       Information&Communication Technology Centre
Uniwersytet Mikolaja Kopernika         Nicolaus Copernicus University,
pl. Rapackiego 1, Torun                pl. Rapackiego 1, Torun, Poland
tel: +48-56-611-2750     fax: +48-56-622-1850       tel kom.: +48-693-032-576