OpenLDAP、Samba、およびパスワードエージング

サーバー上のシェルへのアクセス、Sambaドメイン、WiFi、OpenVPN、Mantisなどへの単一のユーザーパスワードペアを介してすべてのITリソースが利用できるシステムを構成していますグループメンバーシップまたはユーザーオブジェクトフィールド）。ネットワークには個人データがあるため、EUデータ保護指令（またはポーランド語版）に従って、パスワードエージングを実装する必要があります。

問題は、LDAPのSambaおよびPOSIXアカウントが異なるパスワードハッシュおよびエージング情報を使用することです。パスワード自体の同期は簡単ですが（ldap password sync = Yesin smb.conf）、パスワードエージングをミックスに追加すると問題が解決します。SambaはshadowLastChangeを更新しません。Togetherはobey pam restrictions = Yes、Windowsユーザーが古いパスワードを変更できないシステムを作成しますが、使用しない場合、ホームディレクトリは自動的に作成されません。別の方法は、パスワードの変更にLDAP拡張操作を使用することですが、smbk5pwdモジュールもそれを設定しません。さらに悪いことに、このフィールドは非推奨と見なされるため、OpenLDAPメンテナーはパッチを更新または受け入れません。

だから、私の質問は、最善の解決策は何ですか？それらの利点と欠点は何ですか？

1. LDAP ppolicyおよび内部LDAPパスワードエージングを使用しますか？

   1. NSS、PAMモジュール、Samba、その他のシステムでどれだけうまく機能しますか？
   2. NSSおよびPAMモジュールは、シャドウではなくppolicyを使用するために特別な方法で構成する必要がありますか？
   3. GOsa²はppolicyで動作しますか？
   4. ppolicy-enabled LDAPで機能する他の管理ツールはありますか？

2. LDAPのフィールドを更新するパスワード変更スクリプトを一緒にハックします。（ユーザー自身がパスワードを変更せずにフィールドを更新する可能性を残します）

EXOPパスワードが変更されるたびshadowlastchangeにshadowLastChange属性を更新するために呼び出されるOpenLDAPオーバーレイを独自に作成しました。以下で有効化されslapd.confます。

moduleload smbk5pwd
moduleload shadowlastchange
...

database bdb
...
overlay smbk5pwd
overlay shadowlastchange

smb.confEXOPを介してパスワードを変更するように構成しました。

ldap passwd sync = Only

次に、アカウントごとにshadowMax、パスワードが有効な日数に設定します。OpenLDAPモジュールが残りを処理します！

一時的なギャップとして、shadowLastChangeパスワードの変更時に更新するSamba用のスクリプトを作成しました。

#!/bin/sh
# script to update shadowLastChange when samba updates passwords
# it's not needed when using 'passwd', it does update the field,
# even if pam_ldap is using LDAP Extented Operation to change password

LDAP_MODIFY="/usr/bin/ldapmodify"
LDAP_SEARCH="/usr/bin/ldapsearch"
LDAP_USER="uid=shadow-update,ou=Services,dc=example,dc=com"
LDAP_PASSWORD="change-me"
LDAP_HOST="localhost"

# get date
SLC=$((`date '+%s'` / 24 / 3600))

# get user login name
user=$1

# find user's DN
dn=$($LDAP_SEARCH -x -h $LDAP_HOST -LLL -b dc=example,dc=com "(uid=$user)" dn)
dn=${dn#dn:}

# check if DN is not base64 encoded
if [ "${dn:0:1}" = ":" ]; then
        # update password change date
        echo "dn:$dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
else
        # update password change date
        echo "dn: $dn
changetype: modify
replace: shadowLastChange
shadowLastChange: $SLC" | cat | $LDAP_MODIFY -x -h "$LDAP_HOST" \
 -D "$LDAP_USER" -w "$LDAP_PASSWORD" > /dev/null 2>&1
fi

err=$?

if [ ! $err -eq 0 ]; then
   echo "error: can't update shadowLastChange: $err"
   echo "`date`: shadow.sh: can't update shadowLastChange: $err"\
       >> /var/log/shadow-update.log
   exit;
fi

echo OK

サンバではそれが必要configコンunix password syncに設定しyes、passwd chatに設定*OK*してpasswd programして上記のスクリプトを"%u"PARAMとして。

で指定されたアカウントLDAP_USERをLDAPで作成しuid、すべてのSambaユーザーの読み取り権限と書き込み権限を付与する必要がありますshadowLastChange。

（進行中、詳細は後で追加します）

皆さん、良いニュースです！テスト環境で多かれ少なかれ...すべてが動作しました...：

1. パスワードポリシー（品質および時間の両方）がOpenLDAPレベルで適用されます（ppolicy、not24getおよびに感謝passwdqc）
2. パスワードは両方の方法でSambaとPOSIXの間で同期されます（おかげでsmbk5pwd）。注：Sambaとppolicyを使用した品質チェックは明らかではありません：password check script（pwqcheck -1from passwdqc）はLDAPと同じチェックを実行する必要があります。そうしないと、ユーザーは「パスワードが簡単すぎて別のものを試す」の代わりにアクセス許可が拒否されます。
3. PAMとSambaの両方は、パスワードがまもなく期限切れになることをユーザーに警告します。
4. ユーザーディレクトリは次を使用して作成されますpam_mkhomedir
5. RFC2307bis（および関連するスキーマ）のGOsa²実装はuidグループエントリに挿入されるため、NIS（「UNIXy」のほとんど）またはRFC2307bisスキーマ（「AD用に設計された」アプリケーションのほとんど）を期待するアプリケーションは問題なく動作します。

唯一の問題は、アカウントを無効にするにはCLIツールの使用（またはGOsaのpostmodifyスクリプトの作成）が必要であること、またはアカウントがPAMとSambaだけのためにLDAPレベルでロックされないことです。パスワードの有効期限は引き続き適用されるため、大きな問題ではありません。

GOsa開発者の1人から回答があります。現時点では、GOsaはppolicyオーバーレイをサポートしていません。