たくさんのウェブやチュートリアルを検索しましたが、問題の答えを見つけることができませんでした。
パスワード ポリシー オーバーレイを使用して、OpenSUSE 12.3 マシンに OpenLDAP 2.4 をセットアップしました。クライアントは、libnss-ldap および libpam-ldap パッケージがインストールされた Linux Mint 17.1 マシンです。クライアントとサーバーは、自己署名証明書で TLS を使用するように構成されています (サーバーは CA として機能し、独自の証明書に署名します)。属性をpwdReset: TRUEユーザーに追加するまではすべて正常に動作します。
私の意図は次回ログイン時にユーザーにパスワードの変更を強制するただし、この属性を設定すると、ユーザーは認証できなくなります。ユーザーを 'su' (またはログイン) しようとすると、「認証失敗」というエラーが表示されます。また、syslog には次のメッセージが表示されます。
Mar 4 07:27:11 client-desktop nslcd[3198]: [90cde7] <authc="johndoe"> ldap_result() failed: Insufficient access: Operations are restricted to bind/unbind/abandon/StartTLS/modify password
Mar 4 07:27:11 client-desktop nslcd[3198]: [dcc233] <authc="johndoe"> cn=John Doe,ou=people,cd=domain,dc=com: lookup failed: Invalid credentials
このメッセージは、ユーザーの資格情報が無効になったことを伝えています。これは、パスワードをリセットしたにもかかわらず、ユーザーにパスワードの変更の必要性などについてプロンプトが表示されていないため、妥当です。さらに、クライアントは専門家ではないため、ldappasswd などの openldap ユーティリティの使用を防止したいと考えています。したがって、クライアントが引き続き一般的な passwd コマンドを使用して自分のパスワードを変更できるようにしたいと考えています。少なくとも、pwdReset が設定されていない場合は可能です。また、shadowLastChange属性を 0 に設定することでこの動作を実現できますが、少なくとも 8 文字のパスワードの使用を強制しようとしているため、パスワード ポリシーですべてを実行したいと考えています。ちなみに、この機能はまったく問題なく動作します。
これは、何かが欠けているかどうかを確認できるようにするためのベース DN の抜粋です。pwdResetユーザーでは TRUE に設定され、pwdMustChangeポリシー自体では変数が TRUE に設定されていることに注意してください。
# John Doe, people, domain.com
dn: cn=John Doe,ou=people,dc=domain,dc=com
cn: John Doe
sn: Doe
objectClass: top
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: johndoe
uidNumber: 1003
gidNumber: 1000
homeDirectory: /home/johndoe
loginShell: /bin/bash
userPassword: e1NTSEF9VWFSMDVsSGNIWFMxcnJ5VzBtaWRkOHFmTDE1ai9RYlQ=
pwdReset: TRUE # This attribute only appears if I explicitly request it
# policies, domain.com
dn: ou=policies,dc=domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
(以下の属性は cn=default,ou=policies に属しますが、何らかの理由でここに何かを書き込まない限り表示されません)
pwdInHistory: 3
pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 30
pwdMustChange: TRUE
pwdSafeModify: FALSE
pwdAllowUserChange: TRUE
pwdFailureCountInterval: 0
pwdGraceAuthNLimit: 0
これは私のバックエンドとパスワード ポリシーの構成です。
# {1}hdb, config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=domain,dc=com
olcAccess: {0}to attrs=userPassword by self write by * auth
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to attrs=userPKCS12 by self read by * none
olcAccess: {3}to * by * read
olcRootDN: cn=admin,dc=domain,dc=com
olcRootPW: {SSHA}############## omited
olcDbCacheSize: 10000
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 15000000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbConfig: {4}set_lk_max_locks 30000
olcDbConfig: {5}set_lk_max_objects 30000
olcDbIDLcacheSize: 30000
olcDbIndex: objectclass eq
[...more indexes...]
# {0}ppolicy, {1}hdb, config
dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: top
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=domain,dc=com
olcPPolicyHashCleartext: TRUE
(次の 2 つの属性も {0}ppolicy に属します)
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE
誰かがこの件について説明してくれることを願っています。どんな助けでも大歓迎です!
よろしく
編集：
ユーザー認証を妨げている原因を突き止めるために、デフォルト ポリシーにいくつか変更を加えました。 がpwdMustChangeTRUE に設定され、pwdResetも TRUE に設定されている場合 (ユーザー エントリの場合)、ユーザー認証はエラー 'su: 認証失敗' で失敗することがわかりました。ただし、 がpwdResetTRUE でが FALSE の場合、そのユーザーで何度でもログインできます。このために 2 つの変数を使用するのは無用で直感に反すると思います。代わりに、 またはのpwdMustChangeいずれかと呼びたい単一の変数をユーザーのエントリのみで使用する必要があります。pwdResetpwdMustChange
答え1
LDAPサーバ上のポリシーは、必ずしもOS内のポリシーと同じではありません。このオーバーレイプロパティを設定し、OSパスワード変更の必要性を認識しますが、ご覧のとおり、それは機能しません。
オペレーティング システム内でプロンプトをトリガーするには、アカウンティング モジュール (通常は PAM) が条件を認識する必要があります。OpenLDAP のパスワード ポリシー オーバーレイは POSIX 標準ではありません。shadowポリシーを設定するためにユーザーのプロパティを調整する場合とは異なり、pam_unix設定している属性は認識されません。OpenLDAP サーバー自体については同じことが言えません。ユーザーは Linux サーバーに認証できず、LDAP サーバーと直接連携してパスワードを変更するための十分な LDAP 情報がないため (ご自身も指摘されているように)、ユーザー ロックアウトが発生します。
OS 内でパスワード変更プロンプトをトリガーしたい場合、これは適切なツールではありません。個人的には、関連するshadow属性をよく理解し、集中管理する必要がある場合は LDAP に保存し、それらを使用して目的の動作をトリガーすることをお勧めします。
マンページからpam_unix(8):
アカウント コンポーネントは、次のシャドウ要素に基づいて、ユーザーのアカウントとパスワードの状態を確立するタスクを実行します: expire、last_change、max_change、min_change、warn_change。後者の場合、ユーザーにパスワードの変更に関するアドバイスを提供したり、PAM_AUTHTOKEN_REQD の戻り値を通じて、ユーザーが新しいパスワードを設定するまでサービスの提供を遅らせたりします。上記のエントリは、shadow(5) マニュアル ページに文書化されています。ユーザーのレコードにこれらのエントリが 1 つ以上含まれていない場合、対応するシャドウ チェックは実行されません。