Запрос к sys.server_principals не возвращает собственный логин

Question

У меня есть следующий запрос SQL Server:

SELECT dbp2.name AS nombre
   FROM sys.server_principals AS sp JOIN 
   sys.database_principals AS dbp ON sp.sid=dbp.sid JOIN
   sys.database_role_members AS dbrm ON dbp.principal_Id=dbrm.member_principal_Id JOIN
   sys.database_principals AS dbp2 ON dbrm.role_principal_id=dbp2.principal_id
   WHERE dbp.name = SUSER_NAME() AND dbp2.name NOT LIKE 'db_%';

Это возвращает роли базы данных, к которой принадлежит текущий пользователь, и я использую эту информацию для проверки разрешений внутри моего приложения (я использую только пользователей Windows). По неизвестной причине этот запрос возвращается пустым для обычного пользователя, но если я выполню этот запрос как пользователь сисадмина, меняя SUSER_SNAME() на пользователя, которого я хочу, он возвращает данные. После нескольких тестов я обнаружил, что когда я вошел в систему как пользователь без привилегий sysadmin, системное представление sys.server_principals не возвращает собственный логин пользователя, поэтому соединение с другими представлениями не возвращает данных. В документации Microsoft об этом виде системы указано, что

Любой логин может видеть свое собственное логин, системные логины и фиксированные роли сервера

Фактически, запрос возвращает системные логины и фиксированные роли сервера, но не имеет собственного логина пользователя. Я пытался найти какую-либо подсказку, почему это происходит без удачи. До сих пор я тестировал это поведение в SQL 2014/2016 в Windows 7/8/10 или Windows Server 2012 с тем же результатом.

Ожидаемый результат от запроса sys.server_principals должен быть таким:

• са
• общественности
• сисадмин
• securityadmin
• ServerAdmin
• setupadmin
• processadmin
• diskadmin
• DBCreator
• bulkadmin
• ДОМЕН \ имя_пользователя

Есть ли какая-либо конфигурация, которую я должен предоставить пользователю на уровне домена или на уровне SQL Server, чтобы этот запрос работал? Заранее благодарю за любую помощь.

Answer 1

После многих попыток я обнаружил, что проблема в базе данных. Я выполнил это заявление:

ALTER DATABASE XXX SET TRUSTWORTHY ON

Это решило мою проблему. Однако, это решение немного горькое, потому что этот запрос должен работать без каких-либо дополнительных разрешений согласно документации.