Quelle est la différence entre EXECUTE AS USER et EXECUTE AS LOGIN qui fait que le second se comporte de façon inattendue?

Récemment, j'ai utilisé EXECUTE AS LOGIN pour vérifier si une certaine personne pouvait ou ne pouvait pas utiliser une fonction de table dans l'une de nos bases de données. Les tests ont montré qu'il le pouvait mais il a signalé à plusieurs reprises un échec.

La personne utilise la connexion «WEB» pour se connecter à la base de données et l'utilisateur «WEB» dans cette base de données est associé à la connexion «WEB», j'ai donc essayé les scripts suivants:

-- part 1
EXECUTE AS USER = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

-- part 2
EXECUTE AS LOGIN = 'WEB'
GO
SELECT 
    USER_NAME() AS 'user_name'
    ,SUSER_NAME() AS 'suser_name'
    ,SUSER_SNAME() AS 'suser_sname'
    ,SYSTEM_USER AS 'system_user'
GO
REVERT
GO

La première partie s'est bien passée avec le résultat de:

WEB | WEB | WEB | LA TOILE

Mais le deuxième résultat était un peu déroutant:

dbo | WEB | WEB | LA TOILE

Quelle est la différence entre EXECUTE AS USER et EXECUTE AS LOGIN qui fait échouer le second? En outre, bien sûr, le premier étant au niveau de la base de données et le second étant l'emprunt d'identité au niveau du serveur, de ce que je sais et n'explique pas la situation ici.

sql-server-2008 security

— gemisigo
source

Le 2ème n'est pas "défaillant", il vous indique simplement que la connexion a un rôle serveur (sysadmin) assigné. Avez-vous vérifié les schémas demandés par l'utilisateur? Avait cela avant où le schéma par défaut de dbo n'est pas celui que les développeurs s'attendaient à ce qu'il soit. Mieux corrigé dans le code en référençant entièrement le tableau

— Stuart Moore

Un membre du sysadmingroupe est toujours mappé dbo, même s'il a un utilisateur explicite dans la base de données. Il semble donc que la connexion WEBsoit membre de sysadmin, donc USER_NAME()retourne correctement dbodans le deuxième cas.

— Remus Rusanu
source

Vérifié et confirmé. C'était un membre de sysadmin en effet. Il s'est avéré que ce rapport a atteint l'un des autres développeurs et au lieu de la bonne solution, il a simplement attribué le rôle sysadmin de connexion. Je ne penserais même pas à cela, je suis vraiment déçu. Nous allons avoir des discussions sérieuses quand il reviendra. J'ai appris quelque chose de nouveau aujourd'hui, merci.

— gemisigo

Cela signifie également que votre application (rapport?) Dispose d'une autorisation d'emprunt d'identité sur un membre sysadmin. Regardez comment exactement dans la hiérarchie des autorisations cela est accordé. Il est probable que même maintenant, le rapport peut, s'il le souhaite, se faire passer pour un autre sysadminmembre, de sorte que l'application de signalement est un administrateur système de facto. C'est à dire. En tant que vecteur d'attaque d'élévation de privilèges possible, il peut être utilisé par un pirate ou, plus probablement, par votre personnel.

— Remus Rusanu

Si l'application Repor a l'autorisation IMPERSONATE activée WEBet a WEBété supprimée, sysadminla porte est fermée. Mais vaut la peine d'être vérifié néanmoins.

— Remus Rusanu

Oui, nous devrons vérifier à nouveau tout ce qui affecte les droits pour voir si d'autres problèmes ont été "résolus" de cette façon. Pas très content en ce moment :( Merci encore, Remus.

— gemisigo