接続の確立
コネクタ内で利用可能なオブジェクトは、"cdata.sql" モジュールからアクセスできます。モジュールのオブジェクトを直接使用するには:
- モジュールを以下のようにインポートします。
import cdata.sql as mod
- 接続を確立するには、以下のような適切な接続文字列を使用してコネクタオブジェクトからconnect() メソッドを呼び出します。
mod.connect("user=myuser;password=mypassword;Server=localhost;Database=Northwind;")
SQL Server への接続
CData Python Connector for SQL Server を使用して、Microsoft SQL Server、Azure SQL Server、またはAzure Data Warehouse の任意のインスタンスに接続できます。
Microsoft SQL Server
SQL Server に接続するには、次の接続プロパティを設定します。
- Server:SQL Server を実行するサーバー名。
- Database:SQL Server データベース名。
Azure SQL Server またはAzure Data Warehouse
以下の接続プロパティを設定することで、Azure SQL Server またはAzure Data Warehouse に接続できます。
- Server:Azure を実行しているサーバー。Azure ポータルにログインして、SQL データベース(またはSQL データウェアハウス) -> 自身のデータベースを選択 -> 概要 -> サーバー名に進むと確認できます。
- Database:Azure ポータルのSQL データベース(またはSQL データウェアハウス)ページに表示されるデータベース名。
SQL Server への認証
本製品 は、SQL Server 認証、Windows 認証、またはKerberos 認証を使用するSQL Server への認証をサポートします。Microsoft SQL Server
SQL Server のユーザーログイン認証情報を使用してMicrosoft SQL Server に認証するには、以下のように設定します。
- AuthScheme:Password に設定。
- User:SQL Server との認証に使われるユーザー名。
- Password:認証ユーザーに関連付けられたパスワード。
Windows
本製品 がプロセスを実行しているWindows ユーザーのID から自動的にログイン認証情報を取得できるようにするには、以下のように設定します。
- AuthScheme:NTLM に設定。
- IntegratedSecurity:true に設定。
Kerberos
Kerberos でSQL Server への認証を行うには、AuthScheme をKERBEROS に設定します。
Kerberos 経由でSQL Server への認証を行うには、認証プロパティを定義し、Kerberos が認証チケットを取得する方法を選択する必要があります。
Kerberos チケットの取得
Kerberos チケットは、依頼者のID を認証するために使用されます。正式なログイン / パスワードの代わりにチケットを使用することで、パスワードをローカルに保存したり、ネットワーク経由で送信したりする必要がなくなります。 ユーザーは、ローカルコンピュータでログインするか、 コマンドプロンプトでkinit USER と入力するたびに、再認証されます(チケットはリフレッシュされます)。本製品 は、 KRB5CCNAME および / またはKerberosKeytabFile 変数が存在するかどうかに応じて、必要なKerberos チケットを取得する3 つの方法を提供します。
MIT Kerberos 資格情報キャッシュファイル
このオプションを使用すると、MIT Kerberos チケットマネージャーまたはkinit コマンドを使ってチケットを取得できます。このオプションでは、User またはPassword 接続プロパティを設定する必要はありません。
このオプションは、KRB5CCNAME がシステムに作成されている必要があります。
MIT Kerberos 資格情報キャッシュファイル経由でチケット検索を有効にするには:
- お使いの環境にKRB5CCNAME 変数が存在することを確認します。
- KRB5CCNAME を資格情報キャッシュファイルを指すパスに設定します。(例えば、C:\krb_cache\krb5cc_0 または/tmp/krb5cc_0 です。)資格情報キャッシュファイルは、MIT Kerberos チケットマネージャーを使用してチケットを生成するときに作成されます。
- チケットを取得するには:
- MIT Kerberos チケットマネージャーアプリケーションを開きます。
- Get Ticket をクリックします。
- プリンシパル名とパスワードを入力します。
- OK をクリックします。
チケットの取得に成功すると、チケット情報がKerberos チケットマネージャーに表示され、クレデンシャルキャッシュファイルに保存されます。
本製品 はキャッシュファイルを使用してSQL Server に接続するためのKerberos チケットを取得します。
Note: KRB5CCNAME を編集したくない場合は、KerberosTicketCache プロパティを使用してファイルパスを手動で設定することができます。この設定後に、本製品 は指定されたキャッシュファイルを使用してSQL Server に接続するためのKerberos チケットを取得します。
Keytab ファイル
お使いの環境にKRB5CCNAME 環境変数がない場合、Keytab ファイルを使用してKerberos チケットを取得できます。
この方法を使用するには、User プロパティを目的のユーザー名に設定し、KerberosKeytabFile プロパティをユーザーに関連付けられたキータブファイルを指すファイルパスに設定します。
User およびPassword
お使いの環境にKRB5CCNAME 環境変数およびKerberosKeytabFile プロパティが設定されていない場合、ユーザーとパスワードの組み合わせを使用してチケットを取得できます。
この方法を使用するには、User およびPassword プロパティを、SQL Server での認証に使用するユーザー / パスワードの組み合わせに設定します。
クロスレルム認証の有効化
より複雑なKerberos 環境では、複数のレルムおよびKDC サーバーが使用されるクロスレルム認証が必要になる場合があります。例えば、1つのレルム / KDC がユーザー認証に使用され、別のレルム / KDC がサービスチケットの取得に使用される場合です。このようなクロスレルム認証を有効にするには、KerberosRealm およびKerberosKDC プロパティをユーザー認証に必要な値に設定します。また、KerberosServiceRealm およびKerberosServiceKDC プロパティを、 サービスチケットの取得に必要な値に設定します。
NTLM
NTLM 認証メカニズムを使用して、ユーザー名とパスワードで認証することができます。認証するには、次を設定します。
- AuthScheme:NTLM
- User:認証するユーザーの名前。
- Password:認証ユーザーに関連付けられたパスワード。
または、AuthScheme をAzureAd、AzurePassword、AzureMSI のいずれかに設定してOAuth を使用することもできます。すべてのOAuth接続で、AzureTenant 接続プロパティをSQL Server データベースがホストされているテナントのId に設定する必要があります。
Azure AD
Azure AD は、Microsoft のマルチテナント、クラウドベースのディレクトリおよびID 管理サービスです。これはユーザーベースの認証で、AuthScheme をAzureAD に設定する必要があります。Web アプリケーションを介したAzure AD への認証には、必ずカスタムOAuth アプリケーションの作成が必要です。詳細はカスタムAzure AD アプリケーションの作成 を参照してください。
デスクトップアプリケーション
CData は、デスクトップアプリケーションからAzure AD への接続を簡略化する埋め込みOAuth アプリケーションを提供します。カスタムOAuth アプリケーションを使用して、デスクトップアプリケーションで認証することもできます。(詳しくは、カスタムAzure AD アプリケーションの作成 を参照してください。) Azure AD 経由で認証するには、以下のパラメータを設定します。
- AuthScheme:AzureAD。
-
カスタムアプリケーションのみ:
- OAuthClientId:カスタムOAuth アプリケーションの登録時に割り当てられたクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーションの登録時に割り当てられたクライアントシークレット。
- CallbackURL:カスタムOAuth アプリケーションの登録時に定義したリダイレクトURI。
接続すると、本製品 はデフォルトブラウザでSQL Server のOAuth エンドポイントを開きます。ログインして、アプリケーションにアクセス許可を与えます。
本製品 はOAuth プロセスを完了し、SQL Server からアクセストークンを取得してそれを使ってデータをリクエストします。 OAuth 値はOAuthSettingsLocation で指定されたパスに保存されます。これらの値は接続間で永続化されます。
アクセストークンの期限が切れたときは、本製品 は自動でアクセストークンをリフレッシュします。
Web アプリケーション
Web アプリケーションを使用してAzure AD 経由で認証する場合は、SQL Server にカスタムOAuth アプリケーションを登録する必要があります(カスタムAzure AD アプリケーションの作成 を参照)。 それから本製品 を使用してOAuth トークンの値を取得および管理します。Azure AD OAuth アクセストークンの取得
はじめに、以下の接続プロパティを設定してOAuthAccessToken を取得します。
- AuthScheme:AzureAD。
- OAuthClientId:アプリケーション設定のクライアントId。
- OAuthClientSecret:アプリケーション設定のクライアントシークレット。
次に、ストアドプロシージャを呼び出してOAuth 交換を完了します。
- GetOAuthAuthorizationUrl ストアドプロシージャを呼び出します。AuthMode インプットをWEB に、CallbackURL インプットをアプリケーション設定で指定したリダイレクトURI に設定します。必要に応じて、Permissions パラメータを設定してカスタム権限をリクエストします。
ストアドプロシージャがOAuth エンドポイントのURL を返します。 - URL を開き、ログインして、アプリケーションを認可します。コールバックURL にリダイレクトされます。
- GetOAuthAccessToken ストアドプロシージャを呼び出します。AuthMode インプットをWEB に設定します。Verifier インプットを、コールバックURL のクエリ文字列の"code" パラメータに設定します。必要に応じて、Permissions パラメータを設定してカスタム権限をリクエストします。
アクセストークンとリフレッシュトークンを取得すると、データに接続し、Azure AD アクセストークンを自動または手動でリフレッシュすることができるようになります。
Azure AD OAuth アクセストークンの自動リフレッシュ
本製品 がAzure AD OAuth アクセストークンを自動的にリフレッシュするようにするには、データへの初回接続時に以下のパラメータを設定します。
- AuthScheme:AzureAD。
- InitiateOAuth:REFRESH。
- OAuthClientId:アプリケーション設定のクライアントId。
- OAuthClientSecret:アプリケーション設定のクライアントシークレット。
- OAuthAccessToken:GetOAuthAccessToken によって返されたアクセストークン。
- OAuthRefreshToken:GetOAuthAccessToken によって返されたリフレッシュトークン。
- OAuthSettingsLocation:ドライバーがOAuth トークン値を保存する場所。これは接続間で維持されます。
それ以降のデータ接続では、OAuthAccessToken とOAuthRefreshToken の値はOAuthSettingsLocation から取得され、接続時に設定する必要はありません。
Azure AD OAuth アクセストークンの手動リフレッシュ
データ接続時に手動でAzure AD OAuth アクセストークンをリフレッシュするために必要な値は、OAuth リフレッシュトークンのみです。
GetOAuthAccessToken が返すExpiresIn パラメータ値が経過した後に、RefreshOAuthAccessToken ストアドプロシージャを使用して手動でOAuthAccessToken をリフレッシュし、次の接続プロパティを設定します。
- OAuthClientId:アプリケーション設定のクライアントId。
- OAuthClientSecret:アプリケーション設定のクライアントシークレット。
ここでRefreshOAuthAccessToken を呼び出し、OAuthRefreshToken にGetOAuthAccessToken によって返されたOAuth リフレッシュトークンを指定します。新しいトークンが取得できたら、OAuthAccessToken をRefreshOAuthAccessToken が返す値に設定し、新しい接続をオープンします。
最後に、OAuth リフレッシュトークンを保存し、OAuth アクセストークンの有効期限が切れた後に手動でリフレッシュできるようにします。
ヘッドレスマシン
ヘッドレスマシンのユーザーアカウントでドライバーを設定するには、インターネットブラウザに対応した別の端末で認証する必要があります。
以下のいずれかの方法で行います。
- 後述のオプション1:Verifier code を取得および交換に従い、OAuthVerifier 値を取得します。
- 後述のオプション2:OAuth 設定を転送で説明するように、本製品 を別のマシンにインストールします。通常のブラウザベースのフローで認証した後、OAuth 認証値を転送します。
オプション1:Verifier code を取得および交換
-
認可エンドポイントを見つけます。
カスタムアプリケーションのみ: 次のプロパティを設定して、Authorization URL を作成します。
- InitiateOAuth:OFF。
- OAuthClientId:アプリケーションの登録時に割り当てられたクライアントId。
- OAuthClientSecret:アプリケーションの登録時に割り当てられたクライアントシークレット。
カスタムアプリケーションおよび埋め込みアプリケーション:GetOAuthAuthorizationUrl ストアドプロシージャを呼び出します。
- ストアドプロシージャによって返されたURL をブラウザで開きます。
- ログインして、本製品 にアクセス許可を与えます。verifier code を含むコールバックURL にリダイレクトされます。
- verifier code の値を保存します。この値は後でOAuthVerifier 接続プロパティを設定する際に使用します。
-
OAuth verifier code をOAuth リフレッシュトークンおよびアクセストークンと交換します。
ヘッドレスマシンでは、次のプロパティを設定します。
- AuthScheme:AzureAD。
- InitiateOAuth:REFRESH。
- OAuthVerifier:verifier code。
- OAuthSettingsLocation:接続間で維持されるOAuth トークンの値を保存するファイルの場所。
-
カスタムアプリケーションのみ:
- OAuthClientId:カスタムOAuth アプリケーション設定のクライアントId。
- OAuthClientSecret:カスタムOAuth アプリケーション設定のクライアントシークレット。
-
OAuth 設定ファイルが生成されたら、以下のように接続プロパティをリセットします。
- InitiateOAuth:REFRESH。
- OAuthSettingsLocation:暗号化されたOAuth 認証値が保存される場所。アクセストークンの自動リフレッシュを有効にするために、この場所が本製品 に読み書きのアクセス許可を与えることを確認してください。
-
カスタムアプリケーションのみ:
- OAuthClientId:アプリケーションの登録時に割り当てられたクライアントId。
- OAuthClientSecret:アプリケーションの登録時に割り当てられたクライアントシークレット。
オプション2:OAuth 設定を転送
ヘッドレスマシン経由の接続に先立ち、インターネットブラウザに対応したデバイスでドライバーとの接続を作成し、インストールする必要があります。上述の「デスクトップアプリケーション」の説明に従って、接続プロパティを設定します。
「デスクトップアプリケーション」の手順を完了すると、生成された認証値は、OAuthSettingsLocation で指定された場所に暗号化されて書き込まれます。デフォルトのファイル名はOAuthSettings.txt です。
接続が正常にテストされたら、OAuth 設定ファイルをヘッドレスマシンにコピーします。
ヘッドレスマシンでは、次のプロパティを設定します。
- AuthScheme:AzureAD。
- InitiateOAuth:REFRESH。
- OAuthSettingsLocation:OAuth 設定ファイルの場所。アクセストークンの自動リフレッシュを有効にするために、この場所が本製品 に読み書きのアクセス許可を与えることを確認してください。
-
カスタムアプリケーションのみ:
- OAuthClientId:アプリケーションの登録時に割り当てられたクライアントId。
- OAuthClientSecret:アプリケーションの登録時に割り当てられたクライアントシークレット。
Azure サービスプリンシパル
サービスプリンシパルは、Azure AD アプリケーション内のセキュリティオブジェクトであり、特定のAzure AD テナント内でそのアプリケーションができることを定義します。 サービスプリンシパルは、Azure サービスポータルで作成します。 作成プロセスの過程で、サービスプリンシパルがクライアントシークレットまたは証明書のどちらを経由してAzure AD リソースにアクセスするかも指定します。サービスプリンシパルの権限は、特定のユーザーに紐づくのではなく、割り当てられたロールに基づきます。 リソースへのアプリケーションのアクセスは、割り当てられたロールの権限によって制御されます。
Azure サービスプリンシパルを使用して認証する場合、サービスプリンシパルによるAzure AD アプリケーションの作成 で説明するようにAzure AD テナントにアプリケーションを登録する必要があります。
次のサブセクションで説明するプロパティを設定すれば、接続の準備は完了です。これらは、クライアントシークレットで認証するか、証明書で認証するかによって異なります。
クライアントシークレットによる認証
- AuthScheme:AzureServicePrincipal。
- AzureTenant:接続するAzure AD テナント。
- OAuthGrantType:CLIENT。
- OAuthClientId:アプリケーション設定のクライアントId。
- OAuthClientSecret:アプリケーション設定のクライアントシークレット。
証明書による認証
- AuthScheme:AzureServicePrincipalCert。
- AzureTenant:接続するAzure AD テナント。
- OAuthGrantType:CLIENT。
- OAuthClientId:アプリケーション設定のクライアントId。
- OAuthJWTCert:JWT 証明書のストア。
- OAuthJWTCertType:JWT 証明書ストアの種類。
Azure Password
AuthScheme をAzurePassword に設定します。
Azure 資格情報を使用して直接接続するには、次の接続プロパティを指定します。
- User:Azure に接続するためのユーザーアカウント。
- Password:Azure に接続するためのユーザーアカウントのパスワード。
- AzureTenant:Azure 上のSQL Server への認証に使用するカスタムAzure AD アプリケーションのディレクトリ(テナント)ID。カスタムアプリケーションの概要ページに表示されます。
Managed Service Identity (MSI)
Azure VM 上でSQL Server を実行しており、MSI を利用して接続したい場合は、AuthScheme をAzureMSI に設定します。
User-Managed Identities
マネージドID のトークンを取得するには、OAuthClientId プロパティを使用してマネージドID の"client_id" を指定します。VM に複数のユーザーが割り当てられたマネージドID がある場合は、OAuthClientId も指定する必要があります。