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

[Alexander_01_13]

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

[Michael_Koyfma1]

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]

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]

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]

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]

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]

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?