Nhận được quyền Cho phép CHỌN đã bị từ chối trên đối tượng, mặc dù nó đã được cấp

Tôi là một lập trình viên, không phải là một dba ... Tôi biết chỉ đủ nguy hiểm.

Tôi đã kế thừa cơ sở dữ liệu với người dùng cũ là db_owner cho cơ sở dữ liệu. Chúng tôi không thể điều chỉnh sự cho phép của người dùng này đối với các bảng, lược đồ hiện có, v.v., vì lý do kinh doanh, nhưng một số bảng mới đang được tạo và tôi chỉ muốn người dùng này có quyền truy cập CHỌN trên chúng.

Quyền đã được đặt cho người dùng này đối với các bảng này để mọi thứ đều bị TỪ CHỐI, ngoại trừ CHỌN, được đặt thành GRANT.

Tuy nhiên, khi người dùng này (dbadmin) cố gắng thực hiện CHỌN trên một trong các bảng này (AccountingAudit), lỗi này xảy ra:

The SELECT permission was denied on the object 'AccountingAudit', database 'billing', schema 'dbo'.

Tôi đã chạy SQL này để thử và xem những quyền nào được đặt cho bảng / người dùng này:

select object_name(major_id) as object,
 user_name(grantee_principal_id) as grantee,
 user_name(grantor_principal_id) as grantor,
 permission_name,
 state_desc
from sys.database_permissions

Và đây là những gì tôi nhận lại:

AccountingAudit dbadmin dbo ALTER   DENY
AccountingAudit dbadmin dbo CONTROL DENY
AccountingAudit dbadmin dbo DELETE  DENY
AccountingAudit dbadmin dbo INSERT  DENY
AccountingAudit dbadmin dbo REFERENCES  DENY
AccountingAudit dbadmin dbo SELECT  GRANT
AccountingAudit dbadmin dbo TAKE OWNERSHIP  DENY
AccountingAudit dbadmin dbo UPDATE  DENY
AccountingAudit dbadmin dbo VIEW DEFINITION DENY
AccountingAudit dbadmin dbo VIEW CHANGE TRACKING    DENY

Có vẻ như nó nên được làm việc phải không?

Cuộc gọi CHỌN tôi đang thực hiện là một CHỌN rất cơ bản * TỪ AccountingAudit, từ bên trong SSMS. Tôi không làm bất kỳ sp_executesql đặc biệt hoặc bất cứ điều gì tương tự.

Tôi đã cố gắng cấp phép rõ ràng:

GRANT SELECT ON [dbo].AccountingAudit TO dbadmin

Điều này không có tác dụng (tại sao nó, truy vấn ở trên đã cho thấy nó được cấp! ;-)

Tôi đã tìm kiếm thông qua stackoverflow.com và các nơi khác, và không thể tìm thấy bất cứ điều gì tôi chưa thử. Tôi tự hỏi nếu nó có một cái gì đó để làm với cách các lược đồ được thiết lập. (Tại thời điểm này tôi biết rất ít về lược đồ.)

Có ý kiến ​​gì không? Cảm ơn!

Tôi không chắc ở đây, nhưng tôi sẽ đi ra ngoài. Tôi nghĩ vấn đề của bạn có thể là với DENY CONTROLhồ sơ của bạn . Xem ở đây khoảng một nửa trang:

Từ chối quyền KIỂM SOÁT trên cơ sở dữ liệu ngầm từ chối quyền CONNECT trên cơ sở dữ liệu. Hiệu trưởng bị từ chối quyền KIỂM SOÁT trên cơ sở dữ liệu sẽ không thể kết nối với cơ sở dữ liệu đó.

Tôi nhận ra ví dụ đó là cho một cơ sở dữ liệu, nhưng hãy xem nó ở cấp độ chi tiết hơn. A DENY CONTROLtrên bàn sẽ từ chối tất cả các đặc quyền trên đó, tôi đoán vậy. Làm một REVOKE CONTROLđể thoát khỏi điều đó và xem nếu điều đó khắc phục vấn đề của bạn.

Nếu vậy, bạn sẽ phải đặt người dùng vào vai trò cơ sở dữ liệu hoặc từ chối họ các đặc quyền rõ ràng đối với bảng.

1. Sử dụng Ken Fisher sp_DBPermissionsthủ tục lưu trữ để xem xét các điều khoản.

   1. Hãy chắc chắn rằng DENY CONTROLkhông được áp dụng cho bảng, ngoài việc phổ biến DENY SELECT, DENY INSERT, DENY UPDATE, DENY DELETEvà DENY REFERENCES.
   2. Nếu SELECTcâu lệnh chứa các hàm có giá trị bảng, hãy đảm bảo có một hàm EXECUTE AS OWNERtrên giá trị bảng hoặc một hàm GRANT EXECUTEtrên nó (và không DENY EXECUTE!). Nếu đây là trường hợp, hãy đọc thông báo lỗi cẩn thận hơn vì có thể sẽ không nói rằng quyền CHỌN đã bị từ chối trên bàn, nhưng thay vào đó, một cái gì đó về EXECUTE bị từ chối.

2. Nếu người dùng là người dùng hoặc nhóm AD, hãy sử dụng tập lệnh sau để xác định login_token(các) người dùng :

EXECUTE AS LOGIN = 'EXAMPLEDOMAIN\JOHN.DOE';
SELECT * FROM sys.login_token;
REVERT;

3. Nhìn vào kế hoạch thực hiện thực tế. Nếu lỗi nằm trong một thủ tục được lưu trữ SET NOCOUNT ON;, thì kế hoạch thực hiện thực tế sẽ cho bạn cái nhìn sâu sắc mà bạn có thể không chú ý bằng cách chỉ nhìn vào tab Tin nhắn trong SSMS, vì "Hàng bị ảnh hưởng" có thể nằm ngoài tầm kiểm soát của bạn.

   1. Tìm kiếm các kích hoạt hoặc bảng thời gian.

4. Bạn có thể biên dịch câu lệnh dưới dạng một thủ tục được lưu trữ và SSMS "Xem phụ thuộc đối tượng", cũng như các thủ thuật được đưa ra bởi Svetlana Golovko theo các cách khác nhau để tìm phụ thuộc đối tượng máy chủ SQL

5. Sử dụng sự kiện SQL Server Profiler Security "Sự kiện truy cập đối tượng lược đồ kiểm toán" và các cột "TextData" và "Thành công" để theo dõi đối tượng SQL Server nào đang đánh giá quyền. - Tôi đã thấy các tình huống có hai hàng được phát ra cho sự kiện này và một giá trị cho biết Thành công = 1 và hàng còn lại cho biết Thành công = 0. Trong kịch bản này, giải pháp duy nhất tôi tìm thấy để làm việc là khởi động lại máy chủ. Ngay cả khi chạy repadmin /syncallcũng không khắc phục được sự cố, cũng không khởi động và dừng ứng dụng (và do đó là nhóm kết nối).

6. Xác định các quyền hiệu quả cho đăng nhập:

-- '<domain>\<username>' is a domain user in the group you wish to test
EXECUTE AS LOGIN = '<domain>\<username>';
SELECT * FROM fn_my_permissions('Database.Schema.Table', 'OBJECT');
REVERT;

8. Nếu người dùng bị ràng buộc với người dùng hoặc nhóm AD, hãy xem xét việc chạy repadmin /syncallđể buộc mọi thay đổi được thực hiện trong thư mục hoạt động để đồng bộ hóa qua các bộ điều khiển miền của bạn. - Nếu ai đó biết một cách tốt để so sánh các giá trị hiện tại của hai bộ điều khiển miền, vui lòng cho tôi biết.

9. Trước khi xem xét khởi động lại toàn bộ hệ thống, hãy thử tắt tất cả các kết nối hoạt động cho người dùng đó. Lý do là người dùng nhận được mã thông báo windows của họ từ DC bao gồm các nhóm của họ. Mã thông báo sẽ không được cập nhật cho đến khi người dùng nhận được mã thông báo mới - thường bằng cách đăng xuất và sau đó đăng nhập lại.

10. Khó khởi động lại hệ thống. Nó đã làm cho tôi. Vẫn chưa chắc chắn 100% tại sao. CHỈ LÀM ĐIỀU NÀY NẾU BẠN CÓ THỂ KIẾM THỜI GIAN XUỐNG! HÃY CẨN THẬN VỀ VIỆC LÀM ĐIỀU NÀY KHI BẠN CÓ NHỮNG GIAO DỊCH TUYỆT VỜI!