EAP Session problems
Hi, I'm experiencing a problem with EAP sessions/new conversations not starting when I'm using the Janet testing as shown below. https://community.ja.net/library/janet-services-documentation/orps-role-desi... We've run up 2 new pre-prod RADIUS servers with a newer release of freeradius and have indicated they are 'testdev' under our site's eduroam support. When we attempt to login with an account 'username@test.ucl.ac.uk' to our production ORPS we see the request reach our testdev ORPS but it fails to authenticate locally. (We've declared test.ucl.ac.uk as a realm in proxy.conf to be authorised locally to avoid looping back up to the NRPS and back to us etc). It fails with an EAP 'did not finish' (in the style as shown at the bottom section of here http://wiki.freeradius.org/guide/Certificate-Compatibility, the client is linux) failing to see it as a new session. Our certificates are the same on both production and testdev. The other odd behaviour is that despite getting a REJECT from this testdev server, I get authenticated by our production ORPS using 'username@test.ucl.ac.uk' which is not a declared local realm on the production ORPS. If I connect directly to the testdev ORPS it's fine. I've contacted the Janet Service desk but not got anywhere as yet, but they suggested I contact here to. I've attached the debug output (zipped to reduce size). Regards, Emma
On 8 Sep 2014, at 09:18, Cardinal-Richards, Emma <e.cardinal-richards@ucl.ac.uk> wrote:
I'm experiencing a problem with EAP sessions/new conversations not starting when I'm using the Janet testing as shown below.
I'm not sure I fully understand your current configuration - are you saying that you're routing test.ucl.ac.uk from your production radius servers, via the national proxies, back to your pre-production servers? The issue seems to be that your client is responding too slowly:
Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 1 with timestamp +17
Increase the cleanup delay in radiusd.conf and requests should complete - but over 5 seconds is an obscenely long time, things should be much faster. Could you give an overview of where the requests being transmitted to the NRPS are originating from?
The other odd behaviour is that despite getting a REJECT from this testdev server, I get authenticated by our production ORPS using 'username@test.ucl.ac.uk' which is not a declared local realm on the production ORPS.
We'd need to see a log from the production servers to investigate this. Thanks, Adam Bishop gpg: 0x6609D460 Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
On 8 Sep 2014, at 09:18, Cardinal-Richards, Emma <e.cardinal- richards@ucl.ac.uk> wrote:
I'm experiencing a problem with EAP sessions/new conversations not starting when I'm using the Janet testing as shown below.
I'm not sure I fully understand your current configuration - are you saying that you're routing test.ucl.ac.uk from your production radius servers, via the national proxies, back to your pre-production servers?
I believe that's the process of the test as per the guidance from JANET here? This is for testing purposes, not our final configuration. "ORPS Testing Setting an ORPS to testdev allows organisations to bring up a test box and for it to only be sent specific test traffic during logic/rules checking etc. eduroam administrators will need to generate such test traffic themselves, eg. by using rad_eap_test with the username 'testuser@test.youruniversity.ac.uk' to do a 'loopback test' to the new systems. This can be done by using your live systems: 'testuser@test.youruniversity.ac.uk' -> Production ORPS -> NRPS -> Testdev ORPS For this test realm handling facility to work eduroam administrators do NOT have to specifically configure a 'test' sub-realm (eg.'test.youruniversity.ac.uk') in the Realms section of eduroam Support." https://community.ja.net/library/janet-services-documentation/orps-role-desi... I was just concerned that this behaviour would mean our roaming clients would fail to authenticate back to us when they're visiting another institution.
The issue seems to be that your client is responding too slowly:
Finished request 0. Going to the next request Waking up in 4.9 seconds. Cleaning up request 0 ID 1 with timestamp +17
Increase the cleanup delay in radiusd.conf and requests should complete - but over 5 seconds is an obscenely long time, things should be much faster.
Dropping it to 3 seconds fixes it..
Could you give an overview of where the requests being transmitted to the NRPS are originating from?
Sorry do you mean the client? I tested from my Linux (Ubuntu) laptop and my colleagues Windows 7 laptop with the same behaviour.
The other odd behaviour is that despite getting a REJECT from this testdev server, I get authenticated by our production ORPS using 'username@test.ucl.ac.uk' which is not a declared local realm on the production ORPS.
We'd need to see a log from the production servers to investigate this.
Just wondering is this technically correct behaviour (will have to organise a specific time to run it in debug on our live servers..) my 'test' user gets authenticated on my test ORPS so the NRPS tell my production ORPS (as if they are another institution I'm visiting) to allow me on the network? Regards, Emma
Hi,
We've run up 2 new pre-prod RADIUS servers with a newer release of freeradius and have indicated they are 'testdev' under our site's eduroam support. When we attempt to login with an account 'username@test.ucl.ac.uk' to our production ORPS we see the request reach our testdev ORPS but it fails to authenticate locally. (We've declared test.ucl.ac.uk as a realm in proxy.conf to be authorised locally to avoid looping back up to the NRPS and back to us etc). It fails with an EAP 'did not finish' (in the style as shown at the bottom section of here http://wiki.freeradius.org/guide/Certificate-Compatibility, the client is linux) failing to see it as a new session. Our certificates are the same on both production and testdev.
what happens if you just fire requests straight to this new box using another client - eg a linux box with eapol_test or a windows box with JRADIUSSimulator or NTRADping etc? you should be able to test/validate behaviour of packet handling/authentication with another local client (as thats all a remote proxy would be treated as) before opening up to another remote client. you state the above works - so a full radiusd debug of what happends when a local client connects versus what happens when the remote proxy connects should look the same - you need to validate/verify that. alan
Cardinal-Richards, Emma wrote:
We've run up 2 new pre-prod RADIUS servers with a newer release of freeradius and have indicated they are 'testdev' under our site's eduroam support. When we attempt to login with an account 'username@test.ucl.ac.uk' to our production ORPS we see the request reach our testdev ORPS but it fails to authenticate locally. (We've declared test.ucl.ac.uk as a realm in proxy.conf to be authorised locally to avoid looping back up to the NRPS and back to us etc). It fails with an EAP 'did not finish' (in the style as shown at the bottom section of here http://wiki.freeradius.org/guide/Certificate-Compatibility, the client is linux) failing to see it as a new session. Our certificates are the same on both production and testdev.
If you get EAP "did not finish", it's almost always the fault of the client. For this, you'll have to run the server with "-Xx", in order to get timing information.
The other odd behaviour is that despite getting a REJECT from this testdev server, I get authenticated by our production ORPS using 'username@test.ucl.ac.uk' which is not a declared local realm on the production ORPS.
See the debug output on the production servers for why that's happening. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Adam Bishop -
Alan DeKok -
Cardinal-Richards, Emma