Password Token View

When a password is behind token, users cant even SEE that there is a password entry.

They assume there is not a password in ranger, then create an entry for the perceived missing password after they speak to someone who is authorized to give them the password to the asset.

Long story short, we now have assets with multiple admin passwords. We have different people updating different password entries (based on what they can see) and we have passwords visible to everyone that should be a tokened password, since they can create new passwords without a token.

The duplication and confusion is creating a HUGE problem. People are trying password that don't work, and on and on.

Users with the password manager should be able to see the password entry, even if they cant access the username or password.

Thank you for posting this.

Passwords that are secured with tokens are not visible to users that do not have the relevant token allocated for them, so they can see nothing about it.

Your suggestion to show some indication that there is such a password record while still not allowing any access to it is clear and will be reviewed. Thanks.

Thank you.

Thanks for making me not feel crazy.

Am I the first to ask for this? You should see the number of duplicate passwords we now have.

In a recent exit interview a tech said "There are more password that dot work, than password that do work. it takes too many tries to find the correct password".

I was like ?!? What in the word is he talking about. Then someone showed me all the duplication and i'm like oh no. Who knows which password is the correct one...

We would recommend you to review the usage of tokens.

It seems that the passwords might be "over-protected" and most users cannot access them.
Meaning, if user X is allowed to access passwords of a server, but does not see them listed (because of lack of tokens) then it might be wrong already. In other words, users should be allocated with tokens in a way that allows them to see anything they should see, this way they'll never, or almost never, not see a password record that is there but is hidden because of lack of privileges.

In general the tokens work like any other privilege/permission - once the user has a token, they will see the password that is protected with this token.

Hope it makes sense and we'll be happy to further discuss this with you, if you wish we can also continue the discussion over email as there might be more sensitive aspects to this.

Thanks!

We use tokens for high level passwords and departments. People in the web design have that token and people in the printer dept have that token.

A web design person doesnt have access to printer passwords.

The issue is departments with access levels (like support.) Tech A may not have a token for firewalls, but have the need to access something in a firewall (today) and assume there is no password since there is no one listed. Tech B with firewall access says "here is the password" and teach A adds it assuming its missing. Now there are 2 passwords for the firewall.

Maybe not the best way to do things, but it happens often.

Only current solution is to make it so lower tiers cant add passwords, but that is crazy overburdensome for high level techs.

Thank you for describing your workflow.

Our thoughts on this is that maybe if the person (Tech A) needs the firewall password (or any other password) for their work, they should be granted with access to this password.
In the scenario you described, the firewall password was added anyway, as a duplicate, and it was added without the security token (!).

Maybe blocking users from adding/editing passwords is not the ideal option here, though it seems that high level tech (Tech B) is already involved in this case.

One of the other options you may consider is to use security tokens more granulary, for example, based on the password type (e.g. firewall), instead of based on the department (i.e. support). This method will allow access for some passwords to additional techs from low tier level support, meaning - you'll grant the relevant techs with tokens to see/access the type of equipment they may need. One that needs access to Firewalls will have such a token while someone else that never manages firewalls won't. Anyway, something to think about, maybe you can apply a better workflow with this for your team/s.

Hope this helps!

A password token for every type of device is crazy talk. I would be surprised if ranger could even handle the amount of tokens needed if we tried to set a token for every type of device.