[OPENAM-7054] RADIUS Server Does not Start After Initial Install Without a Web Container Restart Created: 06/Oct/15  Updated: 18/Jun/18  Resolved: 18/Jun/18

Status: Resolved
Project: OpenAM
Component/s: other
Affects Version/s: 13.0.0, 13.5.0
Fix Version/s: None

Type: Bug Priority: Major
Reporter: David Goldsmith Assignee: Jamie Bowen
Resolution: Won't Fix Votes: 1
Labels: AME, Backlog, release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Relates
relates to OPENAM-8057 ServiceConfigManger returns wrong bas... Open
relates to OPENAM-6680 Audit configuration in invalid state ... Resolved
Sprint: Sprint 102 - Team Newton

 Description   

Currently, after I do a clean installation of OpenAM and attempt to enable the RADIUS Server service, the RADIUS server is not enabled until I restart the web container.

Once it's enabled, I can disable and enable it with o problems; it's just that first RADIUS server startup that's the problem.



 Comments   
Comment by Jamie Bowen [ 09/Oct/15 ]

I see the same issue. Thanks for reporting David.

Comment by Jamie Bowen [ 09/Oct/15 ]

It looks like this is a bigger issue, and may be a dupe of OPENAM-6680

Comment by Jamie Bowen [ 09/Oct/15 ]

These two look to be related. Possible Dupe?

Comment by David Goldsmith [ 13/Oct/15 ]

Good news. I have now experienced this symptom after modifying the server configuration well after the first startup.

I'll dig around a little and see if I can replicate the problem.

Comment by David Goldsmith [ 13/Oct/15 ]

I think I figured out how to replicate the problem two ways:

  • Configure the RADIUS Server service with a correct configuration
  • Test with the test client, should be OK
  • Delete the chain from the configuration
  • Test with the test client, should reject the authentication attempt
  • Restore the configuration so that it is the correct one again
  • Attempt to authenticate - it hangs unless you restart the web container

or similarly:

  • Configure the RADIUS Server service with a correct configuration
  • Test with the test client, should be OK
  • Delete the realm from the configuration
  • Test with the test client, should reject the authentication attempt
  • Restore the configuration so that it is the correct one again
  • Attempt to authenticate - it hangs unless you restart the web container

So apparently there is some problem when you mess around with the Handler Class Configuration Properties field in the client configuration. Deleting properties form this field seems to be OK but when you add properties it appears to cause hangs. This would also explain why you have to restart the web container after you initially configure the RADIUS Server service - you're adding values to the Handler Class Configuration Properties field.

Comment by Jamie Bowen [ 06/Jan/16 ]

I think I have a fix for this.

Comment by Jamie Bowen [ 07/Jan/16 ]

Originally in my RADIUS server the ServiceConfigManager was created by Guice and injected into the classes that required it, meaning the same ServiceConfigManager was always used. In case this was the wrong usage pattern (there is no class level doc in ServiceConfigManager to indicate usage patterns) my 'fix' consisted of changing my code to inject a ServiceConfigManagerFactory. Every time config is updated and the RADIUS server now uses this factory to obtain a new instance of the ServiceConfigManager, and then obtain configuration.

I thought this fixed things, and indeed after a fresh install activating and deactivating the RADIUS server via config worked, which led me believe I had a fix. However, as soon as I created a sub config to describe a client that might connect to the radius server, the root config stopped updating correctly. The values returned from the ServiceConfig, obtained from the ServiceConfigManger now always returns the same value for the main config as was set at the point at which the sub config was created.

After a restart of the container you can then change root config values again and all is well.

Peter Major [X] - I've been told you may be able to shed light on ServiceConfigManager and its intended usage patterns?

Comment by Jamie Bowen [ 07/Jan/16 ]

And I've just confirmed that the exact same behaviour existed before my 'fix'. So to sum up, the root global config (enabled, port & thread pool settings) can be changed fine after initial install, until such time a sub configuration is created and then the ServiceConfigManger will always return the settings that were in place when the root global config was created.

I probably have terminology wrong for root global config?

Comment by Jamie Bowen [ 07/Jan/16 ]

So it looks like this is an issue down in the SMS layer. I don't fancy my chances of getting this fixed and satisfactorily tested in the next couple of days (I'm out next week, then we release). What do we want to do with this?

I think I should create a new bug describing the SMS behaviour and link this one too it. Thoughts please Jonathan Scudder & Neil Madden?

Comment by Neil Madden [ 07/Jan/16 ]

Jamie Bowen Yes, please raise a new issue and link it to this one, then we can discuss at the triage.

Comment by Jamie Bowen [ 07/Jan/16 ]

First pull request (https://stash.forgerock.org/projects/TEMPER/repos/openam-functional-tests/pull-requests/88/overview) merged to prevent the RADIUS tests causing failures.

Will raise a new bug as suggested and link to this.

Comment by Keith Daly [ 20/Jun/16 ]

After initial configuration, the system had the opposite behavior from the UI. (Enabled = YES disabled RADIUS; Enabled = NO enabled RADIUS.)

Restarting the container while the services was enabled corrected the condition and Enabled = YES now enables RADIUS.

(UI Screen is: Configuration --> Global --> RADIUS Server)

Comment by Alex Levin [ 23/May/17 ]

Seen in 13.5.0 too. Had to restart to get radius server started which is not what the docs say.

Generated at Sat Oct 31 01:57:31 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.