| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Directory Server Enterprise Edition管理者ガイド 11g リリース1 (11.1.1.7.0) B72439-01 |
|
前 |
次 |
ユーザーがDirectory Serverに接続すると、ユーザーの認証が行われます。ディレクトリは、認証時に設定されたアイデンティティに応じて、ユーザーに対してアクセス権を与え、リソースを制限できます。この章においてのアカウントとは、大まかにユーザー・エントリを意味します。また、アカウントは、ユーザーがディレクトリに対して実行する操作の権限も示します。ここでのパスワード・ポリシーの説明では、すべてのアカウントがユーザー・エントリとパスワードに関連付けられています。
この章では、パスワード・ポリシーの一面であるアカウントのアクティブ化についても説明します。ディレクトリ管理者はパスワード・ポリシーとは関係なく、アカウントを直接ロックおよびロック解除できます。
この章では、認証方法については扱いません。SASL GSSAPIおよびクライアントSSL証明書ベースの認証などの認証方法には、パスワードを使用しないものもあります。この章におけるパスワード・ポリシーについての情報は、それらの認証方法には適用されません。認証メカニズムの構成手順については、第5章「Directory Serverのセキュリティ」を参照してください。
また、この章では、Directory Server 11gリリース1 (11.1.1.6)とDirectory Serverの以前のバージョンとのパスワード・ポリシーの互換性についても扱いません。Directory Server 11gリリース1 (11.1.1.6)のインスタンスを作成すると、以前のバージョンからのアップグレードを容易にするために、パスワード・ポリシー実装はデフォルトでDirectory Server 5互換性モードに設定されます。この章で説明するパスワード・ポリシーの機能を十分に活用するには、パスワード・ポリシーの互換性モードを変更する必要があります。
|
注意:
|
パスワード互換性モード設定の詳細は、「パスワード・ポリシーの互換性」を参照してください。
この章の内容は、次のとおりです。
この項ではパスワード・ポリシーの設定について説明し、要件に適合するパスワード・ポリシーの定義に役立つワークシートを提供します。
Directory Serverでパスワード・ポリシーを指定する場合、オブジェクト・クラスpwdPolicyを含むエントリを変更または作成します。
特定のタイプのユーザーのパスワード・ポリシーを定義する場合、次について検討する必要があります。
侵入者がパスワードをクラックしようとしているように見える場合にアカウントをロックアウトする方法。
詳細は、「アカウント・ロックアウトのポリシー」を参照してください。
パスワードの変更方法。
詳細は、「パスワード変更のポリシー」を参照してください。
許可されるパスワードの値。
詳細は、「パスワード内容のポリシー」を参照してください。
パスワード有効期限の処理方法。
詳細は、「パスワード有効期限のポリシー」を参照してください。
最後に認証に成功した時刻をサーバーが記録するかどうかについて。
詳細は、「最終認証時間追跡のポリシー」を参照してください。
|
注意: パスワード・ポリシーはバイト数によってパスワード長を測るので、パスワードがポリシーで指定された最小文字数未満である場合でも、マルチバイト文字を含んでいればパスワード長のポリシーを満たすことができます。たとえば、2バイト文字を1つ伴う7文字のパスワードは、最小パスワード長が8に設定されたパスワード・ポリシーを満足します。 |
この章の次の各項で、パスワード・ポリシーのこれらの点の処理方法を説明します。「パスワード・ポリシー定義用ワークシート」を使用して、実装を計画する各パスワード・ポリシーを明確にしてください。
この項では、アカウントのロックアウトを制御するポリシーの属性について説明します。
Directory Serverのアカウントとは大まかにユーザーのエントリ、およびディレクトリに対して操作を実行するために必要となるユーザーの権限を指します。各アカウントはバインドDNおよびユーザー・パスワードに関連付けられています。侵入者がパスワードをクラックしようとしているように見える場合、Directory Serverでアカウントをロックする必要があります。このロックにより、侵入者はそのアカウントを使用してバインドできなくなります。また、ロックにより、侵入者が攻撃を続けることができなくなります。
管理者は1つのアカウント、またはロールを共有するすべてのユーザーのアカウントを手動で非アクティブにすることもできます。手順は、「アカウントの手動ロック」を参照してください。しかし、パスワードポリシーを指定する際に重要なことは、Directory Serverが管理者の介入なしにアカウントをロックするのはどのような条件かを指定することです。
最初に、バインドの失敗が著しく発生する場合は、Directory ServerでpwdLockoutを使用して、自動的にアカウントがロックされるように指定する必要があります。Directory Serverでは、連続して失敗したアカウントへのバインド試行を追跡します。pwdMaxFailureを使用して、何回連続して失敗したらDirectory Serverがアカウントをロックするかを指定します。
Directory Serverでは、パスワード・ポリシーに従ってアカウントが厳密にロックされます。その操作は単純に機械的なものとなります。アカウントは、侵入者がアカウントに対して攻撃を仕掛けようとしているためでなく、ユーザーが誤ったパスワードを入力したことによりロックされることもあります。したがって、pwdFailureCountIntervalを使用して、失敗した試行の間隔がどれだけ空いたらDirectory Serverがそれまでの失敗した試行の記録を消去するかを指定できます。pwdLockoutDurationを使用して、Directory Serverがアカウントのロックを自動的に解除するまで、ロックアウトを継続する期間を指定します。悪意なく単なるミスをしたユーザーのアカウント・ロックを解除するために管理者が介入する必要はありません。
レプリケーション・トポロジ全体にユーザー・データをレプリケートする場合、ロックアウト属性が他のエントリ・データとともにレプリケートされます。pwdIsLockoutPrioritized属性のデフォルト設定はTRUEなので、ロックアウト属性の更新は高い優先順位でレプリケートされます。したがって、ユーザーが、ロックアウトされるまでにレプリカの1つへのバインド試行を連続して失敗できるのは、pwdMaxFailureで設定された回数までで、ロックアウトされるまでの他のレプリカでの試行回数はさらに少なくなります。ユーザーが、レプリケートされたトポロジ全体でロックアウトされるまでpwdMaxFailureで設定された回数を試行できるようにする方法の詳細は、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』のグローバル・アカウント・ロックアウトを使用した認証の防止に関する項を参照してください。
この項では、パスワードの変更を制御するポリシーの属性について説明します。
多くのデプロイメントにおいて、Directory Serverはアイデンティティ・データのリポジトリとなります。pwdAllowUserChangeで指定されたとおり、ユーザーは自身のパスワードを変更できるので、管理者がパスワードを変更する必要はありません。
また、ユーザーが自分のパスワード変更を許可した後で、ユーザーが自分のパスワードを変更できる状況を抑制することもできます。pwdSafeModifyを使用して、パスワードを変更する前に、ユーザーが既存のパスワードを正しく入力する必要があることを指定できます。パスワード変更方法の例は、「pwdSafeModifyがTRUEである場合のコマンドラインからのパスワード変更」を参照してください。pwdInHistoryを使用し、Directory Serverが記憶するパスワード数を指定して、ユーザーのパスワード再利用を防止できます。さらに、pwdMinAgeを設定することで、頻繁なパスワード変更も防止できます。
多くの場合、管理者または管理するアプリケーションのいずれかが、ディレクトリにユーザー・エントリを作成します。ユーザーが初めて新しいアカウントにバインドしたときに変更するユーザーパスワード値を割り当てることができます。また、ユーザー・パスワードのリセットが必要な場合もあります。その後の次回アカウント使用時に、ユーザーはパスワードを変更する必要があります。Directory Serverには特定の属性であるpwdMustChangeがあり、これを使用することで、他のユーザーによってパスワード値がリセットされた後で、ユーザーがパスワードを変更する必要があるかどうかを示すことができます。
passwordRootdnMayBypassModsChecksを設定して、ディレクトリ管理者がパスワードを変更する際にのポリシーが適用されないように指定することもできます。
この項では、パスワード内容を制御するポリシーの属性について説明します。
通常、ディレクトリ検索でパスワード値が返されることはありませんが、攻撃者がディレクトリ・データベースへのアクセス権を得る可能性があります。したがって、パスワード値は通常、passwordStorageSchemeで指定した、サポートされるハッシュ形式で格納されます。
さらに、pwdCheckQualityを設定して、パスワードが最低限の品質定義を満たしているかをチェックすることもできます。そのとき、サーバーではパスワードがcn、givenName、mail、ou、snまたはuidのどの属性とも一致しないことをチェックします。これらのいずれかの属性とのパスワード比較では、大文字/小文字が区別されません。
pwdCheckQualityを設定して、追加のチェックも使用できます。pwdMinLengthを設定して、パスワードを指定した文字数以上にすることを強制できます。さらに、強力なパスワード・チェック・プラグインが有効な場合、Directory Serverでは、パスワードにプラグインで使用するディクショナリ・ファイルの文字列が含まれていないことをチェックします。サーバーでは、パスワードに各種タイプの文字が適切に混在して含まれていることもチェックします。
強力なパスワード・チェックは、dsconf set-server-propコマンドにより有効にできます。pwd-strong-check-enabledプロパティを使用してプラグインをオンにしてから、サーバーを再起動させることで変更を有効にします。パスワードに含める必要のある文字セットを指定するには、pwd-strong-check-require-charsetプロパティを使用します。pwd-strong-check-require-charsetプロパティは、次の値のマスクを使用します。
lower新しいパスワードに小文字を含める必要があります。
upper新しいパスワードに大文字を含める必要があります。
digit新しいパスワードに数字を含める必要があります。
special新しいパスワードに特殊文字を含める必要があります。
any-two新しいパスワードには前述の2つ以上の文字セットから、それぞれ1文字以上含める必要があります。
any-three新しいパスワードには前述の3つ以上の文字セットから、それぞれ1文字以上含める必要があります。
pwd-strong-check-require-charsetプロパティのデフォルト設定はlower && upper && digit && specialとなります。
この項では、パスワード期限を制御するポリシーの属性について説明します。
ユーザーがパスワードを定期的に変更するように、pwdMaxAgeを設定して、Directory Serverで、パスワードが特定の経過時間に達すると、有効期限が切れるように構成できます。
ユーザーにはパスワードの有効期限が近づいていることを通知する必要があります。バインドに使用するパスワードの有効期限が切れそうであるという警告を返すように、Directory Serverを構成できます。pwdExpireWarningを使用して、有効期限のどれくらい前からクライアントがバインドしたときに警告を返すかを定義します。クライアント・アプリケーションが警告を受け取ることに注意してください。ユーザーが直接警告を受けるわけではありません。クライアントアプリケーションは、パスワードの有効期限が切れそうであるという警告を受け取ったら、エンドユーザーに通知する必要があります。
ユーザーが有効期限切れのパスワードで1回以上バインドを試みることを許可するには、pwdGraceAuthNLimitを設定します。したがって、パスワードの変更に間に合わなかったユーザーでも、パスワードを変更するためのバインドが可能です。猶予期間ログインによりバインドした場合でも、ユーザーはあらゆる操作が実行できることに留意してください。猶予期間ログインはパスワードを失効していない場合と同様に機能します。
Directory Serverは、エントリ上のパスワードが変更されるたびに、操作属性pwdChangedTimeを更新します。この結果、パスワードの有効期限を有効とすると、古くなったパスワードは即座に無効となります。この動作を意図しない場合は、警告および猶予期間ログインを使用します。
この項では、パスワード・ポリシーの属性pwdKeepLastAuthTimeの使用について説明します。
pwdKeepLastAuthTimeが設定されている場合、Directory Serverではユーザーが認証を行うたびに、最後にバインドに成功した時間が追跡されます。時間はユーザー・エントリのpwdLastAuthTime操作属性に記録されます。
この動作により、成功したバインド操作それぞれに対して更新が追加されるので、pwdKeepLastAuthTime機能はデフォルトでは有効になりません。デプロイメントでこの機能を使用するには、明示的にこれを有効にする必要があります。
このワークシートは、コマンドライン・インタフェースまたはDirectory Service Control Center(DSCC)を使用して実装するパスワード・ポリシーの定義に役立つようデザインされたものです。パスワード・ポリシーごとに1つのワークシートを使用します。
パスワード・ポリシー・エントリのDNを記録したら、各ポリシー領域の属性の設定についての決定を記録します。それらの設定の理由も記録します。
| パスワード・ポリシー・ワークシート |
|---|
| パスワード・ポリシー・エントリ識別名 |
|
|
| ポリシー領域 | 属性 | ここに設定を記入してください | ここに設定の理由を記入してください |
|---|---|---|---|
|
アカウントのロックアウト |
pwdFailureCountInterval |
||
|
pwdIsLockoutPrioritized |
|
|
|
|
pwdLockout |
|
|
|
|
pwdLockoutDuration |
|
|
|
|
pwdMaxFailure |
|
|
|
|
パスワード変更 |
passwordRootdnMayBypassModsChecks |
|
|
|
pwdAllowUserChange |
|
|
|
|
pwdInHistory |
|
|
|
|
pwdMinAge |
|
|
|
|
pwdMustChange |
|
|
|
|
pwdSafeModify |
|
|
|
|
パスワード内容 |
passwordStorageScheme |
|
|
|
pwdCheckQuality |
|
|
|
|
pwdMinLength |
|||
|
パスワードの有効期限 |
pwdExpireWarning |
|
|
|
pwdGraceAuthNLimit |
|
|
|
|
pwdMaxAge |
|
|
|
|
最終認証時間の追跡 |
pwdKeepLastAuthTime |
|
|
|
注意:
|
デフォルトのパスワード・ポリシーは、専用のポリシーが定義されていない、ディレクトリ・インスタンスのすべてのユーザーに適用されます。ただし、デフォルト・パスワード・ポリシーはディレクトリ・マネージャには適用されません。ポリシーの範囲の詳細は、「どのパスワード・ポリシーを適用するか」を参照してください。
デフォルト・パスワード・ポリシーはdsconfコマンドを使用して構成できるポリシーのひとつです。cn=Password Policy,cn=configを読み込むことで、デフォルト・パスワード・ポリシーを表示することもできます。
この項では、各ポリシー領域のポリシー属性および関連するdsconfサーバー・プロパティを示します。さらに、デフォルト・パスワード・ポリシーの設定を表示および変更する方法についても説明します。
dsconfサーバー・プロパティとの相関関係次の表に、各パスワード・ポリシー領域のパスワード・ポリシー属性および関連するdsconfサーバー・プロパティを示します。
| ポリシー領域 | ポリシー属性 | dsconfサーバー・プロパティ |
|---|---|---|
|
アカウントのロックアウト |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
パスワード変更 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
パスワード内容 |
|
|
|
|
|
|
|
|
|
|
|
パスワードの有効期限 |
|
|
|
|
|
|
|
|
|
|
|
最終認証時間の追跡 |
|
|
|
注意:
|
dsconfコマンドにより、デフォルト・パスワード・ポリシーの設定を表示できます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
デフォルトのパスワード・ポリシーの構成を読み取ります。
$ dsconf get-server-prop -h host -p port -v -i \ -w password-file | grep ^pwd-
password-fileには、ディレクトリ・マネージャのパスワードが含まれます。
pwd-accept-hashed-pwd-enabled : N/A
pwd-check-enabled : off
pwd-compat-mode : DS5-compatible-mode
pwd-expire-no-warning-enabled : on
pwd-expire-warning-delay : 1d
pwd-failure-count-interval : 10m
pwd-grace-login-limit : disabled
pwd-keep-last-auth-time-enabled : off
pwd-lockout-duration : 1h
pwd-lockout-enabled : off
pwd-lockout-repl-priority-enabled : on
pwd-max-age : disabled
pwd-max-failure-count : 3
pwd-max-history-count : disabled
pwd-min-age : disabled
pwd-min-length : 6
pwd-mod-gen-length : 6
pwd-must-change-enabled : off
pwd-root-dn-bypass-enabled : off
pwd-safe-modify-enabled : off
pwd-storage-scheme : SSHA
pwd-strong-check-dictionary-path : instance-path/plugins/words-english-big.txt
pwd-strong-check-enabled : off
pwd-strong-check-require-charset : lower
pwd-strong-check-require-charset : upper
pwd-strong-check-require-charset : digit
pwd-strong-check-require-charset : special
pwd-supported-storage-scheme : CRYPT
pwd-supported-storage-scheme : SHA256
pwd-supported-storage-scheme : SHA512
pwd-supported-storage-scheme : SHA
pwd-supported-storage-scheme : SSHA
pwd-supported-storage-scheme : SSHA256
pwd-supported-storage-scheme : SSHA512
pwd-supported-storage-scheme : CLEAR
pwd-user-change-enabled : on
dsconfコマンドにより、サーバー・プロパティを設定することで、デフォルト・パスワード・ポリシーを変更できます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
ワークシートの設定をdsconfコマンド・プロパティの設定に変換します。
dsconf set-server-propコマンドを使用して、デフォルト・パスワード・ポリシーのプロパティを適切に変更します。
たとえば、次のコマンドにより、ディレクトリ・マネージャがパスワードを変更するときに、デフォルトのポリシーに違反してもよいことになります。
$ dsconf set-server-prop -h host -p port pwd-root-dn-bypass-enabled:on
次のコマンドにより、リセット後のパスワード変更が必要となるポリシーを有効にします。
# dsconf set-server-prop -p 20390 pwd-must-change-enabled:on
Directory Serverは、NULLのパスワードによる認証を防止します。したがって、匿名でないすべてのバインドはパスワードを指定して、ディレクトリにバインドする必要があります。これを行わない場合、Directory Serverでは認証エラーLDAP_INAPPROPRIATE_AUTHが返されます。
この機能を無効にするには、dsconf set-server-propコマンドを使用して、サーバー・プロパティrequire-bind-pwd-enabledをoffに設定します。
認証でのバインド要求機能のデフォルト値はonです。次のコマンドを使用して、これをチェックします。
# dsconf get-server-prop -p 20390 -w /tmp/.pwd-file require-bind-pwd-enabled
require-bind-pwd-enabled : on
NULLパスワードで認証を行うと、次のエラー・メッセージが表示されます
# ldapsearch -D cn=altrootdn -w '' -p 20390 -b cn=config 'objectclass=*' dn
ldap_simple_bind: Inappropriate authentication
ldap_simple_bind: additional info: binds with a dn require a password
この機能では、匿名バインドはブロックされないことに注意してください。
# ldapsearch -p 20390 -b cn=config 'objectclass=*' dn
version: 1
dn: cn=SNMP,cn=config
次のように設定をoffにして、この機能を無効にします。
# dsconf set-server-prop -p 20390 -w /tmp/.pwd-file require-bind-pwd-enabled:off # dsconf get-server-prop -p 20390 -w /tmp/.pwd-file require-bind-pwd-enabled require-bind-pwd-enabled : off
今度のNULLパスワードによる認証は成功します。
# ldapsearch -D cn=altrootdn -w '' -p 20390 -b cn=config 'objectclass=*' dn
version: 1
dn: cn=SNMP,cn=config
特殊パスワード・ポリシーは、pwdPolicyエントリ内で定義します。ポリシーはディレクトリ・ツリーの任意の場所で定義できますが、通常はそのポリシーで制御するアカウントでレプリケートされたサブツリーで行います。ポリシーは、cn=policy name,subtreeという形式のDNを持ちます。
パスワード・ポリシーを定義したら、目的のユーザー・エントリにpwdPolicySubentry属性を設定して、パスワード・ポリシーを割り当てます。
この項の項目は次のとおりです。
Directory Serverでは、複数のパスワード・ポリシーを構成できます。この項では、デフォルト・パスワード・ポリシーおよび特殊パスワード・ポリシーについて説明します。さらに、この項では、特定のアカウントに複数のパスワードポリシーを適用できる場合に、どのポリシーを強制するかについても説明します。
最初にDirectory Serverのインスタンスを作成すると、そのインスタンスはデフォルト・パスワード・ポリシーを持ちます。このデフォルト・パスワード・ポリシーは、構成エントリcn=PasswordPolicy,cn=configに表されます。デフォルトのパスワード・ポリシーはディレクトリ・マネージャを除くディレクトリ内のすべてのアカウントに適用されます。
すべてのDirectory Serverのパスワード・ポリシーと同様に、cn=PasswordPolicy,cn=configはオブジェクト・クラスpwdPolicyおよびオブジェクト・クラスsunPwdPolicyを持ちます。
|
注意: Directory Serverのインスタンスを作成すると、パスワード・ポリシーの属性はDirectory Server 5互換モードのままとなり、以前のバージョンからのアップグレードが容易になります。Directory Server 5互換モードでは、Directory Serverはオブジェクト・クラスpasswordPolicyを持つパスワード・ポリシー・エントリも処理します。 アップグレードが完了すると、全機能モードで新しいパスワード・ポリシーを使用します(これについては、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』で説明しています)。管理の移行は、ディレクトリ・アプリケーションに対して透過的に行われます。 この章では、新しいパスワード・ポリシー機能を使用したパスワード・ポリシーの構成について扱います。 |
デフォルト・パスワード・ポリシーを変更することで、デフォルト設定をオーバーライドできます。dsconfコマンドを使用して、デフォルト・パスワード・ポリシーのサーバー・プロパティを設定できます。このようなサーバー・プロパティ名は通常、pwd-の接頭辞で始まります。このようなプロパティの設定を変更する場合、インスタンスのデフォルト・パスワード・ポリシーをオーバーライドします。ただし、レプリケーションでは、レプリカに対する変更はコピーされません。デフォルト・パスワード・ポリシーに対する変更はインスタンスの構成の一部であり、ディレクトリ・データの一部ではありません。
デフォルト・パスワード・ポリシーの構成の他に、特殊パスワード・ポリシーも構成できます。特殊パスワード・ポリシーはディレクトリ・ツリーのエントリにより定義されます。特殊パスワード・ポリシーのエントリはデフォルト・パスワード・ポリシーと同じオブジェクト・クラスpwdPolicyを持つため、同じポリシー属性を取ります。特殊パスワード・ポリシーは正規のディレクトリ・エントリなので、ポリシー・エントリは通常のディレクトリ・エントリと同じ方法でレプリケートされます。
ユーザー・エントリは、操作属性pwdPolicySubentryの値によって特殊パスワード・ポリシーを参照します。ユーザー・エントリにより参照されると、特殊パスワード・ポリシーはインスタンスのデフォルト・パスワード・ポリシーをオーバーライドします。多くのデプロイメントでは、ユーザー・ロールを割り当てます。pwdPolicySubentryの値を設定することにより、サービス・クラス(CoS)と連携してユーザー・アカウントに適用するパスワード・ポリシーを決定するよう、ロールを構成できます。ロールによって設定されたパスワード・ポリシーをオーバーライドするには、そのユーザーのエントリ・ディレクトリのpwdPolicySubentry値を変更します。
この項を要約すると、最初にデフォルト・パスワード・ポリシーを適用します。デフォルト・パスワード・ポリシーを変更することで、デフォルトをオーバーライドできます。次に特殊パスワード・ポリシー・エントリを作成することで、デフォルト・パスワード・ポリシーをオーバーライドできます。パスワード・ポリシーにロールおよびCoSを割り当てる場合、個別エントリのパスワード・ポリシーを指定することで、CoSが割り当てられたポリシーをオーバーライドできます。
特殊パスワード・ポリシーの作成および変更は、他のディレクトリ・エントリの作成および変更と同様の方法で行います。次の手順では、テキスト・エディタを使用して、LDIFでパスワード・ポリシー・エントリを記述する方法について説明します。さらには、-aオプション付きのldapmodifyコマンドを使用して、パスワード・ポリシー・エントリをディレクトリに追加します。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
開始する前に
特に記述がないかぎり、ここで示す例のデータはExample.ldifからのものとなります。
作成するポリシーについて、パスワード・ポリシー・ワークシートへの記入を済ませます。
サンプルは、「パスワード・ポリシー定義用ワークシート」を参照してください。
ワークシートに基づき、LDIFでパスワード・ポリシー・エントリを記述します。
たとえば、次のポリシー・エントリは、Example.comでの臨時従業員用のパスワード・ポリシーを指定します。この従業員のサブツリーのルートはdc=example,dc=comです。
dn: cn=TempPolicy,dc=example,dc=com objectClass: top objectClass: pwdPolicy objectClass: sunPwdPolicy objectClass: LDAPsubentry cn: TempPolicy pwdAttribute: userPassword pwdCheckQuality: 2 pwdLockout: TRUE pwdLockoutDuration: 300 pwdMaxFailure: 3 pwdMustChange: TRUE
デフォルト・パスワード・ポリシーの設定の他にも、ここで示すポリシーは追加動作を指定しています。パスワードの品質チェックが実行されます。3回連続してバインドが失敗すると、5分(300秒)間アカウントがロックされます。パスワードは、リセットの後に変更する必要があります。ポリシーがユーザー・アカウントに割り当てられると、ここで明示的に指定された設定で、デフォルト・パスワード・ポリシーがオーバーライドされます。
パスワード・ポリシー・エントリをディレクトリに追加します。
たとえば、次のコマンドにより、dc=example,dc=comの下にExample.comの臨時従業員用パスワード・ポリシーが追加されます。パスワード・ポリシーはpwp.ldifというファイルに保存されています。
$ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f pwp.ldif Enter bind password: adding new entry cn=TempPolicy,dc=example,dc=com $ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w --b dc=example,dc=com \ "(&(objectclass=ldapsubentry)(cn=temppolicy))" Enter bind password: version: 1 dn: cn=TempPolicy,dc=example,dc=com objectClass: top objectClass: pwdPolicy objectClass: LDAPsubentry cn: TempPolicy pwdCheckQuality: 2 pwdLockout: TRUE pwdLockoutDuration: 300 pwdMaxFailure: 3 pwdMustChange: TRUE $
Example.ldifに示すように、kvaughanは人事マネージャであり、dc=example,dc=comエントリを変更するためのアクセス権を持っています。Example.ldifに示すように、Vaughanのバインド・パスワードは、briberyです。
関連項目:
定義したポリシーにより、どのユーザー・アカウントを管理するかを定義するには、「パスワード・ポリシーを個別アカウントに割り当てるには:」または「ロールおよびCoSを使用して、パスワード・ポリシーを割り当てるには:」を参照してください。
次の手順では、既存のパスワード・ポリシーを1つのユーザー・アカウントに割り当てます。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
特に記述がないかぎり、ここで示す例のデータはExample.ldifからのものとなります。
パスワード・ポリシーDNをユーザー・エントリのpwdPolicySubentry属性の値に追加します。
たとえば、次のコマンドでは、「パスワード・ポリシーを作成するには:」で定義したパスワード・ポリシーをDavid Millerのエントリに割り当てます。David MillerのDNはuid=dmiller,ou=people,dc=example,dc=comです。
$ cat pwp.ldif dn: uid=dmiller,ou=people,dc=example,dc=com changetype: modify add: pwdPolicySubentry pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com $ ldapmodify -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f pwp.ldif Enter bind password: modifying entry uid=dmiller,ou=people,dc=example,dc=com $ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w - -b dc=example,dc=com \ "(uid=dmiller)" pwdPolicySubentry Enter bind password: version: 1 dn: uid=dmiller, ou=People, dc=example,dc=com pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com $
Example.ldifに示すように、kvaughanは人事マネージャであり、dc=example,dc=comエントリを変更するためのアクセス権を持っています。Example.ldifに示すように、Vaughanのバインド・パスワードは、briberyです。
次の手順では、ロールおよびサービス・クラス(CoS)を適用して、既存の特殊パスワード・ポリシーをユーザー・セットに割り当てます。ロールおよびCoSの詳細は、第9章「Directory Serverのグループ、ロールおよびCoS」を参照してください。
WebインタフェースのDirectory Service Control Center (DSCC)を使用して、このタスクを実行できます。
特に記述がないかぎり、ここで示す例のデータはExample.ldifからのものとなります。
パスワード・ポリシーにより管理されるエントリのロールを作成します。
たとえば、次のコマンドにより、Example.comの臨時従業員用のフィルタ処理されたロールが作成されます。
$ cat tmp.ldif dn: cn=TempFilter,ou=people,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: nsRoleDefinition objectclass: nsComplexRoleDefinition objectclass: nsFilteredRoleDefinition cn: TempFilter nsRoleFilter: (&(objectclass=person)(status=contractor)) description: filtered role for temporary employees $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f tmp.ldif Enter bind password: modifying entry cn=TempFilter,ou=people,dc=example,dc=com $
Example.ldifに示すように、kvaughanは人事マネージャであり、dc=example,dc=comエントリを変更するためのアクセス権を持っています。Example.ldifに示すように、Vaughanのバインド・パスワードは、briberyです。
パスワード・ポリシー・エントリのDNを生成するサービス・クラスを作成します。
このDNは、作成したロールを持つユーザーのpwdPolicySubentry属性の値となります。
たとえば、次のコマンドにより、Example.comの臨時従業員用のフィルタ処理されたロールが作成されます。このコマンドにより、cn=TempPolicy,dc=example,dc=comがロールを持つユーザーに割り当てられます。
$ cat cos.ldif dn: cn=PolTempl,dc=example,dc=com objectclass: top objectclass: nsContainer dn: cn="cn=TempFilter,ou=people,dc=example,dc=com", cn=PolTempl,dc=example,dc=com objectclass: top objectclass: extensibleObject objectclass: LDAPsubentry objectclass: costemplate cosPriority: 1 pwdPolicySubentry: cn=TempPolicy,dc=example,dc=com dn: cn=PolCoS,dc=example,dc=com objectclass: top objectclass: LDAPsubentry objectclass: cosSuperDefinition objectclass: cosClassicDefinition cosTemplateDN: cn=PolTempl,dc=example,dc=com cosSpecifier: nsRole cosAttribute: pwdPolicySubentry operational $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f cos.ldif Enter bind password: modifying entry cn=TempFilter,ou=people,dc=example,dc=com $
これで、ステータスがcontractorであるユーザーが、パスワード・ポリシーcn=TempPolicy,dc=example,dc=comの対象となります。
多くのデプロイメントにおいて、新しいアカウントに適用するパスワード・ポリシーは既成アカウントに適用するパスワード・ポリシーとは異なります。この項では、初回ログインのパスワード・ポリシーについて説明します。このポリシーでは、新しく作成したアカウントに対して、ユーザーに3日の使用期間が与えられ、このアカウントがロックされるまでに新しいパスワードを設定するようにします。このポリシーはパスワードがリセットされたユーザーに対しても、同様に機能するよう設計されています。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
新しく作成されたアカウントための特殊パスワード・ポリシーを作成します。
たとえば、有効期間を3日間(259,200秒)に設定するパスワード・ポリシー・エントリを追加します。
|
注意: グローバル・パスワード・ポリシーでは、pwdMustChangeを
$ dsconf set-server-prop -p port-no pwd-must-change-enabled:true
|
$ cat firstLogin.ldif dn: cn=First Login,dc=example,dc=com objectClass: top objectClass: LDAPsubentry objectClass: pwdPolicy objectClass: sunPwdPolicy cn: First Login passwordStorageScheme: SSHA pwdAttribute: userPassword pwdInHistory: 0 pwdExpireWarning: 86400 pwdLockout: TRUE pwdMinLength: 6 pwdMaxFailure: 3 pwdMaxAge: 259200 pwdFailureCountInterval: 600 pwdAllowUserChange: TRUE pwdLockoutDuration: 3600 pwdMinAge: 0 pwdCheckQuality: 2 pwdMustChange: TRUE $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f firstLogin.ldif Enter bind password: adding new entry cn=First Login,dc=example,dc=com
新しく作成されたすべてのアカウントを含むロールを作成します。
このロールの作成では、新しく作成されたアカウントを既存のアカウントと区別するなんらかの方法を設定します。
新しいアカウントを、pwdReset属性がTRUEに設定されたアカウントとして定義します。
ユーザーのパスワードがパスワード管理者などの他のユーザーによって変更されると、pwdResetはTRUEに設定されます。
新しいアカウントを識別するロールを作成します。
たとえば、次のコマンドにより、パスワードがリセットされたアカウントのロールが作成されます。
$ cat newRole.ldif
dn: cn=First Login Role,ou=people,dc=example,dc=com
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: First Login Role
nsRoleFilter: (pwdReset=TRUE)
description: Role to assign password policy for new and reset accounts
$ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f newRole.ldif
Enter bind password:
adding new entry cn=First Login Role,ou=people,dc=example,dc=com
新しく作成されたアカウントのパスワード・ポリシーにサービス・クラスを割り当てます。
$ cat newCoS.ldif dn: cn=First Login Template,dc=example,dc=com objectClass: top objectClass: nsContainer dn: cn="cn=First Login Role,ou=people,dc=example,dc=com", cn=First Login Template,dc=example,dc=com objectClass: top objectClass: extensibleObject objectClass: LDAPSubEntry objectClass: CoSTemplate cosPriority: 1 pwdPolicySubentry: cn=First Login,dc=example,dc=com dn: cn=First Login CoS,dc=example,dc=com objectClass: top objectClass: LDAPSubEntry objectClass: CoSSuperDefinition objectClass: CoSClassicDefinition cosTemplateDN: cn=First Login Template,dc=example,dc=com cosSpecifier: nsRole cosAttribute: pwdPolicySubentry operational $ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -f newCoS.ldif Enter bind password: adding new entry cn=First Login Template,dc=example,dc=com adding new entry cn="cn=First Login Role,ou=people,dc=example,dc=com", cn=First Login Template,dc=example,dc=com adding new entry cn=First Login CoS,dc=example,dc=com
例8-1 パスワード・ポリシー割当てのチェック
追加したロールに適合する新しいユーザーを追加します。そのユーザーの追加により、新しいユーザーが新しいパスワード・ポリシーの対象となり、既存ユーザーは対象とならないことを確認します。
$ cat quentin.ldif
dn: uid=qcubbins,ou=People,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
uid: qcubbins
givenName: Quentin
sn: Cubbins
cn: Quentin Cubbins
mail: quentin.cubbins@example.com
userPassword: ch4ngeM3!
description: New account
$ ldapmodify -a -D uid=kvaughan,ou=people,dc=example,dc=com -w - -f quentin.ldif
Enter bind password:
adding new entry uid=qcubbins,ou=People,dc=example,dc=com
$ ldapsearch -D uid=kvaughan,ou=people,dc=example,dc=com -w - \
-b dc=example,dc=com uid=qcubbins nsrole pwdPolicySubentry
Enter bind password:
version: 1
dn: uid=qcubbins,ou=People,dc=example,dc=com
nsrole: cn=first login role,ou=people,dc=example,dc=com
pwdPolicySubentry: cn=First Login,dc=example,dc=com
$ ldapsearch -b dc=example,dc=com uid=bjensen nsrole pwdPolicySubentry
version: 1
dn: uid=bjensen, ou=People, dc=example,dc=com
Barbara Jensenの既存アカウントはデフォルト・パスワード・ポリシーにより制御されます。一方で、Quentin Cubbinsの新しいアカウントは定義したパスワード・ポリシーにより制御されます。
次のコマンドを入力して、適用されたパスワード・ポリシーの設定をチェックします。
# ldapsearch -D "cn=directory manager" -w - -b "cn=Password Policy,cn=config" -s base \ '(&(objectClass=ldapsubentry)(cn=Password Policy))' version: 1 dn: cn=Password Policy,cn=config objectClass: top objectClass: ldapsubentry objectClass: pwdPolicy objectClass: sunPwdPolicy objectClass: passwordPolicy cn: Password Policy pwdAttribute: userPassword passwordStorageScheme: SSHA passwordChange: on pwdAllowUserChange: TRUE pwdSafeModify: FALSE passwordRootdnMayBypassModsChecks: off passwordNonRootMayResetUserpwd: on passwordInHistory: 0 pwdInHistory: 0 passwordMinAge: 0 pwdMinAge: 0 passwordCheckSyntax: off pwdCheckQuality: 0 passwordMinLength: 6 pwdMinLength: 6 passwordMustChange: on pwdMustChange: TRUE passwordExp: off passwordMaxAge: 0 pwdMaxAge: 0 passwordWarning: 86400 pwdExpireWarning: 86400 passwordExpireWithoutWarning: on pwdGraceAuthNLimit: 0 pwdKeepLastAuthTime: FALSE passwordLockout: off pwdLockout: FALSE passwordMaxFailure: 3 pwdMaxFailure: 3 passwordResetFailureCount: 600 pwdFailureCountInterval: 600 pwdIsLockoutPrioritized: TRUE passwordUnlock: on passwordLockoutDuration: 3600 pwdLockoutDuration: 3600
pwdSafeModifyがTRUEである場合のコマンドラインからのパスワード変更ユーザーのパスワード・ポリシーで、pwdSafeModifyがTRUEに設定されている場合、古いパスワードに対して新しいパスワードを指定して、パスワードを変更する必要があります。コマンドdsconf set-server-prop pwd-safe-modify-enabled:onはデフォルト・パスワード・ポリシーと同じ効果があります。
ldappasswdコマンドを使用してパスワードを変更できます。このコマンドは、安全なパスワード変更をサポートしています。このコマンドは、RFC 3062、「LDAP Password Modify Extended Operation」(http://www.ietf.org/rfc/rfc3062.txt)を実装しています。
次のコマンドにより、Barbara Jensenに自身のユーザー・パスワードを変更させて、簡単な認証での接続を行います。
$ ./ldappasswd -h host -D uid=bjensen,ou=people,dc=example,dc=com \ -j old.pwd -T new.pwd -t old.pwd uid=bjensen,ou=people,dc=example,dc=com ldappasswd: password successfully changed
LDAPパスワード変更の拡張操作も使用できます。この拡張操作に対するサポートの設定は、「パスワード変更の拡張操作により、パスワードをリセットするには:」で説明します。
パスワード・ポリシーによりパスワードの有効期限が適用されている場合に、期限内にパスワードを変更しないユーザーもいます。この項では、有効期限の切れたパスワードの変更方法を示します。
|
注意: Directory Serverは、エントリ上のパスワードが変更されるたびに、操作属性pwdChangedTimeを更新します。この結果、パスワードの有効期限を有効とすると、古くなったパスワードは即座に無効となります。この動作を意図しない場合は、警告および猶予期間ログインを使用します。 |
この項では、パスワード変更拡張操作によってパスワードをリセットする手順と、パスワードの期限が切れた場合に、猶予認証を許可する手順を説明します。
この項で説明するメカニズムは、管理者か、または実際のユーザーとディレクトリとのやり取りを処理するアプリケーションで使用することを意図しています。一般的には、エンドユーザーに、意図したとおりにメカニズムを実際に使用させるのは、アプリケーションの役割です。
パスワードの有効期限が切れると、ユーザー・アカウントはロックされます。パスワードをリセットすると、アカウントのロックが解除されます。パスワードは管理者などの他のユーザーによってリセットできます。パスワードをリセットすると、Directory Serverによりユーザー・アカウントのロックが解除されます。Directory Serverは、RFC 3062「LDAP Password Modify Extended Operation」(http://www.ietf.org/rfc/rfc3062.txt)をサポートしています。拡張操作により、ディレクトリ管理者またはディレクトリ・アプリケーションがパスワードのリセットによりアカウントのロックを解除することを許可できます。
次の手順でも示すとおり、パスワード変更の拡張操作の使用を許可する際には注意してください。アクセスは信頼のある管理者とアプリケーションのみに制限してください。ネットワーク上でパスワードをクリアテキストで送受信しないでください。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
パスワード管理者または管理アプリケーションにユーザー・アクセス権を与えます。
パスワード管理者に、パスワード変更の拡張操作を使用するためのアクセスを許可します。
次のコマンドは、Password ManagersロールのメンバーがSSLで接続した場合にパスワード変更拡張操作を使用できるようにするACIを設定します。
$ cat exop.ldif dn: oid=1.3.6.1.4.1.4203.1.11.1,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 1.3.6.1.4.1.4203.1.11.1 cn: Password Modify Extended Operation aci: (targetattr != "aci") (version 3.0; acl "Password Modify Extended Operation"; allow( read, search, compare, proxy ) (roledn = "ldap:///cn=Password Managers,dc=example,dc=com" and authmethod = "SSL");) $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f exop.ldif Enter bind password: adding new entry oid=1.3.6.1.4.1.4203.1.11.1,cn=features,cn=config $
cn=features,cn=configの下のエントリにより、パスワード変更の拡張操作を使用する操作に対するアクセス管理が可能になります。
パスワード管理者にユーザー・パスワードをリセットしてもらいます。
この手順によってユーザー・アカウントのロックが解除され、これはldappasswdコマンドで実行できます。
ユーザーがパスワードを変更する必要があるときは、パスワード管理者からユーザーへ通知してもらいます。
ユーザー・エントリを管理するパスワード・ポリシーがpwdMustChange: TRUEを含む場合、ユーザーはリセット後に自身のパスワードを変更する必要があります。
この項では、ユーザーに猶予認証を与えて、期限切れになったパスワードを変更できるようにする方法を説明します。
猶予認証は、パスワードポリシーのリクエストおよびレスポンス制御を処理するアプリケーションによって管理することを意図しています。この手順では、アプリケーションにおける制御の使用方法について、簡単な例を示します。
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
ユーザーがパスワード・ポリシーのリクエストおよびリクエスト制御を使用するアプリケーションに対するアクセス権を持つことを確認します。
アプリケーションでは、ユーザーが猶予認証を適切に処理していることを確認する必要があります。
アプリケーションでパスワード・ポリシー制御を使用できるようにします。
次のコマンドは、Password Managersロールのメンバーがパスワード・ポリシー制御を使用できるようにするACIを設定します。
$ cat ctrl.ldif dn: oid=1.3.6.1.4.1.42.2.27.8.5.1,cn=features,cn=config objectClass: top objectClass: directoryServerFeature oid: 1.3.6.1.4.1.42.2.27.8.5.1 cn: Password Policy Controls aci: (targetattr != "aci") (version 3.0; acl "Password Policy Controls"; allow( read, search, compare, proxy ) roledn = "ldap:///cn=Password Managers,dc=example,dc=com";) $ ldapmodify -a -D cn=admin,cn=Administrators,cn=config -w - -f ctrl.ldif Enter bind password: adding new entry oid=1.3.6.1.4.1.42.2.27.8.5.1,cn=features,cn=config $
cn=features,cn=configの下のエントリの目的は、パスワード・ポリシーのリクエストおよびレスポンス制御を使用する操作へのアクセスを管理できるようにすることのみです。
パスワード・ポリシーのpwdGraceAuthNLimitにより、パスワードの有効期限が切れた後に猶予認証によるログインを何回許可するかを設定します。
アプリケーション側では、ユーザーに対して猶予認証の許可されている回数内で期限の切れているパスワードをすみやかに変更するように指示する必要があります。
|
注意:
|
次の各項では、アカウントの検索制限、サイズ制限、時間制限およびアイドル・タイムアウトの設定方法を説明します。
ldapmodifyコマンドを使用して、nsLookThroughLimitの値を設定します。
次のコマンドでは、Barbara Jensenの検索制限が解除されます。
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsLookThroughLimit nsLookThroughLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $
ldapmodifyコマンドを使用して、nsSizeLimitの値を設定します。
次のコマンドでは、Barbara Jensenのサイズ制限が解除されます。
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsSizeLimit nsSizeLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $
ldapmodifyコマンドを使用して、nsTimeLimitの値を設定します。
次のコマンドでは、Barbara Jensenの時間制限が解除されます。
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsTimeLimit nsTimeLimit: -1 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D $
ldapmodifyコマンドを使用して、nsIdleTimeoutの値を設定します。
次のコマンドでは、Barbara Jensenのアイドル・タイムアウトが5分(300秒)に設定されます。
$ ldapmodify -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bjensen,ou=people,dc=example,dc=com changetype: modify add: nsIdleTimeout nsIdleTimeout: 300 ^D modifying entry uid=bjensen,ou=people,dc=example,dc=com ^D
Directory Serverでは、指定した回数のバインド試行が失敗した後に、アカウントを強制的にロックアウトするパスワード・ポリシーを設定できます。詳細は、「アカウント・ロックアウトのポリシー」を参照してください。この項では、ディレクトリ・マネージャが使用できる手動のアカウント・ロックおよびアクティブ化ツールについて説明します。
ディレクトリ・マネージャはロックアウト期間タイマーを使用せずに、アカウントのロックアウトを管理できます。ロックされたアカウントは、アカウントが明示的にアクティブ化されるまで、ロックされたままとなります。ディレクトリ・マネージャは無期限で特定のアカウントを非アクティブにすることもできます。
この項では、アカウント・ステータスを確認し、アカウントを非アクティブにして、再びアクティブにする方法について説明します。
次に示すように、アカウントのステータスをチェックします。
|
注意: ディレクトリ・マネージャとしてバインドする必要があります。 |
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
dsutil account-statusコマンドを使用して、アカウントまたはロールのステータスをチェックします。
次のコマンドでは、Barbara Jensenのアカウント・ステータスがチェックされます。
$ dsutil account-status -p port-number -w pwd.txt \
uid=bjensen,ou=people,dc=example,dc=com
uid=bjensen,ou=people,dc=example,dc=com activated.
詳細は、dsutilのマニュアル・ページを参照してください。
次に示すように、アカウントまたはロールを非アクティブにします。
|
注意: ディレクトリ・マネージャとしてバインドする必要があります。 |
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
dsutil account-inactivateコマンドを使用して、アカウントまたはロールを非アクティブにします。
次のコマンドでは、Barbara Jensenのアカウントが非アクティブとなります。
$ dsutil account-inactivate -p port-number -w pwd.txt \
uid=bjensen,ou=people,dc=example,dc=com
uid=bjensen,ou=people,dc=example,dc=com inactivated.
$
詳細は、dsutilのマニュアル・ページを参照してください。
次に示すように、アカウントまたはロールのロックを解除します。
|
注意: ディレクトリ・マネージャとしてバインドする必要があります。 |
このタスクの実行には、DSCCを使用できません。次の手順の説明に従って、コマンドラインを使用してください。
dsutil account-activateコマンドを使用して、アカウントまたはロールを再度アクティブにします。
次のコマンドでは、Barbara Jensenのアカウントが再度アクティブとなります。
$ dsutil account-activate -p port-number -w pwd.txt \
uid=bjensen,ou=people,dc=example,dc=com
uid=bjensen,ou=people,dc=example,dc=com activated.
詳細は、dsutilのマニュアル・ページを参照してください。
Directory Server 5.2では、パスワード・ポリシー属性セットが使用されます。Directory Server 6.0では、新しくパスワード・ポリシー属性セットが導入されました。Directory Serverでは、両方のパスワード・ポリシー属性セットを管理し、互換性を維持することができます。pwp-compat-modeの値に基づき、サーバーは、他のサーバーを正確に複製できます。
移行用に、新しいパスワード・ポリシーでは、互換性モードを実装することにより、以前のDirectory Serverのバージョンとの互換性を維持しています。互換性モードでは、パスワード・ポリシーの属性を古い属性として処理するか、新しい属性として処理するかが決定されます。ここで古いとは、Directory Server 5.2のパスワード・ポリシー属性を意味します。
この項では、互換性モードの設定、およびデプロイメントに適したモードの決定に役立つ情報を提供します。
次のように、dsconfコマンドを使用して互換性モードを読み込むことができます。
$ dsconf get-server-prop pwd-compat-mode
pwd-compat-modeプロパティは次のいずれかの値を持ちます。
DS5-compatible-modeDS5-compatible-modeの目的は、レプリケートされた既存のトポロジをDirectory Server 5.2のインスタンスからDirectory Server 11gリリース1 (11.1.1.7.0)のインスタンスに移行できるようにすることです。DS5-compatible-modeのDirectory Server 11gリリース1 (11.1.1.7.0)のインスタンスは、新しい、または古いパスワード・ポリシーの属性を含む更新を受け入れ、両方の属性セットを含む更新を生成します。更新はLDAPクライアントまたはレプリケーションより受け取ることができ、パスワード・ポリシーの評価結果として(認証失敗、パスワード変更などの結果として)、変更がローカルに生成されます。バージョン11gリリース1 (11.1.1.7.0)のインスタンスによって(直接または他のインスタンスを介して)生成されたレプリケート済更新を使用するバージョン5.2のインスタンスは、00ds6pwp.ldifで更新されるスキーマを持つ必要があります(これについては、『Oracle Fusion Middleware Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』のパスワード・ポリシーの問題に関する項で説明しています)。Directory Server 5.2のインスタンスでは、新しい属性を含むエントリがそのスキーマでスキーマを更新せずに更新された場合には、パスワード・ポリシーの処理の際に新しい属性を無視しますが、更新されたエントリが書き込まれた場合には、スキーマ・チェックは失敗します。
DS6-migration-modeDS6-migration-modeはDS5-compatible-modeとDS6-modeの中間ステップです。ポリシーの決定はすべて新しいパスワード・ポリシーの属性に基づき、古い(Directory Server 5.2)パスワード・ポリシーの属性はサーバー・データから削除されます。ポリシー構成エントリの数は少ないので、古いパスワード・ポリシー構成の属性は、インスタンスがDS6-migration-modeに進むとすぐに、すべてのポリシー・エントリから一掃されます。ただし、ユーザー・エントリのクリーンアップについては、エントリがパスワード変更処理において通常のパスワード・ポリシー処理の一部として変更されるまで見送られます。この方法により、クリーンアップを段階的に進めることができるので、サーバーのパフォーマンスが低下することはありません。古いポリシー属性の削除が必要な変更は、DS5-compatible-modeのままのインスタンスの操作との干渉を避けるため、レプリケートされません。
DS6-modeDS6-modeのDirectory Serverインスタンスでは、パスワード・ポリシー決定の計算に新しいポリシー属性のみを使用します。エントリに残る古いパスワード・ポリシー属性はいずれも無視されます。
互換性モードの設定には、次のようにdsconfコマンドを使用します。
$ dsconf pwd-compat new-mode
new-modeアクションは次のいずれかの値を取ります。
to-DS6-migration-modeDS5-compatible-modeからDS6-migration-modeに変更します。
変更後は、DS6-migration-modeおよびDS6-modeしか使用できません。
to-DS6-modeDS6-migration-modeからDS6-modeに変更します。
変更後は、DS6-modeしか使用できません。
サーバーの状態は、新しいパスワード・ポリシー仕様に、より厳密に準拠する方向にのみ移行します。
この項では、Directory Serverのデプロイメントに適した互換性モードについて詳しく説明します。
pwd-compat-modeに関する重要な情報pwd-compat-modeの設定は内部のサーバー処理に影響を及ぼし、LDAPクライアントで見られるパスワード・ポリシーの動作とは大幅に異なります。特に、pwd-compat-modeの設定がLDAPクライアント認証(バインド)に対するサーバー・レスポンスの範囲に影響することはありません。
パスワード・ポリシーの実装で使用する構成および操作属性は、pwd-compat-modeの設定によって異なります。したがって、最初のDS5-compatible-modeからpwd-compat-modeに進める前に、古い(Directory Server 5.2)属性にアクセスするLDAPアプリケーションを変更する必要があります。
DS5-compatibility-modeパスワード・ポリシーは非推奨となります。今回のバージョンでは、DS6-modeパスワード・ポリシーに切り替える必要があります。
DS5-compatible-modeがデフォルト設定です。既存のサーバーをDirectory Server 11gリリース1 (11.1.1.7)に更新するか、新しいDirectory Server 11gリリース1 (11.1.1.7)のインスタンスを作成する場合、互換性の状態はDS5-compatible-modeに設定します。
スタンドアロンのDirectory Serverインスタンスをインストールする場合、または新しくレプリケートされたトポロジをデプロイする場合、互換性モードをDS6-modeに設定して、新しいパスワード・ポリシー実装で使用できる機能をただちに利用します。新しいDirectory Server 11gリリース1 (11.1.1.7)のインスタンスは互換性モードがDS5-compatible-modeで作成されるので、インスタンスがすでにDS6-modeに設定されたレプリケート済トポロジにインストールする前に、必ずこのインスタンスをDS6-modeに更新するようにしてください。
既存のレプリケート済トポロジを移行する場合で、最低1つのDirectory Server 5.2インスタンスがレプリケーション・トポロジに残っている場合、Directory Server 11gリリース1 (11.1.1.7)インスタンスはすべてDS5-compatible-modeに設定する必要があります。
レプリケートされたトポロジが完全に(DS5-compatible-modeに)移行すれば、古いパスワード・ポリシーとの互換性の維持から新しいパスワード・ポリシーのみの使用へ移行することを検討できます。DS5-compatible-modeからDS6-modeへの移行は2段階で行い、これにはDS6-migration-modeの中間ステージが含まれます。
また、古いパスワード・ポリシー属性に依存するアプリケーションも、古い属性がDS6-migration-modeでは使用できなくなるため、Directory Server 11gリリース1 (11.1.1.7)インスタンスがDS5-compatible-modeである間に、新しい属性に移行する必要があります。この時点で、レプリケートされたトポロジを構成するインスタンスはDS6-migration-modeに移行できます。
第2段階では、中間のDS6-migration-modeでレプリケートされたトポロジのすべてのインスタンスを実行し、エントリ内の古い操作属性を消去します。次のいずれかの方法を使用します。
このクリーンアップはDS6-migration-modeからDS6-modeに移行する前に行う必要があります。これを行わない場合、古い属性がエントリに残ることになります。古いパスワード・ポリシーの操作属性のクリーンアップのオーバーヘッドを軽減するために、Directory Server 11gリリース1 (11.1.1.7)インスタンスではパスワード変更と併せてその属性のみを削除します。したがって、パスワード有効期限の機能が有効であると仮定した場合、クリーンアップを簡単に行うには、パスワードの有効期限の全サイクルの間、Directory Server 11gリリース1 (11.1.1.7)インスタンスをDS6-migration-modeのままにしておけばよいことになります。最後に、古いパスワード・ポリシー属性がエントリからクリーンアップされたら、インスタンスをDS6-modeに移行できます。新しいDirectory Server 11gリリース1 (11.1.1.7)インスタンスが作成され、DS5-compatible-modeに設定されることに留意してください。インスタンスがすでにDS6-modeに設定されたレプリケート済トポロジにインストールする前に、インスタンスをDS6-modeに更新することを忘れないでください。
次の表は、Directory Serverのバージョンとパスワード・ポリシーの互換性モードの可能な組合せを示しています。レプリケートされたトポロジでは許可される組合せは常に最大2つとなります。たとえば、トポロジにDirectory Server 11g リリース1 (11.1.1.7)のDS5-compatible-modeのインスタンスとDS6-migration-modeのインスタンスが含まれる場合、従来型Directory Serverインスタンスなし、またはDS6-modeのDirectory Server 11g リリース1 (11.1.1.7)インスタンスの2つのみが認められます。
表8-1 Directory Serverのパスワード・ポリシー・モード相互運用性
| Directory Server 5.2 | DS5-compatible-modeのDirectory Server 11gリリース1 (11.1.1.x) |
DS6-migration-modeのDirectory Server 11gリリース1 (11.1.1.x) |
DS6-modeのDirectory Server 11gリリース1 (11.1.1.x) |
|
|---|---|---|---|---|
|
Directory Server 5.2 |
X |
X |
||
|
|
X |
X |
X |
|
|
|
X |
X |
X |
|
|
|
X |
X |
サーバーがDS6-migration-modeの場合、パスワード・ポリシー属性を手動でクリーンアップする代わりに、convert-pwp-opattr-to-DS6フラグでrewriteコマンドを実行できます(第8.8.2.3.1項「DS5-Modeのパスワード・ポリシーの操作属性を手動で削除」に記載あり)。ただし、サーバーがDS5-compatible-modeまたはDS6-modeの場合、リクエストは却下されます。
convert-pwp-opattr-to-DS6フラグがonに設定されている場合、そのInternet Draft (ID)と同等のものをベースに、DS5-modeのすべてのパスワード・ポリシー属性が許可され、DS6-modeで実行されます。
convert-pwp-opattr-to-DS6フラグを設定するには、すでにトポロジでDS6-migration-modeとなっている各サーバー上で次のコマンドを実行します。
$ dsconf rewrite -f convert-pwp-opattr-to-DS6=on
または、次のコマンドをオフラインで実行できます。
$ dsadm rewrite -f convert-pwp-opattr-to-DS6=on /my/instance/path o=mysuffix.com
サーバーの移行が正常に完了した後で、切替えの準備ができ次第いつでも、安全にDS6-modeに切替えできます。
リセット時の必須変更(pwd-must- change-enabled)およびパスワード品質チェックの管理上のバイパス(pwd-root-dn-bypass-enabled)などのパスワード・ポリシー機能は、userPassword属性の変更を、本人による変更と管理リセットのどちらに分類するかにより異なります。
Directory Server 5.2では、デフォルトで、ディレクトリ・マネージャのみがユーザー・パスワードの管理リセットを実行できます。その他のパスワード変更はいずれも本人による変更と見なされます。Directory Server 5.2p4では、パスワード・ポリシー構成属性passwordNonRootMayResetUserpwdが導入されました。これが有効であるときは、次の2つの場合に対して本人による変更と見なされるuserPassword変更操作を制限するものです。
ユーザーが認証され、自身のアカウントのパスワードを変更している。
管理者がパスワードを変更しているが、LDAPプロキシ認証制御(http://www.ietf.org/rfc/rfc4370.txt)がuserPassword変更操作に対して設定され、プロキシ・ユーザーDNが変更操作のターゲットになっている。
その他のパスワード変更は管理リセットと見なされます。この機能により、ルーチンのパスワード管理にディレクトリ・マネージャを使用する必要がなくなる一方、本人以外による簡易テスト(本人とは別のユーザーによるパスワード変更)では、管理ユーザーを識別するための個別スキームの複雑さを回避します。
今回のバージョンのDirectory Serverのパスワード変更の評価は、passwordNonRootMayResetUserPasswordを有効にしたDirectory Server 5.2と類似しています。つまり、Directory Serverでは、ユーザー自身によるパスワード変更の場合またはプロキシ認証制御が使用された場合を除いて、パスワード変更を管理リセットとみなします。インスタンスがDirectory Server 5.2互換モードのときに、passwordNonRootMayResetUserpwd属性がDirectory Serverパスワード・ポリシーの構成エントリに存在できる場合でも、この属性は変更できず、この機能は常に有効となります。
LDAPアプリケーションに基づくDirectory Server 5.2でディレクトリ・マネージャとは別の管理アカウントを使用して、ユーザーのかわりにパスワードを変更する(つまり、変更は本人による変更となる)と、アプリケーションがDirectory Server 7.0で使用される場合、変更は管理リセットと見なされます。オリジナルの動作をリストアするには、userPassword変更操作でLDAPプロキシ認証制御(http://www.ietf.org/rfc/rfc4370.txt)を使用します。プロキシ認証制御はプロキシ・ユーザーによる起動されたかのように操作を処理します。この制御は、LDAP C SDK (https://wiki.mozilla.org/LDAP_C_SDK)およびLDAP SDK for Java (http://www.mozilla.org/directory/javasdk.html)と、ldapmodifyコマンドで使用できます。プロキシ認証制御は、次のようにldapmodifyコマンドを使用して起動します。
$ ldapmodify -D <administrative-user-DN> -Y <proxied-user-DN>
|
注意: 他の製品からの |
