I am the admin of my SQL server which I have created and I am testing on altering server level roles and for that I am trying below commands. The first one returns executed successfully and the second one returns 0, which means I dont have that spoecific server role. can anyone explain me why this is happening. What wrong am i doing here?
ALTER SERVER ROLE ##MS_ServerStateReader##
ADD MEMBER zzzsharepoint;
GO
select IS_SRVROLEMEMBER('##MS_ServerStateReader##', 'zzzsharepoint')
This is documented behaviour:
Return Types
int
Return value
Description
0
login is not a member of role. In Azure SQL Database, this statement always returns 0.
1
login is a member of role.
NULL
role or login is not valid, or you do not have permission to view the role membership.
For whatever reason, the documentation on Azure SQL Databases suggests otherwise. It also suggests using a query to check the permissions, however, that always returns no results as well. If the ALTER SERVER ROLE ran successfully, I would suggest that the role has had the role added.
Related
I do have admin permission for a certain Azure SQL Server. So using my admin login I created a database user against a specific Azure SQL database in the following manner:-
CREATE USER myuser WITH PASSWORD = '<pwd>'
ALTER ROLE [db_datareader] ADD MEMBER [myuser]
After this I successfully logged into the database using this new credential for myuser. I discovered that while I can query data from most of the tables , there are certain tables for which I can't select any data. I can see the table name in SSMS , also no error for SELECT queries against those tables I receive , the only issue is that SELECT doesn't return any data ( 0 rows ) for those tables. If I fire SELECT using my admin credentials , I can very much see the result.
I tried to reproduce the same issue using the same commands which you have shared.
FYI, as a part of repro, I created an Azure SQL Server and then SQL database in the same server. I added three sample tables to match the scenario as you mentioned. Then I created user and grant db_datareader role with the same commands as you mentioned. It worked fine for me. I’m able to read the data of all the table in that specific database.
I suggest you consider How to Create Login, User & Assign Permissions in SQL Server and Overview of db_datareader role.
Alternatively, you can grant select permission to those tables which you are unable to read using below command:
GRANT SELECT ON <tablename> TO <user>;
We are trying to install a release for our application. The program uses 2 SLQ Accounts: SA and SAA2.
SAA2 should be a standard user which can run some Select Statement. SA is a super admin (Captain Obvious).
However we are stuck in 2 different ways:
1) If we grant sysadmin right to SAA2, our scripts could not run because it refers to to the defined schema implemented in login page of the account. As we understood, since it's associated to sysadmin, the default schema change to dbo.
But, the account can login successfully
If we want to resolve it by this way, we have to implements these workaround :
Force account to use his own default schema
Change our scripts with a full name without using schema (not possible)
Invalid object name ...
2) If we want to use SAA2 as a standard accounts (because script are mainly focus on SELECT), MSSSQL refuse the account to connect. Indeed, if we try to simply login using SQL Credentials, as a sysadmin it works, as a standard user, it wont. (like this https://social.msdn.microsoft.com/Forums/sqlserver/en-US/23952fef-7ad7-4374-b7e9-89476a62adc9/users-unable-to-access-their-database-unless-they-are-given-sysadmin-permission?forum=sqlsecurity)
Error number 18456, Severity 14, State 1
We just want to find a way to execute our query, as a sysadmin or not.
I am having trouble adding a user to a test database I set up on my local machine. I have added the user fine but the user does not have permission to SELECT (Or anything else for that matter) on the database. I have tried gone the the permission tab under the server, the database, and the table (there is only one it is a very simple database just for testing) and selected grant for every single option yet it still does not work. I have also tried doing a Transact-SQL command like:
use testing
GRANT SELECT, UPDATE, DELETE, INSERT TO User
and a couple of other combinations that return successfully but I still do not have permission to select data from the table. Any suggestions?
Add the user to the db_datareader role to give the user select access to all of the tables.
Add the user to the public database role and they should be able to SELECT against the database (unless you have changed the public role's permissions).
I'm making a call to odbc32.dll (SQLBrowseConnect) to return a list of databases on a sql server.
From running a trace I can see the query being executed is
select name from master..sysdatabases where has_dbaccess(name)=1
If the credentials I pass aren't the sa user it returns just the system databases. Is there anyway I can use SQLBrowseConnect with another user (whose default database is also not guarenteed to be the master database) to return all databases on the server?
Also I want to avoid smo objects
The query does work without sysadmin credentials.
You need to ensure that you / the credentials you are using are at least in the public database role on each of the databases that you need to connect to.
As you would guess, select name from master..sysdatabases returns all database names irrespective of your access to the DB.
Consider this T-SQL:
CREATE USER my_test_user WITHOUT LOGIN;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name();
EXECUTE AS USER = 'my_test_user' WITH NO REVERT;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name();
I'm looking at using these accounts WITHOUT LOGIN for auditing purposes. Basically, my "get a database connection" code returns a connection on which the EXECUTE AS USER...WITH NO REVERT has already been executed.
The problem is that I can't get consistent results from any of these user name functions. The two lines of output are:
dbo dbo original_user original_user original_user
my_test_user my_test_user S-1-9-3-XXXXX.. S-1-9-3-XXXXX.. S-1-9-3-XXXXX..
The USER functions produce correct output AFTER the 'EXECUTE AS', but beforehand they're showing dbo rather than the user name
The SUSER functions are just the opposite -- they're correct initially but after impersonation they're showing some sort of ID
The MSDN docs for SUSER_SNAME explicitly give an example where this is supposed to work.
UPDATE: What I'm looking for is a function that will produce 'original_user' in the first case and 'my_test_user' in the second.
Update: you need the ORIGINAL_LOGIN fn here too
Original:
Afterwards, there is no matching system level user. So, it can't resolve the database level sid, so it simply returns the sid from sys.database_principals
CREATE USER my_test_user WITHOUT LOGIN;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name();
EXECUTE AS USER = 'my_test_user' WITH NO REVERT;
SELECT USER_NAME(), USER, SUSER_SNAME(),SYSTEM_USER, suser_name(),
SUSER_SID();
SELECT * FROM sys.database_principals WHERE sid = SUSER_SID();
I don't know if this is by design, but it explains where the number comes from. The rest is as expected as explained below
Notes:
You'll get dbo for USER_NAME() because you are logged on with sysadmin rights. Everyone with "sysadmin" is dbo when using db level user functions.
After changing user context, db level user functions resolve to the database user context
For system level user functions, you'll get the login you used before
Users without login are a special case used exclusively for service broker security (remote service bindings) or for code signing. They represent identity, not impersonation. Do not use users without login for EXECUTE AS. You'll run into all sort of edge cases because they explicitly don't have a user to login mapping and almost everywhere a mapping is expected.
Just a guess here, but it looks like to me that the first select is being run as the user you're currently logged into as with the connection, and in the second select you are then telling sql server to execute as the newly created user.