SQL Server のインストールに関する問題への対処は、特に Windows ポリシーによって SeDebugPrivilege などの特定の権限がブロックされている場合、少々面倒な場合があります。前回は、インストーラーが SeSecurity、SeBackup、SeDebug などの権限をチェックする方法で面倒な問題が発生し、これらの権限が事前に設定されていない場合は、単に続行を拒否されることがありました。SQL Server をインストールまたはアップデートしようとして、権限不足に関する警告（具体的には、アカウントにデバッグ権限がない）が表示された場合は、グループポリシーを恒久的に変更することなく、問題を軽減できる回避策があります。これは本格的なセキュリティ修正ではありませんが、ローカル管理者権限があり、テストやセットアップのために簡単なバイパスが必要な場合は有効です。とはいえ、興味があれば、この方法では、組み込みの secedit ツールを使用して SeDebugPrivilege をグループに手動で追加します。つまり、セッション中は一時的に、Windows にアカウントに適切な権限があると思わせるのです。
ポリシーを無効にせずに SQL Server セットアップに SeDebugPrivilege を付与する方法
方法1: seceditを使用して権限を即座に追加する
これは古典的な手法です。現在のユーザー権限をエクスポートし、権限ファイルを調整してから再インポートします。secedit というツールは、ローカルセキュリティ設定の管理に非常に強力で、レジストリをいじったりグループポリシーを直接変更したりする必要はありません。設定によってはハッキングに近いですが、合法的な方法です。肝心なのは、現在のユーザー権限を抽出し、管理者グループの SeDebugPrivilege を含むようにセクションを修正し、変更をプッシュすることです。この方法の素晴らしい点は、少なくとも一時的には、再起動や GPO の変更を必要とせずにこれらすべてを実行できることです。欠点は、GPO を更新またはログオフした後にこの手順を再度実行する必要があるため、一時的な解決策に過ぎないことです。
まず、管理者としてコマンド プロンプトを開き、現在の権限を確認します。
whoami /privSeDebugPrivilegeが有効になっていない場合、それが不足していることを意味します。これはSQL Serverのインストールが失敗する原因となることがよくあります。次に、既存のセキュリティポリシーをテキストファイルにエクスポートします。
secedit /export /cfg secpolicy.inf /areas USER_RIGHTSメモ帳またはお気に入りのエディターでsecpolicy.inf を開き、 [Privilege Rights]セクションに移動して、次のような行を追加します。
SeDebugPrivilege = *S-1-5-32-544この行は、SIDがS-1-5-32-544であるローカル管理者グループにSeDebugPrivilegeを割り当てています。ドメインに参加している場合や異なる設定を使用している場合は、SIDが異なる場合がありますが、一般的なWindowsインストールではこれで問題なく動作するはずです。
ファイルを保存し、次のコマンドを使用して更新された権限を再インポートします。
secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS既存のポリシーを上書きするかどうかを確認するメッセージが表示されます。その後、ログオフして再度ログインし、新しい権限が有効になっていることを確認してください。whoami /privで権限を再度確認してください。すべて正常に完了すると、SeDebugPrivilege が以下のように「Enabled」と表示されます。
SeDebugPrivilege Debug programs Enabledこれにより、SQL Server のインストーラーまたはアップデーターを実行できるようになり、権限エラーに再度遭遇することがなくなります。ただし、ログオフすると、この上書き設定は保持されません。Windows は次回の更新時に、グループポリシーで指定された権限にリセットします。そのため、これは一度限りのインストールには便利な方法ですが、永続的な解決策ではありません。
念のためお知らせしますが、デバッグプログラムを有効にしてもセキュリティは万全ではありません。管理者権限を持つ悪意のあるスクリプトがSeDebugPrivilege権限を奪取する可能性もあります。そのため、セキュリティ上の状況を把握し、リスクを理解している場合のみ、デバッグプログラムを有効にしてください。
これは少し怪しいと感じる人もいるかもしれませんが、実際には、GPO が作業の妨げになっていて SQL Server をすぐに起動する必要がある場合、これが最短ルートとなることがよくあります。ポリシーがなかなか変更できない場合は、このちょっとした調整で何日もイライラする時間を節約できます。
まとめ
- 実行して
whoami /priv現在の権限を確認します。 - 現在のユーザー権限を でエクスポートします
secedit /export /cfg secpolicy.inf /areas USER_RIGHTS。 - secpolicy.infを編集して追加します
SeDebugPrivilege = *S-1-5-32-544。 - を使用して設定を再インポートします
secedit /configure /db secedit.sdb /cfg secpolicy.inf /overwrite /areas USER_RIGHTS。 - ログオフして再度ログインし、 で確認します
whoami /priv。
まとめ
このトリックは一種のチートですが、SQL Serverのインストールやアップデートを、ポリシーを長期的に変更せずに迅速に実行したい場合に有効です。デバッグ権限を永続的に有効にしておくのは安全ではないので、後で必ずリセットするか、グループポリシーを再検討してください。しかし今のところは、GPOの制限に悩まされている場合は、この方法で回避できるかもしれません。誰かの時間の節約になることを願っています！