Are these any method or function on RSA SecurID that would allowed users from LDAP
using LDAP password instead of PIN by automatic (users don’t need create pin via self service console).
Are these any method or function on RSA SecurID that would allowed users from LDAP
using LDAP password instead of PIN by automatic (users don’t need create pin via self service console).
No.
A users LDAP password is solely to get into self-service if you allow ldap as a method to access self-service.
Or if the user is an admin, to access the security console login with ldap password.
It is not used anywhere else.
It appears to be used for windows agent logins (windows password integration)
but it really isn't the ldap password, it is the password we capture at the time a user actually logs into
windows and stored and treated separately from the actual ldap password
If you require pins for tokens (default setting is require pins for tokens and basically the whole reason this called 2 factor)
-they can be set up ahead of time by the user when they request a new token if you have provisioning enabled in self-service, or they can be set up the first time the token is used for a login somewhere, either at an agent, or at the self-service, or if an admin, the security console login.
kraiphol,
To add to what Ed has said, 2-factor authentication means integrated 2 factors, the something you have (tokenCode) and the something you know (SecurID PIN for that specific Token) integrated in the same system. We think of a PINless TokenCode plus LDAP or AD password as more of two 1-factor authentications, not exactly the same as 2-factor. We think that each of these one factor authentications can be more easily compromised seperatly. And also believe that integrated 2-factor of PIN+TokenCode is more difficult to compromise because both must be compromised at the same time in the same system that tracks both.
If you use the LDAP password as the something you know factor, then you are still exposed to the same possibility that a hacker or bad guy could compromise that password. Hope this helps make sense of this difference. In all honesty, there is some small but noticeable percentage of SecurID customers that do what you propose, but we tell them the same thing and they assume the risk (wittingly or unwittingly).
No.
A users LDAP password is solely to get into self-service if you allow ldap as a method to access self-service.
Or if the user is an admin, to access the security console login with ldap password.
It is not used anywhere else.
It appears to be used for windows agent logins (windows password integration)
but it really isn't the ldap password, it is the password we capture at the time a user actually logs into
windows and stored and treated separately from the actual ldap password
If you require pins for tokens (default setting is require pins for tokens and basically the whole reason this called 2 factor)
-they can be set up ahead of time by the user when they request a new token if you have provisioning enabled in self-service, or they can be set up the first time the token is used for a login somewhere, either at an agent, or at the self-service, or if an admin, the security console login.