Who rated this post

You have something wrong/misconfigured in your LDAP setup.  SecurID/RADIUS/TACACS authentication methods are accessed through an External User Profile object (formerly known as the generic* user), which is always checked after the local user database then LDAP, and this order of operations cannot be changed.  See this screenshot:

When no match is found for the user login name in the local user database, all defined LDAP Account Units (AUs) are queried simultaneously.  They must all respond before the authentication process can move on to External User Profiles and SecurID, or the above timer must be reached.  The most common cause of this is an old or invalid AU specifying servers that are unreachable or no longer exist, if you clean up those old AUs the delay should go away.  If you only have one AU and it appears to be valid, check the defined servers for that AU object and make sure they are correct and reachable.  The delay you are seeing is not normally caused by an LDAP credentials issue since that results in a quick failure; the delay is normally caused by unreachable or invalid LDAP servers defined somewhere in an AU configuration.

If you can't delete the old AUs for some reason, on the above screen you can configure a firewall to query only certain AUs and ignore others (or maybe even shorten the timer), but the best long-term approach is to clean up your AU configuration and/or servers definitions.