Martin Kosek wrote:
On 03/18/2013 04:07 PM, Rob Crittenden wrote:
Martin Kosek wrote:
On 03/15/2013 04:42 PM, Rob Crittenden wrote:
Rob Crittenden wrote:
Martin Kosek wrote:
On 03/11/2013 10:07 PM, Rob Crittenden wrote:
Fixed a number of issues applying password policy against LDAP binds.
See patch
for details.

rob


I see some issues with this fix:

1) Shouldn't group password policy serve only as an override to the main
policy? I.e. if I have this policy:

# ipa pwpolicy-show test
     Group: test
     Priority: 10
     Max failures: 2

We should still follow settings other than "Max failures" configured in
global policy, right? At least the Kerberos seem to do it. I think we
should be consistent in this case. Now, other values just seem to be
zero.

There should be only one policy. It isn't supposed to merge policies
together (there is only one krbPwdPolicyReference per principal).

That's a good point.


How is the KDC acting differently?

For example, if you set only maximal number of bad password guesses, it does
not allow any more (user fbar1 is a member of test group):

# ipa pwpolicy-mod test --maxfail 3
    Group: test
    Priority: 10
    Max failures: 3

# kinit fbar1
Password for fb...@idm.lab.bos.redhat.com:
kinit: Password incorrect while getting initial credentials
# kinit fbar1
Password for fb...@idm.lab.bos.redhat.com:
kinit: Password incorrect while getting initial credentials
# kinit fbar1
Password for fb...@idm.lab.bos.redhat.com:
kinit: Password incorrect while getting initial credentials
# kinit fbar1
kinit: Clients credentials have been revoked while getting initial credentials

But LDAP binds are still allowed

# ldapsearch -h localhost -D
uid=fbar1,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo
-s base -b ""
ldap_bind: Invalid credentials (49)

I think this is just caused by different processing of
krbpwdfailurecountinterval in ipa-kdb and in bind preop (when it is not set,
max auth tries checks are pretty much disabled).

We can't examine things until a successful bind is done. If it is done and we
determine that they should be locked out we refuse to continue.

I am not sure I follow - what do you mean by "examine things"? The bind preop
plugin can check current policy with unsuccessful login, right? I just thought
that when the custom policy has krbpwdmaxfailure set, but does not have
krbpwdfailurecountinterval set, we should still enforce the krbpwdmaxfailure
"somehow", as ipa-kdb does.

If not, I think we should either mark those params in pwpolicy plugin as
required or at least add a note to ipa help mentioning this limitation for LDAP
binds....

Ok, I think I explained things wrongly before. This is already registered as a pre_bind plugin. I'll see if I can figure out what its doing. This should already be happening as you described. It could be that the bad auth return value is overriding the unwilling to perform. I'd think the bind wouldn't be attempted at all if we return an error in a pre-bind plugin.



I think we will need to fix both the pre-op and the post-op to make this
working really consistently.

2) The lockout post-op still counts failed logins even though we are in
lockout time, is this expected? It is another point if inconsistency
with Kerberos auth. It leaves user's krbloginfailedcount stay on "Max
failures".

Ok.


3) Sometimes, I get into a state when I lockout a new user with Kerberos
and then wait some time until the lockout time passes (no admin unlock),
I am able to run as many LDAP binds as I want.

Can you clarify? Successful or unsuccessful binds?

Unsuccessful binds. I will try to reproduce it again when you fix the crash, it
is hard to investigate it with this crash around.


This is all I found so far. Honza is also reviewing it, so I will let
him post hist findings too.

Martin

Here is an updated patch to not increment past the max failures on LDAP binds.

The new patch now causes 389-ds to crash with SIGSEGV if I try to bind as a
user with no group policy assigned (Stacktrace attached).

Stupid mistake on my part.

rob


Fixed now :) I found one more issue. When you add a new user with a password,
wrong LDAP binds do not increase failure count until the latest failure
timestamp is set, for example via failed Kerberos login:

# ipa user-status fbar2
-----------------------
Account disabled: False
-----------------------
   Server: vm-037.idm.lab.bos.redhat.com
   Failed logins: 0
   Last successful authentication: N/A
   Last failed authentication: N/A
   Time now: 2013-03-19T09:01:35Z
----------------------------
Number of entries returned 1
----------------------------

# ldapsearch -h localhost -D
uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo
-s base -b ""
ldap_bind: Invalid credentials (49)

# ipa user-status fbar2
-----------------------
Account disabled: False
-----------------------
   Server: vm-037.idm.lab.bos.redhat.com
   Failed logins: 0
   Last successful authentication: N/A
   Last failed authentication: N/A
   Time now: 2013-03-19T09:01:54Z
----------------------------
Number of entries returned 1
----------------------------

# kinit fbar2
Password for fb...@idm.lab.bos.redhat.com:
kinit: Password incorrect while getting initial credentials

# ipa user-status fbar2
-----------------------
Account disabled: False
-----------------------
   Server: vm-037.idm.lab.bos.redhat.com
   Failed logins: 1
   Last successful authentication: N/A
   Last failed authentication: 2013-03-19T09:02:14Z
   Time now: 2013-03-19T09:02:16Z
----------------------------
Number of entries returned 1
----------------------------

# ldapsearch -h localhost -D
uid=fbar2,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com -x -w foo
-s base -b ""
ldap_bind: Invalid credentials (49)

# ipa user-status fbar2
-----------------------
Account disabled: False
-----------------------
   Server: vm-037.idm.lab.bos.redhat.com
   Failed logins: 2     <<<<<< It increased now
   Last successful authentication: N/A
   Last failed authentication: 2013-03-19T09:02:20Z
   Time now: 2013-03-19T09:02:24Z
----------------------------
Number of entries returned 1
----------------------------

Yikes.


As for the issue you could not reproduce, it is also quite difficult to
reproduce it for me, I usually have to combine same failed/successful logins,
waits for lockouts etc. I need to look at that more closely. Just for the
record, attaching an LDIF of a user in such a state when I can do as many
failing ldapsearches as I want. This is the password policy:

# ipa pwpolicy-show
   Group: global_policy
   Max lifetime (days): 90
   Min lifetime (hours): 1
   History size: 0
   Character classes: 0
   Min length: 8
   Max failures: 6
   Failure reset interval: 60
   Lockout duration: 30

Martin


We specifically don't want to use REPLACE. It is supposed to loop up to 5 times trying to clean things up. I'll see if I can figure out why the loop is failing. It may be due to other changes I made here.

rob

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to