web-dev-qa-db-fra.com

Réglez TRUSTWORTHY On sent que le courtier de service ne fonctionne pas

J'ai une base de données en cours d'exécution sur un SGBD SQL-Server 2012. Considérez que le serveur exécutant SQL Server ne fait pas partie du domaine réseau. Quand j'exécute cette commande sql

ALTER DATABASE myDatabase SET TRUSTWORTHY ON;

une file d'attente Service Broker (réglée et en état de marche) reçoit des messages mais la procédure stockée activée associée à la file d'attente ne démarre pas. Les messages continuent de circuler dans la file d'attente, mais rien d'autre ne se produit. Dans le journal SQL SERVER, j'ai trouvé ce message

Le processus activé 'proofSchema.mySP' exécuté sur la file d'attente 'proofSCHEMA.myQueue' a généré ce qui suit: 'Le SID du propriétaire de la base de données enregistré dans la base de données master diffère du SID du propriétaire de la base de données enregistré dans la base de données' myDatabase '. Vous devez corriger cette situation en réinitialisant le propriétaire de la base de données 'myDatabase' à l'aide de l'instruction ALTER AUTHORIZATION. '

Si j'exécute cette même configuration sur une machine à l'intérieur d'un domaine réseau, tout fonctionne.

Je ne peux pas comprendre ce qui se passe et pourquoi un écrasement fiable avec la file d'attente Serveur Broker.

sql-serversql-server-2012securityservice-broker
7
zappasan

Dans chaque base de données, il existe un utilisateur dbo. Cet utilisateur (au niveau de la base de données) existe toujours, mais le SID (Security IDentifier) ​​auquel il est mappé n'est pas toujours le même; il sera mappé à toute connexion (au niveau de l'instance) spécifiée lors de la création de la base de données ou modifiée pour avoir un nouveau "propriétaire de la base de données". L'utilisateur dbo est l'une des entrées de sys.database_principals.

Lors de la définition initiale du propriétaire de la base de données pendant CREATE DATABASE, ou lors d'une modification ultérieure, le SID du "propriétaire" n'est pas seulement placé dans sys.database_principals, mais est également enregistré dans master.sys.databases. Si la base de données ne quitte jamais l'instance dans laquelle elle a été créée, il ne devrait jamais y avoir de différence entre les valeurs SID dans sys.database_principals et master.sys.databases. Mais, si la base de données est jamais restaurée ou attachée à (ou depuis) ​​une autre instance, il est possible que les valeurs SID ne correspondent pas. Vous pouvez vérifier les valeurs aux deux endroits à l'aide des requêtes suivantes:

USE [tempdb]; -- Change to whatever DB you want to check

SELECT      msd.owner_sid,
            msp.[name]
FROM        [master].[sys].[databases] msd
INNER JOIN  [master].[sys].[server_principals] msp
        ON  msp.[sid] = msd.[owner_sid]
WHERE       msd.[database_id] = DB_ID();

SELECT sdp.[sid]
FROM   [sys].[database_principals] sdp
WHERE  sdp.[name] = N'dbo';

Désormais, par défaut, TRUSTWORTHY est défini sur OFF et les autorisations sur les opérations impliquant l'emprunt d'identité (c'est-à-dire EXECUTE AS) sont limités à la base de données à partir de laquelle l'opération a été exécutée. Lors de l'emprunt d'identité d'un utilisateur de base de données, en tentant d'accéder à une autre base de données (ou même à des ressources au niveau du serveur/instance, je crois), SQL Server supposera que le SID de l'utilisateur de la base de données actuel (c'est-à-dire celui qui se fait passer) a une connexion correspondante pour qu'il puisse prendre sur ces autorisations. Ceci est bloqué lorsque TRUSTWORTHY est OFF, mais le définir sur ON lève la quarantaine au niveau de la base de données et permet à l'emprunt d'identité de s'étendre au-delà de la base de données initiale. Le SID de l'utilisateur dbo peut certainement exister en tant que connexion, mais s'il ne s'agit pas du même SID qui est mappé en tant que propriétaire de la base de données dans sys.databases, cela indique clairement que quelque chose ne va pas (et très probablement que cette base de données provient d'une autre instance), et qu'il pourrait y avoir une intention malveillante dans l'opération demandée.

6
Solomon Rutzky

Cela peut se produire lorsque vous restaurez une base de données créée sur un autre serveur et que le compte de connexion du propriétaire de la base de données n'existe pas ou a un SID différent sur le serveur sur lequel vous avez restauré.
Choisissez une connexion qui vous convient avec la base de données et exécutez ceci:

ALTER AUTHORIZATION ON DATABASE:: [Database Name Here] TO [Login Name];
4
T.H.