Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-21 Thread Rob Crittenden 

Martin Kosek wrote:


Good job! I noticed just one last case when there is inconsistency with
Kerberos auth.

If you have Lockout duration set to 0, Failure reset interval does not work
in postop. Also, following errors in 389-ds-base error log are printed:

[21/Mar/2013:07:54:01 -0400] - slapi_modify_internal_set_pb: NULL parameter
[21/Mar/2013:07:54:01 -0400] - allow_operation: component identity is NULL

I also saw that we sometimes set krbLoginFailedCount to 0 even though it was
already zero. I think this could create unnecessary replication events or at
least unnecessary mod call.

Attaching a patch for both. If you found the patch OK, you can squash it and
push the whole beast.

Martin



This data isn't replicated anyway, but not doing an empty mod makes sense.

Thanks for the suggestions. I squashed this and pushed to master.

rob

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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-20 Thread Martin Kosek 
On 03/19/2013 05:09 PM, Rob Crittenden wrote:
 Martin Kosek wrote:
 On 03/19/2013 10:57 AM, 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




 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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-20 Thread Rob Crittenden 

Martin Kosek wrote:

On 03/19/2013 05:09 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 03/19/2013 10:57 AM, 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








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:

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-20 Thread Martin Kosek 

On 03/20/2013 04:52 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 03/19/2013 05:09 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 03/19/2013 10:57 AM, 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








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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-20 Thread Rob Crittenden 

Martin Kosek wrote:

On 03/20/2013 04:52 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 03/19/2013 05:09 PM, Rob Crittenden wrote:

Martin Kosek wrote:

On 03/19/2013 10:57 AM, 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








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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-19 Thread Martin Kosek 
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

 


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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-19 Thread Martin Kosek 
On 03/19/2013 10:57 AM, 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
 



 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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-19 Thread Rob Crittenden 

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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-19 Thread Rob Crittenden 

Martin Kosek wrote:

On 03/19/2013 10:57 AM, 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








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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-18 Thread Martin Kosek 
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).


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

Martin

 
 I couldn't reproduce your 3rd point.
 
 rob
 

Thread 1 (Thread 0x7fdde4ff9700 (LWP 7617)):
#0  __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31
No locals.
#1  0x7fddfe4b15bc in slapi_mods_add_string (smods=0x7fddc8001c70, 
modtype=modtype@entry=1, type=type@entry=0x7fddf4b9cf21 krbLastFailedAuth, 
val=0x0) at ldap/servers/slapd/modutil.c:370
No locals.
#2  0x7fddf4b9c833 in ipalockout_postop (pb=0x1cad1b0) at ipa_lockout.c:544
dn = 0x7fddc8000dd0 
uid=fbar1b,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
policy_dn = 0x7fddc8005390 
cn=test,cn=IDM.LAB.BOS.REDHAT.COM,cn=kerberos,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
target_entry = 0x7fddc8008620
policy_entry = 0x7fddc80026e0
sdn = 0x7fddc80018c0
pbtm = 0x0
smods = 0x0
objectclass = 0x0
errstr = 0x0
ldrc = optimized out
rc = 49
ret = 0
failedcount = 1
failedcountstr = 
1\000�\001\000\000\000\000\200$\224\001\000\000\000\000�\233�\001\000\000\000\000�Cz\001\000\000\000
failed_bind = 1
max_fail = 3
utctime = {tm_sec = 0, tm_min = 0, tm_hour = -453022896, tm_mday = 
32733, tm_mon = -453022936, tm_year = 32733, tm_wday = 0, tm_yday = 0, tm_isdst 
= 26485888, tm_gmtoff = 140591433548788, tm_zone = 0x17a4488 }
time_now = 1363608767
timestr = 34633-453022935
failcnt_interval = optimized out
lastfail = 0x0
tries = 0
failure = 1
actual_type_name = 0x7fddc8007c20 krbPwdPolicyReference
attr_free_flags = 2
values = 0x7fddc8008560
__func__ = ipalockout_postop
#3  0x7fddfe4bd8e1 in plugin_call_func (list=0x17a4b20, 
operation=operation@entry=501, pb=pb@entry=0x1cad1b0, 
call_one=call_one@entry=0) at ldap/servers/slapd/plugin.c:1453
n = optimized out
func = 0x7fddf4b9c280 ipalockout_postop
rc = optimized out
return_value = 0
count = 1
#4  0x7fddfe4bdb07 in

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-18 Thread Rob Crittenden 

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

From 251c242bafb6c3fb6031851ea9b4cff802d2de4c Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Fri, 15 Feb 2013 11:51:59 -0500
Subject: [PATCH] Fix lockout of LDAP bind.

There were several problems:

- A cut-n-paste error where the wrong value was being considered when
  an account was administratively unlocked.
- An off-by-one error where LDAP got one extra bind attempt.
- krbPwdPolicyReference wasn't being retrieved as a virtual attribute so
  only the global_policy was used.
- The lockout duration wasn't examined in the context of too many failed
  logins so wasn't being applied properly.
- The failedcount is no longer updated past max failures.

https://fedorahosted.org/freeipa/ticket/3433
---
 .../ipa-slapi-plugins/ipa-lockout/ipa_lockout.c| 152 +
 1 file changed, 96 insertions(+), 56 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
index fea997d79825e05a6ffe4bf65e22821948794ff3..c7c4cf0d0a537eac1975aaae196a2787e293b211 100644
--- a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
+++ b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
@@ -226,6 +226,50 @@ done:
 return ret;
 }
 
+int ipalockout_getpolicy(Slapi_Entry *target_entry, Slapi_Entry **policy_entry,
+ Slapi_ValueSet** values, char **actual_type_name,
+ const char **policy_dn, int *attr_free_flags,
+ char **errstr)
+{
+int ldrc = 0;
+int flags = 0;
+int type_name_disposition = 0;
+Slapi_DN *pdn = NULL;
+
+/* Only continue if there is a password policy */
+ldrc = slapi_vattr_values_get(target_entry, krbPwdPolicyReference,
+values,
+

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-15 Thread Martin Kosek 

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.


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.


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.


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


Martin

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

Re: [Freeipa-devel] [PATCH] 1092 Fix LDAP lockout plugin

2013-03-15 Thread Rob Crittenden 

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

How is the KDC acting differently?


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?


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.


I couldn't reproduce your 3rd point.

rob

From 196e3e4158bcefbc8cd417c0b6410b931472 Mon Sep 17 00:00:00 2001
From: Rob Crittenden rcrit...@redhat.com
Date: Fri, 15 Feb 2013 11:51:59 -0500
Subject: [PATCH] Fix lockout of LDAP bind.

There were several problems:

- A cut-n-paste error where the wrong value was being considered when
  an account was administratively unlocked.
- An off-by-one error where LDAP got one extra bind attempt.
- krbPwdPolicyReference wasn't being retrieved as a virtual attribute so
  only the global_policy was used.
- The lockout duration wasn't examined in the context of too many failed
  logins so wasn't being applied properly.
- The failedcount is no longer updated past max failures.

https://fedorahosted.org/freeipa/ticket/3433
---
 .../ipa-slapi-plugins/ipa-lockout/ipa_lockout.c| 149 +
 1 file changed, 94 insertions(+), 55 deletions(-)

diff --git a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
index fea997d79825e05a6ffe4bf65e22821948794ff3..9e8920af96aae757be54f98836dd14dfdd7d3c13 100644
--- a/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
+++ b/daemons/ipa-slapi-plugins/ipa-lockout/ipa_lockout.c
@@ -226,6 +226,50 @@ done:
 return ret;
 }
 
+int ipalockout_getpolicy(Slapi_Entry *target_entry, Slapi_Entry **policy_entry,
+ Slapi_ValueSet** values, char **actual_type_name,
+ const char **policy_dn, int *attr_free_flags,
+ char **errstr)
+{
+int ldrc = 0;
+int flags = 0;
+int type_name_disposition = 0;
+Slapi_DN *pdn = NULL;
+
+/* Only continue if there is a password policy */
+ldrc = slapi_vattr_values_get(target_entry, krbPwdPolicyReference,
+values,
+type_name_disposition, actual_type_name,
+SLAPI_VIRTUALATTRS_REQUEST_POINTERS,
+attr_free_flags);
+if (ldrc == 0) {
+Slapi_Value *sv = NULL;
+
+slapi_valueset_first_value(*values, sv);
+
+if (values != NULL) {
+*policy_dn = slapi_value_get_string(sv);
+}
+}
+
+if (*policy_dn == NULL) {
+LOG_TRACE(No kerberos password policy\n);
+return LDAP_SUCCESS;
+} else {
+pdn = slapi_sdn_new_dn_byref(*policy_dn);
+ldrc = slapi_search_internal_get_entry(pdn, NULL, policy_entry,
+getPluginID());
+slapi_sdn_free(pdn);
+if (ldrc != LDAP_SUCCESS) {
+LOG_FATAL(Failed to retrieve entry \%s\: %d\n, *policy_dn, ldrc);
+*errstr = Failed to retrieve account policy.;
+return LDAP_OPERATIONS_ERROR;
+}
+}
+
+return LDAP_SUCCESS;
+}
+
 int
 ipalockout_init(Slapi_PBlock *pb)
 {
@@ -346,7 +390,7 @@ ipalockout_close(Slapi_PBlock * pb)
 static int ipalockout_postop(Slapi_PBlock *pb)
 {
 char *dn = NULL;
-char *policy_dn = NULL;
+const char *policy_dn = NULL;
 Slapi_Entry *target_entry = NULL;
 Slapi_Entry *policy_entry = NULL;
 Slapi_DN *sdn = NULL;
@@ -360,6 +404,7 @@ static int ipalockout_postop(Slapi_PBlock *pb)
 unsigned long failedcount = 0;
 char failedcountstr[32];
 int failed_bind = 0;
+unsigned int max_fail = 0;
 struct tm utctime;
 time_t time_now;
 char