Le serveur principal "XYuser" ne peut pas accéder à la base de données "YDB" dans le contexte de sécurité actuel

Question

Caractéristiques du système

Microsoft SQL Server Management Studio   9.00.4035.00 
Microsoft Analysis Services Client Tools  2005.090.4035.00 
Microsoft Data Access Components (MDAC)   2000.085.1132.00 
               (xpsp.080413-0852) 
Microsoft MSXML         2.6 3.0 4.0 5.0 6.0 
Microsoft Internet Explorer      7.0.5730.13 
Microsoft .NET Framework      2.0.50727.1433 
Operating System        5.1.2600 

Sur un SQL Server 2005 appelé BHAVMSQL02, j'ai deux bases de données Mattercentre_dev et CMSNET_DEV. Le Mattercentre_dev a une procédure stockée qui génère une liste à partir d'une table dans CMSNET_DEV. La procédure stockée ressemble comme ça ...

USE [Mattercentre_dev] 
GO 
/****** Object: StoredProcedure [dbo].[UDSPRBHPRIMBUSTYPE] 
    Script Date:02/12/2009 10:18:10 ******/ 
SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER OFF 
GO 


ALTER PROCEDURE [dbo].[UDSPRBHPRIMBUSTYPE] WITH EXECUTE AS 'Readuser' AS 

DECLARE @SERVERNAME nvarchar(30) 
DECLARE @DBASE nvarchar(30) 
DECLARE @SQL nvarchar(2000) 
SET @SERVERNAME = Convert(nvarchar, 
    (SELECT spData FROM dbSpecificData WHERE spLookup = 'CMSSERVER')) 
SET @DBASE = Convert(nvarchar, 
    (SELECT spData FROM dbSpecificData WHERE spLookup = 'CMSDBNAME')) 

SET @SQL = 
'SELECT 
    null as Code 
    , ''(not specified)'' as Description 
UNION SELECT 
    clnt_cat_code as Code 
    , clnt_cat_desc as Description 
FROM ' 
    + @SERVERNAME + '.' + @DBASE + '.dbo.hbl_clnt_cat 
WHERE 
    inactive = ''N'' 
ORDER BY Description' 
PRINT @SQL 

EXECUTE sp_executeSQL @SQL 

@SERVERNAME == 'BHAVMSQL02' 

@DBASE  == 'CMSNET_DEV' 

Lorsque la procédure stockée a été exécuté le message d'erreur suivant est apparu ...

The server principal "ReadUser" is not able to access the database "CMSNET_DEV" under the current security context. 

Après googler le message d'erreur, je portai le correctif suivant ...

• supprimé le ReadUser utilisateur de BHAVMSQL02 -> bases de données -> Mattercentre_dev -> sécurité -> utilisateurs

• Set Up ReadUser de BHAVMSQL02 -> de sécurité -> Logins avec les paramètres suivants ...

  Général
  Connexion Nom - readUser
  Mot de passe - xxxxxxxxxxxx
  Confirmer - xxxxxxxxxxxx
  Par défaut db - maître
  par défaut lg - Anglais britannique
  Tout le reste - Unset

  Rôles du serveur uniquement Ensemble public

  Mappages utilisateur CMSNET_DEV - ReadUser - dbo
  Base de données des membres de rôle - db_owner publique

  Mattercentre_dev - ReadUser - dbo
  Base de données des membres Rôle - db_owner publique

J'ai ensuite exécuté le script suivant ...

ALTER DATABASE CMSNET_DEV SET TRUSTWORTHY ON 
GO 
ALTER DATABASE mattercentre_dev SET TRUSTWORTHY ON 
GO 

J'ai réexécuté la procédure stockée et l'a exécutée à nouveau et j'ai toujours le même message d'erreur .

J'ai regardé cette question dans Stack Overflow et les solutions suggérées sont similaires aux miennes.

Answer 1

Vous ne pouvez pas utiliser le chaînage de propriété lorsque votre procédure stockée contient du SQL dynamique, ce qui casse la chaîne de propriété.

Pour que cela fonctionne, vous devrez utiliser un certificat pour signer vos procédures stockées.

Vous trouverez ci-dessous un article génial contenant des instructions pour la signature des procédures stockées.

http://www.sommarskog.se/grantperm.html

En regardant ce plus en détail, le fait que vous utilisez le « exécuter comme la clause » devrait nier le fait que la chaîne de propriété est rompue à la suite de l'intégration SQL dynamique. Dans cet esprit, il est probable que, pour une raison ou une autre, le login "ReadUser" ne dispose pas d'un accès en lecture approprié aux bases de données en question, mais cela ne devrait pas être le cas, étant donné que le login est membre du rôle db_owner dans les deux bases de données. Cela dit, si les rôles de la base de données ont été modifiés par rapport à leur état d'origine, cela peut ne pas être vrai. Pour tester que le problème n'est pas isolé du login "ReadUser", je suggère de créer une nouvelle connexion SQL Server et de mapper la connexion aux deux bases de données (en créant des connexions de base de données du même nom) avec un accès en lecture approprié . Ensuite, modifiez la procédure stockée pour l'exécuter en tant que nouvelle connexion.