Security

Anyone seeing this issue today? Service fails to get data from Insight database. Users unable to authenticate.

<p>Anyone seeing this issue? Just started today. Been working fone for weeks, but as off today noone can authenticate after captive portal. Service fails to pull the required data from the Insight datbase.</p>

Failed to construct filter=SELECT EXTRACT(EPOCH FROM (NOW() - timestamp))::integer AS seconds_since_auth, ((EXTRACT(EPOCH FROM (NOW() - timestamp)))/60)::integer AS minutes_since_auth, ((EXTRACT(EPOCH FROM (NOW() - timestamp)))/3600)::integer AS hours_since_auth, ((EXTRACT(EPOCH FROM (NOW() - timestamp)))/86400)::integer AS days_since_auth FROM auth WHERE auth.timestamp < NOW() AND auth.error_code = 0 AND auth.auth_username = '%{Endpoint:Username}' ORDER BY timestamp DESC LIMIT 1.
Failed to get value for attributes=[Days-Since-Auth, Hours-Since-Auth, Minutes-Since-Auth, Seconds-Since-Auth]

Check to see if all the services are running.

@ HeyEddie

Do you recall why you were getting the error message "Failed to construct filter". I know with the Days-Since-Auth you have to have the Insight option enabled under the Server Admin.

The reason why I ask is that I was working with custom SQL filters and they work in my lab environmnet, although trying to apply them into production we keep seeing the error "Failed to construct filter". 

This only relates to the SQL filter that is happening. With the same code in the lab as production we dont have any issues. Currently in production we are also using Days-Since-Auth.... and its working as intended. 

So we know the insight option is enabled in our situation, although for some reason we are still seeing this odd errors with failure to construct. I may have to engage aruba to get me admin access to validate the SQL tables are present. 

I was just wondering what your outcome was, I know its been a while since you posted this question. 

Thanks!

I would like to know what the resoultion was as well. I just started getting the same error. I believe it has something to do with the HTTPS server certificate.

@ChadinTX

The best way to review what the root cause on this is to look at the Summary page via Access Tracker, to see what type of auth method is being applied. 

Since the Days-Since-Auth is typically used with a Captive Portal (L3) and MAC Auth (L2) authentication. Any L2 auth will attempt to happen before L3 Auth. If the user has not passed the captive portal authentication, or the retention rate for insightDB was not extended and the data was purged (depends how many days you are doing mac caching for). We will see this error. 

In the end it just means that the data was not presented via the insightDB, and the only way to get this data inside insightDB is to have the user pass captive portal authentication. 

I have included a screenshot that I had generated in the past via insightDB, and you can see that Item #3 shows the email address (backed out) for both username fields. This is where I was able to validate that the L3 auth was being passed. Once the L3 auth was in place, and insightDB has the data the user should not get any errors about the days-since-auth not being calculated. 



I dont have the exact colums as what I used to make up the report, although with a little work you can probably take this data and go through the options and review what would be needed with the client info from Access Tracker and this to build your report. 

Hope this info helps! 

Justin