RSA Server Add User Password Field?

[JosephWhite1]

Hello,

Just exported RSA 6 to RSA 8 and looks like that part worked fine.  I have a closed network with  30 users, Windows Domain Controller ect. I'm trying to add a ONE user and assign a token and I'm confused about the PASSWORD field. 

Why would a regular user need a password in RSA, passwords are managed through Domain Controller, they should only need a PIN in RSA server?  Now for the couple of users that can login to the consoles that makes since, but not for everyone else.  For regular users can that password field be left blank?

Thanks,

Joe

[jeffshurtliff]

Hi Joe,

I have moved this thread to the https://community.rsa.com/community/products/securid?sr=search&searchId=7390edd2-8f70-43e1-8a0a-2f6fb41ef999&searchIndex=0‌ page so that you can get an answer to your question.

Thanks,
Jeff

[EdwardDavis]

That password field is something you make up for user in the internal database

(internal identity source), and is the ldap password for the user if the user is found on an

AD connection (external identity source).

It is used for any user accessing the self-service console as a way to log in if they do not have

a token yet, or have problems with a token...etc. So, mainly for self-service console access.

If the user has an admin role it can be used to login to the security console also.

You can edit the identity source in the operations console and make having a password optional....but by default

new users you create have to also have a password.

[JosephWhite1]

Hello,

"and is the ldap password for the user if the user is found on an  AD connection (external identity source). "

So if the user has a password in Active Directory the RSA password is of no use; or should it be the same or different? Very Confusing...

During login the user will be challenged for there  RSA keyfob pin / code  and then their domain password, correct?

Thanks,

Joe

[_EricaChalfin]

Joseph White‌,

To follow on to Edward Davis,  that password field can be confusing.  It's not something that existed in 6.1.  The password defined when editing or adding a user is used by:

• RSA administrators (who, for best practices, should exist in the internal database) to access the Security Console instead of using a token. 
• Regular users that exist in the internal database to access the Self-Service Console if the RSA_Password authentication method is implemented.  Self-Service Console authentication settings can be changed in the Security Console by navigating to Setup > Self-Service Settings > Self-Service Console Authentication.  Check the Authentication Manager online help for information on setting the authentication method for the Self-Service Console.

You can set it to be the same as a user's AD password but it's not integrated at all with AD and is not the same as the AD password.

Out of the box, that password field is mandatory but you can turn off the password requirement for the internal database through the Operations Console under Deployment Cnfiguration > Identity Sources > Manage Existing.  Click on the context arrow next to the internal database and choose Edit.  On the next page under User Configuration, choose the option that the user password is optional and click Save.

External identity sources do not have the ability to make this field optional.

Depending on the device through which your users are authenticating they present their user ID and RSA passcode or their user ID and RSA passcode followed by their AD credentials.

Regards,
Erica

[EdwardDavis]

OK.

1) on security console , where you can edit a user

if this is an AD user the password is already filled in and is the ldap password

if this user is internal database, then the field is either optional or filled in with a password

This password here is ONLY for access to the web pages of the RSA server.

2) LDAP passwords used where a token is used for login.

If you use a token to log in somewhere, and you also asked for an additional password

[ using a windows password or LDAP password ], the RSA server is not doing anything with the users ldap password.

This password is 100% up to the device you are logging into to handle and do lookups on or verification.

It is not the same as the password on item (1) above.

However...there are some RSA agents that can do what is called windows password integration. And

it would appear that RSA is using someones LDAP password, but it really is not. It is using a stored value in

the database that is captured from at least one prior login somewhere. [as mentioned before,

RSA only uses someones LDAP password/RSA password that is on the edit user screen, when accessing one of

the RSA servers own web pages.]

How windows password integration works is:

say you have an ldap user or internal database user, with a token on the RSA server,

and they log into a windows desktop...windows desktop asks for username and passcode,

then the Microsoft password, then you log in.

the agent could capture the password that got you in, and store it on the RSA server next to the

username, and then the next time the user logs into windows, the agent will see if it can fetch the 

stored password and replay it in the background, so the user gets in with the token alone, but

in reality the Microsoft password is being fetched and replayed behind the scenes. If the fetched 

password is wrong, or due to change, the agent allows the Microsoft prompting to pop up

and the user can change it or enter a new one...then again, whatever password lets the user into the

desktop....the agent will try to store it on the RSA server for future replay. NOTE: this is NOT the same

as the ldap password/rsa password on the edit user screen. It may actually be the same 'string' but when using windows

password integration, it really is captured at the login, and stored as an entirely separate database object,

and replayed back to any agent that knows how to do 'windows password integration'. RSA agent for windows

can do password integration and I think some PAM agents can do it too, but when Cisco login or other things

ask for LDAP password they cannot do windows password integration, they need their own connection

to AD to verify the password is correct.