Currently we authenticate users via AD, then enforce the multi authentication ( Approve, Token, Voice etc)
When we see an issue with the RSA cloud ( which I was promised should never happened but I digress), we are forced to log into the radius client itself, and switch from pointing to IDR to point to something else ( such as AD directly)
I would like to see more flexibility for fail open/close type scenarios like this, where the administrator would not need to take any extra steps in order to have users log into the system. I am asking for flexible options as I don't think there will be a 1 solution fits all type scenario.
This means to 1st implement a fail option that can be set per policy. This means when creating a new policy, currently there are sections called
I would propose a 4th section called " Fail Open/Close Options " ( I believe policy is the best place as all devices using the same policy typically would leverage the same fail open/close open, vs doing this in the Radius Client config)
Within the 4th section called " Fail Open/Close Options ", I am proposing these options:
1 - Fail Close - No access to the system if cloud is unreachable ( Some super secret services would want this)
2 - Fail Open
a - Allow Auth via 1st factor only ( in our case a user would have entered their AD credentials and this would allow them in - in our case the device in question leverages certs as 1st factor, and AD creds as 2nd factor)
b - Fall back to internal Access Manager authentication for MFA
c - This option would require the most work on DEV side, but would be the best option for most companies - IDR should function as local Authenticate Token Replica where the token code on the users device can be leveraged. This means the IDR senses the cloud is down, and can respond back to the radius client with a special message " Primary Authentication Cloud is not accessible, please enter Authenticate Token to continue"
d - Allow any other custom directory authentication - can't think of one outside of AD, maybe an option to tie to a different LDAP such as IBM LDAP ( a SAML auth would be far fetched, but this is the RSA Ideas section where anything goes)
thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.