LDAP連携を更新するときは、ログインできるかだけでなく、どのグループ・ロールを受け取ったかも確認したいところです。FessのPR #3690・#3691はマージ済みで、ネストしたグループの検索とOUの判定を修正します。
OU名の前方一致に依存しない
これまではDNの文字列にou=roleが含まれると、グループをロールとして扱っていました。修正後はDNを解析し、いずれかのOUがRoleまたはRolesと完全一致する場合にロールと判断します。大文字小文字は区別しません。OU=Roles-RequestsやOU=RoleOwnersは対象にならず、不正なDNはグループとして扱います。
authentication.admin.rolesの初期値はadminです。たとえばadminという名前が同じでも、グループと管理ロールでは意味が異なります。従来の部分一致に依存したディレクトリー構成では、更新後に必要なロールが付かなくなるため、Role・RolesのOUへ配置するか、権限マッピングを見直します。
ldap.role.search.user.enabled・ldap.role.search.group.enabled・ldap.role.search.role.enabledの初期値はいずれもtrueです。既存の有効・無効フラグは引き続き適用され、この修正のための新しいスイッチはありません。
エスケープ付きDNとネストしたグループ
memberOfから得たDNをldap.group.filterへ埋め込むとき、LDAPフィルターの値としてエスケープするようになります。カンマを含むCNなどでは、DNとしてのエスケープと検索フィルターとしてのエスケープが別に必要だからです。既存DNを手作業で二重エスケープする手順ではありません。
更新時は通常のグループに加え、カンマなどを含む名称とネストしたグループを使い、ログイン後に期待した検索対象が見えることを確認します。従来取得できていなかった上位グループが取得される場合もあるため、付与する権限も併せて確認します。
日本語・絵文字を含む名前は別の修正案
PR #3698は、管理画面やLDAPログインがURL-safe Base64で保存したグループ・ロールIDを、ユーザー情報の読み取り側でも同じ形式として扱う提案です。標準Base64の+・/も読み取れる形に変換してからデコードします。