I have the default schema for my user XYZCORP\JShmoe set to 'accounting'.
When I log as XYZCORP\JShmoe and execute SELECT SCHEMA_NAME() it returns "dbo" instead of 'accounting'.
Consequentially this works:
Select * From accounting.UserInfo
but this doesn't:
Select * From UserInfo
XYZCORP\JShmoe is not sysadmin.
As a note, the above is on our production server.
On our dev server everything seems to be the same (all the login and user properties I can see) but it does work.
As you're finding, default_schema is kind of fragile. My recommendation would be to not rely on that mechanism for object resolution but rather to fully qualify your objects (e.g. accounting.UserInfo instead of UserInfo). That said...
Here are a couple of situations that could explain what you're seeing:
The user is a member of the sysadmin group. According to the documentation, members of sysadmin always get dbo as their default schema regardless of database ownership. Check the sys.login_token view to confirm or deny this
The user is a member of a Windows group that is itself a database principal (i.e. has an entry in sys.database_principals) and has a default_schema set. The documentation is clear about how resolution works here as well: if a user belongs to such a group, that group's default schema is used. If a user belongs to multiple such groups, the default_schema for group with the lowest principal id is used (emphasis mine). So, even if you have the same groups between your dev and production servers, if they were created in a different order, your results will be different between the two environments. Check the sys.user_token view to see what group memberships the current user has.
So, assuming that you can't take my initial advice of fully qualifying your objects, check the two conditions above.
Related
We have MS SQL Server 2012 in production use and MS AD.
Let me explain in short what our concept of assigning user permissions is like.
For certain user group that has some access to a certain application we create AD group and assign AD users to it. Since this application needs to access data in other DB, we add that group to that DB as well and set access/execute rights to needed objects (either specific object or schemas).
Since certain people use other applications and DBs, they are added to other AD groups as well. Those groups, by no surprise, need to access some objects to second database too.
So we have situation when certain users are in few different AD groups with different accesses to the same objects in a DB. That causes lots of "strange" behaviors when, all of a sudden, some user gets denied access to objects in DB.
My questions are:
Is there any way to find out with which privileges (through which AD group) some user got access/denial for certain sql query that was triggered from application?
Can someone explain how sql server handles privileges in such environment?
I'm open for any suggestions on how to handle/set accesses differently altogether but not involving reprogramming applications (only DBA site).
Thank you.
Assuming that you're an admin, you can look at sys.login_token, sys.user_token, and sys.fn_my_permissions() while impersonating the user in question to get some idea. Something like:
execute as login='yourDom\User1';
select * from sys.login_token;
select * from sys.user_token;
select * from sys.fn_my_permission('dbo.someObject', 'OBJECT');
revert;
Evening,
I would like some practical confirmation in relation to an issue we are having.
We have a K2/SourceCode solution that turns upon the successful use of EXECUTE AS with Sql Server 2008 R2.
We have no direct control over how this solution is implemented, i.e. we cannot modify the queries that are submitted to the Sql Server engine. We can, of course, capture them using Profiler, and they tend to follow this pattern:
DECLARE #cookie VARBINARY(100);
EXECUTE AS LOGIN = 'DOMAIN\username' WITH COOKIE INTO #cookie;
SELECT #cookie;
exec [dbo].[SomeStoredProcedure] /* ... various params ...*/
exec sp_executesql N'REVERT WITH COOKIE = #cookie;',N'#cookie varbinary(100)',#cookie=/* some cookie value */
So what is happening is that [SomeStoredProcedure] is being executed in the security context of the user [Domain\username], with the service (application) account impersonating that user. Again, I emphasise that we have no control over this pattern. That's what the app does.
Outwardly this behaviour is perfectly-desirable, because we want things arranged in such a way that the stored procedure is effectively executed by whichever user is at the front-end of the application at the time.
However, these queries were consistently failing, and our investigation eventually led us to this, from the Sql Server documentation (my emphasis):
Specifying a User or Login Name
The user or login name specified in EXECUTE AS must exist as a principal in
sys.database_principals or sys.server_principals, respectively, or the
EXECUTE AS statement fails. Additionally, IMPERSONATE permissions
must be granted on the principal. Unless the caller is the database
owner, or is a member of the sysadmin fixed server role, the principal
must exist even when the user is accessing the database or instance of
SQL Server through a Windows group membership. For example, assume the
following conditions: CompanyDomain\SQLUsers group has access to the
Sales database. CompanyDomain\SqlUser1 is a member of SQLUsers and,
therefore, has implicit access to the Sales database. Although
CompanyDomain\SqlUser1 has access to the database through membership
in the SQLUsers group, the statement EXECUTE AS USER =
'CompanyDomain\SqlUser1' fails because CompanyDomain\SqlUser1 does not
exist as a principal in the database. If the user is orphaned (the
associated login no longer exists), and the user was not created with
WITHOUT LOGIN, EXECUTE AS will fail for the user.
We have a group of around 30 end users who need to be able to use this application, and the requirement is that the application security account must be able to impersonate any one of those users for the execution of these stored procedures. This requirement is fixed and non-negotiable.
The above documentation seems to preclude the possibility of meeting this requirement by adding all 30 users to an AD group, adding that group as a SQL Server login, and granting the group adequate permissions. And our practical testing results support this - EXECUTE AS fails.
Take one of those Users and give them their own, individual AD login on the Sql Server and the solution will work successfully for that user. EXECUTE AS succeeds, and the necessary permissions do not need to be assigned to the individual account because they have already been assigned by way of the AD group.
So, at this point, I am reasonably confident that I know what I am going to have to do. The requirement will be that every user has to have their AD account added as an individual Sql Server Windows login.
However, before I proceed with the rigmarole of implementing this, I wanted to ask the question publicly: is there something I am missing here?
It's instructive to imagine a similar scenario on an Enterprise-scale application - this model would somewhat fall apart, because of the need to add hundreds of individual, Windows-authenticated, Sql Server logins. Setting aside the possibility of automating this process, and the administrative burden that would ultimately result, I'm just finding it a bit of a stretch to imagine that this is the only way.
I would be grateful for confirmation and/or comments.
Thanks
Robert
As no-one has responded to the contrary (or indeed at all) we have assumed that BOL is accurate, and that there is no alternative resolution.
i googled it and find nothing. Short story, i created a user and granted to a table in my SyBase. but when i try
select * from table1
it didn't work. Error show Permission denied: you don't have permission to select from "table1" and i try add dbname before table name like this and it works :
select * from dbname.table1
i suspect that user default database is something else so i want to set dbname to his default database. Anyone know how to do this?
This has nothing to do with database names (or login policies). Given your comment that "dbname" is actually the user who owns the table, here's what's happening.
When you specify a table name without an owner, the server has to figure out which table you mean. It first looks for a table that you own with that name. If it doesn't find one, it looks for tables owned by any groups that you are a member of. I suspect that one of these groups has a table named "table1" that you do not have permission to select from.
When you specify a table name with an owner, the server knows exactly which table to use. Since you do have permission to select from that table, you get the results you want.
IQ doesn't have default databases/schemas. Instead it uses login policies. Each database has a login policy assigned to it, which can be altered. You can also create custom login policies.
When you create a user account with out specifying a login policy, it automatically gets the root login policy.
For more information, check the following SAP Sybase IQ docs:
Intro to IQ: Managing Users and Groups
System Admin Guide V1: Managing User IDs and Permissions
Using a view or procedure is a useful method. That said, to establish a "default" schema in (IQ 15.x) one would use groups. Essentially, one grants group to the schema owner and makes the individual login accounts (or other groups) members of that group. Note that this only gives the user access to the schema--that is, it eliminates the need to preface the object with the schema/owner name (unless there are object name conflicts only resolvable with explicit schema.object naming). This does not include a grant of permissions. None of the implicit table-owner related privileges will inherit. However, as the schema/owner is now also a group, permissions could be granted at that level.
See: http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00170.1540/doc/html/san1288042708174.html (Managing User ID's and permissions). Be warned: this material generally requires some close reading and experimentation before it becomes useful.
As I understand it, this method is complementary to (functionally replaced by) the new role-based model in IQ 16. However, as I am still feeling my through IQ 16, there is probably a great deal more to be said, and I am not ready to comment just yet.
At work we use AD groups to control access to SQL Server databases.
I can see these groups in Security > Logins and (database) > Security > Users.
The problem is that some DBs have 50+ such AD groups as valid logins/users and I know I am a member of more than one.
Is there a way I can determine which of these AD groups I am logged in under?
You're effectively logged in as all of them. You'll have the union of all of the individual permissions granted to each group that you're a member of.
There are 2 straight forward built in commands that can help with what you are looking for:
First the extended procedure XP_LoginInfo (available at least since SS2000) will show you all the connection paths a particular login is allowed to use to connect to the instance with
DECLARE #LoginName sysname
SELECT #LoginName = SYSTEM_USER
EXEC xp_LoginInfo #AcctName = #LoginName, #Option = 'all'
All the group names shown under the last column "permission path" are the groups that the supplied LoginName is part of. Also note the "privilege" column; it will show if a login has admin or user level rights on the instance.
Now, the function fn_my_permissions (available since SS2005) will show you all the permissions the currently connected login has on the current database or the server.
SELECT * FROM fn_my_permissions(NULL, 'DATABASE');
SELECT * FROM fn_my_permissions(NULL, 'SERVER');
As Damien_The_Unbeliever responded on 11/28/12, basically the final list of permissions is the union of all the permissions assigned--both Grant and Deny--to each group's (and individually where an ID has been added explicitly) permission path you see by executing xp_LoginInfo.
So the answer basically is that you don't exactly connect with any one group when there are multiple allowed paths. Instead, in essence, you connect with them all. While nowhere does SQL Server clearly show or even state the 'unioned' nature of permissions, it can be inferred with the above 2 commands.
A ton of useful Security Catalog Views can be found on MSDN here.
I have a SQL Server 2005 database that I'm trying to access as a limited user account, using Windows authentication. I've got BUILTIN\Users added as a database user (before I did so, I couldn't even open the database). I'm working under the assumption that everybody is supposed to have permissions for the "public" role applied to them, so I didn't do anything with role assignment. Under tblFoo, I can use the SSMS Properties dialog (Permissions page) to add "public", then set explicit permissions. Among these is "Grant" for SELECT. But running
SELECT * from tblFoo;
as a limited (BUILTIN\Users) account gives me an error "Select permission denied on object 'tblFoo', database 'bar', schema 'dbo'". In the properties dialog, there's an "Effective Permissions button, but it's greyed out.
Further, I tried creating a non-priv account called "UserTest", adding that at the server level, then mapping it down to the "bar" database. This let me add UserTest to the "Users or Roles" list, which let me run "Effective Permissions" for the account. No permissions are listed at all -- this doesn't seem right. The account must be in public, and public grants (among other things) Select on tblFoo, so why doesn't the UserTest account show an effective permission? I feel like I'm going a bit crazy here.
ASIDE: I am aware that many people don't like using the "public" role to set permissions. This is just my tinkering time; in final design I'm sure we'll have several flexible (custom) database roles. I'm just trying to figure out the behavior I'm seeing, so please no "don't do that!" answers.
UPDATE: Apparently I know just enough SQL Server to be a danger to myself and others. In setting permissions (as I said, "among others"), I had DENY CONTROL. When I set this permission, I think I tried to look up what it did, had a vague idea, and decided on DENY. I cannot currently recall why this seemed the thing to do, but it would appear that that was the reason I was getting permission failures. So I'm updating my question: can anyone explain the "CONTROL" permission, as it pertains to tables?
You only need to have SELECT rights. In raw SQL (see the "script" icon/button in your dialogue box), it's GRANT SELECT ON dbo.tblFoo to public. This is the only permission needed to view the data,
In this case, the error message explicitly mentions "deny". "DENY" is a right in itself, so it mentions it,
If you had no rights, you'd get the message (very approximately) "tblFoo does not exist or you do not have rights"
"DENY CONTROL" is mentioned here. In this case, you denied all rights to the public role.
The grantee effectively has all
defined permissions on the securable
Assuming "UserTest" is a domain user account, connect as a member of the sysadmin role and run
EXEC MASTER.dbo.xp_logininfo 'Domain\UserTest', 'all'
(substituting your domain name for "Domain")
this will display the Windows groups etc. that the account is inheriting security permissions from and the level of access, e.g. you would expect to see something like:
account name type privilege mapped login name permission path
domain\usertest user user domain\usertest BUILTIN\Users
This will help troubleshoot where the account is inheriting permissions from, e.g. which Windows groups it is part of that have permissions to the database. If this all looks OK then I would follow your own advice and not mess with the public role.
Create a database role in your
database
Assign explicit permissions for that
role
Create a server login for your user
account
Open the server login, go to the
User Mapping section, click on the
database and select the database
role you created