admin1 と admin2 の 2 つの AD アカウントがあります。どちらも同じマシンにログインし、両方とも SQL Server Management Studio を開き、同じ SQL ユーザーとして同じ SQL サーバーにログインし (統合セキュリティではなく SQL Server 認証を使用)、同じクエリを実行します: "SELECT * FROMビュー1」。ただし、admin1 は多くの結果 (正しい結果セット) を受け取りますが、admin2 は空の結果セットを受け取ります。これは、Windows のバージョン、有線/無線接続などに関係なく、ドメイン内のすべてのコンピューターで発生します。
なぜこうなった？SQL Server 認証を使用する場合、SSMS は Windows アカウントにとらわれるべきではありませんか? どんな助けでも大歓迎です。
私が抱えていた問題は、SQL Server 自体ではなく、Microsoft Dynamics CRM の結果でした。Windows 認証を使用していないユーザーにはゼロの結果を返すフィルター ビューを使用していました。上記の結果がどのように得られたのかはわかりませんが、別の日にもう一度試してみると、使用している Windows アカウントに関係なく、SQL 認証で結果を得ることができませんでした。同様に、Windows 認証でログインすると、常に結果を取得できました。
生のテーブルを使用するか、SQL Server 認証ログイン ID としてドメイン名を示すレコードを手動で挿入し、CRMReaderRole ではなく標準の DQL ロールを付与することで、基になるビュー フレームワークをハックすることができます。すべての内部ビューが結合する SystemGuid を検索する素晴らしい fn_FindUserGuid 関数をのぞいてみてください。このレコードと他のいくつかのレコードとあなたの良いものをでっち上げてください。システムをリバース エンジニアリングすると、システムをだます方法があることがわかります。
基本的には、SystemUserBase、SystemUserPrincipals、UserSettingsBase だけです。
明らかに、これは Microsoft が推奨するものではありません。¯(°_°)/¯ しかし、すばらしい CRM の世界以外の多くのユーザーに一般的なレポートを提供する共有サーバーで ODBC 接続が必要な場合は、これを行う必要があります。データを別のデータベースにレプリケートする以外に方法はありませんが、ダイナミクスは非常に動的であり、頻繁に変化することを覚えておいてください。環境の同期を頑張ってください。
私の意見では、このシステムは明らかに、ユーザーをマイクロソフト製品に向かわせるために設計されたものです。私がマイクロソフトを所有していたとしても、同じことをしないと言っているわけではありません。ハッキングを余儀なくされたときは、ハッキングを余儀なくされました。