Microsoft Entra (旧Azure AD) と SQL Server をECMAコネクタで連携する際の認証エラー対策

Entra (旧Azure AD) と SQL Server を ECMA コネクタで連携させようとした際、テスト用資格情報で認証エラーが起こると、原因の切り分けに手間がかかりがちです。本記事では、よくある設定ミスや認証モードの問題から、ネットワーク設定や時刻同期まで、幅広い観点で対策を詳しくご紹介します。ぜひ最後までご覧いただき、スムーズな連携に役立ててください。

ECMA コネクタと Microsoft Entra での SQL Server 連携の概要

Microsoft Entra (旧 Azure AD) 上でユーザーを管理しながら、オンプレミスやクラウド環境にある SQL Server と連携し、一貫した ID 管理や自動プロビジョニングを実現するケースが増えています。これにより、ユーザーが新規に作成・変更・削除された際にも、ECMA コネクタによる同期やアカウント管理が容易になります。
しかし、ECMA コネクタでの接続設定は、少しでも誤りがあると認証に失敗しやすく、トラブルシューティングが複雑化します。特に SQL Server の認証モードやアカウント情報の扱い方、ネットワーク設定など、多方面での確認が必要となります。

ECMA コネクタとは？

ECMA (Extensible Connectivity Management Agent) コネクタは、Microsoft Entra ID（旧 Azure AD）や Microsoft Identity Manager (MIM) などの製品と外部システムをつなげるための拡張性の高いアダプターです。オンプレミスのディレクトリや SQL データベース、SaaS アプリケーションなど多種多様なシステムとの連携が可能になります。
標準で用意されているコネクタが無いシステムでも、ECMA の仕組みを使って独自のコネクタを作成することで、ユーザーやグループなどのアイデンティティ情報を自動的にプロビジョニング・デプロビジョニングできます。SQL Server 連携も同様で、この ECMA コネクタを使ってユーザー情報を同期しようと試みるケースが多くあります。

Microsoft Entra (旧Azure AD) と SQL Server の連携が重要な理由

Microsoft Entra ID を用いたユーザー管理は、組織内のセキュリティや効率的なアカウント運用に直結します。オンプレミスで動作する SQL Server に対しても、ユーザー情報の一元管理を行うことで、下記のようなメリットが得られます。

• 重複アカウントの防止
• パスワードリセットやアカウントロックアウトの一元化
• 監査ログの統合管理
• ユーザー追加・削除時の作業負荷軽減

一方で、これらを実現するには Microsoft Entra 側の設定と、SQL Server 側のセキュリティ・認証方式の設定が噛み合っている必要があります。特に ECMA コネクタを介した連携は設定項目も多いため、誤設定があれば認証エラーが最初に目立ちやすいポイントとなります。

認証エラーが発生する主な原因

ECMA コネクタを利用した Microsoft Entra と SQL Server の連携で認証エラーが生じる場合、次のような原因が考えられます。

資格情報の誤入力

最も単純な原因ですが、ECMA コネクタ ホストで入力したユーザー名やパスワード、あるいは SQL Server 側で設定しているログイン情報が一致していない可能性があります。入力フォームや設定ファイルにタイプミスが含まれているケースが意外と多いため、まずはコピーペーストを使って再入力するなど、徹底した再チェックを行うことが重要です。

SQL Server の認証モードの不一致

SQL Server は「Windows 認証モード」と「SQL Server および Windows 認証モード (混合モード)」をサポートしています。SQL Server 認証を使う設定なのに、実際には Windows 認証モードしか許可されていないと、当然ながらログインは失敗します。混合モードを有効にしていたとしても、実際に使用するログインが Windows アカウントなのか SQL アカウントなのかを誤っていると同様に失敗します。

ECMA コネクタ ホスト側の設定ミス

ECMA コネクタ自体の接続文字列やホスト情報に誤りがある可能性があります。たとえば、サーバー名やインスタンス名が間違っている、複数インスタンスを運用しているのにデフォルトインスタンスの想定で設定してしまった、などのミスが見られます。
また、ECMA コネクタの構成上、接続先がローカルホストとして認識されない場合や、名前解決が失敗しているケースも考えられます。

ポート番号やホスト名の設定不備

SQL Server の既定ポートは 1433 ですが、セキュリティ上やマルチインスタンスの都合でポートを変更しているケースがあります。その場合、ECMA コネクタの設定画面や接続文字列で正しいポート番号を指定しないと、接続自体が確立できず、結果的に認証エラーを返すことがあります。
また、DNS 設定が不十分な環境では、ホスト名を解決できないことが原因でタイムアウトやエラーが起こる場合もあります。

エラーを解決するための具体的手順

ここからは、実際にエラーを解消するために行うべき手順を具体的に解説します。トラブルシューティングを効率化するため、原因切り分けの優先度に従って取り組んでみてください。

1. 資格情報の再チェックと再発行

まずは資格情報の再確認を徹底します。特にパスワードが複雑な場合、目視では気づきにくいミスが起こりがちなので、以下の点を試してみてください。

• コピーペーストでパスワードを入力し、不要な空白文字が入っていないか確認
• SQL Server Management Studio (SSMS) などの外部ツールで同じアカウント情報を使い、ログインできるかテスト

必要に応じて SQL Server ユーザーのパスワードを再設定するのも手です。SSMS の例を挙げると、以下のような手順を取ります。

USE [master];
GO
ALTER LOGIN [YourSqlLogin] WITH PASSWORD = 'NewStrongPassword' MUST_CHANGE;
GO

SSMS 上でログイン名を右クリックし、「プロパティ」→「一般」タブからもパスワード変更が可能です。再設定したパスワードを用いて、ECMA コネクタ ホスト側でも再設定します。

2. SQL Server 認証モードの確認と変更

SQL Server の認証モードが SQL Server 認証をサポートしていない場合、SQL アカウントを使った接続テストは失敗します。SQL Server 構成マネージャーや SSMS を使って、以下の手順をチェックしてください。

SQL Server 構成の確認例 (SSMS)

1. SSMS で SQL Server に接続する (Windows 認証で OK)。
2. データベース エンジンを右クリックし「プロパティ」を開く。
3. 「セキュリティ」ページで「サーバ認証」が「SQL Server と Windows 認証モード」になっているか確認。
4. 必要に応じて「SQL Server と Windows 認証モード」に変更し、「OK」で確定。
5. サービスを再起動して反映させる。

認証モードを切り替えたあとに、SQL Server ログインが適切に作成されているかどうかも再度確認しましょう。特に Windows アカウントのみ存在していて、SQL Server アカウントが用意されていないケースでは、SQL Server ログインを新規に作成しておく必要があります。

3. ECMA コネクタの設定とログ確認

ECMA コネクタの構成画面で、接続文字列や認証方式の選択が正しいかを確認します。典型的には以下のような接続文字列を使用することが多いです。

Server=<サーバー名またはIPアドレス>,<ポート番号>;
Database=<対象データベース名>;
User ID=<SQL ログイン名>;
Password=<パスワード>;

実際にコネクタをデプロイした後、ECMA コネクタ ホストのログや Microsoft Entra の「監査ログ」「サインインログ」を参照して、接続エラーがどの時点で発生しているかを確認すると原因の切り分けが容易になります。

• 資格情報エラー：パスワードやユーザー名の不一致
• 接続タイムアウト：ホスト名やポート番号、ファイアウォールの問題
• トークン関連：Microsoft Entra 側のアプリ登録やスコープ設定の誤り

こういったエラーの種類を見分けることで、対処方針が絞り込まれます。

4. Microsoft Entra 側のエンタープライズ アプリケーション設定再確認

ECMA コネクタを利用する際、Microsoft Entra には専用のエンタープライズ アプリケーションを作成・登録する必要があります。このアプリケーションがアカウントのプロビジョニングやグループの同期に適切に設定されていないと、連携時に認証エラーや属性マッピングの不備が発生することがあります。

属性マッピングやスコープ設定の見直し

• 「マッピング」タブで、SQL Server が受け取れる属性（ユーザー名、電子メール、スキーマ定義など）と Entra 側のユーザー属性を正しく紐付ける。
• 「スコープ」設定で、同期対象のグループやユーザーが正しく指定されているか確認。誤った条件で同期対象外になっていないか要チェック。
• 必要に応じて「ステージング モード」を有効化し、実際に同期する前にテスト環境で動作確認するのも安全策として有効。

5. ネットワークとファイアウォールの検証

SQL Server との通信は通常 TCP ポート 1433 を使用しますが、環境によっては別ポートが割り当てられているかもしれません。ファイアウォールが原因でブロックされていると、認証情報以前に接続自体が拒否されることになります。

ポート 1433 以外を使用する場合の注意点

• SQL Server のインスタンスごとに動的ポートが割り当てられている場合は、SQL Server Browser サービスを起動しておく。
• ECMA コネクタ ホストのマシンから、対象ポートに対して telnet や Test-NetConnection (PowerShell) などを実行し、疎通を確認。
• ファイアウォールのルールで特定ポートの通信を許可しているかをチェックし、ポート番号の指定に誤りがないか見直す。

6. 時刻同期とタイムゾーン設定の重要性

多くの認証システムでは、OAuth や Kerberos といったプロトコルに時間情報を活用します。特にクラウドベースの Microsoft Entra ID とオンプレミスの SQL Server 環境が連携する場合、それぞれのサーバーが数分以上ずれると認証エラーが生じる可能性があります。NTP サーバーやドメイン コントローラーを用いた時刻同期設定を再確認し、タイムゾーンも統一されていることを確認すると安心です。

トラブルシューティングの補足情報

認証エラーが一度生じると、関連するサービスや設定が複数あるため、原因究明が長期化しがちです。ここでは、より詳しい確認ポイントをいくつか挙げます。

ログファイルの詳細確認方法

• ECMA コネクタ ホスト: Windows のイベント ビューアーやコネクタ専用ログを参照する。
• SQL Server: SQL Server Error Log に接続失敗や認証失敗の詳細が記録されている。
• Microsoft Entra: Azure Portal の「Azure Active Directory」→「監査ログ」「サインインログ」を確認し、特定ユーザーでどのような認証イベントが発生したか追跡する。

それぞれのログをクロスチェックすることで、どのタイミングでエラーが発生し、何がトリガーとなったかを明確にできます。

環境の再構成と再起動のタイミング

設定を変更したら、SQL Server や ECMA コネクタ、場合によってはサーバー自体の再起動が必要になることがあります。特に SQL Server の認証モードを変更した際はサービス再起動が必須です。ECMA コネクタ側の設定変更でも、コネクタ ホストの再起動または再デプロイが必要になる場合があるため、一連の作業後には必ず再テストを実施し、変更が正しく反映されたかどうか確かめましょう。

ECMA コネクタのバージョン整合性

ECMA コネクタにはバージョンが複数あり、Microsoft Entra ID (または Azure AD) のバージョンや MIM のバージョンとの互換性がない場合、思わぬエラーが生じることもあります。最新のサービスアップデートを適用したことで逆に古いコネクタが使えなくなるケースや、その逆もありえます。
以下の点をチェックしましょう。

• コネクタのバージョンがサポート対象かどうか
• 更新プログラムやパッチの適用状況 (ECMA コネクタ、SQL Server、OS、MIM など)
• Microsoft の公式ドキュメントやコミュニティ フォーラムで似た不具合が報告されていないか

バージョンの問題は見落としがちですが、一度疑ってみると早期解決につながる可能性があります。

まとめ

Microsoft Entra (旧Azure AD) と SQL Server を ECMA コネクタで連携する際に発生する認証エラーは、資格情報のミスや SQL Server の認証モード、コネクタの設定、ネットワークや時刻同期といった多岐にわたる要因が絡み合っている場合があります。
まずはパスワードやユーザー名などの基本的な要素を疑い、次に SQL Server 側の認証モードやコネクタ設定の不備を確認する流れがスムーズでしょう。ポート番号やファイアウォール設定の見直し、Microsoft Entra 側のエンタープライズ アプリケーション構成、さらには時刻同期やバージョン整合性も含めて総合的にチェックすることで、問題を根本から解決できるはずです。
運用環境で動作させる前にテスト環境での検証やステージング モードの活用を行い、リスクを最小化するのも大切なポイントとなります。正しく設定が完了すれば、Microsoft Entra に新規に作成・変更・削除されたユーザーが自動的に SQL Server 上でも管理され、一貫性のあるセキュリティと運用効率を実現できるでしょう。