Unable to save the user in the database

Could you get me the error message from the application logs?

Help -> View Application Logs -> Report tab -> "Send to support"

Please add "Attn: Stefane" to the message body.

Thanks,

Hi Stefane,

I have sent you the application logs.

Thanks.

I am getting the same error message so would like to know the answer when you have it.

hi!
i got the same error. to reproduce here is what i did (using 10.0.4.0):

i wanted to get rid of the users and have the settings set via the groups they are members of.
please let me know if this is just the wrong way i'm doing it or if it's a bug.
thanks in advance!
KR
Guenther

@Guenther - You are not connecting to an Azure SQL are you? I'm assuming local SQL Server instance correct?

@Nick Terry & @davidl - I'm working on it, should have something in the next beta build. The issue at hand here is if you create new admins with an Azure DB, the DB security permissions given to this new admin doesn't allow for the user to create other users (ie: "Grantor does not have GRANT permission", "Reference to database and/or server name in 'master.dbo.syslogins' is not supported in this version of SQL Server"). In the past the recommendation was to create/manage users using the "main" SQL Azure account (the one created by MS when you created the Azure SQL Server instance), other (newer) admins could do anything else as long is it didn't involve "users".

This should all be resolved in the next build, I will post back when the build is available.

Regards,

Thanks

correct, we are using a local SQL server instance.

@Guenther Schmitz - could you please send us you application logs?

@Nick Terry & @davidl - I'm still working on it, it's more complicated than expected.

@Guenther Schmitz - You will need to give TESTDOM\testgroup read/write access to the RDM database. When using roles in this manner, when "testuser" first logs in needs to create a row in the UserInfo table of RDM, this is failing due to not having the proper rights on the DB.

It's done. The documentation has to be updated so I will detail the changes here.

The main issue is that we did not support admin right chaining (admin A creates admin B that creates admin C...). So if you wanted to create an RDM admin you needed to create them using an already "admin" SQL user, 'sa' for local SQL or you main Azure SQL user for example. This has now be resolved but not without some constraints.

I will outline an Azure SQL case; GRANTS, ROLES & steps to configure. First create a data source using the user created by Azure SQL when you created the server. This user has "full SQL Azure" privileges, what ever that means. It actually has some limits when it comes to SQL but we can get around that. We will use this user to create our second admin via the RDM UI. Doing this execute the following SQL statements:

SQL Azure master db:GRANT ALTER ANY USER TO [XYZ] WITH GRANT OPTION;

GRANT ALTER ON ROLE::dbmanager TO [XYZ] WITH GRANT OPTION;
GRANT ALTER ON ROLE::loginmanager TO [XYZ] WITH GRANT OPTION;

EXEC sp_addrolemember 'dbmanager', 'XYZ';
EXEC sp_addrolemember 'loginmanager', 'XYZ';

GRANT ALTER ANY LOGIN TO [XYZ] WITH GRANT OPTION;SQL Azure RDM db:EXEC sp_addrolemember 'db_owner', 'XYZ';

GRANT SELECT, INSERT, DELETE, UPDATE TO [XYZ];

GRANT ALTER ANY USER TO [XYZ];Given these statements user XYZ can now create an admin and grant them enough privileges to keep the chain going.

Note: if admin A creates admin B that creates admin C. Now if you user A removes admin rights from user B, in this case we don't revoke the rights in the DB since this would cause admin C to loose it admin rights since the chain would be broken. In this case we block user B from doing admin type stuff but the rights in the db are preserved. This is important since it could introduce a security hole if this user connects directly to the database it could make itself admin again through the db. This can be resolved with the following statement:

SQL Azure master db:DENY ALTER ANY USER TO [adminB] CASCADE;

DENY ALTER ON ROLE::dbmanager TO [adminB] CASCADE;
DENY ALTER ON ROLE::loginmanager TO [adminB] CASCADE;

EXEC sp_droprolemember 'dbmanager', 'adminB';
EXEC sp_droprolemember 'loginmanager', 'adminB';

DENY ALTER ANY LOGIN TO [adminB] CASCADE;In this case you will now need to fix adminC. RDM can help with this. Using admin A, edit the admin C user and hit OK, this will fix the grant chain. Now AdminC user has its grant chain attached to admin A and no longer admin B.

Confused? Does this make any sense? Hope it clear enough...

Changes will be in the next beta build.

Note: local SQL (non Azure) the GRANTS are somewhat different but server the same purpose.

Best regards,

We have a new version available:
http://download.devolutions.net/Devolutions.RemoteDesktopManager.Bin.10.0.18.0.zip
http://download.devolutions.net/Setup.RemoteDesktopManager.10.0.18.0.exe

To start make sure you connect using the "main" admin and for each admin user (other than the main) select, click edit, click OK. This will make sure all rights are properly applied. Then all should be good.

Best regards,

Hi Stefane,

Thanks for your work on this. I have finally had a chance to look into it properly. I still get the error even with the latest version. However, I suspect this is because I haven't followed your instructions exactly as I'm a bit confused with what is going on.

What I have done however is to start from scratch and have been able to create a fully working SQL Azure instance by doing the following. By logging onto the Azure SQL server master database via the web portal with the initial 'account creation' SQL login I:

- Created a new login for the Azure SQL server

- Created a user from that login for the Azure SQL server master database

- Created a new database on the Azure SQL server to hold the RDM entries

- Created a user from the login created earlier for this new database

- Granted that user the db_owner role for this database

- Created a new connection in Remote Desktop Manager entering the Azure server name, the server login created in the first step and the name of the database created in step 3

- On the upgrade tab clicked the 'Update Database' button to create the RDM tables

After doing the above I was able to connect to the Azure instance and start creating and removing entries.

I did a bit more testing and have noticed that you can't re-use an existing SQL server login with a new database. For example, I followed the steps above but instead of creating a new login in step 1 I re-used the existing one I created. If I don't create a new login I get the following error:

'Unable to save the user the database!'

'Invalid object name 'sys.sql_login'

Any reason for this?

Also, is there any advantage to letting RDM create the database for you in the Connection Manager window? I notice that if I let RDM create the database it uses the old 'Web/Business' tiers types instead of the new 'Basic/Standard/Premium' tiers.

Finally, is granting the 'db_owner' role giving too many permissions to the RDM database user and would read/write permissions be sufficient?
edited by nickterry on 12/29/2014

I will need to investigate this to figure out what is going on.

I will change RDM, you are correct we should be creating Basic/Standard/Premium databases. We should probable even prompt for the azure DB tier and max DB size.

db_onwer is only granted to RDM Admins, the users needs enough SQL rights to grant/revoke rights when creating/modifying other user (admin and non-admin).

I still/also have this issue.

While in the phase of documenting RDM for the team, I deleted a user from the RDM - User And Security Management window.
When I tried to re-create the same AD-integrated user, I get the following error messages:

(Orange - Warning):

Unable to save the user in the database!
The server principal '<domain>\<username>' already exists.


(Red - Error):
Unable to save user

I have checked that the user is not already created under the "Security" 'folder' (for lack of better word, the icon is the same as a folder :)) on the SQL Server. He's gone..
I have tried connecting to the data source (SQL 2014, hosted in-house) with both my own credentials (created via. RDM User and Security Management - with admin rights), and with the service account I used while configuring the RDM database. Same results. :(

Let me know if you would like the application log, or if you have any ideas on how to solve this. It's a bit of a problem that a fifth of our team cannot connect because I deleted his account and now cannot create him again. :(