Bug 1480131 - krbLoginFailedCount doesn't get reset following subsequent failed logins via ssh after the "Failure reset interval" has elapsed
krbLoginFailedCount doesn't get reset following subsequent failed logins via ...
Status: CLOSED WORKSFORME
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ipa (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: IPA Maintainers
ipa-qe
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-08-10 05:21 EDT by Ming Davies
Modified: 2017-08-29 08:13 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-29 08:13:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ming Davies 2017-08-10 05:21:58 EDT
Description of problem:
Customer said that the krbLoginFailedCount does NOT get reset following subsequent failed logins via ssh after the "Failure reset interval" has elapsed, however the counter does get reset following a subsequent successful login.

The behavior is different when bind via ldapsearch.

The issue can be easily reproduced in house.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Configure a customized group password policy, assign it to the user who belongs to the group:
# ipa pwpolicy-show --user=ppolicy-user
  Group: ppolicy-group
  Max lifetime (days): 90
  Max failures: 4
  Failure reset interval: 300

2. **************Behavior via ssh**************
From an IPA server:
#  date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCount
Thu 10 Aug 09:03:35 BST 2017
  krbLoginFailedCount: 0

From an IPA client:
$ ssh ppolicy-user@ipaclient date
Password: <WRONG password>
Password: <WRONG password>

From the IPA server:
# date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCount
Thu 10 Aug 09:03:54 BST 2017
  krbLoginFailedCount: 2

From the IPA client:
$ sleep 400
$ date;ssh ppolicy-user@ipaclient 
Thu 10 Aug 09:13:02 BST 2017
Password: 
Password: 

From the IPA server:
# date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCount
Thu 10 Aug 09:13:18 BST 2017
  krbLoginFailedCount: 4   <<<<<<This should reset to 2 rather than increment!!


3. **************Behavior via ldapsearch**************
# date;ldapsearch -D "uid=ppolicy-user,cn=users,cn=accounts,dc=linux,dc=testrealm,dc=local" -w password1 -b "uid=ppolicy-user,cn=users,cn=accounts,dc=linux,dc=testrealm,dc=local" objectclass=*

Wed  9 Aug 15:17:31 BST 2017

ldap_bind: Invalid credentials (49)

# date;ldapsearch -D "uid=ppolicy-user,cn=users,cn=accounts,dc=linux,dc=testrealm,dc=local" -w password1 -b "uid=ppolicy-user,cn=users,cn=accounts,dc=linux,dc=testrealm,dc=local" objectclass=*

Wed  9 Aug 15:17:33 BST 2017

ldap_bind: Invalid credentials (49)

# date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCountWed  
9 Aug 15:17:43 BST 2017

  krbLoginFailedCount: 2   <<<<<<<<<<<<<<<<<<

# sleep 350

# date;ldapsearch -D "uid=ppolicy-user,cn=users,cn=accounts,dc=linux,dc=testrealm,dc=local" -w password1 -b "uid=ppolicy-user,cn=users,cn=accounts,dc=linux,dc=testrealm,dc=local" objectclass=*

Wed  9 Aug 15:30:07 BST 2017

ldap_bind: Invalid credentials (49)

[root@ipareplica slapd-LINUX-TESTREALM-LOCAL]# date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCount
Wed  9 Aug 15:30:10 BST 2017

  krbLoginFailedCount: 1   <<<<<<<<<<<<<<<Gets reset to 1


Actual results:
krbLoginFailedCount behaves differently when ssh versus bind via ldapsearch for subsequent failed logins

Expected results:
The behavior should be consistent whether it's via ssh or ldapsearch


Additional info:
Comment 2 Ming Davies 2017-08-10 09:05:43 EDT
Here are the version number:

ipa-server-4.4.0-12.el7.x86_64
389-ds-base-libs-1.3.5.10-11.el7.x86_64
389-ds-base-1.3.5.10-11.el7.x86_64
Comment 3 Alexander Bokovoy 2017-08-14 07:09:08 EDT
A simple LDAP bind operation does not concern Kerberos principal, so there are no changes in Kerberos attributes. When one logs into SSH with a password, SSSD performs Kerberos authentication which failure is then reflected via krbLoginFailedCount.

Please note that IPA does not provide a pure password policy. What is named 'password policy' is, in fact, a Kerberos password policy. As result, it only applies to Kerberos operations.
Comment 4 Petr Vobornik 2017-08-14 07:12:00 EDT
And wrt the behavior - why it is not reset:

By quick look into code, it might be caused by "Lockout duration" not being set.

        if (ied->pol->lockout_duration != 0 &&
            ied->pol->failcnt_interval != 0 &&
            client->last_failed + ied->pol->failcnt_interval < authtime) {
            /* Reset fail_auth_count, the interval's expired already */
            client->fail_auth_count = 0;
            client->mask |= KMASK_FAIL_AUTH_COUNT;
        }

From doc: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/pwd-policies-how.html#pwd-policies-global-group

"""
If multiple password policies are applicable to a user, the policy with the lowest priority value takes precedence. All rules defined in other policies are ignored.

The password policy with the lowest priority value applies to all password policy attributes, even the attributes that are not defined in the policy. 

The global password policy does not have a priority value set. It serves as a fallback policy when no group policy is set for a user. The global policy can never take precedence over a group policy. 
"""

I.e. the value won't be inherited from global policy.
Comment 7 Ming Davies 2017-08-14 09:19:43 EDT
Thanks for the update, Alexander.

You and Petr are indeed right!

Just did a quick test:
[root@ipareplica ~]# ipa pwpolicy-show --user=ppolicy-user
  Group: ppolicy-group
  Max lifetime (days): 90
  Max failures: 4
  Failure reset interval: 300
  Lockout duration: 60


From the IPA replica:
[root@ipareplica ~]# date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCount
Mon 14 Aug 13:52:06 BST 2017
  krbLoginFailedCount: 0


From the IPA client:
$ date; ssh ppolicy-user@ipaclient
Mon 14 Aug 13:52:19 BST 2017
Password: <WRONG PASSWORD>
Password: <WRONG PASSWORD>


From the IPA replica:
[root@ipareplica ~]# date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCount
Mon 14 Aug 13:52:29 BST 2017
  krbLoginFailedCount: 2


From the IPA replica:
$ date; sleep 350
Mon 14 Aug 13:52:40 BST 2017
[ming@snowflake ~]$ date; ssh ppolicy-user@ipaclient
Mon 14 Aug 14:15:00 BST 2017
Password:  <WRONG PASSWORD>


From the IPA replica:
[root@ipareplica ~]# date;ipa user-show --all ppolicy-user --raw |grep krbLoginFailedCount
Mon 14 Aug 14:15:09 BST 2017
  krbLoginFailedCount: 1   <<<< It has indeed reset to 1.


I will ask the customer to try and let you know it goes.

Best regards,
Ming

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