web-dev-qa-db-ja.com

信頼性をオンに設定すると、サービスブローカーが機能しなくなります

SQL-Server 2012 DBMSでデータベースを実行しています。 SQL Serverを実行しているサーバーがネットワークドメインの一部ではないことを考慮してください。このSQLコマンドを実行すると

ALTER DATABASE myDatabase SET TRUSTWORTHY ON;

service Brokerキュー（早期に設定され、機能している）はメッセージを受信しますが、キューに関連付けられているアクティブなストアドプロシージャが開始されません。メッセージは引き続きキューに流れ込みますが、それ以外は何も起こりません。 SQL SERVERログでこのメッセージを見つけました

キュー 'proofSCHEMA.myQueue'で実行中のアクティブ化されたプロシージャ 'proofSchema.mySP'は、次のように出力します。 ALTER AUTHORIZATIONステートメントを使用してデータベース 'myDatabase'の所有者をリセットすることにより、この状況を修正する必要があります。

ネットワークドメイン内のマシンでこれと同じ構成を実行すると、すべてが機能します。

私は何が起こっているのか、そしてなぜserviブローカーのキューで信頼できるクラッシュができるのか理解できません。

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

各データベース内にはdboユーザーが存在します。このユーザー（データベースレベル）は常に存在しますが、マッピング先のSID（セキュリティIDentifier）は常に同じとは限りません。データベースを作成するとき、または新しい「データベース所有者」を持つように変更されたときのいずれかで指定されたログイン（インスタンスレベル）にマップされます。 dboユーザーは、sys.database_principalsのエントリの1つです。

CREATE DATABASEでデータベース所有者を最初に設定するとき、または後で変更するとき、「所有者」のSIDはsys.database_principalsに配置されるだけでなく、master.sys.databasesにも記録されます。データベースが作成されたインスタンスをデータベースから離れることがない場合は、sys.database_principalsとmaster.sys.databasesのSID値が一致しないようにする必要があります。ただし、データベースが復元されるか、別のインスタンスに（または別のインスタンスから）アタッチされた場合、SID値が一致しない可能性があります。次のクエリを使用して、両方の場所の値を確認できます。

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';

現在、デフォルトでTRUSTWORTHYはOFFに設定されており、偽装を伴う操作（つまり、EXECUTE AS）の権限は、操作の実行元のデータベースに限定されています。 DBユーザーを偽装し、別のDB（またはサーバー/インスタンスレベルのリソースでさえも）にアクセスしようとすると、SQL Serverは、現在のDBユーザーのSID（つまり、偽装されているユーザー）が一致するログインを持っていると想定して、ログインできるようにしますこれらの権限について。これは、TRUSTWORTHYがOFFの場合にブロックされますが、ONに設定すると、データベースレベルの隔離が解除され、偽装が初期データベースを超えて拡張されます。 dboユーザーのSIDは確かにログインとして存在する可能性がありますが、sys.databasesでデータベース所有者としてマップされているSIDと同じでない場合は、何かが正しくないことを示しています。正しく（そのDBが別のインスタンスからのものである可能性が高い）、要求された操作に悪意がある可能性があります。

6
Solomon Rutzky

これは、別のサーバーで作成されたデータベースを復元し、データベース所有者のログインアカウントが存在しないか、復元先のサーバーに別のSIDがある場合に発生する可能性があります。
データベースの所有に慣れているログインを選択し、これを実行します。

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