openldap-bugs October 2017

openldap-bugs@openldap.org

29 participants
41 discussions

(ITS#8768) Syncprov shouldn't send a new cookie at the end of delete phase
by ondra＠openldap.org 31 Oct '17

31 Oct '17

Full_Name: Ondrej Kuznik Version: master/re24 OS: URL: Submission from: (NULL) (82.10.24.68) If sessionlog data is available and found useful, syncprov will send a cookie at the end of delete phase, itself followed by the entries modified since time recorded in the client's original cookie. Some of those entries might have been last modified before the new cookie's recorded time and if the connection is severed before this is communicated, they would not be re-sent under the new cookie. To replicate this issue, in test043, configure sessionlog and after it has finished, run ldapsearch with a cookie set to entryCSN from the mod that adds dc=testdomain2,dc=example,dc=com and record the cookie returned at the end of delete phase (it is the operation that deletes cn=Rosco P. Coltrane,ou=Retired,ou=People,dc=example,dc=com). Then try to run a syncrepl search with the recorded cookie instead. Taking only the information from this search and delete phase from the previous search, the client will not see modifications to these objects: - cn=ITD Staff,ou=Groups,dc=example,dc=com - cn=Gern Jensen,ou=Information Technology Division,ou=People,dc=example,dc=com - ou=Retired,ou=People,dc=example,dc=com

1 0

Re: (ITS#8116) [PATCH] ldapsearch: print 'SyncInfo Received' as a comment.
by ondra＠mistotebe.net 31 Oct '17

31 Oct '17

On Wed, Apr 29, 2015 at 05:04:27PM +0000, hyc(a)symas.com wrote: > linuxgeek(a)gmail.com wrote: >> When the -Esync command line option is used and a Sync Info >> Message (RFC4533) is received, ldapsearch simply prints >> 'SyncInfo Received' to STDOUT. This causes LDIF parsers and >> other tools which consume ldapsearch output to break on invalid >> input. >> >> Change this informational message to be conveyed as a comment. >> Additionally, hide the message when comments are disabled (-LL or >> -LLL). > > If we're going to the trouble of patching this bit of code, I wonder if > it would be worthwhile to actually print the contents of the syncinfo as > well. Maybe a hex dump. It has just been useful to be able to observe and experiment with syncrepl from ldapsearch so I went ahead and implemented this. The patch is available at branch ITS8116 here: https://github.com/mistotebe/openldap/tree/ITS8116 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8767) Binddn issue with a comma in the DN
by michael＠stroeder.com 31 Oct '17

31 Oct '17

This is a cryptographically signed message in MIME format. --------------ms060700000500090903040904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable christian.palacios(a)cgg.com wrote: > We have an OpenLDAP server configured as a proxy so that it can be used= to > authenticate against three Active Directory domains. We are able to ge= t it > configured with two of the domains, but it fails with the third one. T= he > problem that I have been told is that the binddn definition cannot have= a comma > in the DN. Unfortunately we don't have control over this third domain = and all > of the accounts, including service accounts, have a format that include= s a comma > in their DN. For example: binddn=3D"CN=3Dgisadmin, CNE (SVC),OU=3DCNE-= Calgary > FDSCI,OU=3DNASA,OU=3DService Accounts,DC=3Dint,DC=3Dcgg,DC=3Dcom" crede= ntials=3D"" > mode=3D"legacy" flags=3D"non-prescriptive". The ITS is only for reporting bugs. This is not a bug. It's a usage question. You should post such questions to openldap-technical mailing list after subscribing to it: https://www.openldap.org/lists/mm/listinfo/openldap-technical A short hint about escaping, e.g. a comma in DN string representation: https://tools.ietf.org/html/rfc4514#section-2.4 Note that depending on your client config system more escaping might be needed because of the config syntax. Ciao, Michael. --------------ms060700000500090903040904 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 CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMDMxMTYzOTM0WjAvBgkq hkiG9w0BCQQxIgQge7+Z+6sM+RRTXVvx9x3W5I6PSKNKGt7n9Sho8ugXDgQwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEASkkADRugnyWq1+dVYV8mSaz8+G07v0p065+5ydk22wu9iwWPCjvvDcG2c0iA3erGi0PF zKFTBygRjEfKUPbC3u2zVIH4C0k/3r8GO0eiKHYUzi1fVtWRvk+ARfT1rOQEVDwQsZtL4J0l 4ufIXNJiR9AdvQhPrs6yywVhj7TV6Upt8QsjdZtwW/6pZHPKv5U2uu2DPfGANEqfqAvef0tF o/abwZO3PSew42yYLTdP8vRK0EYfFePvIZhZ6NmQjt70Rdsl8xEtgLPyTN/qCEJ5M/DcHWzw 8AgeOI3BhCUjlpO0THnAMGacx/5eo6O5+yjvpPh0zUed3LVdP+bFcSMcVQAAAAAAAA== --------------ms060700000500090903040904--

1 0

(ITS#8767) Binddn issue with a comma in the DN
by christian.palacios＠cgg.com 31 Oct '17

31 Oct '17

Full_Name: Christian Palacios Version: LTB package version 2.4.45 OS: Debian "Stretch" URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (104.129.192.55) We have an OpenLDAP server configured as a proxy so that it can be used to authenticate against three Active Directory domains. We are able to get it configured with two of the domains, but it fails with the third one. The problem that I have been told is that the binddn definition cannot have a comma in the DN. Unfortunately we don't have control over this third domain and all of the accounts, including service accounts, have a format that includes a comma in their DN. For example: binddn="CN=gisadmin, CNE (SVC),OU=CNE-Calgary FDSCI,OU=NASA,OU=Service Accounts,DC=int,DC=cgg,DC=com" credentials="" mode="legacy" flags="non-prescriptive". As you can see, the DN has a comma next to the gisadmin value. We have been told that this is a problem so we want to see if anyone has a fix for this so that the defined binddn can have a comma in it. It's going to be hard to get another user account created in a different format that will work, so we're hoping there is a quick fix for OpenLDAP. >From the OpenLDAP Log file: Oct 16 10:11:17 CNE-LDA01 slapd[5501]: @(#) $OpenLDAP: slapd 2.4.45 (Jun 10 2017 17:54:31) $#012#011root@stretch:/opt/openldap-deb/debian/paquet-openldap-debian/openldap-ltb-2.4.45/servers/slapd Oct 16 10:11:17 CNE-LDA01 slapd[5501]: invalid bind config value binddn=CN=gisadmin, CNE (SVC),OU=CNE-Calgary FDSCI,OU=NASA,OU=Service Accounts,DC=int,DC=cgg,DC=com Oct 16 10:11:17 CNE-LDA01 slapd[5501]: /usr/local/openldap/etc/openldap/slapd.conf: line 65: "idassert-bind <args>": unable to parse field "binddn=CN=gisadmin, CNE (SVC),OU=CNE-Calgary FDSCI,OU=NASA,OU=Serv$ Oct 16 10:11:17 CNE-LDA01 slapd[5501]: slapd stopped.

1 0

Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by emmanuel.fuste＠thalesgroup.com 31 Oct '17

31 Oct '17

SGVsbG8sDQoNCkkgc3VwcG9ydCBNaWhhaSB2aWV3IG9mIHRoZSBzcGVjLg0KRXZlbiBpZiBpdCBw bGVhc2UgSm9uIHVzZSBjYXNlLCBjdXJyZW50IGJlaGF2aW9yIGNvdWxkIGJlIHZpZXcgYXMgDQpp bmNvbnNpc3RlbnQgd2l0aCB0aGUgc3BlYywgYW5kIG1vcmUgZ2VuZXJhbGx5IGlzIGluY29uc2lz dGVudCB3aXRoIA0KY29tbW9ubHkgbWVldCBwYXNzd29yZCBwb2xpY3kgc3lzdGVtcy4NCg0KIEZy b20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IG9uZSBhdHRlbXB0IG9yIHRyZWUgKG9yIGZpdmUg b3IgLi4uKSANCmFmdGVyIHRoZSAidW5sb2NrIiBpcyB0aGUgIHNhbWUsIGJydXRlIGZvcmNlIGF0 dGVtcHRzIGFyZSBkZWZlYXRlZC4NCg0KIEZyb20gYSBzdXBwb3J0L3NlcnZpY2UgZGVzayBwb2lu dCBvZiB2aWV3LCAgdGhpcyBpcyBub3QgdGhlIHNhbWUgZ2FtZS4NCkEgY29tbW9ubHkgc2FuZSAi cHdNYXhGYWlsdXJlIiBvZiAzIGlzIGdvb2QgZm9yIGRhaWx5IGZpbmdsaW5nIGVycm9ycy4NCkJ1 dCBmb3IgaG9saWRheSByZXR1cm5zLCBvbmUgdW5sb2NrIGZvciB0cmVlIG1vcmUgYXR0ZW1wdHMg aXMgb2Z0ZW4gDQpuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQgYmVmb3JlIHRoZSAiaGVhdnkiIHBh c3N3b3JkIGNoYW5nZSBwcm9jZXNzLg0KDQpJbiBjYXNlIG9mIG1hbGljaW91cyBhdHRlbXB0cywg d2Ugb25seSBvbmUgImJ5IGRlc2lnbiIgYXR0ZW1wdCBhZnRlciANCnVubG9jaywgeW91IGp1c3Qg Z2V0IERvUyBhbXBsaWZpY2F0aW9uIGFuZCBmb3JjZSBhIGVuZGxlc3MgcGFzc3dvcmQgDQpjaGFu Z2UgcHJvY2VzcyBmb3IgdGhlIHVzZXIgYmVmb3JlIHRoZSBhZG1pbnMgZml4IHRoZSBzb3VyY2Ug b2YgdGhlIA0KbG9ja2luZyAocmVhbCBtYWxpY2lvdXMgc291cmNlIG9mIGF0dGVtcHRzIG9yIG5v dCkuDQoNCklmIHRoZSBwcm9qZWN0IGFncmVlIHdpdGggSm9obiB2aWV3IG9mIHRoZSBpbnRlcnBy ZXRhdGlvbiBvZiB0aGUgYWN0dWFsIA0KaW1wbGVtZW50ZWQgc3BlYyAod2hpY2ggaXMgbm90IHRo ZSBsYXRlc3QgcHVibGlzaGVkIG9uZSksIGl0IGNvdWxkIGJlIA0KZG9jdW1lbnRlZCB3aXRoIG9u ZSBsaW5lciBpbiB0aGUgcHBvbGljeSBvdmVybGF5IGRvYy4NCg0KRW1tYW51ZWwuDQoNClBTOiBl dmVuIGlzIHRoZSBlbWFpbCBhZGRyZXNzIHNheSBvdGhlcndpc2UsIEknbSBub3QgaW4gdGhlIHNh bWUgDQooc3ViKWVudGl0eSBhcyBNaWhhaSBhbmQgZGlkIG5vdCBrbm93IE1paGFpIGJlZm9yZSB0 aGlzIElUUy4=

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by jckidder＠aep.com 31 Oct '17

31 Oct '17

I can't speak on behalf of the project but my position has not changed. If= we pursue your interpretation of the standard to a logical conclusion then= once the account is locked the user can never authenticate again. That is= not the intent. The goal of any lockout mechanism is to make brute force password guessing = impractical. They keyword here is guessing. How many attempts should your= users have to legitimately guess their password? If your users don't know= their password then they need to change it anyway. If your users can't re= member the password they just changed then you have problems you can't addr= ess in code. If you want to give your users more than 3 attempts to guess = their password then set pwdMaxFailure to that value. Don't set it to a low= er value and then manually unlock their accounts multiple times. Unlocking= a user's account so that they can continue to guess their password adds no= value. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: MUNTEANU Mihai-Adrian [mailto:mihai.munteanu@thalesgroup.com]=20 Sent: Tuesday, October 31, 2017 3:57 AM To: Jon C Kidder; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime Hello Jon, Have you reconsidered your resolution after my last comment related to the= password policy described in https://urldefense.proofpoint.com/v2/url?u=3D= https-3A__tools.ietf.org_html_draft-2Dbehera-2Dldap-2Dpassword-2Dpolicy-2D1= 0&d=3DDwIFAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&m=3DUita= RrJCJvbTRkNKnAG1MUsggW9F3FGUn7Nufv__g0U&s=3DxO5WwTWeNQanNDEj4KkwiizlVWEJDjY= kkfXMVAglLZM&e=3D ? Thanks, Kind regards, Mihai -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com] Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be= locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks = test1's account and notify test1 user 3. user test1 tries 1 time to login u= sing a wrong password and gets his account locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not= also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu＠thalesgroup.com 31 Oct '17

31 Oct '17

Hello Jon, Have you reconsidered your resolution after my last comment related to the= password policy described in https://tools.ietf.org/html/draft-behera-ldap= -password-policy-10 ? Thanks, Kind regards, Mihai -----Original Message----- From: Jon C Kidder [mailto:jckidder@aep.com]=20 Sent: Friday, October 27, 2017 2:46 PM To: MUNTEANU Mihai-Adrian; openldap-its(a)OpenLDAP.org Subject: RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdF= ailureTime This is not a bug. pwdFailureTime is only cleared after the first successful bind. If you're = manually unlocking the user's account it can be assumed that you've gone th= rough the exercise of ensuring the user is using the proper password. Perh= aps by setting a new temporary password? If you haven't gone through that = exercise 1 attempt vs multiple attempts is not going to matter. The user i= s going to lock their account again anyway. We've just recently deployed a password self-service tool and have accounte= d for this current behavior in our help desk procedures. Our cyber securit= y team loves this behavior. JON C KIDDER | MIDDLEWARE ADMINISTRATOR LEAD JCKIDDER(a)AEP.COM | D:614.716.4= 970 1 RIVERSIDE PLAZA, COLUMBUS, OH 43215 -----Original Message----- From: openldap-bugs [mailto:openldap-bugs-bounces@openldap.org] On Behalf O= f mihai.munteanu(a)thalesgroup.com Sent: Friday, October 27, 2017 3:48 AM To: openldap-its(a)OpenLDAP.org Subject: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailu= reTime This is an EXTERNAL email. STOP. THINK before you CLICK links or OPEN attac= hments. If suspicious please forward to incidents(a)aep.com for review. ********************************************************************** Full_Name: Mihai Munteanu Version: 2.4.44 OS: CentOS7 x64 URL: https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.openldap.org_= incoming_&d=3DDwIBAg&c=3DgMbiD-Q9WoaRgoXZKCrSug&r=3DWacA_KdnzU1pvF8wEQ4v1A&= m=3D3fgtnQphBlucWYzXakB6baAXEq2msUxFLlsMdi1aZQY&s=3DfE28OfhKUqMQkynWWNTkl9-= sUN8henbPip3IgOunodI&e=3D Submission from: (NULL) (86.12.190.162) Scenario:=20 0. we have configured that after 3 login failed attempts, the account to be locked. 1. user test1 fails to login 3 times -> account is locked 2. admin unlocks test1's account and notify test1 user 3. user test1 tries 1 time to login using a wrong password and gets his acc= ount locked again. Expectation here: account should not be locked after first attempt of a wro= ng password, but after third attempt, as it was the case on step 1.=20 It turns out that it is locked again after first attempt due to the fact th= at on step 2, only pwdAccountLockedTime field is removed from LDAP, but not also pwdFailureTime fields. It seems pwdFailureTime is internally cleared only: - when test1 successfully authenticate (having his account unlocked) - admin changes test1's password See below my details: $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z pwdAccountLockedTime: 20171027052024Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... $>cat unlock.ldif: dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime - delete: pwdFailureTime $>ldapmodify -x -W -D "cn=3Dadmin,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f unloc= k.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" ldap_modify: Constraint violation (19) additional info: pwdFailureTime: no user modification allowed $>cat unlock.ldif dn: cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom changetype: modify delete: pwdAccountLockedTime $>ldapmodify -x -W -D "cn=3Djamessmith,ou=3Dusers,dc=3Dthales,dc=3Dcom" -f = unlock.ldif Enter LDAP Password:=20 modifying entry "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" $>ldapsearch -x -b "cn=3Dtest1,ou=3Dusers,dc=3Dthales,dc=3Dcom" + ... pwdChangedTime: 20171027043554Z pwdFailureTime: 20171027052019.225837Z pwdFailureTime: 20171027052021.776604Z pwdFailureTime: 20171027052024.436413Z entryCSN: 20171027055105.381686Z#000000#000#000000 ... Result: pwdAccountLockedTime is removed but pwdFailureTime is not automatic= ally removed also. Expected: since I'm not allowed to remove pwdFailureTime I would expect to = be automatically removed via removal of pwdAccountLockedTime.

1 0

Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova＠symas.com 30 Oct '17

30 Oct '17

Hi, A new version of the patch has been uploaded as ftp://ftp.openldap.org/incoming/nadezhda-ivanova-171030.patch It contains fixes to a couple of problems found after the initial submission: 1. A problem where asyncmeta could not proxy a request containing a \0 in the filter 2. An unnecessary and misleading log message, that logged the operation as timed out when it wasn't. ----- Original Message ----- From: "openldap-its" <openldap-its(a)OpenLDAP.org> To: nivanova(a)symas.com Sent: Wednesday, September 13, 2017 4:22:51 PM Subject: Re: (ITS#8734) Fixes for multiple back-asyncmeta issues *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#8734. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#8734) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#8734) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=8734 Please remember to retain your issue tracking number (ITS#8734) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8764) A small typo in README
by believelinan＠aliyun.com 29 Oct '17

29 Oct '17

Full_Name: Nan Li Version: 2.4.45 OS: URL: Submission from: (NULL) (137.69.117.201) I download source code of version 2.4.45, found a small typo in README at line 32: 32 detailed instructions can be found in the OpenLDAP Admnistrator's where "Admnistrator" should be "Administrator".

1 0

Re: (ITS#8763) ACL scope warning
by Claude.Dube＠MUHC.MCGILL.CA 29 Oct '17

29 Oct '17

--0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: multipart/alternative; Boundary="1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4" --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-transfer-encoding: quoted-printable Content-type: text/plain; charset=US-ASCII Ryan, Thank for the information Claude = Ryan Tandy = <ryan(a)nardis.ca> = = To 10/28/2017 07:58 claude.dube(a)muhc.mcgill.ca = PM = cc openldap-its(a)OpenLDAP.org = Subj= ect Re: (ITS#8763) ACL scope warning= = = = = = = Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage o= r configuration questions. If you post your slapd.conf to the list I'm sure someone will be able to point out the reason for the warning. This ITS will be closed. = --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-transfer-encoding: quoted-printable Content-type: text/html; charset=US-ASCII Content-Disposition: inline <html><body> Ryan, Thank for the information<b= r> Claude <img width=3D"16" height=3D"16" src=3D"cid:1__=3D0ABB0B5BDFE312E48f9e8a= 93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D"Inactive hide details for Ryan = Tandy ---10/28/2017 07:58:38 PM---Ryan Tandy <ryan(a)nardis.ca>"><f= ont size=3D"2" color=3D"#424282" face=3D"sans-serif">Ryan Tandy ---10/2= 8/2017 07:58:38 PM---Ryan Tandy <ryan(a)nardis.ca> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td style=3D"background-image:url(cid:2__=3D0ABB0B5B= DFE312E48f9e8a93d(a)isn.rtss.qc.ca); background-repeat: no-repeat; " widt= h=3D"40%"> <ul style=3D"padding-left: 72pt"><= b>Ryan Tandy <ryan(a)nardis.ca>  10/28/2017 07:58 PM</ul>= </td><td width=3D"60%"> <table width=3D"100%" border=3D"0" cellspacing=3D"0" cellpadding=3D"0">= <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">To</di= v></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""> <ul style=3D"padding-left: 7pt">cl= aude.dube(a)muhc.mcgill.ca</ul> </td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">cc</di= v></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""> <ul style=3D"padding-left: 7pt">op= enldap-its(a)OpenLDAP.org</ul> </td></tr> <tr valign=3D"top"><td width=3D"1%"><img width=3D"58" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""> <div align=3D"right">Subject</font= ></div></td><td width=3D"100%"><img width=3D"1" height=3D"1" src=3D"cid= :3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D"">= <ul style=3D"padding-left: 7pt">Re= : (ITS#8763) ACL scope warning</ul> </td></tr> </table> <table border=3D"0" cellspacing=3D"0" cellpadding=3D"0"> <tr valign=3D"top"><td width=3D"58"><img width=3D"1" height=3D"1" src=3D= "cid:3__=3D0ABB0B5BDFE312E48f9e8a93d@isn.rtss.qc.ca" border=3D"0" alt=3D= ""></td><td width=3D"336"><img width=3D"1" height=3D"1" src=3D"cid:3__=3D= 0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca" border=3D"0" alt=3D""></td></= tr> </table> </td></tr> </table> <tt>Hi Claude, Please use the openldap-technical(a)openldap.org mailing list for usage o= r configuration questions. If you post your slapd.conf to the list I'm <b= r> sure someone will be able to point out the reason for the warning. This ITS will be closed. </tt> </body></html>= --1__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4-- --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="pic11478.gif" Content-Disposition: inline; filename="pic11478.gif" Content-ID: <2__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=0ABB0B5BDFE312E48f9e8a93d(a)isn.rtss.qc.ca> Content-Transfer-Encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=0ABB0B5BDFE312E48f9e8a93df938690918c0ABB0B5BDFE312E4--

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2017