According to the documentation the user should have either VIEW ANY DEFINITION or ALTER ANY CREDENTIAL to view the credentials. The issue is when I grant this permission, the user can see all the credentials. Is there a way to limit the user can view only one credential in SQL Server 2014?
You create a new view object that looks at the sys.credentials table based on the current user login, e.g.
CREATE VIEW dbo.GetAllowedCredentials
AS
SELECT c.credential_id,
c.name,
c.credential_identity,
c.create_date,
c.modify_date,
c.target_type,
c.target_id
FROM sys.credentials AS c
INNER JOIN sys.server_principals AS sp ON sp.credential_id = c.credential_id
WHERE sp.name = ORIGINAL_LOGIN();
You can apply permissions to this view as required.
Related
In the Security/Users folder in my database, I have a bunch of security groups, include "MyApplication Users". I need to check if I am (or another user is) in this group, but I have no idea how to query for it or where I could see this information. I tried looking in the properties, but couldn't find anything. Any ideas?
Checking yourself or the current user:
SELECT IS_MEMBER('[group or role]')
A result of 1 = yes,0 = no, and null = the group or role queried is not valid.
To get a list of the users, try xp_logininfo if extended procs are enabled and the group in question is a windows group :
EXEC master..xp_logininfo
#acctname = '[group]',
#option = 'members'
For a quick view of which groups / roles the current user is a member of;
select
[principal_id]
, [name]
, [type_desc]
, is_member(name) as [is_member]
from [sys].[database_principals]
where [type] in ('R','G')
order by [is_member] desc,[type],[name]
To find the AD Group members in the Instance, we can use below query:
xp_logininfo 'DomainName\AD_GroupName', 'members'
By using this query, we can find the below states.
account name, type, privilege, mapped login name, permission path
Accepted answer from DeanG is the preferred solution for getting this info within SQL Server
You can use Active Directory tools for this. I like Active Directory Users and Computers that is part of the Remote Server Administration Tools. Follow the link to download and install the tools on Windows 7.
Once installed, you can search for a specific group name:
Then you can see group membership using the Members tab:
If you don't want to use the AD browser packaged with RSA tools, there are several others available.
You don't.
Instead you use the users and groups to grant/deny privileges, and let the engine enforce them appropiately. Attempting to roll your own security will get you nowhere fast. A banal example is when you will fail to honor the 'one deny trumps all grants' rule. And you will fail to navigate the intricacies of EXECUTE AS. Not to mention security based on module signatures.
For the record: users, roles and groups are exposed in the sys.database_principals catalog view. sys.fn_my_permissions will return the current context permissions on a specific securable.
The code that is provided on the Microsoft page here works for me, every time.
SELECT DP1.name AS DatabaseRoleName,
isnull (DP2.name, 'No members') AS DatabaseUserName
FROM sys.database_role_members AS DRM
RIGHT OUTER JOIN sys.database_principals AS DP1
ON DRM.role_principal_id = DP1.principal_id
LEFT OUTER JOIN sys.database_principals AS DP2
ON DRM.member_principal_id = DP2.principal_id
WHERE DP1.type = 'R'
ORDER BY DP1.name;
Please let me know if this works for you!
I'm currently using a free DB2 warehouse on cloud provided by IBM. What I'm trying to do is to create a new table in the database. However, an error message pops up saying that
To resolve this, I open the web console and run the following command: create tablespace mytablespace pagesize 4096. Then, another error message pops up:
Based on what I have googled, it looks like I need to grant administrator role for the user "DASH******". So I do this by adding an optional parameter to the credentials:
But it doesn't work. Is there any way to workaround this?
EDIT1: I create the table using the following command:
Users are not allowed to create their own tablespaces in free DB2WoC systems, since they don't have the SYSCTRL or SYSADM authorities there. You have to use existing tablespaces where you are allowed to create your tables.
Run the following statement from your DASH*** user.
This statement returns all the tablespaces, where your user is allowed to create tables.
If it doesn't return any rows, then this means, that you should open a ticket to the IBM support. Support should create it for you and grant your user the USE privilege on this tablespace.
SELECT
T.DATATYPE
--, P.PRIVILEGE
--, P.OBJECTTYPE
--, P.OBJECTSCHEMA
, P.OBJECTNAME
, U.AUTHID, U.AUTHIDTYPE
FROM SYSIBMADM.PRIVILEGES P
CROSS JOIN TABLE(VALUES USER) A (AUTHID)
JOIN TABLE (
SELECT GROUP, 'G' FROM table(AUTH_LIST_GROUPS_FOR_AUTHID(A.AUTHID))
UNION ALL
select ROLENAME, 'R' from table(AUTH_LIST_ROLES_FOR_AUTHID(A.AUTHID, 'U'))
UNION ALL
SELECT * FROM TABLE(VALUES ('PUBLIC', 'G'), (A.AUTHID, 'U')) T (AUTHID, AUTHIDTYPE)
) U (AUTHID, AUTHIDTYPE) ON U.AUTHID=P.AUTHID AND U.AUTHIDTYPE=P.AUTHIDTYPE
JOIN SYSCAT.TABLESPACES T ON T.TBSPACE=P.OBJECTNAME
WHERE P.OBJECTTYPE='TABLESPACE' AND T.DATATYPE IN ('A', 'L')
I am executing a SQL script in SQL Server Management Studio 2018. In my script I need to specify a user (including the domain - unsure if I need the server name).
So I have created a user sam, set the user type to SQL user without login and set the users role to db_datareader and db_datawriter.
I then execute my script but it gives me the error: User or role 'MHT.sam' does not exist in this database.
But I am almost certain I have added this user to the database (see my images below to double check). Is my user and domain name format correct? What do you think I am doing wrong?
Here's my domain and server:
The error is pretty obvious.
In your screen shot in the object explorer you have a user called SAM, but for sp_AddRoleMember you are using MHT.SAM user.
Your sp_addrolemember should also have only Sam something like...
Exec sp_addrolemember N'RunStoredProc' , N'Sam'
GO
Also to double check what your user type is what login it is mapped to and what really is going on, use the following query.
SELECT
d.name AS User_Name
, d.type_desc AS User_Type
, d.default_schema_name AS User_default_schema_name
, d.create_date AS User_Created_Date
, s.name AS Login_name
, s.type_desc AS Login_LoginType
, s.is_disabled AS Login_is_disabled
, s.create_date AS Login_create_date
, s.default_database_name AS Login_default_database_name
, s.default_language_name AS Login_default_language_name
FROM sys.server_principals s
INNER JOIN sys.database_principals d on s.sid = d.sid
WHERE d.name = 'Sam'
I have created a login and database user called "MYDOMAIN\Domain Users". I need to find what roles a logged on domain user has but all the calls to get the current user return the domain username eg. "MYDOMAIN\username" not the database username eg. "MYDOMAIN\Domain Users".
For example, this query returns "MYDOMAIN\username"
select original_login(),suser_name(), suser_sname(), system_user, session_user, current_user, user_name()
And this query returns 0
select USER_ID()
I want the username to query database_role_members is there any function that will return it or any other way I can get the current users roles?
I understand that the Domain Users login is mapped into AD group?
You have to bear in mind that user can be in several AD groups and each of them can be mapped somehow in database which may be a bit messy. Also it means you need something with multiple results :)
Try this:
select * from sys.server_principals where type_desc = 'WINDOWS_GROUP' and is_member(name) = 1
I think it should grab properly all Windows Group logins that will be tied with particular users. After that you can join it for database users i.e.:
Select u.name from YourDB.sys.syslogins l
inner join YourDB.sys.sysusers u
on l.sid = u.sid
where l.loginname = ANY (select * from sys.server_principals where type_desc = 'WINDOWS_GROUP' and is_member(name) = 1)
You have to keep in mind that - all the way - you may need to handle whole sets rather then single values.
I have the following T-SQL to display all the permissions granted to principals on my SQL server 2005:
select dp.NAME AS principal_name, --1
dp.type_desc AS principal_type_desc, --2
o.NAME AS object_name, --3
p.permission_name, --4
p.state_desc AS permission_state_desc --5
from sys.database_permissions p
left OUTER JOIN sys.all_objects o
on p.major_id = o.OBJECT_ID
inner JOIN sys.database_principals dp
on p.grantee_principal_id = dp.principal_id
order by principal_name, object_name
The result displays public with SELECT granted:
1 2 3 4 5
...
public DATABASE_ROLE system_views SELECT GRANT
....
I think object_name system_views is for all the views in my database Views|system_views folder. I tried the following T-SQL (just to see if it works by GRANT again):
GRANT SELECT ON system_views TO public
I got error "Cannot find the object 'system_views', because it does not exist or you don't have permission". I do connect the SQL server as sa.
My question is how to revoke SELECT permission on system_views for public (user or principal?) and roll permission back if I have to. The second question is if the revoke on system_views for public have any side-effect for other users?
There's no reason to revoke rights to view the system views. Users can only see the objects that they already have access to, so they already know those objects exist.
If you want to grant a user the right to see all objects in the database then grant them view definition on the schema or the database.
select * from sys.system_views
Does public have VIEW DEFINITION on any of these?
I would highly recommend against mucking about with any of this.
You could just
DENY VIEW DEFINITION ON SCHEMA::DBO TO PUBLIC
public is a "special" role. Don't mess with it.
Every user is a member of public by default, for example.
Metadata visibility actually determines what a user sees. So even if someone does SELECT * FROM sys.columns, they will see only the columns for objects they have rights on. No other rights = only info on the columns for system views.
You're likely to break stuff if you do this, especially in SSMS or direct access clients (Access, Excel etc)