Ignorowane uprawnienia MS SQL

0

Witam,
mam taki problem.
Pracuję na MS SQL Management Studio + SQL Express na sąsiedniej maszynie w lan.
Będąc zalogowany do bd jako administrator, nadaję uprawnienia do procedur składowanych.
Na drzewie obiektów wskazuję procedurę A, potem properties/permissions, wybieram użytkownika X, nadaję mu jedyne uprawnienie do EXECUTE.
Uzytkownik ten nadal nie może odpalić procedury. Dostaje on błąd:

Msg 229, Level 14, State 5, Server WIN-46R9FVCBPCO\SQLEXPRESS, Procedure sp_BackupDatabases, Line 1
The EXECUTE permission was denied on the object 'sp_BackupDatabases', database 'master', schema 'dbo'.

Gorzej. Na procedurze innej, gdzie użytkownik miał juz wczesniej nadane uprawnienia i z niej korzystał - odbieram mu je na próbę żeby zobaczyć czy dostanie odmowę.
I co? Odmowy brak, użytkownik może nadaużuwać procedury. A użytkownika nawet nie ma na liście...
Co robię źle?
Może to sprawa jakiegoś mapowania użytkowników/loginów.
Używam logowania SQL nie Windowsowego.

0

Odbierasz to dajesz mu DENY?

0

Nie. Odznaczałem ale DENY nie dałem.
Już sprawdzam co gdy dam DENY.

0

Jak dam DENY to użytkownik dostaje błąd że nie ma uprawnień.
Czyli poprawnie.
Jakie to rzuca światło na sprawę ?

0

żadnego ;)
Wiemy, ze działa poprawnie.

Zweryfikujmy nadanie uprawnień. Pusc odpowiednio podmieniajac:

GRANT EXECUTE on [dbo].[sp_BackupDatabases] to [nazwauzytkownikaX]

I sprawdź czy zadziała.

0

Puściłem
Command(s) completed successfully.
A do procedury nadal dostepu brak.

NIe wiem czy to ma znaczenie, ale uzytkownik który próbuje uzyskać dostęp jest zalogowany jako admin na maszynie s SQL-em.
Używa klienta SQLCMD czyli z linii poleceń podając jawnie użytkownika i hasło w trybie autentyfikacji SQL (nie przez login windowsowy)

0

No to upewnij się że łaczysz się prawidlowym użytkownikiem:

select suser_sname()

I sprawdzić jak wygladają uprawnienia:

sp_helprotect 'dbo.sp_BackupDatabases'
0

Tak, kwerenda Select suser_sname() odpalona przez klienta niemogącego uzyskać dostępu dała w wyniku login z którym ten klient sie loguje (Wojtek).
Druga kwerenda sp_helpprotect dała:
Object Grantee Grantor Owner ProtectType Action Column
sp_BackupDatabases Wojtek dbo dbo Grant ALTER .
sp_BackupDatabases Wojtek dbo dbo Grant CONTROL .
sp_BackupDatabases Wojtek dbo dbo Grant Execute .
sp_BackupDatabases Wojtek dbo dbo Grant TAKE OWNERSHIP .
sp_BackupDatabases Wojtek dbo dbo Grant VIEW DEFINITION .

poprzesuwało się, ale wszędzie jest
Grantee: Wojtek
Grantor dbo
do wszystkich rodzajów dostępu

0

Zwrócila tylko dla Wojtek czy nie pokazałes reszty?

0

Pokazałem cały wynik.

0

Równolegle sprawdziłem uprawnienia dla drugiej procedury o której pisałem że użytkownik nie powinien mieć dostępu a ma.
Zwrócony wynik podaje jednego użytkownika R_SERVER (innego niż Wojtek):
Owner Object Grantee Grantor ProtectType Action Column
dbo getItem R_SERVER dbo Grant Execute .

A użytkownik Wojtek i tak ma do niej dostęp...

0

To też był cały wynik.

0

No to to musi być "wyżej:

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' AND DP1.name = 'wojtek'

i to

SELECT  
    [UserName] = CASE princ.[type] 
                    WHEN 'S' THEN princ.[name]
                    WHEN 'U' THEN ulogin.[name] COLLATE Latin1_General_CI_AI
                 END,
    [UserType] = CASE princ.[type]
                    WHEN 'S' THEN 'SQL User'
                    WHEN 'U' THEN 'Windows User'
                 END,  
    [DatabaseUserName] = princ.[name],       
    [Role] = null,      
    [PermissionType] = perm.[permission_name],       
    [PermissionState] = perm.[state_desc],       
    [ObjectType] = obj.type_desc,--perm.[class_desc],       
    [ObjectName] = OBJECT_NAME(perm.major_id),
    [ColumnName] = col.[name]
FROM    
    --database user
    sys.database_principals princ  
LEFT JOIN
    --Login accounts
    sys.login_token ulogin on princ.[sid] = ulogin.[sid]
LEFT JOIN        
    --Permissions
    sys.database_permissions perm ON perm.[grantee_principal_id] = princ.[principal_id]
LEFT JOIN
    --Table columns
    sys.columns col ON col.[object_id] = perm.major_id 
                    AND col.[column_id] = perm.[minor_id]
LEFT JOIN
    sys.objects obj ON perm.[major_id] = obj.[object_id]
WHERE 
    princ.[type] in ('S','U')
UNION
--List all access provisioned to a sql user or windows user/group through a database or application role
SELECT  
    [UserName] = CASE memberprinc.[type] 
                    WHEN 'S' THEN memberprinc.[name]
                    WHEN 'U' THEN ulogin.[name] COLLATE Latin1_General_CI_AI
                 END,
    [UserType] = CASE memberprinc.[type]
                    WHEN 'S' THEN 'SQL User'
                    WHEN 'U' THEN 'Windows User'
                 END, 
    [DatabaseUserName] = memberprinc.[name],   
    [Role] = roleprinc.[name],      
    [PermissionType] = perm.[permission_name],       
    [PermissionState] = perm.[state_desc],       
    [ObjectType] = obj.type_desc,--perm.[class_desc],   
    [ObjectName] = OBJECT_NAME(perm.major_id),
    [ColumnName] = col.[name]
FROM    
    --Role/member associations
    sys.database_role_members members
JOIN
    --Roles
    sys.database_principals roleprinc ON roleprinc.[principal_id] = members.[role_principal_id]
JOIN
    --Role members (database users)
    sys.database_principals memberprinc ON memberprinc.[principal_id] = members.[member_principal_id]
LEFT JOIN
    --Login accounts
    sys.login_token ulogin on memberprinc.[sid] = ulogin.[sid]
LEFT JOIN        
    --Permissions
    sys.database_permissions perm ON perm.[grantee_principal_id] = roleprinc.[principal_id]
LEFT JOIN
    --Table columns
    sys.columns col on col.[object_id] = perm.major_id 
                    AND col.[column_id] = perm.[minor_id]
LEFT JOIN
    sys.objects obj ON perm.[major_id] = obj.[object_id]
UNION
--List all access provisioned to the public role, which everyone gets by default
SELECT  
    [UserName] = '{All Users}',
    [UserType] = '{All Users}', 
    [DatabaseUserName] = '{All Users}',       
    [Role] = roleprinc.[name],      
    [PermissionType] = perm.[permission_name],       
    [PermissionState] = perm.[state_desc],       
    [ObjectType] = obj.type_desc,--perm.[class_desc],  
    [ObjectName] = OBJECT_NAME(perm.major_id),
    [ColumnName] = col.[name]
FROM    
    --Roles
    sys.database_principals roleprinc
LEFT JOIN        
    --Role permissions
    sys.database_permissions perm ON perm.[grantee_principal_id] = roleprinc.[principal_id]
LEFT JOIN
    --Table columns
    sys.columns col on col.[object_id] = perm.major_id 
                    AND col.[column_id] = perm.[minor_id]                   
JOIN 
    --All objects   
    sys.objects obj ON obj.[object_id] = perm.[major_id]
WHERE
    --Only roles
    roleprinc.[type] = 'R' AND
    --Only public role
    roleprinc.[name] = 'public' AND
    --Only objects of ours, not the MS objects
    obj.is_ms_shipped = 0
ORDER BY
    princ.[Name],
    OBJECT_NAME(perm.major_id),
    col.[name],
    perm.[permission_name],
    perm.[state_desc],
    obj.type_desc--perm.[class_desc] 
0

O kurcze.
Pierwsza dała wynik zerowy, a druga 203 wiersze...
Za cienki jestem żeby to zrozumieć. Czego szukać?

0

Co widzę:

  • UserName = DatabaseUserName w każdym przypadku
  • w wyniku nie zaistniała kwerenda która stanowi problem dla użytkownika Wojtek
0

DENY w kolumnie permissionstate

0

Nie ma ani jednego Deny w kolumnie Permission State.

Wszystkie obiekty typu SQL_STORED_PROCEDURE mają GRANT na wszystkich rodzajach dostepu.

ALE (!) wśród obiektów nie ma procedury sp_BackupDatabases.

To chyba dziwne? Inne sa a tej nie ma.

Kwerendę odpaliłem z konta sa oczywiście

0

Użytkownik Wojtek ma GRANT do wszystkich obiektów (procedur i tabel).
Ale wsród nich nie ma tej procedury o którą chodzi.

0

Może brak uprawnien do schematu dbo na bazie master, nadaj

GRANT EXECUTE ON SCHEMA ::dbo TO wojtek
0

Panczo

za 1-2h będę mógł sprawdzić
dziękuję za cierpliwość i proszę o jeszcze trochę

0

Panczo
dziękuję za poświęcony czas.
Okazało się że to ja pochrzaniłem. Jak mogło być inaczej.
Omyłkowo umieściłem procedurę składowaną w dwóch miejscach,
raz omyłkowo w jednej z baz użytkowych
drugi raz tam gdzie miała być czyli w master.
Potem działałem na jednej a próbowałem odpalić drugą:)
Tak to jest jak się ma (nieświadomie) bliźniacze obiekty a nie podaje pełnych ścieżek albo nie zmienia kontekstu za pomocą USE.

Dziękuję za niezłą lekcję zaawansowanego administrowania serwerem.

1

Złą praktyką jest nadawanie uprawnień bezpośrednio dla użytkownika.
Powinieneś oprzeć zabezpieczenia na poziomie ról lub schematów, wtedy zakładając nowego użytkownika przypisujesz go do konkretnej roli i wszystko śmiga.
Najwieksza zaleta to taka, że masz przetestowane uprawnienia i nie musisz ich zmieniać w przypadku dodawania użytkownika, a jak potrzebujesz to "hurtem" modyfikujesz wszystkim zainteresowanym.

1 użytkowników online, w tym zalogowanych: 0, gości: 1