通常の ESF Verify 要求に新しいパスワードが含まれている場合、パスワードの変更が試行されます。「通常」の要求とは、既存のパスワードを含む通常のサインオン操作に対する要求です (パスワードなしの Verify ではありません)。
MLDAP ESM モジュールによるパスワードの変更の試行は、ユーザーが正常に認証されると開始されます。セキュリティ構成に複数のセキュリティ マネージャーが含まれている場合は、この要求に対するユーザーのパスワードの変更がどのセキュリティ マネージャーでも完了していない場合にのみパスワードの変更が試行されます。
パスワードの変更を許可するために、MLDAP ESM モジュール、セキュリティ マネージャー、または LDAP サーバーで追加の構成が必要になる場合があります。パスワードの変更は LDAP 自体の機能ではないため、LDAP を使用して常に実行できるとは限りません。パスワードの変更に失敗した場合、利用できる診断情報は限られているため、LDAP 管理者またはシステム管理者は他の情報源から情報を診断しなければならないことがあります。
MLDAP ESM モジュールでのパスワードの変更では、いずれも LDAP の「変更」操作を使用しますが、変更される具体的な属性とその内容はパスワードのタイプによって異なります。詳細については、「LDAP ベースのセキュリティでのパスワードについて」を参照してください。
「内部検証機能」を使用する MF-A2 などのパスワード タイプは、ターゲット ユーザーを表す LDAP オブジェクトの属性 microfocus-MFDS-User-Pwd (またはセキュリティ マネージャー構成で指定された別の属性) の値を変更することで変更されます。
属性の新しい値は暗号化ハッシュになり、以降のサインオンの試行で新しいパスワードの検証に使用できます。
MLDAP ESM モジュールでは、ユーザーの資格情報の認証に成功した場合、つまり、すべてのサインオン制約 (アカウント ロックアウトなど) の適用と構成されている可能性のあるパスワード制約に対する新しいパスワードのチェックが完了した後にのみ、この属性の値の変更が試行されます。
特殊なケースとして、新しいパスワードが指定された場合は、サインオン制約の「パスワードの期限切れ」(microfocus-MFDS-User-Pwd-ExpirationDate 属性で制御) および「パスワードの変更が必要」(microfocus-MFDS-User-Pwd-MustChange 属性で制御) は無視されます。新しいパスワードが存在していれば、これらの制限にユーザーが対処していると見なされます。
LDAP の変更が成功するには、セキュリティ マネージャー定義で LDAP 接続用に構成されているアカウント ([Authorized User] フィールドで指定) に属性への書き込みアクセス権が必要です。
AD や SSHA512 などの他のパスワード タイプは、LDAP サーバーまたは LDAP サーバーが関連付けられているその他の認証システムで管理されるパスワード検証機能を参照します。これらのパスワードを変更するには LDAP 変更要求を行いますが、多くの場合、その要求は特別な処理のために LDAP サーバーによって傍受されます。
AD (Microsoft Active Directory および AD LDS) パスワード タイプの場合、MLDAP ESM モジュールは、この目的のために Microsoft によって文書化された特別な LDAP 要求を使用します。これには、書き込み専用の属性 unicodePwd に対する、古い (既存の) パスワードの「値の削除」要求と新しいパスワードの「値の追加」要求の組み合わせが含まれます。これにより、ユーザーの Windows パスワードを変更するように AD に指示されます。AD LDS では、ターゲット ユーザーはユーザー クラスのオブジェクトであれば、Windows ユーザー アカウントである必要はありません。この操作は、古いパスワードが正しく、新しいパスワードがローカル コンピューターやドメインで設定された要件を満たしている場合にのみ成功します。
その他の外部パスワード タイプの場合、MLDAP ESM モジュールは、RFC 2307 で示されているメカニズムを使用します。このメカニズムでは、パスワード タイプで指定されたハッシュを使用してパスワードから形成された新しい値を使用して属性 userPassword (構成で別の属性が指定されている場合はその属性) を更新します。その際、属性の値を設定するだけのサーバーもあれば、値を変換したり、外部認証サービスなどに対して他の何らかの操作を実行したりするサーバーもあります。
userPassword に設定されている値を変換する例として、OpenLDAP サーバーでは、olcPasswordHash 構成オプションを設定して、アプリケーションが userPassword の値の変更を試行したときにその値をハッシュするように指示できます。このような環境では、Enterprise Server 管理者は、リテラル パスワード タイプを使用して新しいパスワードをそのままサーバーに送信するように MLDAP ESM モジュールを構成できます。この構成の場合、Micro Focus では、パスワードがネットワーク上に公開されないように LDAP で TLS を使用することを強くお勧めします。
通常、外部パスワードの変更は、ユーザーの認証後に実行されます。外部パスワード タイプはバインドモード検証で使用されるため、パスワードの変更が試行されると、MLDAP ESM モジュールの LDAP セッションはターゲット ユーザーの ID にバインドされます。そのセッションを使用してパスワードの変更が試行されるため、外部検証機能では、セキュリティ マネージャー用に構成されたアカウントを使用してパスワードの変更を試行するのではなく、実質的にユーザーが LDAP サーバーで自分のパスワードを変更することになります。通常、LDAP サーバーは自分のパスワードを変更する権限をユーザーに付与するように構成されているのに対し、セキュリティ マネージャーで使用されるアカウントには任意のユーザーのパスワードを変更する権限がないため、この方が成功する可能性が高くなります。
パスワードの変更はユーザーを確認した後にのみ試行されるため、バインドモード認証で問題が発生します。たとえば、パスワードの有効期限が切れているためにユーザー アカウントのパスワードを変更する必要がある場合、バインド操作は通常は拒否されます。そのため、バインドモード認証が構成されている場合、期限が切れている (変更が必要な) パスワードをユーザーが変更できなくなります。
残念ながら、RFC 2307 パスワード タイプを使用している場合については、この問題に対する直接的な解決策はありません。
Active Directory および AD LDS には、これに対する潜在的な解決策があります。前述のように、AD パスワード タイプのメカニズムで使用する要求には古いパスワードと新しいパスワードの両方が含まれ、実際には、ユーザーはパスワード変更操作の一部として認証されます。つまり、セキュリティを損なうことなく、ユーザーとしてバインドする前にパスワードの変更を試みることができます。
これを機能させるには、2 つ目のセキュリティ メカニズムを緩和する必要があります。また、AD タイプのパスワードを変更する場合、要求に使用する LDAP セッションを、更新するユーザー オブジェクトに対する特別な権限「パスワードの変更」が付与されたアカウントにバインドすることが必要になります。通常、この権限は、ユーザーが自分のパスワードを変更できるように NT_AUTHORITY\SELF にのみ付与されています。
セキュリティ マネージャー用に構成されたアカウントに、AD または AD LDS のユーザー オブジェクトに対する変更権限を付与することができます。これにより、そのアカウントでそれらのユーザーのパスワードを変更できるようになります。上記のように、既存の正しいパスワードが提供された場合しか変更は成功しないため、安全性に問題はありません。
権限を付与するには、ユーザー オブジェクトまたはユーザー オブジェクトのコンテナーのアクセス制御リスト (ACL) を更新します (コンテナーの場合は継承可能にする必要があります)。たとえば、ローカルにインストールした AD LDS と Enterprise Server に付属のサンプルの LDAP 構成で Microsoft の dsacls コマンドを使用する場合は次のようになります。
dsacls "\\localhost\CN=SYSAD,CN=Enterprise Server Users,CN=Micro Focus,CN=Program Data,DC=local" /G "CN=MFReader,CN=ADAM Users,CN=Micro Focus,CN=Program Data,DC=local:CA;Change Password"
通常、個々のユーザー オブジェクトに対して ACL を設定するよりも、継承する ACL をコンテナーで設定する方が効率的です。ACL の変更は、PowerShell を使用してスクリプト化することもできます。
これを実装すると、attempt password change 構成設定で before または both の値を使用して、ユーザーとしてバインドする前にパスワードの変更を試行できます。詳細については、「MLDAP ESM モジュールのカスタム構成情報」を参照してください。
この ACL を設定する代わりに、管理権限を持つアカウントを使用するようにセキュリティ マネージャーを構成することもできます。一部のインストール環境では、AD パスワードの変更を有効にするために、特に AD LDS でこのアプローチが伝統的に使用されてきました。AD LDS には、定義済みのロールとして、更新権限を持たない Reader ロールと AD LDS インスタンスの任意のオブジェクトの任意の属性を更新できる Administrator ロールが用意されています。便宜上、AD LDS 管理者は、Enterprise Server で使用する AD LDS アカウントを Administrator ロールで構成できます。ただし、Micro Focus では、Enterprise Server セキュリティ マネージャーで使用するアカウントには Administrator ロールを使用しないことをお勧めします。セキュリティ上の脆弱性や資格情報の侵害により、AD LDS リポジトリへの高価値のアクセスが攻撃者に与えられる可能性があるためです。
バインド前のパスワードの変更の試行を他の外部パスワード タイプで安全に構成することはできません。
ネットワーク上でパスワードまたはパスワード検証機能が公開されるのを避けるには、SSL/TLS を使用して LDAP サーバーに接続するようにセキュリティ マネージャーを構成する方が安全です。これは、LDAP-over-SSL または LDAPS とも呼ばれます。MF モード認証を使用すると、既存のパスワードがサーバーに送信されず、MF-A2 や SSHA512 などのハッシュ パスワード タイプを使用する場合も新しいパスワードのハッシュしか送信されないため、リスクが少なくなります。
一部のサーバーでは、パスワードの変更を実行するために SSL/TLS 接続が必要になる場合があります。これは、Active Directory および AD LDS では既定の設定になっています。
SSL/TLS を使用するには、サーバーとプロバイダー (クライアント ライブラリ) の両方を SSL/TLS をサポートするように構成する必要があります。詳細については、LDAP ソフトウェアのドキュメントを参照してください。さらに、セキュリティ マネージャー定義の接続文字列を ldaps:// で始まるように変更する必要があります。