MSSQLSERVER_18456

適用対象: SQL サーバー

詳細

属性 Value
製品名 SQL Server
イベント ID 18456
イベント ソース MSSQLSERVER
コンポーネント SQLEngine
シンボル名 LOGON_FAILED
メッセージ テキスト ユーザー '%.*ls'.%.ls はログインできませんでした

説明

このエラー メッセージは、認証エラーが原因で接続の試行が拒否された場合に表示されます。 ユーザー ログインは、無効な資格情報、パスワードの有効期限、間違った認証モードの有効化など、さまざまな理由で失敗する可能性があります。 多くの場合、エラー コードには説明が含まれます。

ユーザー アクション

次の例は、一般的なログイン エラーの一部です。 発生している正確なエラーを選択して、問題のトラブルシューティングを行います。

ユーザー '<username>' のログインに失敗したか、ユーザー '<domain>\<username>' に対してログインに失敗しました

ドメイン名が指定されていない場合、問題は失敗した SQL Server ログイン試行です。 ドメイン名が指定されている場合、問題は失敗した Windows ユーザー アカウントのログインです。 考えられる原因と推奨される解決策については、次を参照してください。

Potential cause (潜在的な原因) 推奨される解決策
SQL Server 認証を使用しようとしていますが、SQL Server インスタンスは Windows 認証モード用に構成されています。 SQL Server と Windows 認証モードを使用するように SQL Server が構成されていることを確認します。 SQL Server Management Studio (SSMS) の対応するインスタンスの PropertiesSecurity ページで、SQL Server インスタンスの認証モードを確認および変更できます。 詳細については、「サーバー認証モードの変更」を参照してください。 または、 Windows 認証モード を使用して SQL Server に接続するようにアプリケーションを変更することもできます。
: このシナリオの SQL Server エラー ログには、次のようなメッセージが表示されます。
Login failed for user '<UserName>'. Reason: An attempt to login using SQL authentication failed. Server is configured for Windows authentication only.
グループを使用して SQL Server にアクセスしようとすると、エラー メッセージが表示されます。 サーバーにアクセスするために必要なアクセス許可がない場合、プロバイダーに "ユーザー 'contoso/user1' のログインに失敗しました" というエラー メッセージが表示されます。 グループ メンバーシップに基づいてサーバーにアクセスするのに役立つ "グループ経由のアクセス" 機能を使用します。
xp_logininfo 'contoso/user1' ストアド プロシージャを実行すると、次の状況が発生する可能性があります。
- エラーが表示された場合、SQL Server はユーザー名をまったく解決できません。 名前が Active Directory (AD) に存在しないか、ドメイン コントローラー (DC) への接続に問題がある可能性があります。 別の名前を試して、問題が特定のアカウントに固有であるかどうかを確認してください。
- クロスドメイン サーバーに接続する場合は、グループのメンバーシップを解決できるように、ユーザー ドメインではなく SQL Server ドメインにグループが存在する必要があります。
- データベース クエリから行が返されない場合は、サーバーへのアクセスを提供するグループがないことを意味します。 クエリが 1 つ以上の行を返す場合は、ユーザーがアクセスを提供するグループに属していることを意味します。
DBA は、SQL Server Management Studio (SSMS) の Security\Logins フォルダーを確認することで、アクセス許可を再確認できます。 Security\Logins には、作成されたログインの一覧が表示されます。 包含データベースの場合、DBA はデータベース名の下にある Security\Logins を確認してログインを確認および管理できます。
詳細については、「 ユーザー アクセス制御とアクセス許可の構成」を参照してください。
SQL ログインが有効になっていない データベース管理システム (DBMS) では、 Login failed for user '<username>' メッセージの一部のバリエーションが表示される場合があります。 このエラーを解決するには、次の手順に従います。
1. SQL Server エラー ログに、"ユーザー '<username> のログインに失敗しました" というエラー メッセージが含まれているかどうかを確認します。 理由: SQL 認証を使用してログインしようとしましたが失敗しました。 サーバーはWindows 認証専用に構成されています。
2. 次のいずれかの方法を使用してエラーを解決します。
- 統合ログインを使用します。 たとえば、OLE DB プロバイダーの場合、接続文字列にINTEGRATED SECURITY=SSPIを追加し、ODBC ドライバーの場合はTRUSTED_CONNECTION=YESを追加します。 .NET プロバイダーは、いずれかの構文を受け入れます。
注: 統合認証を許可するように正しく構成されておらず、別の問題として調査する必要がある場合は、他の問題が発生する可能性があります。
- サーバーで SQL ログインを有効にします。
a. SQL Server Management Studio で、オブジェクト エクスプローラーの SQL Server 名を右クリックし、Properties を選択します。
b. セキュリティ ペインで、SQL Server と Windows 認証 モードを選択します。
c. [OK] を選択します。
d. 変更を行うために SQL Server を再起動します。
注: SQL ログインの定義など、他の問題が発生する可能性があります。
- ローカルの Windows アカウントまたはユーザー名のドメイン アカウントを指定してみてください。 SQL ログインのみが許可されます。 アプリケーションは統合セキュリティを使用している必要があります。
接続先の SQL Server インスタンスにログインが存在しません。 SQL Server ログインが存在し、スペルが正しいことを確認します。 ログインが存在しない場合は、作成します。 存在していてもスペルが間違っている場合は、アプリケーションの接続文字列で修正してください。 SQL Server エラー ログには、次のいずれかのメッセージが表示されます。
- Login failed for user 'username'. Reason: Could not find a login matching the name provided.
- Login failed for user 'Domain\username'. Reason: Could not find a login matching the name provided.DEV または QA サーバーを使用するアプリケーションを運用環境にデプロイし、接続文字列を更新できない場合、これは一般的な問題である可能性があります。 この問題を解決するには、適切なサーバーに接続していることを確認します。 そうでない場合、接続文字列を修正してください。 その場合は、ログインに SQL Server へのアクセス権を付与します。 または、Windows ログインの場合は、直接アクセス権を付与するか、データベース サーバーへの接続を許可されているローカルまたはドメイン グループに追加します。 詳細については、「 ログインの作成」を参照してください。
SQL Server 認証を使用していますが、SQL Server ログインに指定したパスワードが正しくありません。 "Reason: Password did not match that for the login provided" のようなメッセージが SQL エラー ログで確認され、原因が確認されます。 この問題を解決するには、アプリケーションで正しいパスワードを使用するか、パスワードを覚えていない場合は別のアカウントを使用します。 または、SQL Server 管理者と協力して、アカウントのパスワードをリセットします。
アプリケーションが SQL Server Integration Services (SSIS) の場合、ジョブの構成ファイルのレベルが複数存在する可能性があり、パッケージの接続マネージャー設定がオーバーライドされる可能性があります。
アプリケーションが会社によって作成され、接続文字列がプログラムで生成された場合は、開発チームに問い合わせて問題を解決してください。 一時的な回避策として、接続文字列をハードコーディングしてテストします。 UDL ファイルまたはスクリプトを使用して、ハードコーディングされた接続文字列との接続が可能であることを証明します。
接続文字列の構文、サーバー名、またはユーザー資格情報が正しくありません。 これを解決するには、次の手順に従います。
  1. 接続文字列形式を確認します。 接続文字列形式には、サーバー名、データベース名、ユーザー名、パスワードなど、必要なパラメーターが含まれている必要があります。
  2. 接続文字列でサーバー名を確認します。
  3. 名前付きインスタンスを使用している場合は、インスタンス名を含めます。
  4. ターゲット サーバーが正しくない場合は、正しいサーバーを指す接続文字列を更新します。
  5. 接続文字列が正しい場合は、データベースへのログイン アクセス権を指定します。 これを行うには、データベースにユーザーを作成し、そのログインにマップします。
  6. Windows ログインを使用している場合は、データベース サーバーへの接続が許可されているローカル グループまたはドメイン グループにログインを追加します。
ログインなし SQL Server に次のメッセージが表示されているかどうかを確認します。
Logon Error: 18456, Severity: 14, State: 11.
Logon Login failed for user 'CONTOSO\JohnDoe'. Reason: Token-based server access validation failed with an infrastructure error. Check for previous errors. [CLIENT: ]
エラーの一部は、匿名ログオン アカウントに属しています。 これは Kerberos の問題に関連しています。 HOSTS ファイルに不適切な手動エントリがありました。つまり、間違ったサーバー名が指定されました。
残りの問題は、次のカテゴリに分類される可能性があります。
  • エンド ユーザーのログインが拒否された (または許可されていません)。
  • アカウントは Administrators グループを介してアクセス権を持っていました。
  • ユーザーが属していたグループは、SQL Server で DENY アクセス許可を持っていました。
Windows 認証を使用して接続しようとしていますが、正しくないドメインにログインしています。 正しいドメインに正しくログインしていることを確認します。 通常、エラー メッセージにはドメイン名が表示されます。
データベースのアクセス許可を確認する SQL Server Management Studio では、データベースはオフラインで表示されません。 他のユーザー (たとえば、DBA はそれに接続できます)。
対象のユーザー アカウントには、データベースへの明示的なアクセス権が付与されているか、SQL Server ロール、またはデータベースにアクセスできるローカル Windows グループまたはドメイン グループに追加する必要があります。 詳細については、「CREATE USERALTER ROLE、および ALTER SERVER ROLE」を参照してください。
アプリケーション (SSMS など) を管理者として実行していません。 管理者の資格情報を使用して接続しようとしている場合は、 管理者として実行 オプションを使用してアプリケーションを起動します。 接続したら、Windows ユーザーを個別のログインとして追加します。
ログインは、包含データベース ユーザーへの移行後に削除されます。 データベース エンジンが包含データベースをサポートしている場合は、包含データベース ユーザーへの移行後にログインが削除されなかったことを確認します。 詳細については、「 Contained Database Authentication: Introduction」を参照してください。
ログインの既定のデータベースはオフラインであるか、使用できません。 SQL Server 管理者に問い合わせて、データベースの可用性に関連する問題を解決してください。 ログインにサーバー上の他のデータベースへのアクセス許可があり、アプリケーションで現在構成されている既定のデータベースにアクセスする必要がない場合は、次のいずれかのオプションを使用します。
- ALTER LOGIN ステートメントまたは SSMS を使用して、ログインの既定のデータベースを変更するよう管理者に要求します。
- アプリケーション 接続文字列で別のデータベースを明示的に指定します。 または、SSMS スイッチを使用している場合は、 Connection プロパティ タブに切り替えて、現在使用可能なデータベースを指定します。SSMS などのアプリケーションでは、次のようなエラー メッセージが表示される場合があります。
Cannot open user default database. Login failed.
Login failed for user <user name>. (Microsoft SQL Server, Error: 4064)
SQL Server エラー ログには、次のようなエラー メッセージが表示されます。
Login failed for user '<user name>'. Reason: Failed to open the database '<dbname>' specified in the login properties [CLIENT: <ip address>]
詳細については、「 MSSQLSERVER_4064」を参照してください。
接続文字列または SSMS で明示的に指定されたデータベースのスペルが正しくない、オフライン、または使用できない。 - 接続文字列のデータベース名を修正します。 サーバーで大文字と小文字を区別する照合順序を使用する場合は、大文字と小文字の区別に注意してください。
- データベース名が正しい場合は、SQL Server 管理者に問い合わせて、データベースの可用性に関連する問題を解決してください。 データベースがオフラインか、復旧されていないかなどを確認します。
- ログインがサーバー上の他のデータベースへのアクセス許可を持つユーザーにマップされていて、アプリケーションで現在構成されているデータベースにアクセスする必要がない場合は、接続文字列で別のデータベースを指定します。 または、SSMS を使用して接続する場合は、 Connection プロパティ タブを使用して、現在使用可能なデータベースを指定します。
SQL Server エラー ログには、次のようなエラー メッセージが表示されます。
Login failed for user <UserName>. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <ip address>]
: ログインの既定のデータベースが使用可能な場合、SQL Server は接続を成功させることができます。 詳細については、「 MSSQLSERVER_4064」を参照してください。
ユーザーは、要求されたデータベースに対するアクセス許可を持っていません。 - 接続を確立できるかどうかを確認するには、sysadmin 権限を持つ別のユーザーとして接続してみてください。
- 対応するユーザー (たとえば、 CREATE USER [<UserName>] FOR LOGIN [UserName]) を作成して、データベースへのログイン アクセス権を付与します

また、エラー 18456 トラブルシューティング エラー 18456 で、エラー コードの広範な一覧を確認してください。

トラブルシューティングのヘルプについては、「 SQL クライアント/サーバー接続の問題のトラブルシューティングを参照してください。

ユーザー NT AUTHORITY\ANONYMOUS LOGON のログインに失敗しました

この問題には、少なくとも 4 つのシナリオがあります。 次の表では、該当する考えられる各原因を調べて、適切な解決策を使用します。 ホップという用語の説明については、表の下の注を参照してください。

考えられる原因 推奨される解決策
NT LAN Manager (NTLM) 資格情報を同じコンピューター上の別のサービス (IIS から SQL Server など) に渡そうとしていますが、プロセスでエラーが発生します。 DisableLoopbackCheck または BackConnectionHostNames レジストリ エントリを追加します。
複数のコンピューター (制約委任) シナリオがあります。 このエラーは、サービス プリンシパル名 (SPN) の問題が原因で Kerberos 接続が失敗した場合に発生する可能性があります。 各 SQL Server と Web サーバーで SQLCheck を実行します。 トラブルシューティング ガイドを使用します。 0600 資格情報の委任の問題 および 0650 SQL Server のリンク サーバー委任の問題
ダブルホップ (制約委任) が関係していない場合は、重複する SPN が存在する可能性があり、クライアントは、Kerberos 資格情報ではなく NTLM 資格情報を取得する LocalSystem または別のマシン アカウントとして実行されています。 SQLCheckまたはSetspn.exeを使用して、SPN 関連の問題を診断して修正します。 SQL Server 用 Kerberos 構成マネージャーの確認
Windows ローカル セキュリティ ポリシーは、リモート認証要求にマシン アカウントを使用しないように構成されている可能性があります。 ローカル セキュリティ ポリシー>ローカル ポリシー>セキュリティ オプション>ネットワーク セキュリティ: ローカル システムが NTLM のコンピューター ID を使用できるようにするに移動し、設定が無効になっている場合は Enabled オプションを選択し、OK を選択します。
: Explain タブで詳しく説明されているように、このポリシーは既定で Windows 7 以降のバージョンで有効になっています。
制約付き委任を使用しているときにこの問題が断続的に発生する場合は、中間層で更新できない期限切れのチケットが存在することを示している可能性があります。 これは、リンク サーバー シナリオ、またはログオン セッションを 10 時間以上保持しているアプリケーションで想定される動作です。 中間層サーバーの委任設定を Trust このコンピューターから指定されたサービスへの委任のみに変更する - Kerberos のみ を使用して、指定されたサービスへの委任にのみこのコンピューターを する - 任意のプロトコルを使用します。 詳細については、「 SQL Server リンク サーバーのダブル ホップの匿名ログオンを許可するを参照してください。
NTLM ピア ログイン このエラーは、Microsoft Windows OS で使用される NTLM 認証プロトコルに関連しています。 ワークステーション内または相互に信頼されていないドメインにあるコンピューター間で通信する場合は、両方のコンピューターで同じアカウントを設定し、NTLM ピア認証 NTLM ピア ログインを使用できます。 ログインは、両方のマシンでユーザー アカウントとパスワードの両方が一致する場合にのみ機能します。
ループバック保護 ループバック保護は、アプリケーションが同じコンピューター上の他のサービスを呼び出すのを禁止するように設計されています。 これを許可するには、 DisableLoopbackCheck または BackConnectionHostNames (推奨) レジストリ キーを設定できます。 詳細については、「 Windows Server 2003 Service Pack 1 のインストール後に FQDN またはその CNAME エイリアスを使用してサーバーにローカルでアクセスしようとすると、アクセスが拒否されたか、ネットワーク プロバイダーが指定されたネットワーク パスを受け入れなかった場合のエラー メッセージを参照してください。
Always-On リスナー ループバック保護 プライマリ ノードから Always-On リスナーに接続すると、接続は NTLM になります。 これによりループバック チェックが行われ、ユーザーが信頼されていないドメインからのユーザーであることを示す "ログインに失敗しました" というエラーが発生します。 このエラーを解決するには、可用性グループ内のすべてのマシンの BackConnectionHostNames レジストリ キーにリスナー NETBIOS 名と完全修飾名を入力します。 詳細については、「 Windows Server 2003 Service Pack 1 のインストール後に FQDN またはその CNAME エイリアスを使用してサーバーにローカルでアクセスしようとすると、アクセスが拒否されたか、ネットワーク プロバイダーが指定されたネットワーク パスを受け入れなかった場合のエラー メッセージを参照してください。
LANMAN 互換性レベル これは通常、古いコンピューター (Windows 2008 より前) と新しいコンピューターの間で発生します。
LANMAN 互換性レベルをすべてのコンピューターで 5 に設定します。 これにより、NTLM v1 も許可されません。 Kerberos に切り替えて、この問題を回避することもできます。
機密性の高いアカウント 一部のアカウントは、Active Directory で機密性の高いアカウントとしてマークされる場合があります。 ダブルホップ シナリオでは、これらのアカウントを別のサービスに委任することはできません。
制約付きターゲットではない 特定のサービス アカウントに対して制約付き委任が有効になっている場合、ターゲット サーバーの SPN が制約付き委任のターゲットの一覧にない場合、Kerberos は失敗します。
サービスごとの SID この機能は、認証方法として Kerberos ではなく NTLM を使用するようにローカル接続を制限します。 サービスは NTLM 資格情報を使用して別のサーバーにシングル ホップを行うことができますが、制約付き委任を使用しないと、それ以上委任することはできません。
NTLM と制約付き委任 ターゲットがファイル共有の場合、中間層サービス アカウントの委任の種類は Constrained-Any であり、Constrained-Kerberos ではない必要があります。

Note

通常、ダブルホップには、複数のリモート コンピューター間でのユーザー資格情報の委任が含まれます。 たとえば、 SQL1 という名前の SQL Server インスタンスがあり SQL2という名前のリモート SQL Server のリンク サーバーを作成したとします。 リンク サーバーのセキュリティ構成で、ログインの現在のセキュリティ コンテキスト 使用して行うオプションを選択しました。 この構成を使用する場合、Client1 という名前のリモート クライアント コンピューターから SQL1 でリンク サーバー クエリを実行する場合、Windows 資格情報は、最初に Client1 から SQL1 にホップし、次に SQL1 から SQL2 にホップする必要があります (そのため、二重ホップと呼ばれます)。 詳細については、「 Kerberos の二重ホップKerberos の制約付き委任の概要」を参照してください。

ユーザーのログインに失敗しました (空)

このエラーは、ユーザーがログインに失敗したときに発生します。 このエラーは、コンピューターがネットワークに接続されていない場合に発生する可能性があります。 たとえば、次のようなエラー メッセージが表示されることがあります。

Source: NETLOGON
Date: 8/12/2012 8:22:16 PM
Event ID: 5719
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: <computer name>
Description: This computer was not able to set up a secure session with a domain controller in domain due to the following: The remote procedure call was cancelled.
This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

空の文字列は、SQL Server がローカル セキュリティ機関サブシステム サービス (LSASS) に資格情報を渡そうとしたが、何らかの問題が原因で実行できなかったことを意味します。 LSASS が利用できなかったか、ドメイン コントローラーに接続できませんでした。

次の対応する SSPI エラー コードも表示される場合があります。

統合セキュリティとの接続を確立中に、SSPI ハンドシェイクがエラー コード 0x80090311で失敗しました。接続が閉じられました。

統合セキュリティとの接続を確立中に、SSPI ハンドシェイクがエラー コード 0x80090304で失敗しました。接続が閉じられました。

これらのエラー コードは次のように変換されます。

エラー -2146893039 (0x80090311): 認証に対して機関に接続できませんでした。 エラー -2146893052 (0x80090304): ローカル セキュリティ機関に接続できません。

これらのエラーを解決するには、問題のある DC をオフラインにするか、 NLTEST.EXE を使用して DC を切り替えることができます。 - DC にクエリを実行するには、 NLTEST /SC_QUERY:CONTOSO コマンドを実行します。 - DC を変更するには、 NLTEST /SC_RESET:CONTOSO\DC03 コマンドを実行します。

さらにサポートが必要な場合は、Microsoft Active Directory チームにお問い合わせください。

クライアントとサーバーのイベント ログで、障害が発生した前後にログに記録されたネットワーク関連または Active Directory 関連のメッセージがないか確認します。 見つかる場合は、ドメイン管理者と協力して問題を解決してください。

ユーザー '(null)' のログインに失敗しました

"null" の兆候は、LSASS が SQL Server サービス アカウントの資格情報を使用してセキュリティ トークンを復号化できないことを意味する可能性があります。 この条件の主な理由は、SPN が間違ったアカウントに関連付けられているということです。

この問題を修正するには、次の手順に従ってください。

  1. SQLCheck またはSetspn.exeを使用して、SPN 関連の問題を診断して修正します。

  2. SQLCheck を使用して、SQL サービス アカウントが委任に対して信頼されているかどうかを確認します。 出力でアカウントが委任に対して信頼されていないことが示されている場合は、Active Directory 管理者と協力してアカウントの委任を有効にします。

Note

SETSPN -X-Qは、重複または正しく配置されていない SPN をチェックするのに役立つコマンドです。

  1. ドメイン ネーム システム (DNS) の名前解決の問題を診断して修正します。 次に例を示します。

    • PowerShell スクリプトを使用して IP アドレスに ping を実行する:

      • ping -a <your_target_machine>(具体的には IPv4 と -6 IPv6 の-4を使用)
      • ping -a <your_remote_IPAddress>
    • NSLookup を使用して、ローカル コンピューター名とリモート コンピューター名と IP アドレスを複数回入力します。

  2. 返された結果の不一致と不一致を探します。 ネットワーク上の DNS 構成の精度は、SQL Server 接続を成功させるために重要です。 DNS エントリが正しくないと、後で多数の接続の問題が発生する可能性があります。

  3. ファイアウォールまたはその他のネットワーク デバイスが、クライアントがドメイン コントローラーに接続するのをブロックしていないことを確認します。 SPN は Active Directory に格納されます。 クライアントがディレクトリと通信できない場合、接続は成功しません。

その他のエラー情報

セキュリティ向上のために、クライアントに返されるエラー メッセージでは、認証エラーの性質を意図的に非表示にしています。 ただし、SQL Server エラー ログでは、対応するエラーに、認証エラーの条件にマップされるエラー状態が含まれています。 ログインできない理由を判断するには、エラー状態を次の一覧と比較してください。

State 説明
1 エラー情報は使用できません。 通常、この状態は、エラーの詳細を受け取るアクセス許可がないことを意味します。 詳細については、SQL Server 管理者に問い合わせてください。
2 ユーザー ID が無効です。
5 ユーザー ID が無効です。
6 SQL Server 認証で Windows ログイン名を使用しようとしました。
7 ログインが無効で、パスワードが正しくありません。
8 パスワードが正しくありません。
9 パスワードが無効です。
11 ログインは有効ですが、サーバー アクセスに失敗しました。 このエラーの原因の 1 つは、Windows ユーザーがローカル管理者グループのメンバーとして SQL Server にアクセスできるが、Windows が管理者の資格情報を提供していない場合です。 接続するには、 管理者として実行 オプションを使用して接続プログラムを開始し、特定のログインとして Windows ユーザーを SQL Server に追加します。
12 ログインは有効なログインですが、サーバー アクセスに失敗しました。
18 パスワードを変更する必要があります。
38, 46 ユーザーが要求したデータベースが見つかりませんでした。
58 SQL Server は Windows 認証のみを使用するように設定されているのに、SQL 認証を使用したログインがクライアントで試みられた場合です。 もう 1 つの原因は、SID が一致しない場合です。
102 - 111 Azure AD エラー。
122 - 124 空のユーザー名またはパスワードによるエラーです。
126 ユーザーによって要求されたデータベースが存在しません。
132 - 133 Azure AD エラー。

エラー状態は他にも存在し、予期しない内部処理エラーを示します。

よりまれな原因

エラーの理由 SQL 認証を使用してログインしようとしましたが失敗しました。サーバーが Windows 認証 専用に構成されている場合は、次の状況でを返すことができます。

  • サーバーが混合モード認証用に構成されていて、ODBC 接続が TCP プロトコルを使用していて、接続で信頼された接続を使用することが明示的に指定されていない場合。

  • SQL Server が混合モード認証用に構成されていて、ODBC 接続が名前付きパイプを使用し、名前付きパイプを開くために使用されるクライアントの資格情報を使用してユーザーを自動的に偽装する場合、接続文字列は信頼された認証の使用を明示的に指定しません。

この問題を解決するには、接続文字列に TRUSTED_CONNECTION = TRUE を含めます。

この例では、認証エラー状態は 8 です。 これは、パスワードが正しくないことを示します。

ソース メッセージ
2007-12-05 20:12:56.34 ログオン エラー: 18456、重大度: 14、状態: 8。
2007-12-05 20:12:56.34 ログオン ユーザー '<user_name>' のログインに失敗しました。 [CLIENT: <ip address>]

Note

SQL Server が Windows 認証モードを使用してインストールされ、後で SQL Server と Windows 認証モードに変更されると、 sa ログインは最初に無効になります。 これにより、状態 7 エラー "ユーザー 'sa' のログインに失敗しました"。 a ログインを有効にするには、「 サーバー認証モードを変更する」を参照してください。

関連項目