it-swarm-fr.com

L'autorisation Select a été refusée sur l'objet (Afficher) après une subvention explicite Sélectionner à la vue de l'utilisateur.

J'ai une base de données avec vue nommée '1098Statement' Nous effectuons des tests pour une application avec nom d'utilisateur 'Appuser'.

J'ai essayé les solutions suivantes à la sélection de Sélectionner sur la vue et de continuer à obtenir une erreur:

  1. Grant Sélectionner sur la vue
  2. Ajouter l'utilisateur à db_datareader
  3. Ajouter un utilisateur à un rôle de base de données qui a sélectionné accordé à la vue

    MSG 229, niveau 14, état 5, ligne 2 La permission de Select a été refusée sur l'objet "1098Statement", base de données "mydb", schéma "DBO".

Aucun d'entre eux ne fonctionne.

Y a-t-il des indicateurs que quiconque peut fournir sur le dépannage de ce problème.

Mes seules pensées restantes sont à vérifier

  1. le compte d'utilisateur à voir s'il existe des restrictions explicites "refuser" sur l'utilisateur ou les rôles que le compte appartient.
  2. vérifiez la vue pour voir s'il y a une indy explicite
6
johndacostaa

Votre réponse m'a pointé dans la bonne direction.

Après avoir examiné l'objet et vérifiant les autorisations à plusieurs reprises, je me suis concentré sur la connexion et l'utilisateur.

Apparemment, la connexion est mappée sur un autre utilisateur. Alors, quand j'ai vérifié le serveur_principal contre la base de données_principal, il y avait une inadéquation.

Le login s'appelle Appuser et j'essaie également d'accorder des autorisations dans la base de données à Appuser. Malheureusement, une personne a créé un autre utilisateur de base de données qui est appelé AppWebuser.

Donc, une fois que j'ai découvert que nous accordions des autorisations à la mauvaise utilisation et mettons à jour le code à l'utilisateur de la base de données correct, le problème a été résolu.

J'ai utilisé la requête suivante pour suivre le login. J'ajoute dans le nom de serveur et dbname afin que je puisse vérifier sur mes différents environnements et signaler au client.

SELECT 
@@servername  as [server_name]
,db_name()  as [database_name]
,sp.name as [server_principal_name]
,sp.type as [server_principal_type]
,sp.type_desc as [server_principal_type_desc]
,sp.create_date as [server_principal_create_date]
,sp.default_database_name as [server_principal_default_database_name]
,dp.name as [database_principal_name]
,dp.type as [database_principal_type]
,dp.type_desc as [database_principal_type_desc] 
,dp.default_schema_name as [database_principal_default_schema_name]
FROM 
    sys.database_principals  dp INNER JOIN
    sys.server_principals sp ON (dp.sid = sp.sid)
WHERE 
    sp.name like 'appuser'
    or dp.name like  'appuser'
    or sp.name like 'appwebuser'
    or dp.name like  'appwebuser'
4
johndacostaa

Vous pouvez vérifier les autorisations (NYY est une permission) dans SYS.DATABASE_PERMISSIONS

Vous pouvez également avoir une inadéquation d'utilisateur de connexion VS à partir d'une restauration. Regardez sp_change_users_login (toujours utile bien que obsolète)

Avez-vous un serveur lié ou un SQL dynamique aussi qui change de contexte de sécurité? exemple

Enfin, une pensée, 1098Statement n'est pas un identifiant valide . Vous devez l'utiliser avec des délimiteurs [1098Statement]

3
gbn