Device Fingerprint Rule Breaks after Migration to 5 (SBA) - follow up.

Just following up on a closed post 

Device Fingerprint Rule Breaks after Migration to 5 (SBA)

I had the "Error communicating with the identity server" issue when using a fingerprint rule in a RISK policy.

Bizarrely it depended on the order of the rules, if the fingerprint rule is moved to the top of the list, then the error goes away and the rules all process as expected.

As usual, this may not be anyone elses issue, but worth mentioning in case it helps.

Shame the post was closed (unsolved).

  • 0  

    I've never had much luck getting reliable behavior out of the Fingerprint Rules.  How are you using them?  I have a case open right now on NAM 5.0.4 that is a bug.  I typically use it to prevent requiring a second-factor for some period of time.  The one I opened the case on, I have the rule set to a 1 day time frame, so basically we want users to only have to do 2FA once a day.  We are using the browser cache option for storage.  What we have found is that the rule will work for one day and that's it, afterward, it will never get updated and the user will be required to do 2FA for every single login forever.  The only fix is to clear the browser cache.  Then it works for one day again. I've tested on various browsers and OS's.  I've also seen it in multiple installations as well.  

    Matt

  • 0 in reply to   

    Very similar.  Browser based fingerprint rule set to last for 90 days.  If the rule passes, allow access - if not set the risk to 50 to trigger the 2fa contract.  We then wanted to allow certain users (based on an ldap rule) to skip it totally, so added an 'if ldap rule passes' allow access.  That's when I discovered that it likes the fingerprint rule at the top !  No one has complained that it forces 2fa for every login (after 90 days), but maybe we have that joy to come.

  • 0   in reply to 

    I would suggest testing it to see if it works as you expected.  I tried at another site with 5 days, and we saw the same behavior.  A browser with a clean cache gets the finger print set and for 5 days, all works fine, but after the initial 5 days, the user is required to do 2FA for every single auth forever.  You can see when you turn on finger print debug that it is failing no matter what.  Only option is to clear the browser cache to get it to "start over".  I wonder if the database option would work properly?

  • 0 in reply to   

    I have this problem too. The last_usage_time in device_fingerprint table is not updated when you login with a device registered. So when the valid days (in rules config) expire, you will have to registry the device again.
    And in table risk_usrtransaction the deviceID is not registered when the user login with a device. I am using MySQL. With Oracle Database the risk_usrtransaction not worked.

  • 0

    For anyone interested. Several weeks ago I contacted support because of this thread. They provided a fix. I was not able to test it yet.

  • 0   in reply to 

    I've had a case open for MONTHS and support is telling me there is no fix available yet.

  • 0 in reply to   

    The RBA related jar and class files in the zip provided, 260059_5.0.4.zip, are dated 2023-11-14. Don't know what exactly is fixed, the rule order problem, the validity problem, both, or maybe even something different. If your case is still open maybe you can ask for the zip and let us know the outcome?

  • 0   in reply to 

    I have inquired and they are looking into it (NAM support is like the old telephone game where the message gets relayed from party to party and then we find out how messed up it got at the end, and the relay takes days).  But the difference here may be that I'm not using a database to store the fingerprint, I'm relying on the browser to store it.  That's what is not working properly.  So this patch my not be relevant.

    Matt