Security

last person joined: yesterday 

Forum to discuss Enterprise security using HPE Aruba Networking NAC solutions (ClearPass), Introspect, VIA, 360 Security Exchange, Extensions, and Policy Enforcement Firewall (PEF).
Expand all | Collapse all

External Authorization SQL - Timeout

This thread has been viewed 3 times
  • 1.  External Authorization SQL - Timeout

    Posted Oct 26, 2018 11:44 AM

    Hi there,

     

    I'm currently using an external authorization source running on MSSQL.

    I set the timeout to 2 seconds. This is just being used for authorization.

    The problem I'm facing is that if the server goes down all authentications are rejected, and on the logs I see "authorization took 15 secs".

    Unsure why it is showing that 15 seconds and not the 2 seconds I set.

     

    Any ideia why?

     

    Thanks



  • 2.  RE: External Authorization SQL - Timeout

    Posted Apr 11, 2019 04:31 PM

    I'm also having this issue though mine is 30 seconds. ideally if the SQL server is not available, then that role mapping should fail but it shouldn't timeout the whole authentication process.

     

    Does anyone have any insight on this? I'm also only using it for authorization and not authentication. This is pretty critical for my customer (they are using LANdesk).



  • 3.  RE: External Authorization SQL - Timeout

    Posted Apr 12, 2019 02:07 AM

    The short and skinny of this is that if any of the authorization sources are offline, then the entire authentication attempt will fail. I certainly wish there was an option to toggle this per source but alas no such option exists.

     

    I was however able to add some fault tolerance to this setup:

     

    I ended up mirroring the existing service/role mapping and enforcement profile of the primary 802.1X service which is performing the external SQL checks.. I also created a few new endpoint attributes:

     

    Is-Cached - a boolean value
    Cache-Expiry - Date-Time value
    SQL-Exist - a boolean value

     

    I renamed the "copy of" service to "802.1X - Cached". I then added a service condition to look for the Is-Cached endpoint value of "true" (by default it's false) and positioned the new "Cached" service above the primary. I then created some post authentication enforcement profiles: "Is-Cached - True", "Is-Cached - False", "SQL-Exist - True", "SQL-Exist - False" and an update for the Cache-Expiry timer ([Time Source]:One Week DT).

     

    The essential logic is that for the primary 802.1X service, under every condition enforcement, I both mark Is-Cached as True and update the Cache-Expiry timer. In this instance, under normal conditions, the primary service will hit every week per endpoint and query the external SQL sources per usual. If a match is made against SQL, I update the SQL-Exist value to True. When the endpoint reauthenticates, it should hit the cached service that I positioned above the primary due to the Is-Cached value now being true.

     

    Under the cached service, I removed any reference to the external SQL authorization sources and instead relied on the endpoint SQL-Exist attribute to determine if the endpoint was found in SQL when it was last checked against the live servers. I also added an additional check (set first) in the enforcement policy so that if ([Time Source]Now DT) is less than Cache-Expiry I then assume the timer I defined has expired and I update the Is-Cached value to False and terminate the session. This forces the endpoint back through to the primary service and perform their SQL check again against the live servers.

     

    Obvioulsy multiple SQL servers would be much more simple and preferred in this case. In my example however that wasn't an option. It's acceptable in my scenario that the external servers are only getting checked weekly for each endpoint.