This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Reverse authentication problem

Hi all,

I have configured reverse authentication on an utm320 [9.308] for one internal webserver (Microsoft Reporting Services).
I use the form based front end mode and the users are remotly authenticated by a radius server (RSA SecureID Token).
This works quite well unless one problem:
Regardles of the configured session timeout and session lifetime 10-12 minutes after a successful login the user is prompted to authenticate to the frontend form again.
In the user authentication logfile appears the following entries:

2015:03:17-11:48:44 verw-asg320-01-1 aua[20937]: id="3004" severity="info" sys="System" sub="auth" name="Authentication successful" srcip="192.168.130.24" host="" user="myusername" caller="reverseproxy" engine="radius"
2015:03:17-12:02:22 verw-asg320-01-1 aua[18600]: id="3006" severity="info" sys="System" sub="auth" name="Child 20937 is running too long. Terminating child"
2015:03:17-12:02:22 verw-asg320-01-1 aua[23170]: id="3006" severity="info" sys="System" sub="auth" name="Trying 172.25.85.12 (radius)"
2015:03:17-12:02:24 verw-asg320-01-1 aua[23170]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="192.168.130.24" host="" user="myusername" caller="reverseproxy" reason="DENIED"
192.168.130.0/24 is a seperate zone guest wifi - but the issue appears on every external network.

Can anybody tell me if the session timeouts/session lifetime settings do work as expected?

The online help mentions "Caution – When using Reverse Authentication in combination with OTP the OTP tokens will only be checked once when a user session is set up. Once a session is set up, any subsequent request by the same user will not have their OTP tokens evaluated."
That would be my desired behaviour but I think this is just for the internal OTP tokens. Does anybody know if this behaviour can be 'configured' somewhere on the commandline in a configfile?

Regards
Manfred


This thread was automatically locked due to age.
  • Has nobody experienced a similar problem?
  • Manfred, you can use the following command to see what it is now.

    cc get reverse_proxy aua_refresh_interval


    I bet that it doesn't correspond to 13 minutes and 38 seconds though.  Have you checked the log in your RADIUS server to see why it has DENIED the refresh?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

    I've already been playing around with these cc settings
    aua_refresh_enabled$ = 0 (also tested 1) in combination with
    aua_refresh_interval$ = 30 (testet also 1000)
    but it does not seem to change anything - I had put my hope on aua_refresh_enabled$ - it sounds like the setting I am looking for, but .. :-(.

    The Radius server denies the second request because it is a RSA-SecureID-Token and the passcode is only valid for one minute. Thats fine one the first request but after ~10 minutes either the browser or the reverse proxy sends cached credentials and then it fails.

    Regards
    Manfred
  • Manfred, what if you set the 'Session Timeout' to 1 day?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Setting the 'Session Timeout' or 'Session Lifetime' to a long time (I have tested settings up to 24 hours) does not change the behaviour. But that brings me to the idea to set those settings to shorter (e.g 5mins) values to see if that changes the bahaviour or if then the problem happens earlier.

    Regards
    Manfred