CData Python Connector for Microsoft Exchange

Build 25.0.9440

接続の確立

コネクタ内で利用可能なオブジェクトは、"cdata.exchange" モジュールからアクセスできます。モジュールのオブジェクトを直接使用するには:

  1. モジュールを以下のようにインポートします。
    import cdata.exchange as mod
  2. 接続を確立するには、以下のような適切な接続文字列を使用してコネクタオブジェクトからconnect() メソッドを呼び出します。
    mod.connect("User='[email protected]';Password='myPassword';Server='https://outlook.office365.com/EWS/Exchange.asmx';Platform='Exchange_Online';Schema='EWS';")

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

Web アプリケーション

Web アプリケーションから認証を行うには、Microsoft Entra ID(旧称:Azure Active Directory)にカスタムOAuth アプリケーションを登録する必要があります。 Web ベースのフローでは、登録済みのリダイレクトURI と一元的な認証情報の管理が必要となるため、組み込みのOAuth アプリケーションはこの用途ではサポートされていません。

このアプローチは、ホスト型のマルチユーザー環境向けに設計されており、安全で標準に準拠したOAuth ワークフローを経由してアクセスを委任する必要がある場合に適しています。 これにより、組織はOAuth クライアント、リダイレクトURI、ブランディング、権限スコープを制御できます。

開始する前に:Azure ポータルでカスタムOAuth アプリケーションを登録してください。登録時に、以下の値を記録してください。

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

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

Web アプリケーションでAzureAD を使用して認証するには、以下の接続プロパティを設定します。

  • AuthSchemeAzureAD
  • InitiateOAuthOFF – 自動ログインのプロンプトを無効にします。
  • OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
  • OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
  • CallbackURL:アプリケーション登録時に定義したリダイレクトURI。

Web アプリケーションでは通常、OAuth フローをサーバー側で手動で管理するため、InitiateOAuthOFF に設定する必要があります。 これにより、ストアドプロシージャを使用して、トークンの取得および交換のタイミングと方法を明示的に制御できるようになります。

これらのプロパティを設定した後、以下の手順に従ってOAuth トークンを取得および交換してください。

  1. GetOAuthAuthorizationURL ストアドプロシージャを呼び出します。
    • CallbackURL:登録したリダイレクトURI に設定します。
  2. 返されたURL をブラウザで開きます。Microsoft Entra ID アカウントでサインインし、アクセスを許可します。
  3. サインイン後、クエリ文字列にcode パラメータが含まれた状態でCallbackURL にリダイレクトされます。
  4. そのcode を抽出し、GetOAuthAccessToken ストアドプロシージャに渡します。
    • AuthMode:WEB
    • Verifier:CallbackURL からの認可コード。
  5. プロシージャは、以下を返します。
    • OAuthAccessToken:認証に使用されます。
    • OAuthRefreshToken:アクセストークンを更新するために使用されます。
    • ExpiresIn:アクセストークンの有効期間(秒単位)。

トークンの自動更新を有効にするには、以下の接続プロパティを設定します。

InitiateOAuthREFRESH に設定されている場合、ドライバーは提供されたリフレッシュトークンを使用して、自動的に新しいアクセストークンを要求します。

接続に成功すると、ドライバーは更新されたアクセストークンとリフレッシュトークンを、OAuthSettingsLocation によって指定されたファイルに保存します。

リフレッシュトークンが期限切れになるか、取り消されるか、無効になる場合のみ、OAuth の認可フロー全体を再実行する必要があります。

Microsoft Entra ID におけるOAuth フローの詳細については、 Microsoft Entra 認証の概要を参照してください。

ヘッドレスマシン

CI / CD パイプライン、バックグラウンドサービス、サーバーベース連携などのヘッドレス環境では、対話型のブラウザが使用できません。 AzureAD を使用して認証するには、別のデバイス上のブラウザでOAuth フローを完了し、その認証結果をヘッドレスシステムに転送する必要があります。

セットアップオプション :

  • Verifier code を取得および交換
    • 別のデバイスを使用してサインインし、Verifier code を取得します。ヘッドレスシステムがこのコードを使用してトークンを要求します。
  • OAuth 設定ファイルを転送
    • 別のデバイスで認証を行い、その後、保存されたトークンファイルをヘッドレス環境にコピーします。

Verifier code の使用

  1. ブラウザを備えたデバイスで:
    • カスタムOAuth アプリケーションを使用する場合は、次のプロパティを設定します。
      • InitiateOAuthOFF
      • OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
      • OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
    • GetOAuthAuthorizationURL ストアドプロシージャを呼び出し、サインインURL を生成します。
    • 返されたURL をブラウザで開きます。サインインして、ドライバーにアクセス許可を与えます。verifier code を含むコールバックURL にリダイレクトされます。
    • サインイン後、リダイレクトURL のcode パラメータの値を保存します。この値は後でOAuthVerifier 接続プロパティを設定する際に使用します。
  2. ヘッドレスマシンで:
    • 次のプロパティを設定します。
      • AuthSchemeAzureAD
      • InitiateOAuthREFRESH
      • OAuthVerifier:保存したverifier code。
      • OAuthSettingsLocation:OAuth トークンの値を保存するファイルのパス。
      • カスタムアプリケーションの場合:
        • OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
        • OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。
    • トークンを保存した後、以下の設定により再利用できます。
      • InitiateOAuthREFRESH
      • OAuthSettingsLocation:アクセストークンの自動リフレッシュを有効にするために、この場所がドライバーに読み書きのアクセス許可を与えることを確認してください。
      • カスタムアプリケーションの場合:
        • OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
        • OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。

OAuth 設定を転送

  1. ブラウザを備えたデバイスで:
    • デスクトップアプリケーションセクションの説明に従って接続します。
    • 接続後、トークンはOAuthSettingsLocation のファイルパスに保存されます。デフォルトのファイル名はOAuthSettings.txt です。

  2. ヘッドレスマシンで:
    • OAuth 設定ファイルをマシンにコピーします。
    • 次のプロパティを設定します。
      • AuthSchemeAzureAD
      • InitiateOAuthREFRESH
      • OAuthSettingsLocation:アクセストークンの自動リフレッシュを有効にするために、この場所がドライバーに読み書きのアクセス許可を与えることを確認してください。
      • カスタムアプリケーションの場合:
        • OAuthClientId:カスタムOAuth アプリケーションの登録時に生成されたクライアントId。
        • OAuthClientSecret:カスタムOAuth アプリケーションの登録時に生成されたクライアントシークレット。

セットアップ後、ドライバーは保存されたトークンを使用してアクセストークンを自動的に更新するため、ブラウザや手動でのログインは必要ありません。

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 も指定する必要があります。

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