Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by michael＠stroeder.com
This is a cryptographically signed message in MIME format.
--------------ms040304010104090205010307
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: quoted-printable
subbarao(a)computer.org wrote:
> Reading the slapo-ppolicy man page, I was optimistically expecting that=
excess
> stale pwdFailureTime values might be removed from the entry after pwdMa=
xFailure
> was exceeded. For example, if pwdMaxFailure is 5, then only the most re=
cent 5
> pwdFailureTime values would be kept, and the old ones purged as and whe=
n new
> failed bind attempts were made.
>=20
> This wording in the slapo-ppolicy man page sounds friendly towards this=
> interpretation: "Excess timestamps beyond those allowed by pwdMaxFailur=
e may
> also be purged."
>=20
> Looking at the source code though, it doesn't seem that pwdFailureTime =
values
> are actually removed unless a successful bind occurs -- whereupon all v=
alues of
> course are removed.
>=20
> I would like to request an enhancement to purge stale pwdFailureTime va=
lues as
> mentioned above.
Nope. The number of pwdFailureTime is also used as failure lockout counte=
r.
Actually it was improved with ITS#7161.
> This would also largely mitigate the issue raised in ITS#7089
I don't see the relation with ITS#7089.
Ciao, Michael.
--------------ms040304010104090205010307
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD
VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0
ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe
Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg
U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0
ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp
pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9
b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q
zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX
9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/
4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E
BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw
HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG
AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6
Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu
Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB
FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw
Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC
AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py
TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm
CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz
uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm
z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT
5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp
sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076
khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8
J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX
un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG
9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw
NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG
A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry
b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4
uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk
Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK
JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih
34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v
KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL
BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj
z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf
BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL
KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w
b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0
byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g
Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj
b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt
MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF
BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns
YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl
cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0
YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22
A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm
v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3
6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq
YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw
oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV
BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl
IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh
dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq
hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDcwMjIyMDgzOVowLwYJKoZIhvcNAQkEMSIE
IP4/I+JcpHl9IrtvlMxjsSSZ5vx8RYJPw0b0IO3WK0k5MGwGCSqGSIb3DQEJDzFfMF0wCwYJ
YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI
KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB
lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl
Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs
YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ
EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG
A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh
cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq
hkiG9w0BAQEFAASCAQAqQgw0y1hXKHQV5pBgxYa1fHdEaxKhKBUEI6fuKoLyPHtSi1ogTl3f
pDOyssMJ6yCrpIraHLQhYkFt2YKooARQbUGwi2hhUm64DZiG2h5ZCv8wGWbE/KDVVCU1hMF7
LMPKyIxbLBFRA9rJUx5ElY8QbkVdYja15MyIg/dJEIgExhrA9XllBVfdNgyAwv/NXTOK3+tm
YFdJLnGtiDhiNMsA2Zqji5g26MbeUyhCpl91eOI6hbrHKdXLW+GJiLyexo41fIqAqhNlYZyP
s8TRkcyKUSm6FjMfGdpjIeppfDiAEogt1KSRZ/MC+Jtl9weSIdK8nJzaJlHHgedoVajqMEcF
AAAAAAAA
--------------ms040304010104090205010307--
7 years, 11 months
(ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org
Full_Name: Kartik Subbarao
Version: 2.4.40
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (173.75.228.155)
Reading the slapo-ppolicy man page, I was optimistically expecting that excess
stale pwdFailureTime values might be removed from the entry after pwdMaxFailure
was exceeded. For example, if pwdMaxFailure is 5, then only the most recent 5
pwdFailureTime values would be kept, and the old ones purged as and when new
failed bind attempts were made.
This wording in the slapo-ppolicy man page sounds friendly towards this
interpretation: "Excess timestamps beyond those allowed by pwdMaxFailure may
also be purged."
Looking at the source code though, it doesn't seem that pwdFailureTime values
are actually removed unless a successful bind occurs -- whereupon all values of
course are removed.
I would like to request an enhancement to purge stale pwdFailureTime values as
mentioned above. This would also largely mitigate the issue raised in ITS#7089
without needing to develop more involved code for that. The common theme is to
ensure that pwdFailureTime values can't keep accumulating without bound, due to
broken/misconfigured clients that are beyond the LDAP server administrator's
control.
7 years, 11 months
(ITS#8184) MOD operation with a double delete of a pwdFailureTime attribute
by elecharny＠apache.org
Full_Name: Emmanuel L.charny
Version: 2.4.40
OS:
URL:
Submission from: (NULL) (212.195.127.200)
We get an error when trying to change a password in some combinaison of settings
:
- 2 servers, one being the master, one being the slave
- a few backends (MDB)
- one of those backends using the glue overlay, the other being subordinates
- 2 backends using the PPolicy overlay : the one which is the parent, and
another one being a subordinate. FTR, the PPolicy in use are different
What happens is that the password update will try to delete the pwdFailureTime
attribute of the impacted entry (and two other attributes, too : pwdGraceUseTime
and pwdAccountLockedTime. As we have 2 PPolicies, the attribute deletion will be
requested twice, in one single MOD operation. The second DEL modification will
then fail, leading to the rejection of the modification.
To make it a bit more complex, the pwdFailureTime was updated on the slave, not
replicated (it's a slave), and the password update was done on the master, so
the failure was on the slave, as the master was pushing the modification to it.
At the end, the two servers were not anymore in sync.
The reason for this failure was that the code in charge of checking the MOD
request, in ppolicy.c, lines 1575 to 1666, aren't checking if a DEL of one of
the three attributes is already present in the list of MODIFICATION.
Howard's suggestion to get this fix is to replace this code :
got_del_fail = 1;
if ( !a_fail )
drop = 1;
by :
if ( !a_fail || got_del_fail ) {
drop = 1;
} else {
got_del_fail = 1;
}
7 years, 11 months
(ITS#8183) ldap_init() failed at sub thread but runs ok at main.
by 1727647302＠qq.com
Full_Name: wondersoft
Version: 2.4.39
OS: CentOS 6.6 X86_64
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (182.50.119.36)
Hi:
My server is CentOS 6.6(x86_64). When I create a thread on the main(), it's
failed on ldap_init(), but it's ok at main not running on a sub thread. But
using the same version and the same code, it runs pretty well at CentOS
6.6(x86_32).
Test code is here:
void pthread_ldap()
{
LDAP *ld = NULL;
ld=(LDAP*)ldap_init(HOSTNAME,0);
if(ld ==NULL) {
perror("ldap_init");
return ;
}
int protocolVersion = LDAP_VERSION3;
//It failed here, if ituns s on CentOS 6.6(x86_64) as a sub thread.
ldap_set_option( ld, LDAP_OPT_PROTOCOL_VERSION, &(protocolVersion));
return ;
}
int main()
{
int ret = 0;
pthread_attr_t attr_attribute;
pthread_attr_init(&attr_attribute);
pthread_attr_setdetachstate(&attr_attribute,PTHREAD_CREATE_DETACHED);
pthread_t pid;
//If no sub thread created, it's ok
//pthread_ldap();
if( pthread_create( &pid, &attr_attribute, (void*)pthread_ldap, NULL ) ) {
perror(" Create pthread_ldap ERROR");
}
}
gdb chasing result:
(gdb)
222 rc = ldap_set_option(ld, LDAP_OPT_HOST_NAME, defhost);
(gdb)
223 if ( rc != LDAP_SUCCESS ) {
(gdb) p ld
$6 = (LDAP *) 0x7ffff00008c0
(gdb)
pthread_ldap () at OPENLDAP_exam.c8686
186 printf("ldap_init ld = %d\n", ld);
(gdb) p ld
$7 = (LDAP *) 0xfffffffff00008c0
gcc version:
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-11)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
OS version:
Linux localhost.localdomain 2.6.32-504.el6.x86_64 #1 SMP Wed Oct 15 04:27:16 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux
gcc command:
gcc OPENLDAP_exam.c -g -o OPENLDAP_exam -L/usr/local/lib -lldap -llber -lpthread
7 years, 11 months
(ITS#8182) setspec matching fails unexpectedly
by daniel.kauffman＠rocksolidsolutions.org
Full_Name: Daniel Kauffman
Version: 2.4.40
OS: Debian 8.1
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (76.178.89.137)
Issue:
Using access control set=<setspec> to compare an attribute value against a
string converts the attribute value to lower case but does not convert the
string to lower case, so matching sometimes fails unexpectedly.
Expected behavior:
When an attribute value is compared against a string, matching should use the
attribute equality matching rule to determine whether or not to do a
case-sensitive match. An exact match would not convert either the attribute
value or the string, and a case-insensitive matching rule would convert both the
attribute value and the string for comparison.
Steps to reproduce:
Create a user objectclass with a roleName attribute and set the attribute value
to "canBrowse". Note the mixed case.
Create an access control statement with mixed case:
olcAccess: to * by set="user/roleName & [canBrowse]" read
Because the roleName attribute value is converted to lower-case before
comparison, the above will always fail, regardless of the case of the roleName
attribute value.
However, this works, regardless of the case of the roleName attribute value:
olcAccess: to * by set="user/roleName & [canbrowse]" read
7 years, 11 months