Hi Benedikt,
thank you for the feedback. Here are some thoughts why we think this could actually lead to more issues:
First, the data model we use has special "fields" for sensitive/protected data. For example, when you enter something in the password field, the password will never end up in clear text in a document - even if the document is not password protected itself.
If we remove access to those fields, users will ultimately use other fields to remember their passwords (e.g. Custom Fields or Properties). In this case, the password may actually end up in a field which is not protected which then end up in clear text in the document.
You can't really prevent users from putting passwords in other fields. You can't prevent users to put passwords in a text document using notepad.exe or somewhere in an Excel spreadsheet. So what you are asking is not really a solution to a technical problem, it's more an organizational issue. What you can do is to use our password analyzer regularly to see if someone put a password in a document he isn't supposed to:
https://royalapps.com/blog/new-feature-password-analyzer
Regards,
Stefan
We have a similar issue, that users are accidentally creating credentials objects in our shared file, instead of their personal files.
My guess is, this happens when they try to connect to a server, where they don't have a credentials object for and then select the “create credential object” box, thinking it is something like “don’t ask again”…what it is…in a way…
It would be nice to have the option to block certain object types on the document level. Even if it’s just "soft", it could prevent accidental creation of sensitive objects.
Regards,
Roman
Hi Roman,
can you check the following:
Let me know if this helps.
Regards,
Stefan
I just tried PolicyDoNotAllowCreateCredentialObjectsInDocumentsWithoutPassword and it works as expected when I try to create a Credential with right-click->Add or Menu->Add.
It does not catch attempts to create the Object with the Credential Picker.
I tried right-click on a server -> Connect with Options -> Ask for Credentials -> Connect and then in the Credential Picker “Specify username and password” and “Create credential object”. That’s exactly what I don’t want to have.
Also moving
a credential from a encrypted document to an unencrypted one is possible.
(what I personally would consider as a feature, because it has to be done on
purpose)
Regards,
Roman
I think I found an issue where this checkbox is mistakenly enabled even though the policy has been set. Please check the next release if this has been resolved. Thanks!
Strack, Benedikt
Hello,
in my company we want to block the possibility to sace credentials in the connection files. I found the policy "DoNotAllowCredentialObjects", but that policy does not block the option in the connection files, just for the credential object you can create.
The goal is, to block that the users can safe any credentials in the application or local somewhere, so all credentials are safe stored in our password safe. (Sure, you can´t block normal text fields/files, for example...)
A Lockdown for the shared document is not possible, because we are using the pleasant password safe, and its not working withh the dynamic folder, when the document is in lockdown.
ACL is a possibility to forbid users to edit the file and enter credentials, but that will need way more work to manage, because the files need to be edit sometime.
As I see that, the easiest way to block that, would be a policy that delete or block the option in the drop down menu in the credential tab in the connection file.
If someone already found a way to do that, please let me know.
Kind regards!