Permission to add user to db_accessadmin without adding to db_owner - sql

I have a client with a head-office, and various field offices.
I would like to grant a couple of head office people, who are SQL Azure contained users, the permission be become an "admin-lite". Specifically, I want them to be able to be able to create users, and make them in/active (with GRANT or REVOKE CONNECT).
I'd also like them to be able to assign other people to this same "admin-lite" role - they can then nominate one person in each branch who can create and manage their own users (there's quite a high turnover of staff).
The way I've made the first of the Head Office "admin-lites" is by making them a member of these two roles:
db_accessadmin - so they can create new users and issue GRANT or REVOKE CONNECT statements
db_securityadmin - so they can assign the new user to the appropriate role
Incidentally, they only need to be able to assign standard users to is a custom role, not a built-in role.
However, I've been able to make the first of these Head Office "admin-lites" because I'm a member of db_owners. As mentioned, I'd like them to be able to the same for their field offices - but I don't want to make the Head Office admin a member of db_owners, because this also gives them permission to make anyone else a db_owner too.
So, the question is, can I create a custom role with the permission to add people to db_accessadmin and db_securityadmin without them being a db_owner? Can I create a custom role with the same permissions as db_accessadmin and db_security admin that makes this easier, perhaps?
Thanks

If I am not wrong, you want to create a role which mimics the same functionality as db_accessadmin + db_securityadmin combined, but at the same time you do not want the members to be a member of db_owner.
Here is a role called FieldOfficeAdmin that does the same.
CREATE ROLE FieldOfficeAdmin
/* db_accessadmin permissions */
GRANT CONNECT to FieldOfficeAdmin ;
GRANT ALTER ANY USER to FieldOfficeAdmin ;
/* db_securityadmin permissions */
GRANT CREATE SCHEMA to FieldOfficeAdmin ;
GRANT ALTER ANY ROLE to FieldOfficeAdmin ;
GRANT CREATE ROLE to FieldOfficeAdmin ;
GRANT ALTER ANY APPLICATION ROLE to FieldOfficeAdmin ;
GRANT VIEW DEFINITION to FieldOfficeAdmin ;
Add any user(s) to this role, they will further be able to create more users and add them as members to the same role
CREATE USER fieldofficeadmin1 WITH PASSWORD = 'enterStrongPassword#1234';
GO
ALTER ROLE FieldOfficeAdmin ADD MEMBER fieldofficeadmin1
When you login as fieldofficeadmin1, you will be able to create more users and add them to the role
CREATE USER fieldofficeadmin2 WITH PASSWORD = 'enterStrongPassword#1234';
GO
ALTER ROLE FieldOfficeAdmin ADD MEMBER fieldofficeadmin2
But when you login as fieldofficeadmin1 and try to add a member to db_owner
ALTER ROLE db_owner ADD MEMBER FieldOfficeAdmin2
It should fail with the below error
Failed to execute query. Error: Cannot add the principal 'FieldOfficeAdmin2', because it does not exist or you do not have permission.
Please let me know if you have any further questions or if I interpreted your requirement incorrectly.

Related

Postgres doesn't delegate privilege to child role

I am trying to create a group that has the right to create databases and roles. And then inherit these privileges with the next role. But the error constantly pops up that I don't have rights
Edited: (mistake between 'gg' and 'ggc', but steel doesn't work)
create role ggc with createdb createrole;
create user gg login password 'gg';
grant ggс to gg;
Always get this error: "SQL Error [42501]"
This way is also doesn't work
CREATE ROLE qwe WITH NOLOGIN CREATEDB CREATEROLE;
CREATE ROLE ads WITH LOGIN PASSWORD 'pass';
GRANT qwe TO ads;
SET ROLE ads;
CREATE DATABASE test;
This behavior is normal and is actually documented here:
The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can be thought of as special privileges, but they are never inherited as ordinary privileges on database objects are. You must actually SET ROLE to a specific role having one of these attributes in order to make use of the attribute. Continuing the above example, we might choose to grant CREATEDB and CREATEROLE to the admin role. Then a session connecting as role joe would not have these privileges immediately, only after doing SET ROLE admin.
You grant roles to users, not the other way round

Restrict access to creating users on PostgreSQL

Using PostgreSQL and would like to have only admins have the ability to create new users. While allowing some non-admin users read-write access to our tables.
I cannot find a way to get this done. I have a role called webuser to which I gave:
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO webuser;
But now webuser has access to call CREATE USER and GRANT ROLE also. How can I remove access from webuser to do user-management operations while allowing SELECT, INSERT, UPDATE, DELETE on our database tables?
A user can only create other users if it has the createrole property: this property is not assigned by default when creating a user.
Doc. says:
CREATEROLE NOCREATEROLE
These clauses determine whether a role will be permitted to create new roles (that is, execute CREATE ROLE). A role with CREATEROLE
privilege can also alter and drop other roles. If not specified,
NOCREATEROLE is the default.
Either the user has been created with createrole or a superuser has run: alter user webuser createrole.
To revoke that privilege run alter user webuser nocreaterole
NB:
CREATE USER is now an alias for CREATE ROLE. The only difference is
that when the command is spelled CREATE USER, LOGIN is assumed by
default, whereas NOLOGIN is assumed when the command is spelled CREATE
ROLE.

Set permissions by role in Azure SQL Database

I'm attempting to create 4 different roles in Azure SQL database. The 4 role names are READ_ONLY_ACCESS, READ_UPDATE_ACCESS, READ_WRITE_UPDATE_ACCESS, FULL_ACCESS.
-READ_ACCESS - Grant Select
-READ_UPDATE_ACCESS - Grant Select, Update
-READ_WRITE_UPDATE_ACCESS - Grant select, Update, Insert
-FULL_ACCESS - Grant Select, Update, Insert, Delete
My goal is to create these 4 roles with these permissions, and then be able to create a user assigned to one of these roles. Example below of what I want to do after creating these roles:
CREATE USER username WITH PASSWORD = 'password';
ALTER ROLE READ_ACCESS ADD MEMBER username;
I've found a few sites that help with this, but I'm unclear as to whether or not I need to declare whether to deny access to certain permissions as well as declaring the granted access.
First create roles.
create role ApplicationUsers_ReadAccss;
grant select on schema::dbo to ApplicationUsers_ReadAccss;
create role ApplicationUsers_ReadUpdateAccss;
grant select, update on schema::dbo to ApplicationUsers_ReadUpdateAccss;
create role ApplicationUsers_ReadWriteUpdateAccss;
grant select, insert, update on schema::dbo to ApplicationUsers_ReadWriteUpdateAccss;
create role ApplicationUsers_FullAccess;
grant select, insert, update, delete, execute on schema::dbo to ApplicationUsers_FullAccess;
After that create logins and add them to one of the roles.
--create a server-level Login
create login AppUser with Password ='asdfAds01980(*)(*)(#&$)##';
--add a user mapped to that login in each database
create user AppUser for login AppUser;
alter role ApplicationUsers_FullAccess add member AppUser;

Prevent all users from accessing tables/views under a schema

I am connecting to my SQL studio manager using Power BI (a report writing software). I only want tables appearing listed under a certain schema, and deny permission to access all others, instead of displaying all tables which it currently does.
Usually, when preventing individual users from accessing a schema, I would use the following code:
revoke select on schema::UnwantedSchema to User
grant select on schema::WantedSchema To User
However, now I want it so ALL users and Logins have these permission settings. Not just the individual user. Is there a way I can do this without having to set the permissions for every individual user?
If you wanted to set the privileges to multiple user logins, You need to create a role and assign the role to the ers to that role. The give required permission to the role created.
Following are the sample steps.
--Create a new role
EXEC sp_addrole 'yourRole'
GO
--Assiging role to the user
EXEC sp_addrolemember 'yourRole', 'yourUser';
GO
--Assigning permissions to the Role
GRANT ALTER, DELETE, EXECUTE, INSERT, REFERENCES, SELECT,
UPDATE, VIEW DEFINITION ON SCHEMA::YourSchema TO yourRole;
GO
GRANT CREATE TABLE, CREATE PROCEDURE, CREATE FUNCTION, CREATE VIEW TO yourRole;
GO

Vertica role grant not working

I am trying to setup a new role for making the access rights granting easier. I was wondering if there is an easier way to give select on all tables (newly created tables should be accessible automatically) under a schema to selected users. I ran following queries for the same. But still my user is not able to access the specific table.
CREATE ROLE myrole;
GRANT SELECT ON myschema.mytable TO myrole;
GRANT usage ON schema myschema TO myrole;
CREATE USER mytest1 identified BY '***';
GRANT myrole TO mytest1;
After this, when I login with mytest1 user and trying to run select on myschema.mytable it is asking me to grant usage on schema to user. After I grant usage on schema to user directly it is failing with permission denied for that table.
Please help with the same. I am running on vertica 5.0
Update:
I find that u also have to make that role default or explicitely set that role as default for user session for making the role's effect take place.
ALTER USER mytest1 DEFAULT ROLE myrole;
But still, my another question of how to make all tables under a schema accessible to specific users remains.
As per the Vertica SQL Reference Manual.pdf (page 725) (doc version 5.0 - for page numbers)
GRANT (Schema)
...
USAGE
Allows the user access to the objects contained within the
schema. This allows the user to look up objects within the
schema. Note that the user must also be granted access to the
individual objects. See the GRANT TABLE (page 727) ... .
The the user must also be granted access to the individual objects means that you need to also GRANT table.
The two I use is GRANT SELECT and GRANT REFERENCES which allows the user to run queries and join (reference) tables in the query.
Example:
GRANT SELECT ON TABLE [schema].[Table1] TO myUser;
GRANT SELECT ON TABLE [schema].[Table2] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table1] TO myUser;
GRANT REFERENCES ON TABLE [schema].[Table2] TO myUser;
...
6.0 doc reference GRANT SCHEMA (page 808) and GRANT TABLE (page 813).