Q&A
> ASP.netで開発したプログラムをSQLserverへ接続できなくなりました。
過去形で書いてありますが、以前は問題なかったのですか？ であれば、何が変わったのですか？
問題を再現できる必要最低限のサンプルコードを書いてアップできませんか？ 特に接続文字列あたり。
ASP.netで開発したプログラムをIISへ配置しURLを開きましたがSQLserverへ接続できないエラーが発生しました。
接続ユーザはsaでSQLserver認証にしています。
開発環境からの接続できるのですが、IISから接続しようとすると
「ユーザー 'IIS APPPOOL****' はログインできませんでした。」
というエラーになります。
調べてみたところWindows認証にしている場合はこのようなエラーでAPPPOOLアカウントをSQLserverに追加すれば解決するとのことですが、
SQLserver認証にしているのになぜこのようなエラーになるのか、また解決方法がわかりません。
IIS載せているサーバーからSQLserverへの疎通はあります。
Webconfigの中身はこちらです。
<?xml version="1.0" encoding="utf-8"?> <!-- ASP.NET アプリケーションの構成方法の詳細については、 https://go.microsoft.com/fwlink/?LinkId=301879 を参照してください --> <configuration> <connectionStrings> <add name="ConnectionString" connectionString="Data Source =192.168.40.28;Initial Catalog=test;User ID=sa;Password=Password" /> </connectionStrings> <appSettings> <add key="webpages:Version" value="3.0.0.0" /> <add key="webpages:Enabled" value="false" /> <add key="ClientValidationEnabled" value="true" /> <add key="UnobtrusiveJavaScriptEnabled" value="true" /> </appSettings> <system.web> <compilation debug="true" targetFramework="4.6" /> <httpRuntime targetFramework="4.6" /> </system.web> <system.webServer> <handlers> <remove name="ExtensionlessUrlHandler-Integrated-4.0" /> <remove name="OPTIONSVerbHandler" /> <remove name="TRACEVerbHandler" /> <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="*" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" /> </handlers> </system.webServer> <runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" /> <bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="0.0.0.0-5.2.7.0" newVersion="5.2.7.0" /> </dependentAssembly> <dependentAssembly> <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> </assemblyBinding> </runtime> <system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" /> <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=2.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\"Web\" /optionInfer+" /> </compilers> </system.codedom> </configuration>アドバイス、または情報が足りない等ありましたらご教授ください。
宜しくお願い致します。
ご回答ありがとうございます。
書き方がわるくてすみません。
開発環境(VS)で実行したときは接続できて、IISに配置した時点でIISからは接続できませんでした。
SQLServerに接続しにいかないページの表示はできています。
また接続文字列は以下です。
"Data Source =192.168.40.28;Initial Catalog=test;User ID=sa;Password=Password"
質問本文を編集して上記を追記してください。
接続文字列は絶対それに間違いないですか？ どこに設定してあるのですか？ だから、「問題を再現できる必要最低限のサンプルコードを書いてアップできませんか？」と書いたのですが、それをやってもらえませんか？ エラーメッセージからすると Windows 認証になってますよ。
接続文字列はWebconfigに書いています。
saユーザはSQLServer認証なのになぜIISだとWindows認証になるのでしょうか？？
実行しているソースは以下です。
Imports System.Data.SqlClient
Imports System.Web.Http
Public Class StaffController
Inherits ApiController
Private conStr As String = ConfigurationManager.ConnectionStrings("ConnectionString").ConnectionString
Public Function GetValue(ByVal idm As String) As List(Of staff)
Dim staffList As New List(Of staff)
Using con As New SqlConnection()
Dim sql As String
Dim cmd As SqlCommand
Dim reader As SqlDataReader
'接続文字列の設定
con.ConnectionString = conStr
'DBを開く
con.Open()
'クエリの設定
sql = "SELECT staffID,staffName FROM staff WHERE IDm = @IDm;"
cmd = New SqlCommand(sql, con)
cmd.Parameters.Add("@IDm", SqlDbType.VarChar).Value = idm
'クエリ実行
reader = cmd.ExecuteReader()
'DBを閉じる
cmd.Dispose()
If reader.HasRows Then
'データ読み込み
While reader.Read()
Dim obj As staff = New staff With {
.staffID = CStr(reader("staffID")),
.staffName = CStr(reader("staffName"))
}
staffList.Add(obj)
End While
Else
End If
'DBを閉じる
reader.Close()
End Using
Return staffList
End Function
End Class
web.config の接続文字列、コードビハインドでの接続文字列の取得を見る限りは SQL Server 認証での設定のようですね。でも、エラーメッセージをみると IIS のワーカープロセスのアカウント（詳細下記参照）でログインに行ってます。ただ、ログインに行ってる先がどこだか不明で、そこが違うとかの問題なのかぐらいしか疑うことがないですが、今の情報だけでは何とも言えないです。
アプリケーション プール ID
https://docs.microsoft.com/ja-jp/previous-versions/ee886292(v=technet.10)
IISのアプリケーションプールの設定でプロセスモデルをカスタムアカウントにしてWindowsのログイン情報を入れたら正常に接続、うごくようになりました。
なぜこれでうごくようになったのか、 SQL Server 認証設定にしているのにどこでWindows認証に代わるかがわかりませんのでご存知でしたら教えてください。
ログインに行っている先はWebconfigにかいてある場所ではないのですか？
それ以外に記載している場所はないですし、IP、ID、PASSは間違っていません。
> IISのアプリケーションプールの設定でプロセスモデルをカスタムアカウントにしてWindowsのログイン情報を入れたら正常に接続、うごくようになりました。
> なぜこれでうごくようになったのか、
それは Windows 認証としての正常な動きのようです。そのカスタムアカウントに SQL Server でログイン権限を与え、Web アプリのワーカープロセスはそのカスタムアカウントの権限で SQL Server にアクセスに行ったのでログインできたということでしょう。
> SQL Server 認証設定にしているのにどこでWindows認証に代わるかがわかりませんのでご存知でしたら教えてください。
そこは分かりません。想像を膨らませると、そもそも SQL Server では Wndows 認証しか有効になっていないとか？ でもそうだとすると、接続文字列が Windows 認証の設定（Integrated Security=true）になってないとダメそうだし・・・
開発環境では問題なく接続できていたそうですが、その時はどのようにしていたのですか？
> ログインに行っている先はWebconfigにかいてある場所ではないのですか？
SQL Server のログインに限れば接続文字列で指定される SQL Server 以外に行く先はないと思います。でも、ワーカープロセスのアカウントでログインに行ってるのはエラーメッセージから間違いないから、どこか別の場所にワーカープロセスがアクセスに行ったのではないかと思った次第です。
>それは Windows 認証としての正常な動きのようです。そのカスタムアカウントに SQL Server でログイン権限を与え、Web アプリのワーカープロセスはそのカスタムアカウントの権限で SQL Server にアクセスに行ったのでログインできたということでしょう。
なるほどです。ありがとうございます。
調べているとビルドインアカウントApplicationPoolIdentityでの接続でも正常に接続できているかたもいるみたいです。
なにがちがうのかはもう少し調べてみます。
>そこは分かりません。想像を膨らませると、そもそも SQL Server では Wndows 認証しか有効になっていないとか？ でもそうだとすると、接続文字列が Windows 認証の設定（Integrated Security=true）になってないとダメそうだし・・・
SQL Serverでのサーバー認証はSQLServer認証モードとWindows認証モードを有効にした設定にしています。
saもSQLserver認証です。
IISから接続するときはWindows認証に自動的になってしまうのでしょうか。
＞開発環境では問題なく接続できていたそうですが、その時はどのようにしていたのですか？
Webconfigに接続文字列を記載し、VSのIISExpressを起動し接続しています。
VSで実行するのとIIS自体で実行するので違うのでしょうか。
＞SQL Server のログインに限れば接続文字列で指定される SQL Server 以外に行く先はないと思います。でも、ワーカープロセスのアカウントでログインに行ってるのはエラーメッセージから間違いないから、どこか別の場所にワーカープロセスがアクセスに行ったのではないかと思った次第です。
別の場所にWEBサーバをたててから接続しに行ったこともなく、そのような設定も入れていません。
なにも接続情報等をいれていないのに別の場所に接続しにいくのはないと思うのですが、デフォルトで別の場所に接続しにいく設定などがはいっているのでしょうか。
いずれにしても今回正常に指定したSQLserverに接続しにいって成功したので別の場所にアクセスしているということはないかと思います。
> 調べているとビルドインアカウントApplicationPoolIdentityでの接続でも正常に接続できているかたもいるみたいです。
ApplicationPoolIdentity を使ったというのは理解できませんけど、何にせよそのあたりはワーカープロセスのアカウントに関係する話で、そのアカウントの権限で SQL Server にアクセスしに行ってログインできたということは、Windows 認証になっているということだと思います。
> IISから接続するときはWindows認証に自動的になってしまうのでしょうか。
それは無いです。Windows 認証が使えない環境はレンタルサーバーなど多々あるので、それでは SQL Server は使えなくなってしまいます。
> Webconfigに接続文字列を記載し、VSのIISExpressを起動し接続しています。
> VSで実行するのとIIS自体で実行するので違うのでしょうか。
大違いです。Visual Studio は管理者権限でのアカウントで立ち上げて使っているのでは？ そうだとすると IIS Express のワーカープロセスのアカウントはその管理者権限を持ってます。
開発環境で問題なく動いていたが、IIS にデプロイすると動かないというよくある話の原因は大体がそれです。
＞Windows 認証が使えない環境はレンタルサーバーなど多々あるので、それでは SQL Server は使えなくなってしまいます。
ではIISのSQLserverの設定などでこちらが見落としている部分があり、Windows認証になってしまっているのでしょうか。
＞大違いです。Visual Studio は管理者権限でのアカウントで立ち上げて使っているのでは？ そうだとすると IIS Express のワーカープロセスのアカウントはその管理者権限を持ってます。
なるほどです。ちなみにVisual Studio は管理者権限でのアカウントで実行させないのですか？
推奨は通常の権限を持ったアカウント見たいですが、今まで行った現場ではだいたい管理者権限で実行させていました。
IIS にデプロイしたときに動かなくなるのはワーカープロセスの権限の問題と理解してよろしいでしょうか？
> ではIISのSQLserverの設定などでこちらが見落としている部分があり、Windows認証になってしまっているのでしょうか。
「IISのSQLserverの設定」というのはどういう意味ですか？ SQL Server の認証の設定は SQL Server 独自のもので IIS は関係ないです。また、IIS の ASP.NET Web アプリから SQL Server にアクセスに行くからと言って、前に書いたように、接続文字列の指定を無視して勝手に SQL Server 認証が Windows 認証に変わってしまうということもないです（どんなことをしても 100% 絶対ないとは言い切れませんが、もしあったら何か壊れてるレベルの話ではないかと思います）。
「見落とし」についてはここに書いてあること以外は知り得ない第三者には分かりません。ちょっと気になったのは IP アドレスを使っていることですが今回の話とは関係なさそうですし、Windows 認証になってしまうというのは自分が理解・想像できる範囲を超えていて思い当たることもないです。
SQL Server のバージョン・エディションは何か、全体的にどのような環境なのか、どうやってセットアップしたのか等々を一つ一つ聞いていって解決に結びつけるというのも難しそうです。質問者さんの組織のネットワーク・サーバー管理者の方に確認してはいかがですか？
> IIS にデプロイしたときに動かなくなるのはワーカープロセスの権限の問題と理解してよろしいでしょうか？
SQL Server が Windows 認証であればそれが疑わしいということです。
ワーカープロセスのアカウントは Visual Studio から実行して IIS Express 上で動かした場合と、IIS で動かした場合とは違うのは理解できてますか？
Windows 認証ではワーカープロセスのアカウントでログインに行くので、それが SQL Server のログインに登録してあれば、SQL Server が Windows 認証であればログインできます。
自分の開発マシンに自分で SQL Server をインストールすると、自分のアカウントは自動的にサーバーロール sysadmin でログインに登録されているはずです。その人が開発マシンを立ち上げてアプリを Visual Studio から実行して IIS Express 上で動かした場合はワーカープロセスのアカウントは Visual Studio を立ち上げた人（＝自分）のアカウントになります。なので SQL Server のログイン関係の設定は何もしなくても Windows 認証ならログインできます。
IIS で動かした場合のワーカープロセスのアカウントは IIS AppPool\<アプリケーションプール名> になり、SQL Server のログインには登録されてないのでログインできないということになります。
IISのSQLserverの設定
書き間違いです。IISやSQLserverの設定です。
内容よくわかりました。
いろいろご丁寧にご説明ありがとうございました。
上のコメントでちょっと気になると書いた IP アドレスを使っている件、今回の問題とは関係ないかもしれませんが、どういう話かを書いた記事を紹介しておきます。興味があれば読んでください。
IP アドレスで SQL Server に接続
http://surferonwww.info/BlogEngine/post/2016/03/18/connecting-to-sql-server-using-ip-address-instead-of-server-name.aspx
接続文字列のサーバーを IP アドレスで指定していたため、その IP アドレスの PC にインストールした 2 つの SQL Server のうち、意図しない方の SQL Server に接続していたという話です。
それより、その記事の下の方にリンクが貼ってある以下の記事の方が参考になるかもしれません。これは読んだ方が良さそうです。
Troubleshooting Connectivity #1 - SQL Server への接続
https://docs.microsoft.com/ja-jp/archive/blogs/jpsql/troubleshooting-connectivity-1-sql-server
このあたり ↓
"SQL Server 認証の場合には、指定のログインが SQL Server にログインとして登録されているかのチェックを行います。もしも SQL Server 稼動サーバーがドメインに参加しており、パスワード ポリシーを有効化している場合には、Windows 認証の場合と同様に、ドメイン コントローラーへの問い合わせが発生します"
参考にしてみます。ありがとうございます。
また何か困ったらご相談させてください。
結局どうなったんですか？ 放棄しないで結局どうなったのかなど最後までフォローできませんか？
実はこちらで質問させていただいた環境は自分が使用する環境ではなく
クライアント側の環境で私が使うものではありません。
お答えいただいた内容をクライアント側に説明して確認はしてもらっていましたが
全て自分の方で設定などを把握しているわけではありません。
IPアドレスの部分、ドメイン参加のことは話しましたが、
とりあえず接続できたからと、
取引が終了になったのでその後連絡をとっておらず不明です。
結論が不明で申し訳ないです・
では原因不明ということでも良いですのでその旨回答欄に書いてクローズ願います。
回答1件
0
自己解決
接続アカウントとSQLSERVERの設定はSQserver認証だったのですが、
IIS側ではWindows認証になっており接続エラーになってました。
なぜWindows認証になっているかは不明です。
それでIISのアプリケーションプールの設定でプロセスモデルをカスタムアカウントにしてWindowsのログイン情報を入れたら正常に接続、うごくようになりました。
投稿2021/03/03 14:18
総合スコア4
あなたの回答
tips
プレビュー
