11gリリース1(11.1.1)で使用可能なLDAPプロトコルの拡張機能について説明します。この章では、次の項目について説明します。Directoryでは、SASLベース認証の2つのメカニズムをサポートします。この項では、それらのメカニズムについて説明します。次の項目について説明します。2829)で必要な認証メカニズムです。LDAPバージョン2では、Digest-MD5はサポートされません。APIのいずれかを使用して認証を設定できます。APIでサポートされているのはauthモードのみです。Digest-MD5のauth-intモードおよびauth-confモードの使用」を参照してください。C固有の情報は、第8.2.5項「ディレクトリに対する認証」および第8.2.6項「Oracleの拡張機能を使用したSASL認証」を参照してください。Protection(QoP)を表しています。これには、次のようなものがあります。初期バインドにのみ認証が必要です。その後、情報はクリアテキストで渡されます。初期バインドには認証が必要です。その後、チェックサムを使用してデータの整合性が保証されます。初期バインドには認証が必要です。その後、暗号化を使用してデータが保護されます。次に示す5つの暗号方式を使用できます。DES3DESRC4RC4-56RC4-40これらはすべて対称型暗号化アルゴリズムです。Directoryでは、Digest-MD5メカニズムのauthモードのみがサポートされました。APIで3つのモードがすべてサポートされています。SDKでサポートされているのはauthモードのみです。Digest-MD5ベリファイアの生成がサポートされています。Digest-MD5を使用する場合は、新しいユーザーをプロビジョニングする前に関連するパスワード・ポリシーでorclpasswordencryptionenable属性の値を1に変更して、どちらからもパスワードを生成できるようにしておく必要があります。値を変更するLDIFファイルは次のようになります。2831を参照してください。2617)に基づいています。ForceのWebサイト(http://www.ietf.org)。OpenLDAPのクラス・ライブラリ(http://www.openldap.org)。Digest-MD5は、次のようにユーザーを認証します。ディレクトリ・サーバーは、サポートする各種認証オプションと特別なトークンを含むデータをLDAPクライアントに送信します。クライアントは、選択した認証オプションを示す暗号化されたレスポンスを送信して応答します。レスポンスは、クライアントがそのパスワードを知ることがないように暗号化されます。ディレクトリ・サーバーは、クライアントのレスポンスを復号化し、検証します。2222のセクション7.4を翻訳したものです。外部認証に関連付けられたメカニズム名はEXTERNALです。クライアントは、認可アイデンティティの入った初期レスポンスを送信します。サーバーは、SASLの外部にある情報を使用して、クライアントが認可アイデンティティとして認証を行う権限を持っているかを判断します。クライアントにその権限がある場合、サーバーは認証情報の交換が正常に終了したことを示します。クそれ以外の場合、サーバーは失敗したことを示します。IPsecやSSL/TLSなどのシステムによりこの外部情報が提供されます。クライアントが認可アイデンティティとして空の文字列を送信した(クライアントの認証資格証明から作成された認可アイデンティティをリクエストする)場合、認可アイデンティティは外部認証を提供するシステムの認証資格証明から作成されます。Directoryは、SSL相互接続を介してSASL外部メカニズムを提供します。認可アイデンティティ(識別名)は、SSLネットワーク協定時のクライアント証明書から作成されます。v3プロトコルではコントロールによる拡張機能が許可されています。Directoryでは複数のコントロールをサポートしています。一部は標準で、RFCで説明されています。階層検索用のCONNECT_BYコントロールなど、それ以外のコントロールはOracle固有です。コントロールは、JavaまたはCで使用できます。コントロールは、サーバーに送信したり、LDAPメッセージとともにクライアントに戻すことができます。このようなコントロールは、サーバー・コントロールと呼ばれます。APIは、クライアント・コントロールを使用してクライアント側の拡張メカニズムもサポートします。APIの動作にのみ影響し、サーバーに送信されることはありません。CでのLDAPコントロールの使用の詳細は、第8.2.7項「コントロールの使用」を参照してください。JavaにおけるLDAPコントロールの使用の詳細は、http://www.oracle.com/technetwork/java/jndi/index.htmlのJNDIパッケージjavax.naming.ldapに関するドキュメントを参照してください。リリース1(11.1.1)でサポートされているコントロールを示します。単一属性にのみ構成されます。-replaceなどの操作における計算属性値の一意性がディレクトリ全体で確保されます。0x44」が返されます。マルチテナント環境では、ユーザーのUID属性は特定のテナントで一意である必要がありますが、ディレクトリ全体では必ずしも一意である必要はありません。アプリケーションでは、計算属性TenantID_UIDを持つLDAPエントリが作成されます。ここで、TenantIDはテナントの識別子、UIDは属性になります。LDAPエントリが作成されたアプリケーションでは、このコントロールが送信されます。Directoryサーバーによって、LDAP_ALREADY_EXISTSエラー・コードが返されます。2.16.840.1.113730.3.4.9OID_SEARCH_VLV_REQ_CONTROL指定のLDAP検索で、大規模な検索結果セットの連続したサブセットを返すことをクライアントがサーバーに求めることを許可します。このコントロールを使用すると、検索結果を一度に1ページずつ表示できるため、クライアントでのより迅速な検索結果の取得が可能になると同時に、一度に多数の検索結果の格納が必要になる事態を防げます。2.16.840.1.113730.3.4.10が返されます。OID_SEARCH_VLV_REQ_CONTROLは、SORTコントロール(ldapsearchの-T引数)との組合せでのみ使用できます。SORTコントロールを含めないと、リクエストによりLDAPエラー・コード53「VLVリクエスト制御を含む検索操作でSORTリクエスト制御が欠落しています。SORTコントロールでは、サーバーで有効な任意のソート指定を含められます。SORTコントロールをOID_SEARCH_VLV_REQ_CONTROLと一緒に使用すると、サーバーはソートした検索結果の完全セットを返すかわりに、ターゲット・エントリを検索結果の参照ポイントとして使用して、コントロールで指定されているエントリの連続したサブセットを返します。Results」(http://tools.ietf.org/html/draft-ietf-ldapext-ldapv3-vlv-09)を参照してください。1.2.840.113556.1.4.319OID_SEARCH_PAGING_CONTROL「ページング済のLDAP検索結果」を参照してください。1.2.840.113556.1.4.473OID_SEARCH_SORTING_REQUEST_CONTROL「ソート済のLDAP検索結果」を参照してください。Directoryの参照、動的グループおよび別名オブジェクトの管理に使用されます。Directories」を参照してください。2.16.840.1.113894.1.8.1OID_RESET_PROXYCONTROL_IDENTITY確立されたLDAP接続でアイデンティティのプロキシ・スイッチを実行するために使用されます。アプリケーションAがディレクトリ・サーバーに接続していて、アプリケーションBにスイッチする場合を考えます。アプリケーションBの資格証明を提供することで、リバインドは簡単に実行できます。資格証明が使用できないときでも、アプリケーションによるアイデンティティの切り替えを可能にするプロキシのメカニズムを使用できる場合があります。DirectoryでアプリケーションAがアプリケーションBとしてプロキシする権限を持っている場合に、アプリケーションAがアプリケーションBにスイッチすることができます。Directoryによるアカウント・ロックアウトの確認が必要なアプリケーションによって送信されます。Directoryはアプリケーションにベリファイアを送信しません。適切なパスワード・ポリシー・エラーが送信されます。2.16.840.1.113894.1.8.3CONNECT_BY第3.5項「階層検索の実行」を参照してください。DirectoryによってIPロックアウトが実行される場合に、クライアントがエンド・ユーザーIPアドレスを送信するために使用されます。2.16.840.1.113894.1.8.5GSL_REQDATTR_CONTROL動的グループとともに使用されます。ディレクトリ・サーバーに、メンバーシップ・リストではなくメンバーの特定の属性を読み取るよう指示します。2.16.840.1.113894.1.8.6PasswordStatusRequestControlこのコントロールがLDAPバインド/比較操作リクエストの一部としてパッケージ化されている場合、このコントロールによってサーバーでパスワード・ポリシーのレスポンス・コントロールが生成されます。実際のレスポンス・コントロールは状況に応じて異なります。状況とは、差し迫ったパスワードの有効期限、残りの猶予期間ログインの数、パスワードの期限切れ、アカウントのロックなどです。2.16.840.1.113894.1.8.14OID_DYNAMIC_VERIFIER_REQUEST_CONTROLサーバーによる動的パスワード・ベリファイアの作成が必要な場合にクライアントが送信するリクエスト・コントロール。サーバーは、リクエスト・コントロールのパラメータを使用してベリファイアを作成します。Directoryは、パスワード・ポリシーのレスポンス・コントロールを返し、アカウントのロックアウトやパスワードの有効期限などのアカウント状態に関連する情報をクライアント・アプリケーションに知らせます。2.16.840.1.113894.1.8.23GSL_CERTIFICATE_CONTROL"証明書検索コントロール。ユーザー証明書の検索方法を指定するためにクライアントが送信するリクエスト・コントロール。Directory管理者ガイド』の付録「ユーザー証明書のディレクトリの検索」を参照してください。2.16.840.1.113894.1.8.29EffectivePolicyControlこのコントロールは、LDAPベース検索の一部としてパッケージ化されます(ベースDNは、テストされているユーザー・エントリのDNです)。この時点で、ディレクトリにエントリが存在している必要はありません。検索を実行しているエンティティがパスワード・ポリシー・エントリを表示するアクセス権を持つ場合、このコントロールを渡すと、適用されるパスワード・ポリシーが記述されたLDAPエントリが返されます。オプションのtestPasswordパラメータとして望ましいパスワードを指定すると、ディレクトリ・サーバーはレスポンス・コントロール2.16.840.1.113894.1.8.32を返します。2.16.840.1.113894.1.8.36DelSubtreeControlこのコントロールが削除操作とともに送信された場合、指定されたDN以下のサブツリーすべてが削除されます。この操作を実行できるのは必要な権限を持つユーザーです。Controlこのコントロールの値であるトランザクション識別子により操作とトランザクションの関連を示すLDAPコントロールです。このcriticalityはTRUEです。2.16.840.1.113730.3.4.9に応答してこのコントロールを返します。2.16.840.1.113894.1.8.7OID_PASSWORD_EXPWARNING_CONTROLパスワード・ポリシー・コントロール。pwdExpireWarning属性が有効化されていて、クライアントからリクエスト・コントロールが送信された場合にサーバーが送信するレスポンス・コントロール。レスポンス・コントロール値には、パスワードの有効期限を表す秒単位の時間が含まれます。2.16.840.1.113894.1.8.8OID_PASSWORD_GRACELOGIN_CONTROLパスワード・ポリシー・コントロール。猶予期間ログインが構成されていて、クライアントからリクエスト・コントロールが送信された場合にサーバーが送信するレスポンス・コントロール。レスポンス・コントロール値には、猶予期間ログインの残数が含まれます。2.16.840.1.113894.1.8.9OID_PASSWORD_MUSTCHANGE_CONTROLパスワード・ポリシー・コントロール。強制パスワードのリセットが有効化されていて、クライアントからリクエスト・コントロールが送信された場合にサーバーが送信するレスポンス・コントロール。クライアントは、ユーザーがこのコントロールを受信する際にパスワードの変更を強制する必要があります。2.16.840.1.113894.1.8.15OID_DYNAMIC_VERIFIER_RESPONSE_CONTROLエラーが発生した場合にサーバーがクライアントに送信するレスポンス・コントロール。レスポンス・コントロールにはエラー・コードが含まれています。2.16.840.1.113894.1.8.32PasswordValidationControl必要なパスワードがオプションのtestPasswordパラメータとして指定されると、サーバーはコントロール2.16.840.1.113894.1.8.29に応答してこのコントロールを返します。クライアント・アプリケーションはvalidationResultを解析して、サーバーがパスワードを受け入れられるかどうか(成功)、またはパスワードが拒否された理由を判断できます。userpasswordに対するLDAP変更操作が失敗したときに生成されるタイプと同じエラー・メッセージが値として返されます。Directoryインストールで使用可能なコントロールを確認するには、次のように入力します。"objectclass=*"supportedcontrol=で始まるエントリを探します。エンド・ユーザーの代理となるプロキシ多くの場合、アプリケーションはエンド・ユーザーの代理を務めることが必要になる操作を実行する必要があります。エンド・ユーザーのリソース・アクセス記述子を取得する場合などです。Directory管理者ガイド』の概要の章を参照してください。)プロキシ・スイッチは、実行時にJNDIコンテキストで行われます。v3の機能であるプロキシは、InitialDirContextのサブクラスInitialLdapContextを使用しないと実行できません。Oracleの拡張機能oracle.ldap.util.jndi.ConnectionUtilを使用して接続を確立する場合(後述の例)、InitialLdapContextが常に戻されます。JNDIを使用して接続を確立する場合は、InitialLdapContextが戻されるようにしてください。注意:エンド・ユーザーへのプロキシ・スイッチを実行するには、ユーザーの識別名が必要です。サブスクライバからフェッチしたUserオブジェクトがすでに存在する場合、次のコード断片で示すように、ユーザーの識別名を使用できます。subscriber.getUser(...);user.getDn();Userオブジェクトが存在しない場合は、次のコード断片で示すように、ユーザ名、UID、SAMアカウント名またはKerberosプリンシパルから作成できます。Util.IDTYPE_KERB_PRINCIPALuser.getDn();次のコードは、プロキシ・スイッチがどのように行われるかを示しています。}}前述のコードのProxyControlクラスは、javax.naming.ldap.Controlを実装します。Managementリファレンス』のLDAPコントロールに関する項を参照してください。次に、ProxyControlクラスの例を示します。動的パスワード・ベリファイアの作成LDAP認証APIを変更して、アプリケーション・パスワードを動的に(ユーザーがアプリケーションにログインするときに)生成できます。この機能は、パスワード・ベリファイアのパラメータを実行時にのみ指定するアプリケーションの必要性を満たすことを目的としています。この項の項目は次のとおりです。動的パスワード・ベリファイアのリクエスト・コントロールパスワード・ベリファイアを動的に作成するには、LDAP認証APIのldap_searchまたはldap_modifyを変更して、パスワード・ベリファイアのパラメータを含める必要があります。LDAPコントロールDynamicVerifierRequestControlは、このパラメータを転送するためのメカニズムです。これは、パスワード・ベリファイアの静的作成に使用されるパスワード・ベリファイア・プロファイルにかわるものです。動的ベリファイアの場合にも、静的ベリファイアと同様に、ディレクトリ属性orclrevpwd(同期)およびorclunsyncrevpwd(非同期)が存在し、これらの属性に値が移入されていることが必要になります。orclrevpwdを生成する場合は、ユーザー・レルムにあるパスワード・ポリシー・エントリのorclpwdencryptionenable属性を1に設定する必要があることに注意してください。この属性を設定しないと、ユーザーが認証を受けようとしたときに例外がスローされます。orclunsyncrevpwdを生成するには、暗号タイプ3DESをエントリcn=defaultSharedPINProfileEntry,cn=common,cn=products,cn=oraclecontextに追加する必要があります。DynamicVerifierRequestControlの構文リクエスト・コントロールは次のようになります。}コントロール構造のパラメータは出現順に渡す必要があることに注意してください。表3-3に、このパラメータを定義します。DynamicVerifierRequestControlのパラメータパラメータ説明controlOIDコントロール構造を一意に識別する文字列。cryptoハッシング・アルゴリズム。コントロール構造に指定された4種類のうちいずれかを選択します。usernameユーザーの識別名(DN)。この値は常に含める必要があります。realmランダムに選択されたレルム。ユーザーが属するアイデンティティ管理レルムの場合があります。アプリケーション・レルムの場合もあります。SASL/MD5アルゴリズムにのみ必要です。nonceランダムに選択された任意の値。SYNCML1.0とSYNCML1.1に必要です。ハッシング・アルゴリズムに必要なパラメータ表3-4に、動的パスワード・ベリファイアの作成に使用される4種類のハッシング・アルゴリズムを示します。この表には、各アルゴリズムの構成要素として使用されるパラメータも示します。ユーザー名とパスワードのパラメータはすべてのアルゴリズムで使用しますが、realmおよびnonceパラメータを使用するかどうかはアルゴリズムによって異なることに注意してください。認証APIの構成パスワード・ベリファイアを動的に生成する必要のあるアプリケーションの場合、認証APIにDynamicVerifierRequestControlを組み込む必要があります。ldap_searchまたはldap_compareにcontrolOIDとコントロール値をパラメータとして含めることが必要です。これらのAPIは、第3.4.2項「DynamicVerifierRequestControlの構文」に示したコントロール値をBERエンコードし、controlOIDとコントロール値の両方をディレクトリ・サーバーに送信する必要があります。ldap_searchの使用時に渡されるパラメータアプリケーションでユーザーを認証するには、ldap_searchを使用してコントロール構造を渡します。ldap_searchを使用する場合、ディレクトリは作成したパスワード・ベリファイアをクライアントに渡します。ldap_searchには、ユーザーの識別名、controlOIDおよびコントロール値を含める必要があります。ユーザーのパスワードがシングル・サインオン・パスワードの場合、渡される属性はauthpasswordです。パスワードが数値PINやその他の非同期パスワードの場合、渡される属性はorclpasswordverifier;orclcommonpinです。Directoryでユーザーを認証するには、ldap_compareを使用してコントロール構造を渡します。この場合、ディレクトリはベリファイアを保持し、ユーザー自身を認証します。ldap_searchと同様に、ldap_compareには、ユーザーの識別名、controlOID、コントロール値およびユーザーのパスワード属性を含める必要があります。ldap_compareの場合、パスワード属性はorclpasswordverifier;orclcommonpin(非同期)です。動的パスワード・ベリファイアのレスポンス・コントロールエラーが発生すると、ディレクトリはLDAPコントロールDynamicVerifierResponseControlをクライアントに送信します。このレスポンス・コントロールにはエラー・コードが含まれています。Directory管理者ガイド』のトラブルシューティングに関する章を参照してください。動的ベリファイア・フレームワークに対する権限の取得パスワード・ベリファイアをディレクトリで動的に作成するには、アプリケーションのアイデンティティをディレクトリ管理者のVerifierServicesグループに追加する必要があります。このタスクを実行しないと、ディレクトリはLDAP_INSUFFICIENT_ACCESSエラーを戻します。階層検索の実行LDAP検索ファンクションに渡すことのできるサーバー・コントロールの1つはCONNECT_BYです。これは、Oracle固有のコントロールで、階層全体を検索できます。CONNECT_BYコントロールを使用せずにgroup1のすべてのユーザーを検索すると、検索ファンクションはgroup1の直接のメンバーであるユーザーのみを返します。CONNECT_BYコントロールを渡すと、検索ファンクションは階層全体を検索します。group2がgroup1のメンバーの場合には、検索でgroup2のユーザーも返されます。group3がgroup2のメンバーの場合には、検索でgroup3のユーザーも返されます。CONNECT_BYコントロールの新機能10g(10.1.4.0.1)では、CONNECT_BYコントロールは次の2点において拡張されています。階層をどちらの方向にも検索できるようになりました。エントリが含まれているすべてのコンテナとエントリ内に含まれているすべてのコンテナを検索できます。検索する階層のレベル数を指定できるようになりました。CONNECT_BYコントロールの値フィールド以前のリリースでは、CONNECT_BYコントロールには値は必要ありませんでした。新機能により、次に示す値のいずれか、または両方をCONNECT_BYに渡すことができるようになりました。検索対象の属性を表す文字列。この値は、エントリが含まれるすべてのコンテナを検索する場合にのみ必要です。エントリ内に含まれるコンテナを検索する場合、この情報は検索フィルタによって提供されるため、この値を指定する必要はありません。検索するレベル数を表す整数。値を0にすると、すべてのレベルが検索されます。デフォルト値は0のため、すべてのレベルを検索する場合にはこの値を渡す必要はありません。メンバーは検索フィルタに含まれているため指定する必要はありません。デフォルトは0であるため、レベル数の値を渡す必要はありません。例1と同じフィルタを使用し、整数のコントロール値1を渡します。結果は、CONNECT_BYコントロールを使用しなかった場合と同じになります。グループのすべてのメンバーの検索この場合、検索フィルタには(objectclass=*)が指定されていますが、group1のすべてのメンバーを検索する場合、階層全体を検索するための属性はmemberです。この検索では、文字列"member"を階層構成属性として渡す必要があります。デフォルトは0であるため、レベル数の値を渡す必要はありません。ユーザーのすべてのマネージャの検索ユーザーjsmithのすべてのマネージャを検索する点を除き、例3に似ているため、階層全体を検索するための属性はmanagerです。この検索では、文字列"manager"を渡します。デフォルトは0であるため、レベル数の値を渡す必要はありません。2891で説明されているように、LDAP検索からソート済の結果を取得できるようになりました。タイプ1.2.840.113556.1.4.473のコントロールを検索ファンクションに渡すことでソート済の結果をリクエストします。サーバーにより戻されるレスポンス・コントロールは、タイプ1.2.840.113556.1.4.474です。2891を参照してください。ソートおよびページングを一緒に使用できます。Directory実装には、次の制限事項があります。コントロール値でサポートされているのは、1つのattributeTypeのみです。各属性のスキーマに定義されているデフォルトの順序付けルールが使用されます。言語ソートはサポートされていません。デフォルトのソート順序は昇順です。ソート・キーが複数の値を含む属性で、エントリにもその属性に対して複数の値があり、ソート順序に影響するその他のコントロールが存在しない場合、サーバーでは、その属性の順序付けルールに応じて最後の値が使用されます。ソート属性は検索可能である必要があります。Directoryでカタログ化されている属性である必要があります。2696で説明されているように、LDAP検索からページング済の結果を取得できるようになりました。タイプ1.2.840.113556.1.4.319のコントロールを検索ファンクションに渡すことでソート済の結果をリクエストします。2696を参照してください。Manipulation」。ソートおよびページングを一緒に使用できます。Directory実装には、次の制限事項があります。ACIにより検索結果から複数のエントリが部分的にブロックされた場合、ページ内のエントリ数はページ・サイズより少なくなる可能性があります。ページングのレスポンス・コントロールには、合計のエントリ件数の見積りは含まれません。Directoryは、パスワードを制御する一連の豊富なポリシーをネイティブにサポートします。Directory管理者ガイド』のパスワード・ポリシーの管理に関する項を参照してください。実行時にディレクトリのパスワード・ポリシーと対話するようにアプリケーションを設計し、結果として生じるイベントを正常に処理する必要があります。Directoryには、クライアントがサーバーのパスワード・ポリシーと対話できる複数のメカニズムが用意されています。この項の項目は次のとおりです。ユーザーのプロビジョニング使用するアプリケーションでディレクトリ内の独自のユーザーをプロビジョニングする場合、新しいユーザー・エントリをディレクトリにコミットする前に、パスワードがサーバーで受け入れられるかどうかをテストする必要があります。次のカスタム・コントロールを使用して、パスワードをテストできます。(optional)このコントロールをLDAPベース検索の一部としてパッケージ化します。このベースDNは、テストされているユーザー・エントリのDNです。この時点で、ディレクトリにエントリが存在している必要はありません。サーバーは検索を実行しているエンティティがパスワード・ポリシー・エントリを表示するアクセス権を持つ場合に、適用されるパスワード・ポリシーを記述するLDAPエントリを戻します。希望のパスワードをオプションのtestPasswordパラメータとして指定すると、ディレクトリ・サーバーが次のレスポンス・コントロールを戻します。STRINGクライアント・アプリケーションはvalidationResultを解析して、サーバーがパスワードを受け入れられるかどうか(成功)、またはパスワードが拒否された理由を判断できます。エラー・メッセージは、userpasswordに対するLDAP変更操作が失敗したときに生成されるものと同じです。ユーザー認証ユーザー認証の使用例は、大きくは次の2つの主なカテゴリに分類されます。前者は、標準のuserpassword属性に対して実行される認証です。認証プロセス全体はディレクトリ・サーバー内で行われ、アカウントの様々な状態を必要に応じて更新するために適切な内部イベントが生成されます。後者は、パスワード・ベリファイアなどのその他の認証トークンに対して実行される認証で、ユーザー・エントリの一部として管理されます。トークンは、アプリケーションによって取得されます。認証プロセスはアプリケーション内で、ディレクトリ・サーバーの範囲外で行われます。そのため、LDAP検索ベース認証では、ディレクトリは、認証の結果を暗黙的に把握しません。次の2つの項では、この2種類の認証シナリオを扱う場合のアプリケーション統合のベスト・プラクティスについて説明します。LDAPバインド/比較操作ベースの認証このタイプの認証が従来使用されるのは、単純なプロトコルの場合です。アプリケーションは、サーバーに対してLDAPのバインドまたは比較操作のいずれかを実行し、成功したかどうかを確認します。それ以外の場合はすべて認証が失敗したものとして扱います。認証が失敗すると、アプリケーションはその理由を究明し、状況を修正するアクションを実行するか、原因をエンド・ユーザーに公開してエンド・ユーザーが状況を修正する措置を取ることができるようにします。これにより、ユーザーの経験が増し、管理オーバーヘッドが軽減されます。LDAPバインド/比較操作時にこのような原因の情報を取得するには、次のLDAPコントロールを使用します。}このコントロールがLDAPバインド/比較操作リクエストの一部としてパッケージ化される場合、このコントロールはサーバーで処理され、レスポンス・コントロールが生成されます。実際のレスポンス・コントロールは状況に応じて異なります。Directoryでサポートされているレスポンス・コントロール」のパスワードのレスポンス・コントロールを参照してください。状況とは、差し迫ったパスワードの有効期限、残りの猶予期間ログインの数、パスワードの期限切れ、アカウントのロックなどです。LDAP検索操作ベースの認証アプリケーションがディレクトリから認証トークンを取得した後に独自で認証を行った場合、状態関連ポリシーはすべて無効となります。これらのポリシーが無効の場合、アカウント・ロックなどのシナリオを実施できず、期限切れアカウントのユーザーがアプリケーションに対して認証される可能性があります。Directoryには、このようなアプリケーションが、ディレクトリ・サーバーにすでに存在する状態に関連するポリシー・フレームワークを利用できるようにする2つのメカニズムがあります。これらについて次の項で説明します。認証時に状態ポリシーを確認および実施する機能この機能は、次のカスタム・コントロールによって有効になります。Directoryはこのコントロールを処理してレスポンス・コントロールを戻し、アカウントのロックアウトやパスワードの有効期限切れなどのアカウント状態に関連する情報をクライアント・アプリケーションに知らせます。Directoryでサポートされているレスポンス・コントロール」のパスワード・レスポンス・コントロールを参照してください。アプリケーションは結果の解析および実施が可能になります。ポリシーがどのようにしてクライアント・アプリケーションで実施できるかという問題はこれで解決されますが、その他の基本的なアプリケーションの要件は次のようになります。Directoryでは、仮想属性orclAccountStatusEventによってこの機能が提供されます。この属性は、すべてのユーザー・エントリで仮想属性として使用できます。ディスクのフットプリントがありません。これに対して変更操作を適用できます。ディレクトリには、デフォルトでこの属性に対するアクセス制限があるため、ディレクトリ管理者に、関連するユーザー群について、属性に対するアプリケーションのアイデンティティ書込み権限を付与するように依頼する必要があります。認証の成功または失敗をディレクトリに伝えるには、UserAccountEventを保持するようにこの属性を変更します。次のLDIFでこれを示します。Directoryでは、UserAccountEventの次の値が認識されています。Directoryがこれらのイベントを受信すると、LDAPバインドまたは比較操作に対する認証が成功または失敗したときに起動される論理を起動するため、必要なアカウント状態を更新します。Directoryで使用可能な、既存のアカウント状態に関連するインフラストラクチャを使用してアプリケーションを保護できます。ユーザー・アカウントのメンテナンスユーザー・アカウントのメンテナンスと、パスワード・ポリシーとのやりとりは、定期的なパスワード変更の前後で主に行われます。アプリケーションで前述のEffectivePolicyControlを使用して有効なポリシーを取得し、そのポリシーを解析して、エンド・ユーザーをパスワード構成要件を示すメッセージを生成することをお薦めします。このコントロールにカプセル化されたテスト機能を使用して、エンド・ユーザーに変更の失敗の原因を示します。アプリケーション内でこのような状況に対処することで、管理オーバーヘッドが軽減されます。次に、次回のログイン時にユーザーがパスワードを変更する必要がある使用例が多数あります。Directoryは、pwdmustchangeパスワード・ポリシー要素が有効化されていて、userpasswordが非自己変更される場合にこの要件をネイティブにトリガーします。Directoryは、前述のorclAccountStatusEvent属性による要件もサポートしています。関連するイベントは次のとおりです。Requirement)アプリケーションに管理インタフェースがある場合はこの機能が望ましく、この機能は管理者に対して公開できます。reserved.法律上の。