(ITS#8768) Syncprov shouldn't send a new cookie at the end of delete phase
by ondra@openldap.org
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
5 years, 7 months
Re: (ITS#8116) [PATCH] ldapsearch: print 'SyncInfo Received' as a comment.
by ondra@mistotebe.net
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
5 years, 7 months
Re: (ITS#8767) Binddn issue with a comma in the DN
by michael@stroeder.com
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--
5 years, 7 months
(ITS#8767) Binddn issue with a comma in the DN
by christian.palacios@cgg.com
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.
5 years, 7 months
Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by emmanuel.fuste@thalesgroup.com
SGVsbG8sDQoNCkkgc3VwcG9ydCBNaWhhaSB2aWV3IG9mIHRoZSBzcGVjLg0KRXZlbiBpZiBpdCBw
bGVhc2UgSm9uIHVzZSBjYXNlLCBjdXJyZW50IGJlaGF2aW9yIGNvdWxkIGJlIHZpZXcgYXMgDQpp
bmNvbnNpc3RlbnQgd2l0aCB0aGUgc3BlYywgYW5kIG1vcmUgZ2VuZXJhbGx5IGlzIGluY29uc2lz
dGVudCB3aXRoIA0KY29tbW9ubHkgbWVldCBwYXNzd29yZCBwb2xpY3kgc3lzdGVtcy4NCg0KIEZy
b20gYSBzZWN1cml0eSBwb2ludCBvZiB2aWV3IG9uZSBhdHRlbXB0IG9yIHRyZWUgKG9yIGZpdmUg
b3IgLi4uKSANCmFmdGVyIHRoZSAidW5sb2NrIiBpcyB0aGUgIHNhbWUsIGJydXRlIGZvcmNlIGF0
dGVtcHRzIGFyZSBkZWZlYXRlZC4NCg0KIEZyb20gYSBzdXBwb3J0L3NlcnZpY2UgZGVzayBwb2lu
dCBvZiB2aWV3LCAgdGhpcyBpcyBub3QgdGhlIHNhbWUgZ2FtZS4NCkEgY29tbW9ubHkgc2FuZSAi
cHdNYXhGYWlsdXJlIiBvZiAzIGlzIGdvb2QgZm9yIGRhaWx5IGZpbmdsaW5nIGVycm9ycy4NCkJ1
dCBmb3IgaG9saWRheSByZXR1cm5zLCBvbmUgdW5sb2NrIGZvciB0cmVlIG1vcmUgYXR0ZW1wdHMg
aXMgb2Z0ZW4gDQpuZWNlc3NhcnkgYW5kIHN1ZmZpY2llbnQgYmVmb3JlIHRoZSAiaGVhdnkiIHBh
c3N3b3JkIGNoYW5nZSBwcm9jZXNzLg0KDQpJbiBjYXNlIG9mIG1hbGljaW91cyBhdHRlbXB0cywg
d2Ugb25seSBvbmUgImJ5IGRlc2lnbiIgYXR0ZW1wdCBhZnRlciANCnVubG9jaywgeW91IGp1c3Qg
Z2V0IERvUyBhbXBsaWZpY2F0aW9uIGFuZCBmb3JjZSBhIGVuZGxlc3MgcGFzc3dvcmQgDQpjaGFu
Z2UgcHJvY2VzcyBmb3IgdGhlIHVzZXIgYmVmb3JlIHRoZSBhZG1pbnMgZml4IHRoZSBzb3VyY2Ug
b2YgdGhlIA0KbG9ja2luZyAocmVhbCBtYWxpY2lvdXMgc291cmNlIG9mIGF0dGVtcHRzIG9yIG5v
dCkuDQoNCklmIHRoZSBwcm9qZWN0IGFncmVlIHdpdGggSm9obiB2aWV3IG9mIHRoZSBpbnRlcnBy
ZXRhdGlvbiBvZiB0aGUgYWN0dWFsIA0KaW1wbGVtZW50ZWQgc3BlYyAod2hpY2ggaXMgbm90IHRo
ZSBsYXRlc3QgcHVibGlzaGVkIG9uZSksIGl0IGNvdWxkIGJlIA0KZG9jdW1lbnRlZCB3aXRoIG9u
ZSBsaW5lciBpbiB0aGUgcHBvbGljeSBvdmVybGF5IGRvYy4NCg0KRW1tYW51ZWwuDQoNClBTOiBl
dmVuIGlzIHRoZSBlbWFpbCBhZGRyZXNzIHNheSBvdGhlcndpc2UsIEknbSBub3QgaW4gdGhlIHNh
bWUgDQooc3ViKWVudGl0eSBhcyBNaWhhaSBhbmQgZGlkIG5vdCBrbm93IE1paGFpIGJlZm9yZSB0
aGlzIElUUy4=
5 years, 7 months
RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by jckidder@aep.com
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.
5 years, 7 months
RE: [EXTERNAL] (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
by mihai.munteanu@thalesgroup.com
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.
5 years, 7 months
Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova@symas.com
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.
5 years, 7 months
(ITS#8764) A small typo in README
by believelinan@aliyun.com
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".
5 years, 7 months
Re: (ITS#8763) ACL scope warning
by Claude.Dube@MUHC.MCGILL.CA
--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>
<p><font size=3D"2" face=3D"sans-serif">Ryan,</font><br>
<br>
<font size=3D"2" face=3D"sans-serif">Thank for the information</font><b=
r>
<br>
<font size=3D"2" face=3D"sans-serif">Claude</font><br>
<br>
<br>
<br>
<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></font><br>
<br>
<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"><font size=3D"1" face=3D"sans-serif"><=
b>Ryan Tandy <ryan(a)nardis.ca></b></font><font size=3D"1" face=3D"=
sans-serif"> </font>
<p><font size=3D"1" face=3D"sans-serif">10/28/2017 07:58 PM</font></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=
""><br>
<div align=3D"right"><font size=3D"1" face=3D"sans-serif">To</font></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""><br>
<ul style=3D"padding-left: 7pt"><font size=3D"1" face=3D"sans-serif">cl=
aude.dube(a)muhc.mcgill.ca</font></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=
""><br>
<div align=3D"right"><font size=3D"1" face=3D"sans-serif">cc</font></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""><br>
<ul style=3D"padding-left: 7pt"><font size=3D"1" face=3D"sans-serif">op=
enldap-its(a)OpenLDAP.org</font></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=
""><br>
<div align=3D"right"><font size=3D"1" face=3D"sans-serif">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"">=
<br>
<ul style=3D"padding-left: 7pt"><font size=3D"1" face=3D"sans-serif">Re=
: (ITS#8763) ACL scope warning</font></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>
<br>
<tt><font size=3D"2">Hi Claude,<br>
<br>
Please use the openldap-technical(a)openldap.org mailing list for usage o=
r <br>
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.<br>
<br>
This ITS will be closed.<br>
</font></tt><br>
<br>
</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--
5 years, 7 months