MSSQLはアカウントのパスワードを保存せず、ハッシュのみを保存しますが、リンクサーバーでは機能しません。外部サーバーの前で認証を成功させるには、クリア形式のパスワードが必要です。 リンク
master.sys.syslnklgns
パスワードは、
master.sys.syslnklgns
テーブルに暗号化された形式で保存されます。
しかし、それほど単純ではありません。 まず、このテーブルは通常のSQL接続からはアクセスできませんが、 専用管理接続からのみ使用できます。 DACには大きな制限が課されています。sysadmin特権を持つユーザーのみがDACを開くことができ、一度に1つのサーバーに対して開くことができるDACは1つだけです。 サーバーのローカル管理者権限を持っているが、sysadmin権限でMSSQLにログインできない場合、 回避策があります。アカウントからではなく、MSSQLサービスアカウントから、またはLocalSystemからもログインすることです。
第二に、暗号化されたパスワードを持つフィールドは
pwdhash
と呼ばれるという事実にもかかわらず、これはハッシュではなく、暗号化されたデータです。 復号化キーは
master.sys.key_encryptions
システムテーブルに保存されます。
このキーは2つのコピーに保存されます。1つ目（
thumbprint=0x01
）はMSSQLサービスアカウントでのみ使用でき、2つ目（
thumbprint=0x0300000001
）-サーバー上の任意のアカウントで使用できます。 保存されたキーはいずれもサーバー外部のパスワードの「オフライン復号化」に適していないため、攻撃者がこれらのシステムテーブルの両方からデータを盗もうとしても、何も得られないことに注意してください。
第三に、復号化キー自体は暗号化され、「キーのキー」は
HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\$InstanceName\Security\Entropy
のレジストリに保存されます
HKLM:\SOFTWARE\Microsoft\Microsoft SQL Server\$InstanceName\Security\Entropy
：
この値をレジストリから読み取るには、サーバーのローカル管理者権限が再度必要です。
3つすべてのコンポーネントを取得し、保存されたパスワードを復号化するために、作成者は便利なPowerShellスクリプトを作成しました。
サーバーのローカル管理者アカウントで実行すると、次のようなものが表示されます。
実稼働サーバーの誰かが理解できないほどスクリプトを実行したくない場合、最初にSQL Studioとregeditを使用して3つのコンポーネントを引き出し、スクリプトに明示的に挿入すると、管理者権限なしで復号化自体を実行できます。 最初の復号化ステップ（
$ServiceKey = [System.Security.Cryptography.ProtectedData]::Unprotect($SmkBytes, $Entropy, 'LocalMachine')
）はサーバーで実行する必要がありますが、2番目（
$Decrypt = $Decryptor.CreateDecryptor($ServiceKey,$Logins.iv)
および
$Decrypt = $Decryptor.CreateDecryptor($ServiceKey,$Logins.iv)
での後続の作業）はオフラインで実行できます。
MSSQLサービスよりも権限の低いアカウントに代わってコマンド（
xp_cmdshell
など）を実行するためにデータベースに保存された資格情報も 、 同様の方法で復号化されます。
一方で、これらはすべて、あいまいさによるセキュリティの露骨な例のように見えます。リンクサーバーに接続するためのパスワード復号化がMSSQLで既に実装されている場合、忘れた管理者にこれらのパスワードを表示できないのはなぜですか？ 一方、セキュリティの観点から見ると、すべてが非常に優れています。パスワードを解読するには、ローカル管理者権限でサーバーにアクセスする必要があります。攻撃者がそのようなアクセスを取得した場合、彼は既にサーバーで何でもできます。 望ましくない特権の昇格は、あるリンクサーバーからのパスワードが、たとえば同じサーバーの管理者パスワードとして重要なものに使用されている場合にのみ可能です：^）