Escape wildcard, *, in sp_addsrvrolemember - sql

Is it possible to escape a wildcard * in the below stored procedure?
exec sp_addsrvrolemember '*Everyone-Group', 'sysadmin'
I need the script to identify * but not as a wildcard, but rather as an asterisk.
Thank you for your help.

Okay so I reached out to a SQL expert to educate me and here is what I needed:
CREATE LOGIN [_Everyone-Group] FROM WINDOWS WITH DEFAULT_DATABASE=[master]
GO
ALTER SERVER ROLE sysadmin ADD MEMBER [_Everyone-Group]
As for my misunderstandings:
The * is only considered a wildcard in MS Access, not SQL like it was mentioned in this post
The line of code "ALTER SERVER ROLE" assumes the login is already existing in the master database, I had thought it would look for it and add it in (because of ADD MEMBER) and then also apply 'sysadmin' permissions.
I did not know the _ was needed instead of * in the brace.

Related

How to remove a user from SQL Server 2014?

If I open SQL Server 2014 Management Studio GUI and connect to my database, I can expand the database > Security > Logins to see the list of users that can login.
I'm trying to find out the SQL statement that I can use to remove one of those users (I need an automated solution).
I've tried
drop login 'BUILTIN\Users'
delete from master..syslogins where loginname = 'BUILTIN\Users'
drop user 'BUILTIN\Users'
from the drop commands, I get the error
Incorrect syntax near 'BUILTIN\Users'
and the delete throws
Ad hoc updates to system catalogs are not allowed
Don't use the quotes but brackets instead.
DROP LOGIN [BUILTIN\Users]

tSQL to set up user with View Definition permission on SQL Azure

I'm trying to export a SQL Azure database to a .bacpac file using the Azure portal. The administrator username on my database contains a *. When I use it in the username field I get this error.
The login name must meet the following requirements:
It must be a SQL Identifier.
It cannot be a system name, for example:
- admin, administrator, sa, root, dbmanager, loginmanager, etc.
- Built-in database user or role like dbo, guest, public, etc.
It cannot contain:
- White space like spaces, tabs, or returns
- Unicode characters
- Nonalphabetic characters ("|:*?\/#&;,%=)
It cannot begin with:
- Digits (0 through 9)
- #, $, +
So I add a new user to the database using the following tSQL.
USE master;
CREATE LOGIN gu6t6rdb WITH PASSWORD = 'kjucuejcj753jc8j'
USE MyActualDB;
CREATE USER gu6t6rdb FOR LOGIN gu6t6rdb
The portal export form accepts that username but later errors with the following message.
Error encountered during the service operation. Could not extract
package from specified database. The reverse engineering operation
cannot continue because you do not have View Definition permission on
the 'MyActualDB' database.
To fix this I tried the following tSQL
GRANT VIEW ANY DEFINITION TO gu6t6rdb
which throws the following error
Securable class 'server' not supported in this version of SQL Server
How should I use tSQL to provide an additional user on my database and give the user sufficient privileges to export the database through the Azure portal to a .bacpac file in an Azure blobstore?
This will not work on sql azure. You will need to grant view definition at the database level. (without the ANY keyword)
GRANT VIEW DEFINITION TO gu6t6rdb
P.S: I hit the exact same issue and this seemed to solve my problem. I also had to do a Grant Execute (but it depends on what your bacpac is applying to the database)
Got it. I can add the user to the db_owner role and then the export proceeds without error.
EXEC sp_addrolemember 'db_owner', 'gu6t6rdb'
as of now, GRANT VIEW DEFINITION TO [username] works in Azure SQL, I just verified it myself. See https://learn.microsoft.com/en-us/sql/relational-databases/security/permissions-database-engine?view=sql-server-ver15 for reference:
So in order to successfully export database as bacpak file you can created contained user (no need in CREATE LOGIN... command) and give the following permissions:
CREATE USER [user_from_azure_AD] FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER [user_from_azure_AD]
GRANT VIEW DEFINITION TO [user_from_azure_AD]

SQL - Impersonate SYSTEM_USER

Is there a way to impersonate or change the SYSTEM_USER on MS SQL 2005?
I have many views (written by a third party) which I can not change which references an SYSTEM_USER to "ID Table".
... AND idCode = SUBSTRING(SYSTEM_USER, CHARINDEX('\', SYSTEM_USER) + 1, LEN(SYSTEM_USER))
*I do have rights to the tables that the views pull from, BUT these views have the added SYSTEM_USER.*
Thanks.
Check out the Execute As Transact SQL
Providing you have the correct permissions you can execute any T-SQL as another user and then revert back to the original connection credentials.
Select System_User
Go
Execute As Login = 'SomeOtherLogin'
Select System_User
Revert
Go
Select System_User
Go
This will output the current connection credentials for the first and third select and output the specified credentials for the second select.

SQL SERVER stored procedure problem?

I have created a stored procedure using SQL Server Management studio.
I am able to create it but if I tryto right click on the stored procedure and execute it, I am getting permission denied error# 229.
I have administrator rights. How can I execute this procedure.
if you are really connecting as sa this should not happen, if you are not, could be that your user does not really have all the rights.
It is also difficult to understand the problem without seeing the body of the stored in case you are doing anything special in there.
at this link anyway: http://www.sqlservercentral.com/Forums/Topic463688-146-1.aspx somebody was discussing the same error and there are some SQL commands scrolling down the page where some people claim to have fixed the issue.
Are you sure that you have sufficient permissions?
Error 229 means that you don't.
Your user needs at least EXECUTE permissions for the stored procedure:
Stored Procedure and Permissions - Is EXECUTE enough?
Here's how you can check if you have the permission:
MS SQL Server: Check to see if a user can execute a stored procedure
Verify that you didn't add your user to any of the deny roles, like db_denydatareader.
Use this to add execute privillages to your SQL Login:
GRANT EXECUTE ON SPNAME TO UserName;
GO

SQL Select Permissions

I have a database that I need to connect to and select from. I have an SQL Login, let's call it myusername. When I use the following, no SELECT permission shows up:
SELECT * FROM fn_my_permissions ('dbo.mytable', 'OBJECT')
GO
Several times I tried things like:
USE mydatabase
GO
GRANT SELECT TO myusername
GO
GRANT SELECT ON DATABASE::mydatabase TO myusername
GO
GRANT SELECT ON mytable TO myusername
GO
It says the queries execute successfully, but there is never any difference in the first query. What simple thing am I missing to grant database level select permissions.
As a note, I made double sure it was the correct user, correct database, and I have already tried granting table level select permissions. So far I keep getting the error:
SELECT permission denied on object 'mytable', database 'mydatabase', schema 'dbo'.
Any ideas what I'm missing? Thanks in advance.
EDIT/UPDATE:
Upon right clicking the SQL User in SQL Server Management Studio 2008, I discovered every single Database role is checked, including db_denydatareader and db_datareader... might this be blocking my ability to grant permission at the database level? If this is so, what is the purpose of db_denydatareader? It seems silly to me to have a 'DENY' that can't be viewed when querying permissions.
SUMMARY:
Sure enough, that fixed it.
In SSMS - under Databases-->mydatabase-->Security-->Users-->myusername, right click the username, select properties. Under database role membership, make sure db_denydatareader is not checked as this will override whatever permissions you had granted.
Knew it was something simple. :)
Have you tried reconnecting with that SQL user account?