Forum Discussion

Alexander_01_13's avatar
Alexander_01_13
Icon for Nimbostratus rankNimbostratus
Jan 10, 2014

Security issue using two different authentication methods with the same ntlm domain (SSO)

Hello fellows,

 

I have run across a security issue with two web servers using the same ntlm domain for authentication (APM) on our F5 BIGIP Version 11.4.1.

 

ServerA contains critical information and may be accessed only using token based two-factor-authentication and windows authentication.

 

ServerB contains non-critical information that may be accessed using windows authentication with the same ntlm domain as ServerA.

 

Now, the problem is that after authenticating with ServerB no password nor token-code will be asked from the user when he connects to ServerA. He will be logged on without bothering requests! So, users bypass two-factor authentication if they log on to ServerB first. This is kind of security issue.

 

How can I achieve the following: A session cookie for ServerA may be used for SSO to ServerB, but a session cookie from ServerB does not provide access to ServerA?

 

Second best would be to oblige the users to log on to both servers separately.

 

Thanks for help! Alex

 

BIG-IP Access Policy Manager (APM)
deployment
microsoft
security
  • Michael_Koyfma1's avatar
    Michael_Koyfma1
    Icon for Cirrus rankCirrus
    Jan 10, 2014

    Are you using two different polices here? Else are you branching out the authentication schema for the policy evaluation based upon host header/URI? How do you end up in a situation where you would not use two-factor authentication to APM?

     

  • Alexander_01_13's avatar
    Alexander_01_13
    Icon for Nimbostratus rankNimbostratus
    Jan 10, 2014

    Yes, two different policies.

    Would branching out based upon host header solve the sso problem? Still, a session cookie obtained logging on to ServerB would sso to ServerA, wouldn't it?

    After a look at the session variables I found the following useful: In a two-factor authenticated session the variable 

    session.securid.last.state
    has the value 
    SECURID_AUTH_STATE_ACCESS_ACCEPTED
    . So, in an iRule I have to check that this variable is set and if not I will redirect to the login form.

    Good idea?

    Regards, Alex

    • Michael_Koyfma1's avatar
      Michael_Koyfma1
      Icon for Cirrus rankCirrus
      Jan 12, 2014
      Yes, that's certainly a good and easy approach - check for the existence and value of that variable.. However, if you have two different policies why would this matter? Each policy would execute separately, unless you are setting a domain cookie -is that what you're doing?
  • Alexander_01_13's avatar
    Alexander_01_13
    Icon for Nimbostratus rankNimbostratus
    Mar 06, 2014

    Yes, domain cookie. And I would appreciate that after authenticating with password&token I am also sso'ed to the sites that requires only password.

     

  • Alexander_01_13's avatar
    Alexander_01_13
    Icon for Nimbostratus rankNimbostratus
    Mar 06, 2014

    So, getting physical... I would need some help setting up an irule, as I am a miserable programmer...

    The steps of the script would be:

    1. detect that there is a request from an existing session
    2. verify that 
      session.securid.last.state
      has the value 
      SECURID_AUTH_STATE_ACCESS_ACCEPTED
      .
    3. if yes: let it pass on
    4. if no: redirect to apm logon page

    This irule would be attached to the virtual server with the securid requirement.

    Anybody a draft for a script that I can start from? O:-)

    Regards, Alexander

  • Alexander_01_13's avatar
    Alexander_01_13
    Icon for Nimbostratus rankNimbostratus
    Apr 11, 2014

    Finally I got the leisure to put together an irule to check for a successful rsa authentication on the critical server and to kill the session in case there is none.

    when HTTP_REQUEST {
    set rsastate [ACCESS::session data get "session.securid.last.state"]
    if { $rsastate != "SECURID_AUTH_STATE_ACCESS_ACCEPTED" } {
            ACCESS::session remove
    }   
}

    Question: Would it be more efficient to use another event than HTTP_REQUEST?