Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Radius Login Problem

Description

Login via radius is only possible once.

Person 1 logs in (Login1/Password1), OK
Person 2 logs in (Login2/Password2): Error message.

 

Your log-in attempt failed, please try again.

Reason: Error connecting to radius server: net.jradius.exception.TimeoutException: Timeout: No Response from RADIUS Server

Communication with the Radius Server also takes place for person 2, but the Radius Server does not respond to the third "Access Request". Just as if an incorrect password had been used. (checked with tcpdump)

Test with two browsers and the same user produced surprising results:
Browser 1: Person 1 with Login1 and correct password : OK
Browser 2: Person 1 with Login1 and wrong password: OK !!!

*This means that OpenNMS always takes the password of the first login for all other logins after the first successful login.*

 

Environment

OpenNMS 20.0.0, Ubuntu

Acceptance / Success Criteria

None

Attachments

10
  • 30 Jul 2018, 03:58 PM
  • 30 Jul 2018, 03:58 PM
  • 30 Jul 2018, 03:58 PM
  • 30 Jul 2018, 03:54 PM
  • 30 Jul 2018, 03:54 PM
  • 26 Jul 2018, 01:11 PM
  • 24 Jul 2018, 01:46 PM
  • 24 Jul 2018, 01:45 PM
  • 19 Jun 2018, 02:37 PM
  • 19 Jun 2018, 12:39 PM

Lucidchart Diagrams

Activity

Show:

Markus von Rüden August 6, 2018 at 1:18 PM

It was decided to put it in `foundation` (2015).
The PR for this is here: https://github.com/OpenNMS/opennms/pull/2097

Ronny Trommer July 30, 2018 at 4:00 PM
Edited

Todo: Update example configuration and add a changelog note, cause the radius.xml needs to be changed.

<beans:property name="authTypeClass" value="net.jradius.client.auth.MSCHAPv2Authenticator"/>

Ronny Trommer July 30, 2018 at 3:58 PM
Edited

Was able to test branch https://opennms.atlassian.net/browse/NMS-10212#icft=NMS-10212 and works as expected. Set-up 2 RADIUS server.

  • FreeRADIUS monitored using the RadiusAuthenticationMonitor with PAP

  • Windows Server 2016 RADIUS provided by NPS monitored using the RadiusAuthenticationMonitor with MSCHAPv2

  • Configured the external authentication to authenticate a user against Windows Server 2016 with MSCHAPv2.

  • One service logs in as user3 with password of user2 to verify the login fails

Markus von Rüden July 26, 2018 at 3:59 PM
Edited

provided some infrastructure to reproduce the issue and I was able to investigate the problem code-wise.

First let me point out, that RadiusAuthMonitor and the RadiusAuthenticationProvider are not related.

The problem in fact is, that the RadiusAuthenticators are not meant to be re-used, but the RadiusAuthenticationProvider is doing that.
This means, when using a shared RadiusAuthenticator a once set username and password will not be overwritten with the values from the current request, resulting in making the request with previous values.

This also means as long as the user exists at the RADIUS server making the login attempt will always get the same result as the FIRST user ever logging in to the web console since OpenNMS was started.

For completion's sake here is a code snipped from the net.jradius.client.auth.RadiusAuthenticator#setupRequest(RadiusClient, RadiusPacket) class, which is the base class of all authenticators, e.g. MSCHAPv2Authenticator:

public void setupRequest(RadiusClient c, RadiusPacket p) throws RadiusException, NoSuchAlgorithmException { RadiusAttribute a; client = c; if (username == null) { a = p.findAttribute(AttributeDictionary.USER_NAME); if (a == null) throw new RadiusException("You must at least have a User-Name attribute in a Access-Request"); username = AttributeFactory.copyAttribute(a, false); } if (password == null) { a = p.findAttribute(AttributeDictionary.USER_PASSWORD); if (a != null) { password = AttributeFactory.copyAttribute(a, false); } } }

It clearly shows, that username and password are only set once, and never updated.

The following PR https://github.com/OpenNMS/opennms/pull/2076 attempts to fix the issue.
It is for now targeted to foundation-2018.
can you verify that this fixes the problem?
If so, we need to decide on where to put it in as well (foundation-2017, foundation-2016, etc.)

Jeff Gehlbach July 26, 2018 at 1:59 PM
Edited

Well that's terrifying. Thanks for your diligence in reproducing this, and for reporting it .

Where do we go from here? Upstream to the jradius library maintainers? If so, let's try to find a contact method that gives them some time to work on the problem before it's publicly disclosed.

Fixed

Details

Assignee

Reporter

Sprint

Fix versions

Affects versions

Priority

PagerDuty

Created June 18, 2018 at 2:35 PM
Updated August 8, 2018 at 2:11 PM
Resolved August 8, 2018 at 2:11 PM

Flag notifications