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.
Related
When I scan my database, it shows one of the result like VA1143 'dbo' user should not be used for normal service operation in A Vulnerability Assessment scan
They have suggested to "Create users with low privileges to access the DB and any data stored in it with the appropriate set of permissions."
I have browse regarding the same to all form but cannot get the correct suggestion yet. Could you please suggested your idea or where i have to create the user and grand the permission. Since we have only one schema structure in our DB.
About "Create users with low privileges to access the DB and any data stored in it with the appropriate set of permissions.", the first thing you should know is the Database-Level Roles.
Create users with low privileges means that the use does not have the alter database permission.
When we create the user for the database, we need to grant the roles to it to control it's permission to the database.
For example, bellow the the code which create a read-only user for SQL database:
--Create login in master DB
USE master
CREATE LOGIN reader WITH PASSWORD = '<enterStrongPasswordHere>';
--create user in user DB
USE Mydatabase
CREATE USER reader FOR LOGIN reader;
GO
--set the user reader as readonly user
EXEC sp_addrolemember 'db_datareader', 'reader';
For more details, please reference:
Authorizing database access to authenticated users to SQL Database
and Azure Synapse Analytics using logins and user accounts
Hope this helps.
When designing and building databases, one the principal mechanisms for security must be the "least privilege principal". This means that you only give permissions that are absolutely necessary. No application should need to be the database owner in order to operate. This role should be highly restricted to only administration types. Instead, you create a more limited role for the application. It can include access to every single table, all the procedures, but it won't be able to do things like, for example, drop the database.
This is step one to a defense in depth of your system in order to properly and appropriately secure it. It helps with all levels of security issues from simple access to SQL Injection. That's why it's included as part of the vulnerability assessment. It's a real vulnerability.
Yes resolved the issue after creating the least privilege role and assigned to the user. But its leading to different below vulnerable issue's for the newly added user with least privilege role. Any lead will be helpful on this
1.VA2130 Track all users with access to the database
2. VA2109 - Minimal set of principals should be members of fixed low impact database roles
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!
I have a custom procedure that basically replaces msdb.dbo.SP_ADDTASK which works fine when using a user with database role permissions, but when I switch to an application_role permissions scheme, the same procedure fails when trying to access xp_sqlagent_is_starting. I assume that this is the first in a long chain of extended procs that would fail if I simply explicitly granted execute, and I have not had to do this prior to testing with application role permissions.
Both the database role and the application role have the same permissions, and I cannot see any permissions on the original user account or even on the extended proc beyond the role securables, so why am I being denied execute when using the application role?
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 am creating some users on SQL server but I am a little confused as to whether I grant "alter any login" or "alter any linked server" to my LOGIN or to the USER account?
As you all know, on SQL server, you create users in this order:
Create LOGIN sysUser1 (in master db)
Create USER myUser1 for LOGIN sysUser1 (in users db)
CREATE SCHEMA myUser1 AUTHORIZATION myUser1
then, run sp_addrolemember for myUser1 as needed
then, do grants
I am confused as to whether I should:
grant alter any login to myUser1
or
grant alter any login to sysUser1
Can anyone clarify? Am I thinking of this incorrectly?
ALTER LOGIN is a server level permission, so you can't grant it to database users. You need to grant it to sysUser1 in your case.
See http://msdn.microsoft.com/en-us/library/ms186717.aspx
Edit: Dito for linked server.
Logins and Linked Servers are both objects that exist at the instance level, as opposed to at the database level, so these permissions both need to be applied to the login, rather than the user.
If you are using SQL Server 2012, then it is possible to create you own Instance level roles, but in 2008 and below, you are rrestricted to the built in server roles.
There is a server role called setupadmin that lets members manage linked servers.