#39 Account Policy Plugin does not work for simple binds when PAM Pass Through Auth plugin is enabled
Closed: wontfix None Opened 10 years ago by mkosek.


User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101

If PAM passthrough plugin is used to process simple binds the account policy
plugin does not update the lastLoginTime attribute. I have not tested the other
aspects of Acoount Policy Plugin (the actions in case of account

Reproducible: Always

Steps to Reproduce:
1. Configure the account policy plugin to always update the lastLogin:

cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
cn: Account Policy Plugin
nsslapd-pluginPath: libacctpolicy-plugin
nsslapd-pluginInitfunc: acct_policy_init
nsslapd-pluginType: object
nsslapd-pluginEnabled: on
nsslapd-plugin-depends-on-type: database
nsslapd-pluginId: acct-policy
nsslapd-pluginVersion: 1.0
nsslapd-pluginVendor: Hewlett-Packard Company
nsslapd-pluginDescription: Account Policy Plugin

cn=config,cn=Account Policy Plugin,cn=plugins,cn=config
objectClass: top
objectClass: extensibleObject
cn: config
alwaysrecordlogin: true

2. Test that the plugin works with a simple or SASL/GSSAPI bind:
ldapsearch -Y GSSAPI -h ldap-server -b "dc=example,dc=com" uid=testuser

lastLoginTime: 20110610071526Z

3. Configure the PAM Passthrough plugin (I tried 2 different values for
pamIDMapMethod: RDN and ENTRY) :
pamMissingSuffix: ALLOW
pamExcludeSuffix: cn=config
pamExcludeSuffix: o=NetscapeRoot
pamIDMapMethod: ENTRY
pamIDAttr: uid
pamFallback: TRUE
pamSecure: TRUE
pamService: ldapserver
pamIncludeSuffix: dc=example,dc=com

4. Try again the SASL/GSSAPI bind. It still updates the lastLoginTime attribute
ldapsearch -Y GSSAPI -h ldap-server -b "dc=example,dc=com" uid=testuser

lastLoginTime: 20110610071827Z

5. Now try a simple bind using PAM passthrough (not the userPassword attribute
in the entry!!!) :
ldapsearch -x -H ldap://ldap-server -b "dc=example,dc=com" -D
"uid=testuser,ou=users,dc=example,dc=com" -W  uid=testuser lastLoginTime
Enter LDAP Password: <...>

Actual Results:
lastLoginTime: 20110610071827Z

The lastLoginTime is not updated.

Expected Results:
The lastLoginTime should be updated.

SASL binds and simple binds using the userPassword attribute of the entry
continue to update the lastloginTime attribute but not simple binds using the
PAM Passthrough.

Maybe it is possible to solve the problem by simply changing the plugin
precedences/priorities? Don't know whether this solution may have some other
collateral damage.

If FreeIPA uses the kerberos backend with PAM passthrough in 389DS for simple
LDAP binds, this bug also concerns FreeIPA.

By the way, the wiki is not up to date
(http://directory.fedoraproject.org/wiki/Account_Policy_Design). It uses
loginTimeStamp in all the configuration examples (but shows the correct
lastLoginTime in the schema changes)

Reproduced issue. The problem is that in PAM pre op function, we return the result to the client, and then returns 1 which causes the bind to skip the post op plugins(e.g. Account Policy). It returns 1 because it has already sent the result, and it thinks that there is no reason to process the post op plugins. To some extent this is true, or else we might send multiple conflicting results.

Continuing investigation...


Decided to just call the post op plugins even if the pre-op fails. All tests looks good. Fix sent out for review...


Thanks for the review Rich!

[mareynol@localhost slapd]$ git merge ticket39
Updating 9fd4e09..a55c91e
ldap/servers/slapd/bind.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)

[mareynol@localhost slapd]$ git push origin master
Counting objects: 11, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 825 bytes, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
9fd4e09..a55c91e master -> master

Added initial screened field value.

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.10.rc1

5 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/39

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

2 years ago

Login to comment on this ticket.