Excel Add-In for Microsoft Exchange

Build 25.0.9434

接続の確立

接続プロファイルの設定

[CData]リボンから[データの取得]をクリックし、[取得元:Microsoft Exchange]> 設定済みの接続 を選択してCData クエリウィンドウを起動します。新しい接続を設定するには、[新しいMicrosoft Exchange 接続]をクリックします。ここでは、接続の設定、接続のテスト、および接続プロファイルの保存を行うことができます。

Microsoft Exchange への接続

Exchange への接続には2つのスキーマがあります。

  • Microsoft Graph
  • Exchange Web Services(EWS)(非推奨)
    Note:Microsoft は、Exchange Online ユーザーに対してMicrosoft Graph への切り替えを推奨しています。

それぞれのスキーマのデータモデルについては、データモデル を参照してください。

Microsoft Graph とEWS を切り替えるには、SchemaMSGraph またはEWS(非推奨)に設定します。

EWS の使用を続けるExchange Online ユーザーは、SchemaEWS に設定し、PlatformExchange_Online に設定します。

Microsoft Exchange OnPremises への認証

Microsoft Exchange OnPremises は、Basic(デフォルト)、Digest、Negotiate、NTLM 認証をサポートします。

Basic(デフォルト)

Microsoft Exchange OnPremises では、Basic がデフォルトの認証として設定されます。 Basic 認証を使用するには、以下のプロパティを設定します。
  • AuthSchemeBasic
  • User:ユーザーのログインID。
  • Password:ユーザーのログインパスワード。

Digest

オンプレミス環境でHTTP Digest 認証を使用するには、以下のプロパティを設定します。
  • AuthSchemeDigest
  • User:ユーザーのログインID。
  • Password:ユーザーのログインパスワード。

Negotiate

Negotiate は、ドライバーに認証メカニズムをサーバーとネゴシエートするように指示するために使用されます。 この認証スキームの目的は、オンプレミス環境でのKerberos 認証を容易にすることです。 オンプレミス環境でKerberos 認証を使用するには、以下のプロパティを設定します。
  • AuthSchemeNegotiate
  • User:ユーザーのログインID。
  • Password:ユーザーのログインパスワード。

NTLM

オンプレミス環境でWindows NT LAN Manager(NTLM)認証を使用するには、以下のパラメータを設定します。
  • AuthSchemeNTLM
  • User:ユーザーのログインId。
  • Password:ユーザーのログインパスワード。

Microsoft Exchange Online への認証

Microsoft Exchange Online は、複数のOAuth ベースの認証をサポートしています。

EWS を介してExchange Online プラットフォームに接続する場合は、AuthSchemeAzureADAzureServicePrincipalAzureMSI のいずれかに設定します。

Microsoft Graph を介してExchange Online に接続する場合は、SchemaMSGraph に設定します。 SchemaMSGraph に設定されている場合、Platform は無視されます。

Entra ID(Azure AD)

Note:Microsoft はAzure ADEntra ID にリブランドしました。ユーザーがEntra ID 管理サイトを操作する必要があるトピックでは、Microsoft が使用している名称と同じものを使用します。ただし、名前または値が"Azure AD" を参照しているCData 接続プロパティは、依然として存在します。

Microsoft Entra ID は、マルチテナント型のクラウドベースのID およびアクセス管理プラットフォームです。 OAuth ベースの認証フローに対応しており、ドライバーによるMicrosoft Exchange エンドポイントへのセキュアなアクセスを実現します。

Web アプリケーションを介したEntra ID への認証には、必ずはじめにカスタムOAuth アプリケーションを作成して登録する必要があります。 これにより、アプリケーションは独自のリダイレクトURI を定義し、クレデンシャルのスコープを管理し、組織固有のセキュリティポリシーに準拠することができるようになります。

カスタムOAuth アプリケーションの作成および登録方法の詳細については、Entra ID(Azure AD)アプリケーションの作成 を参照してください。

AuthSchemeAzureAD に設定した後の認証手順は、環境によって異なります。 デスクトップアプリケーション、Web ベースのワークフロー、またはヘッドレスシステムから接続する方法の詳細については、以下のセクションを参照してください。

デスクトップアプリケーション

デスクトップアプリケーションでは、ドライバーに組み込まれたOAuth アプリケーション、またはMicrosoft Entra ID に登録されたカスタムOAuth アプリケーションのいずれかを使用して認証を行うことができます。

オプション1:組み込みOAuth アプリケーションの使用

これはドライバーに含まれている、事前登録済みのアプリケーションです。 セットアップが簡単で、独自の認証情報を登録する必要がないため、開発環境、単一ユーザー向けツール、または迅速かつ簡単な認証が求められる構成に最適です。

次の接続プロパティを設定します。

  • AuthSchemeAzureAD
  • InitiateOAuth
    • GETANDREFRESH – 初回ログイン時に使用します。ログインページを起動し、トークンを保存します。
    • REFRESH – すでに有効なアクセストークンおよびリフレッシュトークンを取得している場合は、この設定を使用します。保存されたトークンを再利用するため、ユーザーに再度プロンプトを表示することはありません。

接続時には、ドライバーは既定のブラウザでMicrosoft Entra のサインインページを開きます。 サインインしてアクセスを許可すると、ドライバーはアクセストークンおよびリフレッシュトークンを取得し、OAuthSettingsLocation で指定されたパスに保存します。

オプション2:カスタムOAuth アプリケーションの使用

組織でセキュリティポリシーの管理、リダイレクトURI の設定、アプリケーションのブランディングなど、より高度な制御が必要な場合は、代わりにMicrosoft Entra ID にカスタムOAuth アプリケーションを登録し、接続時にその値を指定することができます。

登録時に、以下の値を記録してください。

  • OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
  • OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
  • CallbackURL:アプリケーション登録時に定義したリダイレクトURI。

カスタムOAuth アプリケーションの登録とリダイレクトURI の設定方法の詳細については、Entra ID(Azure AD)アプリケーションの作成 を参照してください。

次の接続プロパティを設定します。

  • AuthSchemeAzureAD
  • InitiateOAuth
    • GETANDREFRESH – 初回ログイン時に使用します。ログインページを起動し、トークンを保存します。
    • REFRESH – すでに有効なアクセストークンおよびリフレッシュトークンを取得している場合は、この設定を使用します。保存されたトークンを再利用するため、ユーザーに再度プロンプトを表示することはありません。
  • OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
  • OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
  • CallbackURL:アプリケーション登録時に定義したリダイレクトURI。

認証後、トークンはOAuthSettingsLocation に保存されます。 これらの値はセッションをまたいで保持され、アクセストークンの有効期限が切れた際に自動的に更新されるため、次回以降の接続時に再度ログインする必要はありません。

Azure サービスプリンシパル

Note:Microsoft はAzure ADEntra ID にリブランドしました。ユーザーがEntra ID 管理サイトを操作する必要があるトピックでは、Microsoft が使用している名称と同じものを使用します。ただし、名前または値が"Azure AD" を参照しているCData 接続プロパティは、依然として存在します。

Azure サービスプリンシパルは、ロールに基づいたアプリケーションベースの認証です。これは、認証がユーザーごとではなく、アプリケーションごとに行われることを意味します。 アプリケーションで実行されるすべてのタスクは、デフォルトユーザーコンテキストなしで、割り当てられたロールに基づいて実行されます。 リソースへのアプリケーションのアクセスは、割り当てられたロールの権限によって制御されます。

Azure サービスプリンシパル認証の設定方法については、Entra ID(Azure AD)でのサービスプリンシパルアプリの作成 を参照してください。

Managed Service Identity (MSI)

Azure VM 上でMicrosoft Exchange を実行しており、マネージドID(MSI)認証情報を自動的に取得して接続したい場合は、AuthSchemeAzureMSI に設定します。

User-Managed Identities

マネージドID のトークンを取得するには、OAuthClientId プロパティを使用してマネージドID のclient_id を指定します。

VM に複数のユーザーが割り当てられたマネージドID がある場合は、OAuthClientId も指定する必要があります。

接続プロパティ

最後に、Connection プロパティを参照してください。接続の確立に使用できるさまざまなオプションの説明があります。

接続の管理

Microsoft Exchange への認証に成功すると、インポートするデータをカスタマイズすることができます。詳しくは、接続の管理 を参照してください。

関連項目

  • データのクエリ:[データ選択]ウィザードを使用してスプレッドシートにデータをプルします。また、ここではスケジュールされたデータのリフレッシュも設定できます。
  • Excel アドインの使用:利用可能なCData Excel 関数 を使用するなど、Microsoft Exchange データとやり取りする他の方法が見つかります。

Copyright (c) 2025 CData Software, Inc. - All rights reserved.
Build 25.0.9434