I'm trying to change the owner of a database using the alter authorization statement.
Statement:
ALTER AUTHORIZATION ON DATABASE::spentlytestlocal TO renspently
Error:
Cannot find the principal 'username', because it does not exist or you do not have permission
I'm sure I assigned the user permission to take ownership, but any help and direction is greatly appreciated.
For this to work, two things must be true, per Books Online:
Server objects (such as databases) must be owned by a server principal
(a login).
This means the account you want to give ownership must have a login on the server (not just a user in the database -- it is possible to have users without logins if you restore from a backup).
And second,
Requires TAKE OWNERSHIP permission on the entity. If the new owner is
not the user that is executing this statement, also requires either,
1) IMPERSONATE permission on the new owner if it is a user or login;
or 2) if the new owner is a role, membership in the role, or ALTER
permission on the role; or 3) if the new owner is an application role,
ALTER permission on the application role.
Which means, in practice, that you need to be a sysadmin. One common instance of where you're not a sysadmin is if SQL Express has been configured to have local admins as sysadmins, but you don't start Management Studio with elevated permissions.
Related
I am granting permission on some objects to my user in a database, Is there any way to grant permission to user without using database role?
I can easily do it by creating database role, but I do not want to use role.
I assigned some objects to my user by Database User, in Securables tab, it didn't work!
create user [user_test] for login [login_test]
create role role_test authorization user_test
exec sp_addrolemember 'role_test', 'user_test'
grant select on object::dbUser.tbl_05 to role_test
I expected I could grant permission to my user and not to use Database Role.
You have (at least) 2 options here, you can assign the permission straight to your DB user (as mentioned in the comment) or you can grant permission on a certificate, which might give you better control in a production environment.
I have got myself into a little bit of a bind, using SQL Server Management Studio to create a database in Azure SQL. My issue appears to be with assigning roles to users in the database. When I created the database, it prompted me to create a new login, with an associated user, that appeared to have all the rights of a database owner. However, I am now trying to create two additional logins and I realize I am screwed. The login that I created when I made the database isn't the database owner, even though I could do all the DDL / DML necessary to create the full schema under that account. I created an additional login, and I added two users to that login. I now want to add that login to a role (db_datareader, db_denywrite) but I cannot.
It appears that the database owner is a user / login called "dbo" that I did not set up. This is the only user that is added as a database owner, and subsequently is the only one that can edit roles. But I do not know the login credentials for this user!
if I use what I believed to be the administrator account (the one I made) to add a role I get the error:
Cannot alter the role 'db_datareader', because it does not exist or you do not have permission.
How can I fix this? How can I get my original account added as a DB Owner? There has got to be a way, but everything I tried points to the fact that I am not the owner of the resource I created; I'm an outcast in my own country...
Thanks!
Users are created with dbcreator and public role. They can create and delete their own databases.
How do I give them the ability to grant permission to their database to other users? Currently they can only see public and guest object.
You don't need to make someone a sysadmin. The minimum required permissions are described on this page.
In SQL Server, requires ALTER ANY LOGIN permission on the server or
membership in the securityadmin fixed server role.
These permissions still give a user a lot of power. They are able to delete other sysadmin logins.
Perhaps partial contained databases can be a solution for you.
A database user in a regular database needs to be mapped to a login on server level. Managing these server level logins requires a lot of permissions.
Database users within a partially contained database can exists without a login. These users can only login to that specific database. No server level permissions are required to manage these users.
I'm using SqlServer and the application role for my application, but I also have username in SqlServer.
Is there any possibility to change user password when using the application role?
When I'm trying to change user password I get an error, that I don't have permission to change it.
I granted an alter permission to the application role, but it didn't help.
AFAIK, this is not possible and really isn't the use case application role was designed for.
Application roles are database level objects, or more accurately principals since it is a security object. Logins are server level principals. You cannot grant a server level privilege to a database level principal.
It really isn't the use case for app roles but if you absolutely must do it, you can create a stored procedure in the database used by the app and configure it to execute under a different principal but it's hacky and I wouldn't do it for a production system.
I've moved to creating/using schemas in Sql Server 2005, where I've also created database roles and assigned schemas to the roles.
The problem I have is one of the db roles I have should have full access - say SuperSysRole.
However, when I assign a login to that role, it cannot execute specific commands. In particular, I want a user within this role to manage password resets. However, when I execute the stored procedure, it does not return back all users in the database.
The stored procedure has been run which returns back the details and calls a view which integrates the sysusers and sysmembers tables.
The user, say myAdmin, has been assigned to the role SuperSysRole. The role SuperSysRole has been granted execute to the stored procedure selectRoles.
It's probably a simple thing but can someone please tell me what I am missing?
My application authenticates using the myAdmin user name and password. It works fine when I login with the sa account.
Database role membership is queryable through the sys.database_principals and sys.database_role_members catalog views, which are the proper catalog views to use instead of the deprecated sysusers and sysmembers. Both have the same security restrictions:
In SQL Server 2005 and later versions,
the visibility of the metadata in
catalog views is limited to securables
that a user either owns or on which
the user has been granted some
permission.
The necessary permissions are listed in GRANT Database Principal Permissions: VIEW DEFINITION. There is no permission that can be granted to view any principal and role definition.
Your best option is to create a procedure that selects from the proper metadata catalog views and sign this procedure with a credential that is added into the db_securityadmin role. See Signing an Activated Procedure for an example how to sign a procedure. The grant EXECUTE on this procedure to whoever required to view these principals and role memberships.
However, all of this will get you nowhere with regard with the declared intent: manage password resets. Only server principals (aka. logins) have passwords, and any scheme designed at the database principals level can have no effect on server principals, since they are the wrong abstraction. And since there are no server roles to define (you can only have Windows groups as roles, but you want to use SQL Auth), you cannot have this done by role membership.
My recommendation is, again, to use code signing. Create procedures that do the activities you want (query sys.server_principals and sys.sql_logins to inspect password expiration, issue ALTER LOGIN statements to reset passwords etc) then use code signing to sign these procedures and grant the required privileges to the signature. I refer you again to Signing an activated procedure for an example how to do that. Then grant EXECUTE on these procedures to the 'special' users that have to manage these.