Rozwiązywanie problemów z metadanych widoczności

Aby umożliwić użytkownikom wyświetlanie metadanych

Aby umożliwić użytkownikom minimalne uprawnienia Zobacz wszystkie metadane, uruchom jeden z następujących instrukcji:

• GRANT VIEW ANY DEFINITION TO public;

  Ta instrukcja zastępują ograniczenia widoczności metadane w wystąpienie poziom.Wszystkie metadane w wystąpienie będą widoczne dla public.

• GRANT VIEW DEFINITION TO public;

  Ta instrukcja zastępują ograniczenia widoczności metadane poziom bazy danych.Wszystkie metadane w bazie danych będą widoczne dla public.

• GRANT VIEW DEFINITION ON SCHEMA :: <schema_name> TO public;

  Ta instrukcja zastępują ograniczenia widoczności metadane poziom schematu.Wszystkie metadane w schemacie będą widoczne dla public.

• GRANT VIEW DEFINITION ON OBJECT :: <object_name> TO public;

  Ta instrukcja zastępują ograniczenia widoczności metadane poziom obiektu.Wszystkie metadane obiektu będzie widoczna dla public.Jeśli obiekt jest spis wszystkich kolumn, indeksy, statystyki i ograniczeń tabela będą widoczne dla public.Zachowanie to stosuje się również do montażu w definicji WIDOKU dotacji i innych podobnych sprawozdań dotacji.

Aby włączyć określonego użytkownika minimalne uprawnienia lub roli wyświetlić wszystkie metadane, należy użyć określonej nazwy użytkownika lub rolę jako grantee zamiast public.

Aby pozwalają użytkownikom widzieć się nawzajem

Domyślnie użytkownicy, którzy mają uprawnienia minimalne nie widać innych użytkowników w sys.database_principals i sys.server_principals widoki wykazu.Oznacza to, że użytkownik z uprawnieniami minimalny, który jest właścicielem tabela nie widać innych użytkowników, do których użytkownik może chcieć udzielić uprawnień.Aby pozwolić użytkownikowi user_X z minimalnymi uprawnieniami innego użytkownika, zobacz user_Y, można wydać następujące GRANT instrukcja:

• GRANT VIEW DEFINITION ON USER :: <user_Y> TO <user_X>

Należy uruchomić tej instrukcja dla każdego użytkownika.Można zautomatyzować proces tworzenia wyzwalacz DLL podobny do następującego:

CREATE TRIGGER grant_view_definition_on_principal ON DATABASE
FOR CREATE_USER, CREATE_ROLE
AS
    DECLARE @event_type sysname, @principal_name sysname, @sql nvarchar(max);
    SELECT @event_type     = eventdata().value('(/EVENT_INSTANCE/EventType) [1]','sysname');
    SELECT @principal_name = eventdata().value('(/EVENT_INSTANCE/ObjectName)[1]','sysname');
    IF (@event_type = 'CREATE_USER')
        SELECT @sql = 'GRANT VIEW DEFINITION ON USER :: ' + @principal_name + ' TO PUBLIC ' ;
    ELSE
        SELECT @sql = 'GRANT VIEW DEFINITION ON ROLE :: ' + @principal_name + ' TO PUBLIC ' ;
    EXEC (@sql) ;
GO

Aby umożliwić metadanych aplikacji role Zobacz poziomie serwera

rola aplikacji nie może uzyskać dostępu metadane poza własną bazę danych, ponieważ rola aplikacji nie są skojarzone z głównego poziom serwera.Można stosować następujące metody w umożliwiają ról aplikacji, zobacz metadane poziom serwera.

Ustaw flagę śledzenia

Aby umożliwić aplikacji role dostępu poziom serwera metadane do zestaw 4616 flagę globalną.Informacje o ustawienie flagi śledzenia Zobacz DBCC TRACEON (Transact-SQL).Aby uzyskać informacje dotyczące flagi śledzenia 4616, zobacz Flagi śledzenia (Transact-SQL).

Użyj procedura składowana certyfikat podpisany

Zaleca się używania certyfikat podpisany procedur dostępu poziom serwera do tabele systemowe.Certyfikat podpisany procedury mają następujące zalety:

• Nie trzeba użyć flagi śledzenia.

• Mniej informacji poziom serwera może zostać ujawniona.Aplikacje oparte na rolach aplikacji należy użyć procedury przechowywane, zamiast kwerendy ogólne.Procedury przechowywane są bardziej prawdopodobne przywrócić tylko określone dane wymagane przez aplikację.

• Poniższy przykład tworzy procedura składowana certyfikat podpisany i demonstruje, jak rola aplikacji procedura służy do wyświetlania metadane poziom serwera.

USE master;
GO 
CREATE DATABASE approle_db; 
GO 
CREATE LOGIN some_login WITH PASSWORD = '<enterStrongPasswordHere>'; 
GO 
USE approle_db; 
GO 
CREATE USER some_user FOR LOGIN some_login; 
GO
EXEC sp_addapprole 'an_approle', '<enterStrongPasswordHere>'; 
GO
--------------------------------------------------------------------- 
-- This section shows how to use a certificate to authenticate 
-- a signed procedure.
--------------------------------------------------------------------- 
CREATE LOGIN execute_as_login WITH PASSWORD = '<enterStrongPasswordHere>'; 
GO 
USE master; 
GO 
GRANT VIEW ANY DEFINITION TO execute_as_login; 
GRANT VIEW SERVER STATE TO execute_as_login; 
GO 
USE approle_db;
GO 
CREATE USER execute_as_user FOR LOGIN execute_as_login; 
GO 
--
-- You must use EXECUTE AS 'authenticator' here because the application role 
-- does not have a server identity. Therefore, the application role cannot use 
-- the certificate permissions on the server. Therefore, you 
-- need a new execution context to which you can grant 
-- the needed VIEW* permissions. 
-- 
CREATE PROC access_server_system_tables 
    WITH EXECUTE AS 'execute_as_user' 
    AS 
    SELECT sid, status, name, dbname, hasaccess, loginname 
        FROM master.dbo.syslogins; 
    SELECT spid, kpid, lastwaittype, waitresource, dbid 
        FROM master.dbo.sysprocesses; 
GO 
GRANT EXECUTE ON access_server_system_tables TO an_approle; 
GO 
CREATE CERTIFICATE signing_cert 
    ENCRYPTION BY PASSWORD = '<enterStrongPasswordHere>' 
    WITH SUBJECT = 'Signing Cert'; 
GO 
BACKUP CERTIFICATE signing_cert TO FILE = 'signing_cert.cer'; 
GO 
ADD SIGNATURE TO access_server_system_tables
    BY CERTIFICATE signing_cert WITH PASSWORD = '<enterStrongPasswordHere>';
GO
--------------------------------------------------------------------- 
-- Create a copy of the signing certificate in the target 
-- database. In this case, the target database is the master database. 
-- This copy of the signing certificate vouches for the execution context
-- that enters this database from the signed procedure. 
--------------------------------------------------------------------- 
USE master; 
GO 
CREATE CERTIFICATE signing_cert FROM FILE = 'signing_cert.cer'; 
GO 
--------------------------------------------------------------------- 
-- Because the VIEW permissions in question are server-level permissions,
-- we need to grant AUTHENTICATE SERVER permission on a login-mapped certificate. 
--------------------------------------------------------------------- 

CREATE LOGIN signing_cert_login FROM CERTIFICATE signing_cert; 
GO 
GRANT AUTHENTICATE SERVER TO signing_cert_login 
GO 
--------------------------------------------------------------------- 
-- Now you can open a new connection as "some_login" and 
-- set the application role. Then, call the "access_server_system_tables"
-- procedure, and obtain verification that you can access server-level information 
-- when the application role-based application runs. 
-- For an example, see the Demo usage.sql code below.
--------------------------------------------------------------------- 

--------------------------------------------------------------------- 
-- Clean up. 
-- The following statements remove the objects created above.
--------------------------------------------------------------------- 
USE master 
GO 
DROP DATABASE approle_db; 

DROP LOGIN some_login; 
GO 
DROP LOGIN execute_as_login; 
GO 
DROP LOGIN signing_cert_login; 
GO 
DROP CERTIFICATE signing_cert; 
GO 
-- 
-- Delete the certificate file. 
-- 
EXEC sp_configure 'show advanced options', 1; 
GO 
RECONFIGURE; 
GO 
EXEC sp_configure 'xp_cmdshell', 1; 
GO 
RECONFIGURE; 
GO 
EXEC xp_cmdshell 'del "C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Data\signing_cert.cer"'; 
GO 
EXEC sp_configure 'xp_cmdshell', 0; 
GO 
RECONFIGURE; 
GO 

-- ============================================================================
-- - Application role access to server information - Demo usage.sql
--
--  This code is companion code that shows an example of application role access
--  to server information by using a certificate-signed procedure.
--
-- ============================================================================
--  -------------------------------------------------- 
-- Connect as some_login first.
-- ------------------------------------------------ 
USE approle_db;
GO
EXEC sp_setapprole 'an_approle', '<enterStrongPasswordHere>';
GO
-- Display the server-level information the application role can currently view. 
SELECT sid, status, name, dbname, hasaccess, loginname 
FROM master.dbo.syslogins; 
SELECT spid, kpid, lastwaittype, waitresource, dbid 
FROM master.dbo.sysprocesses; 
GO 
-- Display the server-level information the application role
-- can view by running the certificate-signed stored procedure.
EXEC access_server_system_tables;
GO

Zobacz także

Zadania

Koncepcje