Bug 712294 - Account Policy Plugin does not work for simple binds when PAM Pass Through Auth plugin is enabled
Summary: Account Policy Plugin does not work for simple binds when PAM Pass Through Au...
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: 389
Classification: Retired
Component: Server - Plugins
Version: 1.2.8
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 690319
TreeView+ depends on / blocked
 
Reported: 2011-06-10 07:25 UTC by Andrey Ivanov
Modified: 2015-01-04 23:49 UTC (History)
1 user (show)

Fixed In Version: 389-ds-base-1.2.10.rc1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-07 16:10:55 UTC


Attachments (Terms of Use)

Description Andrey Ivanov 2011-06-10 07:25:24 UTC
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

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 inactivity/expiration). 

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

...
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

...
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)

Comment 1 Rich Megginson 2011-06-20 21:10:16 UTC
Is there a PAM plugin that does account activity management?

Comment 2 Andrey Ivanov 2011-06-21 07:32:49 UTC
In our configuration the 389 PAM passthrough plugin uses a very basic pam configuration (the file /etc/pam.d/ldapserver): 

----
auth    sufficient      /lib64/security/pam_krb5.so no_user_check
account required        /lib64/security/pam_krb5.so no_user_check
----

It checks the kerberos password, that's all it does (no user check or account activity management).

Comment 3 Rich Megginson 2011-06-21 14:16:30 UTC
(In reply to comment #2)
> In our configuration the 389 PAM passthrough plugin uses a very basic pam
> configuration (the file /etc/pam.d/ldapserver): 
> 
> ----
> auth    sufficient      /lib64/security/pam_krb5.so no_user_check
> account required        /lib64/security/pam_krb5.so no_user_check
> ----
> 
> It checks the kerberos password, that's all it does (no user check or account
> activity management).

Does kerberos keep track of last login?

Comment 4 Andrey Ivanov 2011-06-21 14:47:30 UTC
Yes. Starting at least from the version 1.8 (maybe even earlier) MIT Kerberos server keeps track of failed and successful logins. It can be obtained from the KDC server with kadmin(.local) utility.

Comment 7 Martin Kosek 2012-01-04 13:22:42 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/39

Comment 8 Rich Megginson 2012-02-07 16:10:55 UTC
Fixed in 389-ds-base-1.2.10.rc1 now in Fedora/EPEL Testing


Note You need to log in before you can comment on or make changes to this bug.