Hello everybody!
Is there any possibility to handle a scenario when Oracle DB which is used for authentication and authorization becomes unavailable?
I've checked the reference guide and found the following:
//
The [Failure] section of the SQL authentication header file can be used to determine theresult of the authentication process (accept or reject) when connectivity to all of theconfigured SQL databases has failed. For example:[Failure]Accept = 1Profile = XYZFullName = Unauthenticated!_
//
So, the question is: what if I should use different Profiles in my environment?
Let's imagine we're using a BNG and SRC-PE. We can't use same profile for BNG and SRC-PE as these devices
are expecting different attributes in Access-Accept messages.
The other option is to include all the attributes that are required for both BNG and SRC-PE into the profile which
is used in case of failure. Will it work??
Thanks in advance.
Solved! Go to Solution.
Yes, you are correct.
If you separate the authentication based on the source (BNG or SRC-PE) then you can define each with its own connection to the database and its own failure profile.
You may want to look at Configuring a Directed Realm and _Configuring SQL Authentication in the admin guide for an overview on how to set those up. For specific settings in each of the files you should use the Reference Guide.
Good luck and don't hesitate to post if you have some more questions.
Default section can take only one value for the profile.
Yes, you need to have a default profile with common attributes defined.
Another option would be to separate the authentication with Directed Realms. That would allow you to have one Oracle method to authenticate BNG and another to authenticated SRC-PE.
If you need help configuring the Directed Realms, you might want to open a JTAC case.
_Hello gentlemen!
Thanks a lot for your replies.
Now then I can define separate failure scenarios for these two Oracle methods, right?
And each profile may use different attributes, correct?
Actually I'm not familiar with SBR. We haven't reached a staging phase so I'm just trying to figure out which failure scenarios we may handle with SBR.
Yes, you are correct.
If you separate the authentication based on the source (BNG or SRC-PE) then you can define each with its own connection to the database and its own failure profile.
You may want to look at Configuring a Directed Realm and _Configuring SQL Authentication in the admin guide for an overview on how to set those up. For specific settings in each of the files you should use the Reference Guide.
Good luck and don't hesitate to post if you have some more questions.
Hello everybody!
Now I've got a working testbed and I'm trying to test SBR's behaviour in case of Oracle Database unavailability_.
It happens that a new subscriber cann't be activated in this scenario as MX receives Access-Rejects from the SBR.
Here's the contents of FAILURE section of the "radsql.aut" file:
[Failure]
Accept=1
Profile=iDNetMotor
FullName=unknown user_
I should mention one thing: same profile (iDNetMotor) is used for suscribers in a regular scenario when
Oracle DB is available. It defines a service bundle and Virtual Router Name.
Log is attached.
Thanks in advance,
Evgeny
Gentlemen, does anybody know whether a Native User named "unknown user" should be created in my case inside SBR itself?
Guys, FYI
this scenario actually works.
After connectivity between SBR and Oracle was lost
new subscribers were authenticated using FAILURE section.
When Oracle goes back online, SBR is authenticating new subscribers using regular Oracle authentication procedure.
Hello everybody!
I've got a last question. We also pass accounting info to the Oracle DB using SBR.
So when DB goes offline accounting info is not stored anywhere.
Can it be stored locally on SBR in case of DB unavailability?
You have the option to enable the local accounting, by which RADIUS accounting attributes will be logged to a comma-delimited text file by SBR.
The accounting file contains information that controls_ the above.
In case of realms, you need to specifically enable RecordLocally_ configuration parameter in the respective _[Acct] Section_ of realm configuration files.
How-ever I want to highlight that recodlocally will be active all the time, irrespective whether the back-end DB is available or unavailable.
Thanks