I'd like to report a bug in the Samba 4 LDAP interface. Versions I've tried and the bug is existent: 4.9.5 (debian package 2:4.9.5+dfsg-5), 4.13.5 (debian package 2:4.13.5+dfsg-1) I've extended the default schema with an attribute with the type of Generalized-Time (attributeSyntax: 2.5.5.11). If I want to set it's value trough the LDAP interface, I get an error: LDAPInvalidAttributeSyntaxResult - 21 from the server. I've tried many formats, which pass the format requirements, including what works in a Microsoft AD: "20171203081334.0Z" (without the quotation) and what works OpenLDAP: "20171203081334Z" (without the quotation). I've tried values already in Samba, set by Samba, like creation times, etc. I've also tried to add the time zone in the generalized time syntax, but that doesn't work either. Also tried with different clients (python3 ldap3 lib, Apache Directory Studio). During experimentation, I found out that if I reduce precision to the minutes, it works: "201712030813Z" (without the quotation) is accepted. The expected behavior would be for Samba to accept generalized time syntax, for our purposes at least to the seconds.
We would prefer you check on a supported version. Having said that, it looks like the culprit is ldb_val_to_time() where nothing has changed for some time, so recent versions are likely affected.
"201712030813Z" fails because we do if (v->data[14] != '.') { return LDB_ERR_INVALID_ATTRIBUTE_SYNTAX; } expecting always a '.'. We try to ignore fractions of a second, but we do seem to parse seconds. I will look into it.
Sorry, last comment was about OpenLdap style "20171203081334Z". "201712030813Z" (without seconds) will be interpreted as a 2-digit year, that is 2020-17-12, which is obviously invalid as a date, so succeeding with that is bad.