Hi,
When duration lockout is enabled in realm, the journeys doesnt have a way to identify if the account is locked out. As the two possible nodes, Account Active Decision and Data Store Decision nodes return success for a locked user when valid credentials are provided. This causes the journey to not fail at that point and continue to due further flow such as 2FA for example, before failing at the end of the journey when the error message is triggered by the realm based lockout.
Have anybody came across this and possible solution for this?
In the below journey, the Dummy step gets executed for a lockedout user, when a valid password is provided.
Thank you
Greetings!
The LDAP Authentication node provides a unique outcome mapping to the “locked” state.
Please see LDAP Decision node :: AM 7.5.0
1 Like
@guy.pensa Thank you for the update. This definitely helps. Only concern being, the Data store decision provides native integration with the Identity store configured on the realm and does not require node specific configuration to the LDAP. Whereas the LDAP decision node appears to be to interact with external LDAP rather than the native user store configured in AM.
In other words it would a good feature, to have the other outcomes mapped on the native Data Store Decision node. I am thinking about doing a custom node that does the lockout validation by reading the lockout status from the sunAMAuthInvalidAttemptsData to overcome this.
Or, a different perspective:
As the implementation of the configuration of the “Identity Store” is an implementation of the LDAP adapter;
The LDAP Authentication node allows for purposeful, advanced configurations not exposed by the “Identity Store node” and of significantly more value.
Moreover, why customize what is available ootb? You would then be committed to a continual development and management effort… which is not needed.
I might have misquoted it (not a custom node), its just a scripted decision node, that reads the attribute and checks the lockout status for duration lockout. Introducing the ldap node, has challenges around deployment, where the environment specific values for the DS needs to be accounted for, whereas the Data Store Decision node leverages the already in place realm configuration.
Sure… or use the ootb functionality… It makes no difference to the realm, only the authentication tree. Your choice of course.
Cheers!
1 Like
agree @guy.pensa, this is the best approach for most scenarios. For our scenario, I have to engage with a team that is responsible for handling AM infrastructure to get the ldap attributes for the LDAP Decision node dynamically populated specific to the environment and integrate it into the CICD pipeline. Hence the different direction.
Quick update. Apparently this feature is available in AM versions 7.1.3 and above. Where the Data Store decision node supports both persistent and duration lockouts.
