Forum / Password Vault Manager - Bug Report

User doesn't get the appropriate rights

  • Create an Issue
  • Cancel

Hi,
I tried to create another user in a SQLServer database. I used the sa account of SQLServer and I selected 'Create SQL Server Login and User'.

After creation I grant the user a role which has access on the appropriate security groups. The user can see all the information he is supposed to see but when he tries to create an entry he gets the following message:

passwordVaultError

Can it be that something goes wrong with the grants when you create a new user?
Is there a workaround?
Kind regards,

Peter

passwordVaultError.png
Clock6 yrs

Hi

This is at the heart of our security system, Its possible there's a bug, but we would have received a ton of bug reports

Can you go in Help - View Application Log on the workstation you used to create the user, try to find a relevant error message.

Can you delete it and recreate it? You should have a notice that the user already existed and that the password could not be set, but that's what we would expect.



Maurice Côté

signaturesignature

Clock6 yrs

Hi,

In the application log I don't see anything. The bottom shows:


[14/04/2014 10:25:34]ERROR SILENT System.DirectoryServices.AccountManagement.PrincipalOperationException: The referenced account is currently locked out and may not be logged on to.
---> System.Runtime.InteropServices.COMException (0x80070775): The referenced account is currently locked out and may not be logged on to.

at System.DirectoryServices.AccountManagement.UnsafeNativeMethods.IADs.Get(String bstrName)
at System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(String target, String userName, String password)
--- End of inner exception stack trace ---
at System.DirectoryServices.AccountManagement.CredentialValidator.BindSam(String target, String userName, String password)
at System.DirectoryServices.AccountManagement.CredentialValidator.Validate(String userName, String password)
at System.DirectoryServices.AccountManagement.PrincipalContext.ValidateCredentials(String userName, String password)
at Devolutions.RemoteDesktopManager.Managers.LockManager.ValidateIntegratedSecurity(String username, String password)


And indeed this morning I locked my own account due to azerty/qwerty mix up. But now I cleared the log, closed it and recreated the account.

The message about the password did indeed show up so I ignored it.

Behavior is still as before however. He gets the error from previous post. Strange thing is that he doesn't see its new entries not even when he refreshes (F5) but when he restarts the vault he does see the entry. But I (administrator) cannot see the entries he created.

When I inspect my log (administrator that created the user) it is still blank.

I attached the logfile of the user.
Kind regards,

Peter

logfile_user.txt
Clock6 yrs

Hi

Can you have the user go in File-My Data source information and use the envelope icon to send us the information?



Maurice Côté

signaturesignature

Clock6 yrs

ok, everything looks normal on that end

Are you able to run the following query in the database?

SELECT Us.name AS username, Obj.name AS object, dp.permission_name AS permission
FROM sys.database_permissions dp
JOIN sys.sysusers Us
ON dp.grantee_principal_id = Us.uid
JOIN sys.sysobjects Obj
ON dp.major_id = Obj.id

The user should have DELETE, INSERT and UPDATE permissions on the Connections table. Please send me the results via PM



Maurice Côté

signaturesignature

Clock6 yrs

ok, figured it.

While working on another feature, I ran into a symptom that turned out to be caused by the same problem, it helped me understand the root cause.

Our roles feature is shared by the MSSQL and RDMS data sources. And because of architectural reasons there is a subtlety that requires us to grant the "public folders" permission in order to be able to insert/update/delete anywhere in your tree.

The "public folders" permissions are at the top of the user permission grid.

image

I always recommend to check the "deny add entry in root folder" for most organizations.

You will have understood that the db permissions on the appropriate tables are driven by these checkboxes. The roles, on the other hand, are resolved by our business layer.

I'm sorry for the delay in identifying the cause, I will update the documentation and I have to fix a few tutorials as well.

Best regards,



Maurice Côté

signaturesignature

Clock6 yrs

Hi Maurice,

Thanks for your reply.

But I am not sure I understand your post (screenshot doesn't show and I think this was to show the solution). Is this a grant I need to do on the DB or on Passwordvault?

Or are the public folders permissions , the "Add" , "Edit" and "Delete" on top of the permissions grid? Because I give these in a role but I need to give them on user level as well?


Kind regards,

Clock6 yrs

exactly, you need to give them in the user permission screen, not in the roles.



Maurice Côté

signaturesignature

Clock6 yrs

Thanks, this is indeed working!

Clock6 yrs