Sounds like DOMAIN\GroupName is a group and DOMAIN\user.name is a member of that group. This means that DOMAIN\user.name has access to SQL Server through that group. You have 2 options:
Create another group, let's say DOMAIN\NewGroupName and grant that group INSERT and UPDATE, then make DOMAIN\user.name a member of that group.
This is not the fastest ...
A better approach to me would seem to be setting up the LimitedAdmin group at the server level, then set up triggers at the server and/or or DB level that check when the command(s) you want to block is run.
In each trigger, check to see if the user is in the LimitedAdmin group, then abort the DDL trigger if they are. This handles multiple different ...
Is there an underlying reason why databases cannot be owned by a secondary principal?
I'm not 100% certain of the reason for this restriction, though I suspect it has to do with the ability to impersonate (i.e. become) that SID. There are certain operations that can reach outside of the instance (e.g. to the OS, file system, etc) and the logic is usually ...
Honestly, sa or a disabled SQL Server account with absolutely minimum permissions is the best choice. As to why? Well, I could write out three or four paragraphs on that, or I can share my favorite article on What account should own the databases and why. A very thorough explanation covering all the bases. Highly recommended.
Here's a core excerpt: (...
I am not sure what your question is. It seems you or the one who has asked you question are a bit confused between these terminologies.
SQL Server provides server-level roles to help you manage the
permissions on a server. These roles are security principals that
group other principals. Server-level roles are server-wide in their
Nowadays MySQL doesn't have a root password and instead uses the auth_socket plugin to verify the user that connected to the socket is the root user of the system. You could use this same technique to solve your problem if you are ok with having unix accounts for all your users, which opens up all kinds of possibilities e.g. easy binary file storage!
No postgresql does not inherit permissions in this fashion, Pretty much anything using the Create command sets the owner to the users that created it.
Use the GRANT command
Or after creating the tables set the Owner with Alter command
Create table Mytable (list of columns);
Alter table Mytable owner to producer;
Through a little experimentation, I discovered that rowcount requires "VIEW DATABASE STATE".
Methodology: Captured queries that SSMS runs and executed as a user with datareader permissions only. One in particular throws an error. After granting the permission, verified that rowcounts were now visible.
With NOLOGIN attribute role has no have permissions to connect to database. And vice versa with LOGIN.
In a simple way - USER is a ROLE with LOGIN attribute ('everything' here is a role in a Postgres).
Group role - is a role without LOGIN attribute (or with NOLOGIN attribute).
Therefore you can add role to a role to have more efficient permissions and ...