

社外からSSH（OpenSSH）PortForwardで社内WindowsServerに接続しSQLServerのDBを操作しようと思います。  
使用言語はC#です。  
SQLServerへは、SQLServer認証で接続しています。

社内WindowsServerに接続した後、  
SQLServerのDBを操作していますが、saユーザーならDBの操作が出来るのですが、SSMSで作った「ログインを持つ SQL
ユーザー（以下、専用ユーザーと呼びます）」でDB操作しようとすると例外になります。

まとめると  
社内LANから接続  
saユーザー：ＯＫ  
専用ユーザー：ＯＫ

社外ネット経由でSSH PortForwardでWindowsServerに接続  
saユーザー：ＯＫ  
専用ユーザー：ＮＧ＝SQLServerのDB操作が出来ません。

こういう事象がありうるのか我ながら不思議なのですが、もしあるとしたら専用ユーザーの権限が足りないのかと思うのですが、どの権限を付与したらよいですか？  
もしくはC#での接続文字列の作り方に、saの場合とは違う工夫が必要なのでしょうか？  
教えてください。

\--- 2022/4/30 21:50追記 ---  
すみません。この質問は、私の全くの勘違いでした。  
結果、この問題は解決いたしました。

いろいろ設定を変えたので厳密なところは分からないのですが、たぶん原因はSQL ユーザーログインパスワードの入力間違いです。

超単純で初歩的な間違いで恥ずかしいです。今後気を付けます。

時間を割いてご助言いただいた方、すみませんでした。


CC BY-SA 4.0
2022-04-28T04:41:53.777
88541
2022-04-30T12:58:00.903
2022-04-30T12:58:00.903
40913
40913
question
c# ssh sql-server openssh
社外からSSH経由で社内のSQLServer接続できない


SSH ……という点が、ちょっと良く意味が分かりませんが (port forward による SQL Server
への接続、という意味でしょうか?)、SQL Server の認証モードは 2 種類あります。

一つは SQL Server 認証で、これは「SQL Server に登録されているユーザー」で接続するモードです。sa
ユーザーで接続するのはこちらの形で、接続文字列にユーザー名とパスワードを指定して接続する形式です。

もう一つが Windows 認証で、こちらを使う場合は Active Directory を使った方が管理が楽だと思いますが、SQL Server
が動作している端末ローカルのユーザーも利用は可能です。  
こちらの場合、Active Directory
のグループなどを登録しておくことでユーザー情報を連動してくれるようにしたり、ローカルに追加したユーザーを個別に SQL Server
のユーザーとして登録する必要があります。  
こちらの場合、「プログラムが動作している Windows ユーザーの権限」で接続することとなるため、接続文字列には Integrated
Security=True や Integrated Security=SSPI を指定する形となり、ユーザー名やパスワードを指定しません。

いずれの場合であっても、使用するユーザーの権限として「SQL Server
へ接続する権限」が最低限必要で、それに加えて「対象とするデータベースへに対する適切な権限」が必要です。  
sa は SQL Server
の管理者ユーザーですから、最初からすべてのユーザーデータベースへの操作権限がありますが、追加したユーザーは個別に権限を付与する必要があります。  
データの読み書きだけができれば良いのであれば db_datawriter/db_datareader ロールを付与するのが簡単だと思います。

その他権限関係については、公式ドキュメント ( <https://docs.microsoft.com/ja-jp/sql/relational-
databases/security/authentication-access/database-level-roles?view=sql-server-
ver15> ) を確認してください。

\--- 2022/4/29 追記 ---

ポートフォワードで接続する場合、当然ですが接続文字列を変更する必要があります。  
SQL Server でデフォルトインスタンスへの接続をベースとしている場合はリモート側の 1433
番に対して接続する「ローカルホスト上で、リモート側へ転送されるポート番号」を指定する必要があります。

例えば `-L 11433:(SQL Server remote IP address):1433` と転送するなら、接続文字列としては「ローカルホスト上の
11433 番で SQL Server が待っている」つもりで書く必要がありますので、`"Server=tcp:localhost, 11433"`
の様に「`"Server=tcp:(local)"` のような、"ローカルインスタンス _ではない_ " ローカルホストで、TCP/IP
接続」を明示した方が確実ですね。

また、"SQLServerのDB操作が出来ません。"
と書かれている部分ですが、実際に受け取っているエラーメッセージなどが提示されていない点が問題解決を妨げています。

これは  
・SQL Server への接続自体ができていない  
・SQL Server への接続は出来ているが、認証ができていない  
・SQL Server への接続ができて認証も出来ているが、権限が不足している  
という点の切り分けが全くできないからです。

OpenSSH の port forward
は、あくまでも「ローカルの通信ポートをリモートの通信ポートと繋ぐ」位の事しかしてくれません。設定していない通信は一切流れないし、転送目的で振り向けた
local listen しているポートに投げた通信のみがリモートに飛ぶものです。  
つまり、VPN で接続している状況とは異なり、「様々な通信をまるごと転送してくれる」訳ではないので、AD
認証などで発生する通信などは成立しなくなります。(「適切な通信が出来ていない」のに、一方的に「このユーザーである」と主張しているだけの資格での接続を許可するとか、ありえない話ですから当然ですね)

OpenSSH port forward での動作を前提とした開発という点で見ると、sayuri さんが仰られている通りの「SQL Server
ユーザーでの接続」が現実的な解ですし、「そもそも sa が有効ってことは、SQL 認証有効にしているのだから、SQL Server
ユーザーでいいのでは?」という感じです。  
Windows 認証 only 運用の場合、そもそも sa ユーザー自体使えませんからね。

そういう辺りの情報がきちんと提示されないと、適切な解は得られないと思いますよ。(この範囲の情報であれば、「変な出し方をしない限り」特定業務の秘密を開示するような話ではないと思います)


CC BY-SA 4.0
2022-04-28T06:46:03.003
88545
2022-04-29T11:57:25.113
2022-04-29T11:57:25.113
13613
13613
88541
answer


概ねkondouさんの回答通りですが、補足します。質問者さんの言う「専用ユーザー」が何であるか、が「専用ユーザー」がどこからログインできるかに影響します。

[SSMS でユーザーを作成する](https://docs.microsoft.com/ja-jp/sql/relational-
databases/security/authentication-access/create-a-database-user?view=sql-
server-ver15#SSMSProcedure)によると **[ユーザーの種類]** には次の６つのユーザーがあるそうです。

  * ログインを持つ SQL ユーザー
  * パスワードを持つ SQL ユーザー
  * ログインを持たない SQL ユーザー
  * 証明書にマップされたユーザー
  * 非対称キーにマップされたユーザー
  * Windows ユーザー

このうち、Windowsユーザーは認証をWindowsに任せます。つまりSQL
Server自身はパスワード管理をしておらず、Windowsの認証をもって接続許可します。  
質問者さんの言う「専用ユーザー」とは「Windowsユーザー」を選択されましたでしょうか？

「社内LANから接続」であれば接続ＯＫとありますが、より厳密には当該ユーザーがActive
Directoryで認証されていることが条件と思われます。逆にActive
Directoryに参加していないマシンは「社内LANから接続」でも接続できないと思われます。  
同様に「社外ネット経由」で接続ＮＧなのも、Active Directoryに参加しておらず、Active
Directoryで認証されていないからではないでしょうか？

Active Directoryに参加していないマシンから接続を受け付けたい場合は「ログインを持つ SQL ユーザー」を作成し、SQL
Server自身でパスワード管理を行う必要があります。


CC BY-SA 4.0
2022-04-28T21:33:54.507
88551
2022-04-28T21:33:54.507
4236
88541
answer