Re: (ITS#8639) Remove support for LANMAN
On 2/28/20 8:40 PM, r...@nardis.ca wrote: > Are you aware of any scenarios where > sambaLMPassword is actually required today? Personally I'm more inclined > to just delete the code rather than #ifdef it; people can always grab > the older code if they really need that. +1 for hunking out LANMAN hashes completely. Ciao, Michael.
Re: (ITS#9157) return additional error code information when OPT_X_TLS_NEWCTX fails
In one of our test envs, had the path wrong in replication config for = encryption artifacts: *** Conf excerpt: *** syncrepl =E2=80=A6 tls_key=3D/opt/symas/etc/openldap/file-name.pem *** Which gives generic error: *** Log Trace: *** an 27 17:25:17 sapz1a slapd[6203]: slapd starting =E2=80=A6 TLS context initialization failed (-1) Jan 27 17:25:17 hostname slapd[6203]: do_syncrepl: rid=3D031 rc -1 = retrying (4 retries left) *** Would have been helpful for the message to specify which artifact = wasn=E2=80=99t found, the line number of the config, or some other way = of narrowing the problem. =E2=80=94 Shawn
Re: (ITS#9154) RFE: Number of entries in MDB database in cn=monitor
On 1/18/20 1:54 PM, Howard Chu wrote: > mich...@stroeder.com wrote: >> The number of entries could be added there as attribute 'olmMDBEntries' or >> similar. > > Added in git master Great! Thank you. Any chance to see it in RE24? At least the back-port patch seems to work smoothly in my local test environment. Ciao, Michael.
(ITS#9154) RFE: Number of entries in MDB database in cn=monitor
Full_Name: Michael Str.der Version: master OS: URL: Submission from: (NULL) (213.240.182.99) As a system engineer I want to see the number of entries within a mdb database in the monitoring (e.g. to alarm unusual fast changes due to false deletions). While one can use mdb_stat or other custom scripts to monitor the number of entries of the id2e sub-DB this requires read access to the MDB environment. But for security reasons this should be avoided. olmMDBDatabase entries in cn=monitor already have attributes for MDB page counts. The number of entries could be added there as attribute 'olmMDBEntries' or similar.
Re: (ITS#9126) add: pwdChangedTime leads to seg fault
This still happens with current RE24 snapshot. Is more information needed to address this?
Re: (ITS#9151) slapd-sock - stumped
On 1/11/20 9:03 PM, matt...@schlutech.com wrote: > Always results in socket connect failed. > > database sock > socketpath/tmp/example.sock > [..] > Always: socket connect(/root/example.sock) failed /tmp/example.sock != /root/example.sock Either something's inconsistent in your config or the information you provided herein. Also this does not seem to be a bug report but the ITS is only for reporting bugs. Please send usage questions to openldap-technical mailing list. Ciao, Michael.
Re: (ITS#9124) CVE-ID?
On 1/10/20 2:28 PM, Stephan Zeisberg wrote: > So far I have not requested a CVE-Id for the issue. That's what Howard > wrote in this regard: > >> Usual practice for CVEs is not to make them public until fixes are >> released. In the future, you should tick the Major Security Issue >> button for potential CVEs so they can be handled privately before >> release.> > I am not aware of a release including the bugfix for the issue. If the > release already exists I am happy to request a CVE-Id for it First of all, many thanks for finding and submitting issues like this. Disclaimer: I'm not an official OpenLDAP project member and I'm not an expert for this CVE-ID process. >From my understanding you can request a CVE-ID which is kept confidential until the vendor developed a fix. This is useful to already have a unique reference for all the work done upstream to fix a particular security issue and for applying back-port patches to downstream packages (e.g. in Linux distributions). Furthermore OpenLDAP's ITS allows to mark an issue as security issue which hides it from public access. I read Howard's comment that he meant exactly this. Ciao, Michael.
Re: (ITS#9124) CVE-ID?
Stephan, regarding: https://www.openldap.org/its/index.cgi?findid=9124 Was there ever a CVE-Id assigned to this issue? I'd like to reference it in back-port patches for downstream packages. Ciao, Michael.
(ITS#9126) add: pwdChangedTime leads to seg fault
Full_Name: Michael Str.der Version: 2.4.48 / RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (213.240.182.73) slapd seg faults in case the client sends a modify operation like this (let me know if you need a stack trace): - snip - $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify add: pwdChangedTime pwdChangedTime: 1972110100Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" ldap_result: Can't contact LDAP server (-1) - snip - Note that this only happens in case the userPassword was *freshly* set via Password Modify ext. op. If the client sends a modify operation with 'replace: pwdChangedTime' this works correctly and after that 'add: pwdChangedTime' is correctly rejected: - snip - $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify replace: pwdChangedTime pwdChangedTime: 1972110100Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify add: pwdChangedTime pwdChangedTime: 1972110100Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" ldap_modify: Type or value exists (20) additional info: modify/add: pwdChangedTime: value #0 already exists - snip -
Re: (ITS#9124) Unauthenticated remote denial-of-service (Null pointer dereference in ber_skip_tag)
On 11/29/19 1:06 PM, on...@mistotebe.net wrote: > thanks for the report, this should be fixed by commit > 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 in master. Will this fix be added to 2.4.49 and when? Ciao, Michael.
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
On 7/23/19 12:42 PM, Alexander Soloviov wrote: > I understood the risks but how can I resolve my issue? As said: By fixing your schema setup on all replicas. > My case I want to upgrade all servers step by step without lost data > on secondary LDAP servers You probably don't want to read this: Fix schema on all replicas before the upgrade. Ciao, Michael.
Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
This is a cryptographically signed message in MIME format. --ms07070908020401080303 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 7/23/19 9:10 AM, alex.solov...@wildix.com wrote: > Actually, I have the configuration with several LDAP server without thi= s =3D > problem. But the version of these LDAPs is a bit less - 2.4.31.=3D20 > On this installation when I changed the schema on the main server, on =3D= > secondary I see fully replicated data and warnings about unknown =3D > attributes like: >=20 > 5d36b192 UNKNOWN attributeDescription "TESTTYPE" inserted. Mainly running a replication setup without consistent schema on all=20 replicas is asking for trouble. It may work in some niche cases. But in=20 most cases it will fail miserably. =3D> Fix your setup. Ciao, Michael. --ms07070908020401080303 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 CyEwggUzMIIEG6ADAgECAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODEyMTYwMDAw MDBaFw0xOTEyMTYyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ryb2VkZXIu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvdaCPHlSjB9Wb51jh60x+6OO lOP14FSXRNDYWcuaCwey30JdrJxw9VMiBEJo7Q7fHWcpna9l9oVKuvjO3VepiyTlQoinvwSG gQrBburWskKupOJPwv0QH8nWpc9KnP7LnOqfepwHNrqhweijxeGg95TQeDfOVbQmGwqnaCtp CBuCu3gyxe/wVkKnr6uqwHFUoGSNIrLAdLFcnFbpKGoYvZvahkdLNglCRLpeSVu9/O0MqkGt gGp6nPcTHwbZYSoGqFJQjPeTlczubTKo9DWYhZ0vMB2fjdadSqZxUgqqdElLRWSqRD1jCm3U xShVkPJDQg3tkQq6Yw4C1Z9+L9KxJQIDAQABo4IB6jCCAeYwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFLn0/ESCAOEV6clL6lYXzOwKIKlyMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wDQYJKoZIhvcNAQELBQADggEB ALFD55CXI+vy81ngFjheHu+TjKJuxrYfw71qz54pmYwR4UYBTSLNvESJXwOfSi7UxBh97xjB bjy5rDByXl1IWAFXcnoHPKJNZL8wOa0MNz4o3X0of7JHZHYlyXJRnZV90+KtZQdn5ZP2hBmg SHxcjdgCMU9p6VoOlJLhpEKN1TmbHq/elcwZKknnGN+54Vn2RhVP0x3998yyhIkiHNAqQImT cqY5QkpGxyocLz54NXudIZSvXyvQI4d7FYl4JKn6gw4PRXht0/xzB/GGGKGWSrgdPCUJ4Rif cGpO43inEBxWlW19cjYSXjqZetq2ZIJnrADxTttTJoUQsGuoT5ZMf2UwggXmMIIDzqADAgEC AhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra 0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr 5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTq Rvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDa ElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEA AaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIB ADARBgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21v ZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUH AQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FB ZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0G CSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj 6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxm gUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTC kk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlL WPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzOb XYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtF OI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3C VJqb1XWeKIJ84F7YLX
Re: (ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"
On 6/7/19 1:49 AM, qua...@symas.com wrote: > --On Friday, January 25, 2019 9:25 PM + mich...@stroeder.com wrote: > >> All links herein are dead: >> https://www.openldap.org/faq/data/cache/220.html >> >> I'd suggest to remove this FAQ page completely. > > I tried, but unfortunatley the FAQ software breaks Apache when you try and > delete an answer. I think the better solution is just to remove the FAQ > software completely. The FAQ contains the only documentation for set-based ACLs. So it's not an option to just shutdown FAQ-O-MATIC. Ciao, Michael.
Re: (ITS#9016) cn=config should fail on EMIT if target directory not empty
This is a cryptographically signed message in MIME format. --ms030705030102060301060203 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/24/19 1:32 PM, on...@openldap.org wrote: > Since it's not feasible to clean up properly, it should just return an = error > instead? Yes. In general I prefer fail-early-fail-hard with clear error messages. Ciao, Michael. --ms030705030102060301060203 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 CyEwggUzMIIEG6ADAgECAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBCwUAMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xODEyMTYwMDAw MDBaFw0xOTEyMTYyMzU5NTlaMCUxIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ryb2VkZXIu Y29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvdaCPHlSjB9Wb51jh60x+6OO lOP14FSXRNDYWcuaCwey30JdrJxw9VMiBEJo7Q7fHWcpna9l9oVKuvjO3VepiyTlQoinvwSG gQrBburWskKupOJPwv0QH8nWpc9KnP7LnOqfepwHNrqhweijxeGg95TQeDfOVbQmGwqnaCtp CBuCu3gyxe/wVkKnr6uqwHFUoGSNIrLAdLFcnFbpKGoYvZvahkdLNglCRLpeSVu9/O0MqkGt gGp6nPcTHwbZYSoGqFJQjPeTlczubTKo9DWYhZ0vMB2fjdadSqZxUgqqdElLRWSqRD1jCm3U xShVkPJDQg3tkQq6Yw4C1Z9+L9KxJQIDAQABo4IB6jCCAeYwHwYDVR0jBBgwFoAUgq9sjPjF /pZhfOgfPStxSF7Ei8AwHQYDVR0OBBYEFLn0/ESCAOEV6clL6lYXzOwKIKlyMA4GA1UdDwEB /wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMF AjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggr BgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwWgYDVR0fBFMwUTBPoE2g S4ZJaHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRp b25hbmRTZWN1cmVFbWFpbENBLmNybDCBiwYIKwYBBQUHAQEEfzB9MFUGCCsGAQUFBzAChklo dHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FDbGllbnRBdXRoZW50aWNhdGlvbmFu ZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5j b20wHwYDVR0RBBgwFoEUbWljaGFlbEBzdHJvZWRlci5jb20wDQYJKoZIhvcNAQELBQADggEB ALFD55CXI+vy81ngFjheHu+TjKJuxrYfw71qz54pmYwR4UYBTSLNvESJXwOfSi7UxBh97xjB bjy5rDByXl1IWAFXcnoHPKJNZL8wOa0MNz4o3X0of7JHZHYlyXJRnZV90+KtZQdn5ZP2hBmg SHxcjdgCMU9p6VoOlJLhpEKN1TmbHq/elcwZKknnGN+54Vn2RhVP0x3998yyhIkiHNAqQImT cqY5QkpGxyocLz54NXudIZSvXyvQI4d7FYl4JKn6gw4PRXht0/xzB/GGGKGWSrgdPCUJ4Rif cGpO43inEBxWlW19cjYSXjqZetq2ZIJnrADxTttTJoUQsGuoT5ZMf2UwggXmMIIDzqADAgEC AhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQswCQYDVQQGEwJHQjEbMBkG A1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFD T01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYD VQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra 0D00SOTq9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr 5SU0RDX/kSsKwer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTq Rvaq8aWccm+KOMjTcE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDa ElmOupyTf1Qib+cpukNJnQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEA AaOCATwwggE4MB8GA1UdIwQYMBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSC r2yM+MX+lmF86B89K3FIXsSLwDAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIB ADARBgNVHSAECjAIMAYGBFUdIAAwTAYDVR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21v ZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNhdGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUH AQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FB ZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0G CSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6JrF/bz9kkIBtTYLzXN30D+03Hj 6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/Hv+GTrNI/AhqX2/kiQNxm gUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWeEykgzClZlPz1FjTC kk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjhk0xQfhNqbzlL WPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJzK8HxzOb XYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q9EtF OI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3C VJqb1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wk yk5S/GFyyPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCBDUwggQxAgEB MIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD VQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmH IQX8SWTc7x5fq9i6IjANBglghkgBZQMEAgEFAKCCAlkwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNDI0MTIwMzU1Wj
Re: (ITS#8998) ldapi:// with SASL_NOCANON -> Local error (-2)
On 4/18/19 3:36 AM, Quanah Gibson-Mount wrote: > Does the patch referenced in ITS#7585 fix this for you? Been waiting > for years for RedHat to update with the IPR. ;) Disclaimer: I'm not a C programmer. Maybe it's me but AFAICS even if nocanon evaluates to True there's always a call into gethostname(). Does that make sense? Ciao, Michael.
Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
I considered contacting current SUSE maintainers of package openldap2. In preparation to that I tried to find out which bug caused this patch to be developed. AFAIK the patch is not applied to the package anymore: https://build.opensuse.org/package/show/network:ldap/openldap2 And I have no reference to further information. To OpenLDAP devs: Does Howard's patch still make sense? Is it worth to dig into SUSE's bugzilla to find out more?
Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
On 4/18/19 12:44 AM, qua...@symas.com wrote: > Sending this to your @suse.com email bounced. Please see below and update > with an IPR as requested. Thanks! Since quite a while Howard Guo does not work for SUSE anymore. Do you need Howard's IPR notice or one from SUSE? Ciao, Michael.
Re: (ITS#9002) Add option to slapcat to honor rtxnsize setting
On 3/29/19 8:58 PM, qua...@openldap.org wrote: > To work around this, slapcat could be given an option to honor the rtxnsize > setting in slapd.conf/cn=config. > [..] > It should be noted in the man page section for this option that the value of > such a backup is of dubious quality, since it is no longer an exact "point in > time" representation of the database but rather a bunch of different "point in > times" stitched together into a single file. Even if slapcat now outputs an exact "point in time" representation of the database this does not say anything about consistency of related LDAP entries anyway. But I wonder how rtxnsize is supposed to interop with LDAP transactions in 2.5.
(ITS#8998) ldapi:// with SASL_NOCANON -> Local error (-2)
Full_Name: Michael Str.der Version: 2.4.47 OS: openSUSE Tumbleweed URL: Submission from: (NULL) (213.240.182.56) Adding line SASL_NOCANON on to my ~/.ldaprc causes ldapwhoami to fail like this: $ ldapwhoami -H ldapi:// -Y EXTERNAL ldap_sasl_interactive_bind_s: Local error (-2) Using the full LDAPI path name just works as expected: $ ldapwhoami -H ldapi://%2frun%2fslapd%2fldapi -Y EXTERNAL SASL/EXTERNAL authentication started SASL username: gidNumber=1000+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=michael,dc=example,dc=com
(ITS#7770) mdb_stat in cn=monitor
I'm currently testing this feature back-ported to RE24 branch. I noticed that these attributes are set to empty values: creatorsName: modifiersName: Rest of entry looks good: dn: cn=Database 1,cn=Databases,cn=Monitor objectClass: monitoredObject objectClass: olmMDBDatabase structuralObjectClass: monitoredObject cn: Database 1 creatorsName: modifiersName: createTimestamp: 20190312102553Z modifyTimestamp: 20190312102553Z monitoredInfo: mdb monitorIsShadow: FALSE namingContexts: cn=accesslog readOnly: FALSE monitorOverlay: noopsrch seeAlso: cn=Overlay 1,cn=Overlays,cn=Monitor seeAlso: cn=Backend 2,cn=Backends,cn=Monitor olmMDBPagesMax: 97656 olmMDBPagesUsed: 33695 olmMDBPagesFree: 88 olmMDBReadersMax: 126 olmMDBReadersUsed: 3 olmDbDirectory: /var/lib/ldap/accesslog/ entryDN: cn=Database 1,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE
(ITS#8971) slapo-accesslog hits assert
Full_Name: Version: RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (212.68.198.84) For the records an issue tested with Howard today: slapo-accesslog hits an assert checking for empty 'reqDN' after processing a password modify extended operation. More information in the ITS upon request.
(ITS#8962) Dead links in FAQ page "Where can I find listings of schema items?"
Full_Name: Michael Str.der Version: OS: URL: Submission from: (NULL) (213.240.182.19) All links herein are dead: https://www.openldap.org/faq/data/cache/220.html I'd suggest to remove this FAQ page completely.
Re: (ITS#8938) ldap 2.4.40 replication
On 11/19/18 11:43 AM, p.vor...@live.com wrote: > Its now been a month and i still couldn't find a way to create a replication > server. > I have transferred my old db from previous version of ldap. everything works > just fine except the replication part. > > i tried synproc etc but nothing.. does any one has some idea about that? The ITS is only used for reporting bugs. In general you should follow instructions in the OpenLDAP admin guide: https://www.openldap.org/doc/admin24/replication.html For asking usage questions please subscribe to openldap-technical mailing list and post your question there: https://www.openldap.org/lists/mm/listinfo/openldap-technical You should describe what you want to achieve, the exact version you're using, OS platform, the config you've tried and some relevant log excerpts if available. Ciao, Michael.
Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
On 11/18/18 7:13 PM, Quanah Gibson-Mount wrote: > --On Sunday, November 18, 2018 5:48 PM + h...@symas.com wrote: >> Sounds like this is an issue for the Cyrus SASL project. Their plugin is >> returning a SASL_BADPROT error code on all failures, instead of a more >> meaningful code like SASL_BADAUTH. > > I opened <https://github.com/cyrusimap/cyrus-sasl/issues/545> Thanks. > since they're working on getting the 2.1.27 release out anytime now > and this should likely be fixed as a part of that release. It seems they cut the release yesterday: ftp://ftp.cyrusimap.org/cyrus-sasl/ Nevermind, I'm not using SASL password mechs for anything serious. Just stumbled across this while implementing a regression test for bad password in ldap0 module which explicitly checks that invalidCredentials(49) is returned. Ciao, Michael.
(ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
Full_Name: Version: 2.4.46 OS: openSUSE Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.240.182.29) SASL bind with SCRAM-SHA-1 does not return invalidCredentials (49) in case of a wrong password being used while DIGEST-MD5 and other password mechs works as expected. This might lead to different error handling in client applications if the user input a wrong password. This proves SCRAM-SHA-1 is enabled and working: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w test123 SASL/SCRAM-SHA-1 authentication started SASL username: test42 SASL SSF: 0 dn:uid=test42,ou=testing,dc=stroeder,dc=de But wrong password returns other(80) as result code: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w wrong SASL/SCRAM-SHA-1 authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-5): bad protocol / cancel: StoredKey mismatch Now testing DIGEST-MD5: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w test123 SASL/DIGEST-MD5 authentication started SASL username: test42 SASL SSF: 128 SASL data security layer installed. dn:uid=test42,ou=testing,dc=stroeder,dc=de Wrong password returns invalidCredentials(49) as expected: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w wrong SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated (tried bogus)
Re: (ITS#8935) slapo-ppolicy requires rewrite
On 11/17/18 11:35 AM, h...@symas.com wrote: > We could instead ship an update.ldif containing the mods between > different schema versions, that must be applied with slapmodify > during the update process... IMO too many prerequisites must be perfectly full-filled and thus is too fragile. That's one of the things where e.g. OpenDS/OpenDJ does a much better job with its cn=config: The schema shipped with the server is stored in various LDIF files in a config directory along with file rootdse.ldif holding cn=config. Schema directly added by modifying cn=schema is sent to a separate user schema file. With such a layout the standard schema shipped with the software is not part of cn=config but can still be dynamically changed (by directly modifying subschema subentry). But there's always a way out of trouble because you can manually fix the separate LDIF schema file(s). Ciao, Michael.
Re: (ITS#8935) slapo-ppolicy requires rewrite
The root cause is that updating slapd with its default schema installed does not update existing content of cn=schema,cn=config. You have to tackle this root cause and not only solve it for a particular overlay. Your conclusion is to hard-code the ppolicy schema into the C code. If you think this to the end you have to move *all* standard schema installed to schema_prep.c. IMO this is bad design. But I'm not the one to decide on that. :-/ Ciao, Michael.
Re: (ITS#8931) deref'ing non-existent attributes should not result in protocolError
On 11/4/18 12:16 AM, h...@symas.com wrote: > I don't see this in the deref code. It only returns protocolError if there is > any type of error when parsing the control itself. It was my fault. Sorry for the noise. Please close this ITS. Ciao, Michael.
(ITS#8931) deref'ing non-existent attributes should not result in protocolError
Full_Name: Version: RE24 OS: URL: Submission from: (NULL) (46.183.103.8) In aehostd I try to limit the number of required search requests. Therefore I'm using the deref control to read group and sudoers entries referenced in service groups. If there are no such references (yet) slapd currently returns protocolError. IMO this is wrong. It should simply omit the deref response control and the client has to deal with that. (No, to save round-trips, log-space and data traffic I don't want to read the service groups first to determine whether which deref attributes are present.)
Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message
On 10/26/18 4:21 PM, OndÅej KuznÃk wrote: > Yes, but `key` had already been freed a few lines earlier and using > o_tmpalloc reliably exposes the issue where ch_malloc just masks it. Ouch! > This is now fixed in master. Thanks. Everything now works like a charm also with RE24. Ciao, Michael.
Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message
On 10/26/18 4:01 AM, Quanah Gibson-Mount wrote: > --On Monday, July 30, 2018 6:58 PM + mich...@stroeder.com wrote: > >> Can someone correct the subject line of the ticket? >> >> Should of course mention slapo-unique instead of slapo-constraint. > > This patch has been applied to OpenLDAP HEAD with a correction to the > memory allocation functions. I'll discuss with Howard about whether or > not to add it to 2.4.47. With your memory allocation correction, op->o_tmpalloc() and op->o_tmpfree(), this does not work as expected with 2.4.x. It does *not* return the filter used for uniqueness check. (I did not test master yet.) Example for expected diagnostic message (with my original patch applied to 2.4.46): non-unique attributes found with (|(gidNumber=30041)) Result with patch backported from git master using op->o_tmpalloc() and op->o_tmpfree(): non-unique attributes found with non-unique attribute Seems to repeat parts of the buffer? In my original patch the use of ch_malloc() and ch_free() was simply copied from other overlay code. There are many occurences of ch_malloc() and ch_free() throughout the whole code. Does op->o_tmpalloc() and op->o_tmpfree() work correctly in RE24 branch? Ciao, Michael.
Re: (ITS#8922) tls_o bug with OpenSSL 1.1.1
On 10/1/18 6:18 AM, norm.gr...@gemtalksystems.com wrote: > Full_Name: Norman Green > Version: 2.4.45 > > Unfortunately the layout of the BIO_METHOD struct changed in OpenSSL > 1.1.1 and the static initialization is now incorrect: CHANGES of release 2.4.46 contains this: -- snip -- OpenLDAP 2.4.46 Release (2018/03/22) [..] Fixed libldap OpenSSL 1.1.1 compatibility with BIO_method (ITS#8791) -- snip -- So your report might be a duplicate of this: https://www.openldap.org/its/index.cgi?findid=8791 Ciao, Michael.
Re: (ITS#8892) ISC dhcpd cannot start TLS session to 389-DS after updating openldap rpm
On 8/6/18 4:42 PM, kre...@i3.cz wrote: > ISC dhcp server cannot start TLS session to 389 Directory server after > updating > openldap from 2.4.44-5 to newist version. > Error: Cannot start TLS session to 10.0.252.31:389: Connect error > > dhcpd version: 4.2.5-68 > 389-ds-base verson: 1.3.7.5-21 > > When I try manually copy old libraries (liblber, libldap, libslapi) back to > updated system, dhcpd works fine with TLS to 389-DS. > > We can disable TLS by "ldap-ssl off" option at /etc/dhcp/dhcpd.conf as a > workaround. The ITS is only for reporting bugs. Please post your questions on the openldap-technical mailing list: https://www.openldap.org/lists/mm/listinfo/openldap-technical Ciao, Michael.
Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
Can someone correct the subject line of the ticket? Should of course mention slapo-unique instead of slapo-constraint.
Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
see also ITS#7738
Re: (ITS#7738) RFE slapo-constraint: List non-unique attrs in diagnostic message
Related to ITS#8866.
Re: (ITS#8884) enabling overlay slapo-rwm makes 'entryDN' invisible
I really wonder why function rwm_attrs() is called with stripEntryDN = 1. A comment indicates the front-end generates 'entryDN'. BTW: The database uses back-mdb. I did not test whether it behaves differently with back-hdb yet.
(ITS#8884) enabling overlay slapo-rwm makes 'entryDN' invisible
Full_Name: Version: 2.4.46 OS: URL: Submission from: (NULL) (213.240.182.45) Enabling slapo-rwm for a database makes operational attribute 'entryDN' invisible (tested with rootdn). It's sufficient to add this line to the database section: overlay rwm IMO this is a serious bug.
Re: (ITS#8882) Null Attribute Value Overlay
This is a cryptographically signed message in MIME format. --ms030107030309090109010404 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 07/24/2018 11:17 AM, tamim.z...@daasi.de wrote: > The eds overlay eliminates empty values of type directory string > (OID 1.3.6.1.4.1.1466.115.121.1.15) from the list of the values in the > following manner: >=20 > =C3=82=C2=A0=C3=82=C2=A0=C3=82 ^ (Jitterbug has big deficiencies processing Unicode chars in e-mails.=20 I've reformatted what came through.) Sorry, for nit-picking a bit: > - add: All empty attribute values will be removed before the add reque= st >is executed What happens if after removing all empty values there are no attributes=20 at all anymore? Is the add operation still processed or just internally=20 abandoned/canceled? > - mod-replace: A replace with empty values will be modified to a repla= ce >without values. As result the attribute will be deleted Maybe it's just a wording issue. But I understand "As result the=20 attribute will be deleted" that the attribute in the target entry is=20 removed. What happens exactly if all empty values are removed from a MOD_REPLACE=20 attribute list? Is the MOD_REPLACE for this attribute removed from the=20 modify operation? This would mean no change to the target entry. Or do you remove the attribute in the entry? > - mod-add: All empty attribute values will be removed before the mod-a= dd >request is executed "mod-add request" is a bit blurry: What happens exactly if all empty values are removed from a MOD_ADD=20 attribute list? Is the MOD_ADD for this attribute removed from the=20 modify operation? > - mod-delete: All empty attribute values will be removed before the >mod-delete request is executed Again: What happens exactly if all empty values are removed from a=20 MOD_DEL attribute list? Is the MOD_DEL for this attribute removed from the modify operation? Or is the MOD_DEL processed with empty attribute list? IMO this would be harmful because it would alter the processing in a way = probably not intended by the client. I vaguely remember that this is meant to deal with broken clients and=20 I'm concerned that following the README all clients are affected by this = special processing. Wouldn't it make sense to limit the functionality to = a defined group of broken LDAP clients (by group membership, peer=20 address check or similar)? Ciao, Michael. --ms030107030309090109010404 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 Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFA
Re: (ITS#8882) Null Attribute Value Overlay
On 07/24/2018 10:09 AM, tamim.z...@daasi.de wrote: > I miserably lost the fight against your ticket system! No way to modify > anything as guest user and no way to create/register a new user as > described in the Jitterbug help pages. Could you please tell me how I > can modify an issue or where I can find a description how to proceed? You can only add new messages to tickets, mainly by a simple follow-up e-mail preserving the e-mail subject. From my understanding this is also the accepted way to add an IPR notice after initial submission. Ciao, Michael.
(ITS#8879) remove stale link in admin guide
Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.182.26) There is a stale link in this section of the admin guide: https://www.openldap.org/doc/admin24/overlays.html#Password%20Policy%20Configuration Points to https://symas.com/blog/?page_id=66 which says "No Results Found" In general the admin guide should IMO not point to volatile external resources.
Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
On 06/20/2018 01:25 PM, Michael Ströder wrote: > This patch is meant to enhance user experience in case a client software > is used to maintain data directly via LDAP. This is a real-world issue. > > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch > > > Also cleanly applies to RE24 and therefore > could be easily added to upcoming release 2.4.47. ;-) Any chance to see this in 2.4.47? It simply works and the patch was also reviewed by another C programmer. Ciao, Michael.
Re: (ITS#8867) ldap_sasl_bind_s failed error during replication
The ITS is for reporting bugs only. Please subscribe to the openldap-technical mailing list and post your usage questions there: https://www.openldap.org/lists/mm/listinfo/openldap-technical Ciao, Michael.
Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
On 06/20/2018 01:41 PM, Michael Ströder wrote: > Ouch! This was not yet complete. I'll come up with a new revision soon. Please review this patch: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch Disclaimer: I'm not a C programmer. Thanks for your patience. Ciao, Michael.
Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
On 06/20/2018 01:26 PM, mich...@stroeder.com wrote: > Find the patch against master here: > https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch Ouch! This was not yet complete. I'll come up with a new revision soon. Ciao, Michael.
Re: (ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
Rationale: This patch is meant to enhance user experience in case a client software is used to maintain data directly via LDAP. This is a real-world issue. Find the patch against master here: https://www.stroeder.com/temp/0001-ITS-8866-slapo-unique-to-return-filter-used-in-diagn.patch Also cleanly applies to RE24 and therefore could be easily added to upcoming release 2.4.47. ;-)
(ITS#8866) RFE: slapo-constraint to return filter used in diagnostic message
Full_Name: Version: OS: URL: Submission from: (NULL) (213.240.182.62) See motivation and disclosure considerations in list archive: https://www.openldap.org/lists/openldap-devel/201711/msg3.html Patch will follow.
Re: (ITS#8846) Patch to introduce new LDAP option to ignore hostname checking while verifying certificates in TLS mode
> c)DNS server is not set up I.e., the certificate could be issued > with a name like ânetact.operatorâ, but weâd be using 10.2.3.7, and > DNS has not been setup in the operator internal network > > But what we feel is that there should be an option to be chosen by > user to either ignore or enable hostname checking. If you're using ldaps://10.2.3.7 for connecting without DNS resolving you could add a subjectAltName extension to your server cert containing this particular IP address. That's basically just another GeneralName type. You could also tweak your local /etc/hosts (preferrably with decent config mgt.) to correctly map FQDN "netact.operator" to the IP address. > Already we know > that HTTP clients, for example, browsers provide such option to user > and it's up to the user that whether to continue communication to the > server or not, if hostname mismatch occurs. Note that web browsers are driven interactively by users whereas LDAP clients are most times systems without direct user interaction. In the interactive case you simply delegate the informed trust decision to the user which is a bad thing to do anyway. Therefore web browsers will also limit this functionality in the not so far future. Ciao, Michael. P.S.: Due to MIME processing deficiencies of the ITS your messages are displayed base64-encoded and therefore hard to read: https://www.openldap.org/its/index.cgi?findid=8846#followup4
Re: (ITS#8847) New LDAP URL syntax to support binding to specific IP address at client side
h...@symas.com wrote: > r...@openldap.org wrote: >> On Sun, May 06, 2018 at 01:50:23PM +, arekk...@r42.ch wrote: >>> Adding a source IP to an URI feels wrong to it. >>> >>> I have not read RFC dealing with URI, however having a quick look [1] seems >>> to >>> indicate that using the at sign in this way is non-standard. >> >> I agree. @ in URIs is already defined as separating credentials (or just >> username) from the host. I don't recall whether OpenLDAP supports that >> usage but in any case we shouldn't re-define it. > > Agreed. URI syntax is pretty thoroughly specified in multiple RFCs, nobody > can > just arbitrarily decide to change it. And the point of a URI is that it is > valid for a destination no matter who/where the source is. > > This patch completely breaks the function and intent of URIs. IMO having the capability to specify the source IP is very useful in multi-homed host setups with strict network security. But of course one should not invent new URL syntax or abuse existing definitions. RFC 4516 indeed specifies LDAP URL extensions and this should be used. This also has the advantage that e.g. python-ldap's LDAP URL parser can also be used for that. Ideally one could write a very short I-D for such an extension. Ciao, Michael.
Re: (ITS#8816) OpenLDAP - Embedded Prodcut or Stand-alone product
muthamma.appa...@wellsfargo.com wrote: > Full_Name: Muthamma > Version: OpenLDAP latest > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:160:e708:6::a) > > > Hi team, > > Could you confirm if the product OpenLDAP is a stand-alone product or > embedded? > > If this comes bundled with any other product? ITS is only used for reporting bugs. Please ask such a question on the openldap-technical mailing list. And please do not file the same question several times. Ciao, Michael.
Re: (ITS#8812) OpenLDAP 2.4 Standalone or embedded
muthamma.appa...@wellsfargo.com wrote: > Full_Name: Muthamma > Version: 2.4 and 2.3 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2620:160:e708:6::a) > > > Hi team, > > Could you confirm if the product OpenLDAP is a stand-alone product or > embedded? ITS is only used for reporting bugs. Please ask such a question on the openldap-technical mailing list. Ciao, Michael.
Re: (ITS#8618) ldapsearch - unexpected behavior with
Alexandre Rosenberg wrote: > Micheal, you are *right* about the man page saying _hostname_. Indeed OpenLDAP > only accepting hostname as per best practice/RFC might be the most correct > behavior. There is no relevant RFC or best practice, only the man-page. And the -h and -p arguments come from the old UMich LDAP times. > However we can not change this behavior without breakable. consider: AFAICS backward compability has only be provided to those ancient Umich or Netscape Directory tools. So IMO LDAP URI does not have to be accepted. > - Underscore are not that uncommon with Active Directory > - What about internationalized DNS name > - ... (probably more) If you want to fix something for 2.4.x to match what the man-page says you could effectively reject LDAP URI by simply rejecting colons and slashes. Those chars are never in even seriously broken hostnames. If they were they would cause more interop issues anyway. > Therefore I believe such change could only be done in a major release. And at > that point we might just remove the depreciated '-h' option altogether. Agreed. 2.5 release chould IMO simply remove options -h and -p. Ciao, Michael.
Re: (ITS#8618) ldapsearch - unexpected behavior with
andrew.lawre...@siemens.com wrote: > I believe the following patch addresses this problem. I am still a > bit conf used about what constitutes a DNS name. Alex has suggested > they should contain an underscore. My colleague who reviewed the code > had a different opinion. Disclaimer: Since I'm not a C programmer I did not really review your patch in detail but just want to add some general notes. 1. Reviewing this ticket my impression is that the only problem is that -h also accepts a LDAP URI because -H should be used instead. IIRC -h was only meant to take an IP address or hostname. Therefore I'd strongly recommend to simply reject an LDAP URI for -h. Is that your goal? 2. The term "DNS name" is a bit too blurry. In case of option -h it should be an IP address or _hostname_. And according to best practices hostnames SHOULD NOT contain underscores. Whether you _allow_ underscores to accommodate some strange setups is your decision. Ciao, Michael.
Re: (ITS#8785) Password quality/Strength check
This is a cryptographically signed message in MIME format. --ms020404010102000204010800 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable kashyap_sun...@ongc.co.in wrote: > We have successfully implemented existing password policy in our DIT bu= t the > most required feature of password strength is missing in existing overl= ay.=20 > Can you suggest that how we could implement password quality/strength i= n this > version of openldap. The ITS is for reporting bug only. Please post usage questions to openldap-technical mailing list where you reach more recipients. So others can answer and learn as well. https://www.openldap.org/lists/ Ciao, Michael. --ms020404010102000204010800 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 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGF
Re: (ITS#8786) Allow OpenLDAP to start as non-root
This is a cryptographically signed message in MIME format. --ms040106020009060205040508 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable akram.benai...@gmail.com wrote: > We want to run OpenLDAP in containers without root privilege, nor root = user id. > Actually, we start it with user uid=3D10009, gid=3D0 AFAICT and independent of OpenLDAP's slapd allowing an arbitrary uid to use gid=3D0 would be an unauthorized privilege escalation / security hole= =2E Why don't you use the primary gid of uid=3D10009? Ciao, Michael. --ms040106020009060205040508 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDx
Re: (ITS#8776) lessOrEqual does not work as expected
This is a cryptographically signed message in MIME format.
--ms080105080402020204000104
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
kristianmcc...@hotmail.com wrote:
> Full_Name: Kristian McColm
> Version: slapd 2.4.40
Did you also test with a newer release?
> With an attribute type defined in the schema and index as per the below=
, and the
> value of the attribute set to 0, the lessOrEqual filter does not work a=
s
> expected.
It works for me.
Example filter (aeStatus<=3D1) also finds entries with (aeStatus=3D0):
https://demo.ae-dir.com/web2ldap?ldapi://%2Fopt%2Fae-dir%2Frun%2Fslapd%2F=
ldapi/cn=3Dtest,ou=3Dae-dir??sub?(aeStatus<=3D1)?bindname=3Duid%3Dzots%2C=
cn%3Dtest%2Cou%3Dae-dir,X-BINDPW=3DCorrectHorseBatteryStaple
(This is an OpenLDAP 2.4.45 server but this worked for me with older
releases too.)
> Schema attribute:
> olcAttributeTypes: {1} ( NAME 'num' DESC 'Numeric Attribute' SYNT=
AX
> 1.3.6.1.4.1.1466.115.121.1.27 X-ORIGIN 'user defined' EQUALITY integerM=
atch
> ORDERING integerOrderingMatch )
Did you use as a placeholder or is that value really literally in
your schema? If you used it as a placeholder herein which OID did you
really use?
Did you eventually changed index-related schema config without re-indexin=
g?
Ciao, Michael.
--ms080105080402020204000104
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/m48jp4AiFXgvxprJrW7izsyet
Re: (ITS#8767) Binddn issue with a comma in the DN
clement.ou...@savoirfairelinux.com wrote: > I confirm there is no bug, but the escaping is a little weird, as we need two > \\ to escape the , character. IMHO it's not weird because for escaping the comma in DN string representation you need the first back-slash which you have to escape once more for config syntax. Ciao, Michael.
Re: (ITS#8770) dsaschema seg faults
Canned config available:
https://stroeder.com/temp/openldap-testbed-its8770.tar.gz
Seg faults with 2.4.45 and current RE24 branch:
$ cd openldap-testbed-its8770
$ ./start-slapd.sh
[..]
5a009864 slapd.conf: line 19 (moduleloadback_mdb)
5a009864 loaded module back_mdb
5a009864 mdb_back_initialize: initialize MDB backend
5a009864 mdb_back_initialize: LMDB 0.9.21: (June 1, 2017)
5a009864 module back_mdb: null module registered
5a009864 slapd.conf: line 22 (moduleload dsaschema.so
schema/oath-ldap-dsa.schema)
5a009864 loaded module dsaschema.so
./start-slapd.sh: line 11: 29304 Segmentation fault (core dumped)
${OPENLDAP_PREFIX}/lib64/slapd -d
config,stats,stats2,acl,args,trace,sync -h "ldap://0.0.0.0:2071
ldapi://slapd1-socket" -n slapd-its8770 -f slapd.conf
(ITS#8770) dsaschema seg faults
Full_Name: Version: RE24 OS: URL: Submission from: (NULL) (213.240.182.108) This leads to a seg fault: moduleload dsaschema.so /home/michael/Proj/oath-ldap/oath-ldap-dsa.schema More information to come...
Re: (ITS#8767) Binddn issue with a comma in the DN
This is a cryptographically signed message in MIME format. --ms06070500090903040904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable christian.palac...@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. --ms06070500090903040904 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/+wq37fU
Re: (ITS#8762) Unlocking an account doesn't remove pwdFailureTime
mihai.munte...@thalesgroup.com wrote: > Scenario: > 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 Please provide the password policy as LDIF. > 2. admin unlocks test1's account and notify test1 user Which exact LDAP operation is done when "admin unlocks test1's account". Are you just removing 'pwdAccountLockedTime'? I'm asking because there might be a misunderstanding how that is supposed to work. In this case it's an usage question better to be discussed on openldap-technical mailing list. Ciao, Michael.
(ITS#8757) RFE: let slapd MMR instances vote primary master
Full_Name: Michael Str.der Version: OS: URL: Submission from: (NULL) (217.145.44.194) In some situations having a "primary" master would be very useful (e.g. where to assign numeric IDs). The providers connected with MMR could try to vote a primary master with the raft algorithm: https://raft.github.io/ Ideally it should be visible in cn=monitor whether a provider replica is the current primary master. Let's discuss this at LDAPcon dinner this evening... ;-)
Re: AW: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g(userAccountControl:1.2.840.113556.1.4.803:=2)
steffen.kr...@nexio.de wrote: > Regarding segmentation fault: that's true, but I have to investigate > further Please make sure to install with debug symbols and read how to use gdb to obtain a stack back trace: https://www.openldap.org/faq/data/cache/59.html Ciao, Michael.
Re: (ITS#8749) Proxy: LDAP-querry doesn't work for e.g (userAccountControl:1.2.840.113556.1.4.803:=2)
This is a cryptographically signed message in MIME format. --ms02070306080901000202 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable steffen.kr...@nexio.de wrote: > I'm using OpenLDAP with LDAP-backend as proxy for ActiveDirectory=20 > It's working well so far, only LDAP-queries which should exclude > deactivated users don't work. It seems slapd does not accept queries > like (attribute:OID:=3Dvalue) OpenLDAP does support extended filters with a matching rule. But only with matching rules implemented in OpenLDAP. > in particular > (!(userAccountControl:1.2.840.113556.1.4.803:=3D2))) The matching rule defined by 1.2.840.113556.1.4.803 is a proprietary matching rule defined by Microsoft for bit-wise matching. AFAICS they never wrote a public formal spec for it. So this particular matching rule is not implemented in OpenLDAP. > performing upper query gets: Oct 1 00:45:33 nxld01 slapd[3002]: > str2filter "(&(sAMAccountType=3D 805306368)(?=3Derror))" Oct 1 00:45:3= 3 > nxld01 kernel: [49436.933735] slapd[3005]: segfault at 18 ip=20 > 7ff4f783d512 sp 7ff4f1afc810 error 4 in=20 > libc-2.23.so[7ff4f77b9000+1c] Does that mean slapd seg faults? It shouldn't. > performing the following query > (&(objectClass=3D*)(userAccountControl:1.2.840.113556.1.4.803:=3D2)) > will get following log wntry: > Oct 1 00:49:07 nxld01 slapd[3033]: str2filter > "(&(objectClass=3D*)(!(objectClass=3D*)))" IMO it makes perfect sense to treat extended filter part with a non-supported matching rule as a filter which always evaluates to False. Ciao, Michael. --ms02070306080901000202 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 LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OB
Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
c...@opensides.be wrote: > I'm not sure I understand the outcome of the discussion > here, why i s 1.3.6.1.4.1.42.2.27.8.5.1 absent from the > supportedControl returned by the rootDSE? > (1.3.6.1.4.1.42.2.27.8.5.1 being > LDAP_CONTROL_PASSWORDPOLICYREQUEST) This prevents client to > know that the server supports ppolicy. Frankly I can't imagine how to make it more clear than I already did. Please re-read my follow-up here: https://www.openldap.org/its/index.cgi?findid=8208#followup2 Especially note that the original poster did *not* mention OID 1.3.6.1.4.1.42.2.27.8.5.1 to be missing. (It's present in all my OpenLDAP servers.) The original poster asked for another outdated password policy mechanism. Ciao, Michael.
Re: (ITS#8735) Significant delay setting LDAP_OPT_X_TLS_REQUIRE_CERT with invalid DNS
sean.ha...@vertivco.com wrote: > I'm seeing a significant delay (32s) when setting > `LDAP_OPT_X_TLS_REQUIRE_CERT` with unreachable DNS servers in > resolv.conf. We initially discovered the issue in 2.4.42 > although I've confirmed it is present in 2.4.45. AFAIK it is > not present in 2.4.23. I assume you see a delay at the client-side. Are you sure that it is not something caused by the TLS library updated in the mean-time? Which one is used by the client? You should re-test with server certs without any URLs (AIA, CRLDP extensions etc.) which might be accessed by your TLS lib. You could also monitor the DNS traffic. Some resolvers allow to switch on query logging. Or tcpdump or similar. And BTW: The most likely answer is that your resolver should always be up and running. Sometimes a local caching resolver helps to overcome upstream resolver outage. Ciao, Michael.
Re: (ITS#8707) slapd: Add systemd service notification support
Howard Chu wrote: > If no one has any other reasons to offer, I'm inclined to reject > and close this ITS. Note that the systemd unit file was only a little detail in this ITS. The most important part is the C code change. Ciao, Michael.
Re: (ITS#8707) slapd: Add systemd service notification support
r...@nardis.ca wrote: > An explicit design goal of systemd is that unit files should be > uniform enough that it's reasonable for upstream projects to > ship them, Yes, systemd has many admirable goals. On the other hands Linux distributions differ a lot especially regarding file system layout, not to speak of their systemd back-port patches. Ciao, Michael. P.S.: Right at this moment I'm trying to figure out the appropriate Requires and After lines in systemd unit file template in Ã-DIR's ansible role. And the ansible role has only support for three (and a half) different Linux distributions [1]. [1] https://www.ae-dir.com/install.html#prereq
Re: (ITS#8707) slapd: Add systemd service notification support
qua...@symas.com wrote: > b) The OpenLDAP project has never provided init scripts of > their equivalents. I'm not sure it would be correct to include > the systemd unit file as a part of the project. I also suspect that many Linux distributions are picky regarding their own systemd flavors. My suggestion would be to provide an example systemd unit file as documentation. Ciao, Michael.
Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
Is there anything wrong with the patch herein?
Re: (ITS#8703) slapd should create its PID file before dropping privileges
On 09/06/2017 09:29 AM, Howard Chu wrote: > > Learn something about Unix, please. > > Use the ps command to verify that the process at least has the correct name. > The init script should know it's looking for a process named slapd, not init. > Supposing we want to copy/paste two or more "ps" calls into every slapd init script, this still lets a hacker prevent his own hacked process from being killed by writing junk into the file. If the standard practice was to write the PID file as an unprivileged user, we would need to not only copy/paste those "ps" calls into every slapd init script, but literally every init script for every daemon. Apparently my predecessors didn't want to do that, so the standard practice is to write the PID file as root. Do with that information what you will.
Re: (ITS#8703) slapd should create its PID file before dropping privileges
On 09/06/2017 08:29 AM, Howard Chu wrote: > >> 4. Someone compromises the daemon, which sits on the open network. > > Nobody compromises slapd from the network. There are no buffer overflow > vulnerabilities, there are no RCE vulnerabilities. > Oh, it's one of /those/ daemons. >> >> 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate >>the weird behavior resulting from the hack. > > Even if that were possible, it's clearly a bug in the init script, which > failed to check that the process with that PID was the process it was > expecting to find. Note that this is something any init script needs to do > anyway, since PID files can go stale and some other process may be using the > PID by the time you reference the file. Have you ever seen such an init script? How should the init system know what process it was expecting to find, if not by reading that process's PID from the PID file? If you decide not to write the PID file as root, that's of course up to you, but I still have to tell something to the people who ship OpenLDAP as part of their distributions. I can tell them "Howard says it should be easy," but considering that no one has ever done it, that's not real helpful advice. There are only two requirements really: it needs to be portable POSIX sh, and the stop() function must only kill the one process created by start(). If you give that a shot, you might see why I suggested that this be fixed in slapd.
Re: (ITS#8703) slapd should create its PID file before dropping privileges
On 09/05/2017 05:38 PM, Ryan Tandy wrote: > > If you would like to propose a patch, we could review that. For myself I > don't think I would attach a high priority to this. I understand that it's a low priority, I'm just trying to clean up the hundred or so cases of this that we have in Gentoo. In a few, it's impossible to do so because of the way the daemon creates the PID file (like it is here), so I'm doing bugs/CVEs to keep track of them. This way that distribution maintainers have something to watch and will know when they can fix their init scripts. > Howard pointed out on IRC that if the directory containing the pid file > is sticky, making it owned by root means slapd can no longer remove it > on exit. I'm not sure how common that is but it's a setup that works > right now. Typically the PID file would go directly in /run (or /var/run) and be owned by root. That means that you can't clean it up when the daemon exits, but no one expects a daemon to do that. Practically, the PID file exists solely for the benefit of init systems. Given the choice between, 1. How do I determine if I can trust the contents of this file owned by an untrusted user? 2. How do I remove the PID file after killing the daemon? the second is much easier to do. The first is next to impossible to get right; so if we have to pick one, that's the way to go IMO.
Re: (ITS#8714)
mich...@stroeder.com wrote: > If you don't mind I just produce another follow-up patch for the > man-page. Find this man-page patch here: https://www.stroeder.com/temp/0001-ITS-8714-man-page-corrections-regarding-EXTENDED-ope.patch Ciao, Michael.
Re: (ITS#8703) slapd should create its PID file before dropping privileges
This has been assigned CVE-2017-14159.
Re: (ITS#8714)
Howard Chu wrote: > You could add a LIMITATIONS section, as slapd-monitor.5 and > slapd-shell.5 does. The manpage now needs an update to note that > the exop value is base64 encoded. Also, since it is encoded, I > don't believe it's necessary to explicitly send the valuelen. Ah, yes. Forgot to update the message format in the man-page. If you don't mind I just produce another follow-up patch for the man-page. Ok? Ciao, Michael.
Re: (ITS#8714)
h...@symas.com wrote: > There's a weird indent at extended.c:50 or so, the if() > statement. > > Would be better to use op->o_tmpalloc instead of ber_memalloc > since you'r= e=20 immediately freeing the buffer again anyway. > > I can fix those here if you don't care. Yes, I'd highly appreciate if you simply adjust it to your coding style. One additional point: Currently the external program is not able to produce a custom extended operation response. Mainly it should always return CONTINUE or an error response. I wanted to make this limitation clear in the man-page but was unsure about the appropriate section. Ciao, Michael.
Re: (ITS#8714)
This is a cryptographically signed message in MIME format. --ms020207030808080005010306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Howard Chu wrote: > Your patch is missing extended.c Aargh! Corrected herein: https://www.stroeder.com/temp/0001-ITS-8714-Send-out-EXTENDED-operation-m= essage-from-back-sock_rev3.patch Ciao, Michael. --ms020207030808080005010306 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwOTA1MTM1NjA1WjAvBgkq hkiG9w0BCQQxIgQg8GCP1w5NtTSxcpwIYyPNKa+KPNyCIiZ5C20j5QlpXN0wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGC
Re: (ITS#8714) RFE: Sendout EXTENDED operation message in back-sock
Howard Chu wrote:
> mich...@stroeder.com wrote:
>> +/* write out the request to the extended process */
>> +fprintf( fp, "EXTENDED\n" );
>> +fprintf( fp, "msgid: %ld\n", (long) op->o_msgid );
>> +sock_print_conn( fp, op->o_conn, si );
>> +sock_print_suffixes( fp, op->o_bd );
>> +fprintf( fp, "oid: %s\n", op->ore_reqoid.bv_val );
>> + if (op->ore_reqdata) {
>> +fprintf( fp, "valuelen: %lu\n", op->ore_reqdata->bv_len );
>> +fprintf( fp, "value: %s\n", op->ore_reqdata->bv_val );
>> +}
>> +fprintf( fp, "\n" );
>
> This isn't safe. The reqdata is binary, not a nul-terminated C string. I
> suppose you
> could hex or base64-encode it instead.
Frankly I don't understand.
I considered using base64 but I wanted to stick to what's already done in
back-sock.
See openldap/servers/slapd/back-sock/bind.c for the password value which is
also an
arbitrary OctetString:
/* write out the request to the bind process */
[..]
fprintf( fp, "credlen: %lu\n", op->oq_bind.rb_cred.bv_len );
fprintf( fp, "cred: %s\n", op->oq_bind.rb_cred.bv_val ); /* XXX */
fprintf( fp, "\n" );
The above should also work with null-bytes, shoudn't it?
Ciao, Michael.
Re: (ITS#8714) RFE: Sendout EXTENDED operation message in back-sock
This is a multi-part message in MIME format.
--4BA376E6A3936AB8C247B47A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
The attached patch file is derived from OpenLDAP Software. All of the
modifications to
OpenLDAP Software represented in the following patch(es) were developed by
Michael
Ströder <mich...@stroeder.com>. I have not assigned rights and/or interest in
this work
to any party.
I, Michael Ströder, hereby place the following modifications to OpenLDAP
Software (and
only these modifications) into the public domain. Hence, these modifications
may be
freely used and/or redistributed for any purpose with or without attribution
and/or other
notice.
This patch can also be found here:
ftp://ftp.openldap.org/incoming/0001-ITS-8714-Send-out-EXTENDED-operation-message-from-back-sock.patch
--4BA376E6A3936AB8C247B47A
Content-Type: text/x-patch;
name="0001-ITS-8714-Send-out-EXTENDED-operation-message-from-back-sock.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename*0="0001-ITS-8714-Send-out-EXTENDED-operation-message-from-back-";
filename*1="sock.patch"
=46rom 732c5646e0a03be8b58e52527b25742f0495807e Mon Sep 17 00:00:00 2001
From: =3D?UTF-8?q?Michael=3D20Str=3DC3=3DB6der?=3D <mich...@stroeder.com>=
Date: Fri, 18 Aug 2017 18:47:41 +0200
Subject: [PATCH] ITS#8714 Send out EXTENDED operation message from back-s=
ock
to external program
---
doc/man/man5/slapd-sock.5| 19 +++-
servers/slapd/back-sock/Makefile.in | 4 +--
servers/slapd/back-sock/config.c | 12 ++--
servers/slapd/back-sock/extended.c | 58 ++=
++
servers/slapd/back-sock/init.c | 2 +-
servers/slapd/back-sock/proto-sock.h | 2 ++
6 files changed, 91 insertions(+), 6 deletions(-)
create mode 100644 servers/slapd/back-sock/extended.c
diff --git a/doc/man/man5/slapd-sock.5 b/doc/man/man5/slapd-sock.5
index 1ac4f7fdd..0c4fc3fdd 100644
--- a/doc/man/man5/slapd-sock.5
+++ b/doc/man/man5/slapd-sock.5
@@ -49,7 +49,7 @@ be sent and from which replies are received.
=20
When used as an overlay, these additional directives are defined:
.TP
-.B sockops [ bind | unbind | search | compare | modify | modrdn | add | =
delete ]*
+.B sockops [ bind | unbind | search | compare | modify | modrdn | add | =
delete | extended ]*
Specify which request types to send to the external program. The default=
is
empty (no requests are sent).
.TP
@@ -115,6 +115,18 @@ dn:
.PP
.RS
.nf
+EXTENDED
+msgid:
+ }>
+oid:
+valuelen: >
+value:
+
+.fi
+.RE
+.PP
+.RS
+.nf
MODIFY
msgid:
}>
@@ -292,6 +304,11 @@ access to the
pseudo_attribute of the searchBase;
.B search (=3Ds)
access to the attributes and values used in the filter is not checked.
+.LP
+The
+.B extended
+operation does not require any access special rights.
+The external program has to implement any sort of access control.
=20
.SH EXAMPLE
There is an example script in the slapd/back\-sock/ directory
diff --git a/servers/slapd/back-sock/Makefile.in b/servers/slapd/back-soc=
k/Makefile.in
index 3e527e545..efb916246 100644
--- a/servers/slapd/back-sock/Makefile.in
+++ b/servers/slapd/back-sock/Makefile.in
@@ -18,9 +18,9 @@
## in OpenLDAP Software.
=20
SRCS =3D init.c config.c opensock.c search.c bind.c unbind.c add.c \
- delete.c modify.c modrdn.c compare.c result.c
+ delete.c modify.c modrdn.c compare.c result.c extended.c
OBJS =3D init.lo config.lo opensock.lo search.lo bind.lo unbind.lo add.l=
o \
- delete.lo modify.lo modrdn.lo compare.lo result.lo
+ delete.lo modify.lo modrdn.lo compare.lo result.lo extended.lo
=20
LDAP_INCDIR=3D ../../../include =20
LDAP_LIBDIR=3D ../../../libraries
diff --git a/servers/slapd/back-sock/config.c b/servers/slapd/back-sock/c=
onfig.c
index dc3f1365c..2dcf68bf6 100644
--- a/servers/slapd/back-sock/config.c
+++ b/servers/slapd/back-sock/config.c
@@ -106,6 +106,7 @@ static ConfigOCs osocs[] =3D {
#define SOCK_OP_MODRDN 0x020
#define SOCK_OP_ADD0x040
#define SOCK_OP_DELETE 0x080
+#define SOCK_OP_EXTENDED 0x100
=20
#define SOCK_REP_RESULT0x001
#define SOCK_REP_SEARCH0x002
@@ -127,6 +128,7 @@ static slap_verbmasks ov_ops[] =3D {
{ BER_BVC("modrdn"), SOCK_OP_MODRDN },
{ BER_BVC("add"), SOCK_OP_ADD },
{ BER_BVC("delete"), SOCK_OP_DELETE },
+ { BER_BVC("extended"), SOCK_OP_EXTENDED },
{ BER_BVNULL, 0 }
};
=20
@@ -249,7 +251,9 @@ static BI_op_bind *sockfuncs[] =3D {
sock_back_modify,
sock_back_modrdn,
sock_back_add,
- sock_back_delete
+ sock_back_delete,
+ 0,/* abandon not supported */
+ sock_back_extended
};
=20
static const int sockopflags[] =3D {
@@ -260,7 +264,9 @@ static const
Re: (ITS#8712) haproxy
dup of ITS#8711
Re: (ITS#8703) slapd should create its PID file before dropping privileges
The problem scenario looks like the following: 1. I run "/etc/init.d/slapd start" to start the daemon. 2. slapd drops to the "slapd" user. 3. slapd writes its PID file, now owned by the "slapd" user. 4. Someone compromises the daemon, which sits on the open network. 5. The attacker is generally limited in what he can do because the daemon doesn't run as root. However, he can write "1" into the slapd.pid file, and he does. 6. I run "/etc/init.d/slapd stop" to stop the daemon while I investigate the weird behavior resulting from the hack. 7. Oops, the machine reboots, because I killed PID 1.
(ITS#8703) slapd should create its PID file before dropping privileges
Full_Name: Michael Orlitzky Version: 2.4.45 OS: Gentoo URL: Submission from: (NULL) (98.218.46.55) The slapd daemon should create its PID file before dropping privileges. This represents a minor security issue; additional factors are needed to make it exploitable. Why? The purpose of the PID file is to hold the PID of the running daemon, so that later it can be stopped, restarted, or otherwise signalled (many daemons reload their configurations in response to a SIGHUP). To fulfill that purpose, the contents of the PID file need to be trustworthy. If the PID file is writable by a non-root user, then he can replace its contents with the PID of a root process. Afterwards, any attempt to signal the PID contained in the PID file will instead signal a root process chosen by the non-root user (a vulnerability). This is commonly exploitable by init scripts that are run as root and which blindly trust the contents of their PID files. If one daemon flushes its cache in response to SIGUSR2 and another daemon drops all connections in response to SIGUSR2, it is not hard to imagine a denial-of-service by the user of the first daemon against the second.
Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message (unsigned)
(Re-sent without S/MIME sign. for better readability in ITS)
This seems really trivial to fix - even for me. ;-)
I've successfully tested it with Python module slapdsock (and ldif module in
python-ldap
2.4.41+).
I, Michael Ströder, hereby place the following modifications to OpenLDAP
Software (and
only these modifications) into the public domain. Hence, these modifications
may be
freely used and/or redistributed for any purpose with or without attribution
and/or other
notice.
https://www.stroeder.com/temp/0001-ITS-8692-let-back-sock-generate-increment-line.patch
---
>From 6c37844c5c52b95aff5e4e547cda8a7258e92a35 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Michael=20Str=C3=B6der?= <mich...@stroeder.com>
Date: Wed, 12 Jul 2017 20:18:22 +0200
Subject: [PATCH] ITS#8692 let back-sock generate increment: line in case of
LDAP_MOD_INCREMENT (see RFC 4525, section 3)
---
servers/slapd/back-sock/modify.c | 4
1 file changed, 4 insertions(+)
diff --git a/servers/slapd/back-sock/modify.c b/servers/slapd/back-sock/modify.c
index c35d31bc6..9342d2702 100644
--- a/servers/slapd/back-sock/modify.c
+++ b/servers/slapd/back-sock/modify.c
@@ -85,6 +85,10 @@ sock_back_modify(
case LDAP_MOD_REPLACE:
fprintf( fp, "replace: %s\n",
mod->sm_desc->ad_cname.bv_val );
break;
+
+ case LDAP_MOD_INCREMENT:
+ fprintf( fp, "increment: %s\n",
mod->sm_desc->ad_cname.bv_val );
+ break;
}
if( mod->sm_values != NULL ) {
--
2.13.2
Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
This is a cryptographically signed message in MIME format.
--ms070903000906000403080407
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
This seems really trivial to fix - even for me. ;-)
I've successfully tested it with Python module slapdsock (and ldif module=
in python-ldap
2.4.41+).
I, Michael Str=C3=B6der, hereby place the following modifications to Open=
LDAP Software (and
only these modifications) into the public domain. Hence, these modificati=
ons may be
freely used and/or redistributed for any purpose with or without attribut=
ion and/or other
notice.
https://www.stroeder.com/temp/0001-ITS-8692-let-back-sock-generate-increm=
ent-line.patch
-=
--
=46rom 6c37844c5c52b95aff5e4e547cda8a7258e92a35 Mon Sep 17 00:00:00 2001
From: =3D?UTF-8?q?Michael=3D20Str=3DC3=3DB6der?=3D <mich...@stroeder.com>=
Date: Wed, 12 Jul 2017 20:18:22 +0200
Subject: [PATCH] ITS#8692 let back-sock generate increment: line in case =
of
LDAP_MOD_INCREMENT (see RFC 4525, section 3)
---
servers/slapd/back-sock/modify.c | 4
1 file changed, 4 insertions(+)
diff --git a/servers/slapd/back-sock/modify.c b/servers/slapd/back-sock/m=
odify.c
index c35d31bc6..9342d2702 100644
--- a/servers/slapd/back-sock/modify.c
+++ b/servers/slapd/back-sock/modify.c
@@ -85,6 +85,10 @@ sock_back_modify(
case LDAP_MOD_REPLACE:
fprintf( fp, "replace: %s\n",
mod->sm_desc->ad_cname.bv_val );
break;
+
+ case LDAP_MOD_INCREMENT:
+ fprintf( fp, "increment: %s\n",
mod->sm_desc->ad_cname.bv_val );
+ break;
}
if( mod->sm_values !=3D NULL ) {
--=20
2.13.2
--ms070903000906000403080407
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
BQcwAYYYaHR
(ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
Full_Name: Version: OS: URL: Submission from: (NULL) (85.115.23.42) back-sock does not generate a MODIFY message with "increment:" line when LDAP clients sends modify operation with LDAP_MOD_INCREMENT. Example of incomplete message (incrementing attribute gidNumber): - snip - MODIFY msgid: 119 binddn: uid=msin,cn=ae,ou=ae-dir peername: PATH=/usr/local/openldap/var/run/ldapi ssf: 256 connid: 1025 suffix: ou=ae-dir dn: ou=ae-dir gidNumber: 1 - - snip -
Re: (ITS#8677) back-sock segfaults on CONTINUE (database sock)
h...@symas.com wrote:
>> When using back-sock (database sock) and the external sock listener returns
>> CONTINUE then slapd seg faults.
>>
>> Yes, returning CONTINUE is only allowed when using back-sock as overlay.
>> But slapd should not seg fault and rather return as LDAP result:
>
> No. This is a configuration error and it's appropriate to halt the server and
> force it to be fixed.
Even if I follow your argument this message does not look like the server was
deliberately halted:
slapd: result.c:83: sock_read_and_send_results: Assertion `si->si_ops != 0'
failed.
./start-slapd.sh: line 21: 30179 Aborted (core dumped)
${OPENLDAP_EXEC}
-d stats,shell -h "ldap://0.0.0.0:9876 ${LDAPI_URI}" -n slapd-sock-test -f
slapd.conf
Also the args and PID files are not cleaned up. I guess database environment(s)
of other
backend(s) is/are also not closed in a controlled manner.
So at least it should properly log a message and shutdown cleanly.
Ciao, Michael.
(ITS#8677) back-sock segfaults on CONTINUE (database sock)
Full_Name: Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (213.240.182.98) When using back-sock (database sock) and the external sock listener returns CONTINUE then slapd seg faults. Yes, returning CONTINUE is only allowed when using back-sock as overlay. But slapd should not seg fault and rather return as LDAP result: result: 80 Other (e.g., implementation specific) error text: CONTINUE not allowed for back-sock
Re: (ITS#8669) Slapd service becomes unresponsive intermittently
qua...@symas.com wrote: >> Is it possible we have the idletimeout set too high and it should be >> lowered? I=C2=B9m wondering if there is some sweet-spot value for this >> particular setting. > > I generally leave it unset unless one is encountering an issue of running > out of connections. Generally, it would be fairly strange for idletimeout > to affect things this way at all. I generally recommend to set idletimeout even somewhat tight in case you don't have a strictly defined set of clients. Because a client application which does not use its LDAP connection for ~5 min. is most times simply not closing connections. And running out of file handles can affect all file creation on your system (e.g. creating BDB's transaction log files). Only the original poster can find out with monitoring. One can find out stale connections via back-monitor in sub-tree cn=Connections,cn=Monitor. IITC attribute 'monitorConnectionActivityTime' contains last client access time on this connection. (Ummh, I have to add this to my own monitoring script...) And of course normal system monitoring of file handles would be also helpful. Ciao, Michael. (Keep repeating this mantra: monitoring, monitoring, monitoring, monitoringâ¦)
Re: (ITS#8669) Slapd service becomes unresponsive intermittently
jmestrad...@gmail.com wrote: > Our server vendor did the upgrade to version 2.4.39 last year in April. In > asking them about upgrading to a newer version, as a potential fix, I was > told the last version in the RHEL repository that they can upgrade to is > 2.4.40. They seem to just recommend what seems to be the easiest choice for them and not what would be the recommended choice for *you*. RHEL packages are heavily patched by Red Hat and generally not recommended. The upstream developers cannot oversee what's the current patch state of RHEL packages. => You should kick out your server vendor from doing the OpenLDAP support. Ciao, Michael.
Re: (ITS#8659) accesslog man page updates
qua...@symas.com wrote: > Seems like it would have been better to leave audit* attrs with slapo-auditlog I was not aware of a specific schema for slapo-auditlog (except attribute type 'olcAuditlogFile' for back-config). Ciao, Michael.
Re: (ITS#8659) accesslog man page updates
This is a cryptographically signed message in MIME format. --ms020708080809040305030308 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable qua...@symas.com wrote: > --On Thursday, May 18, 2017 9:23 AM + elecha...@apache.org wrote: >> There are some differences between the current slapo-accesslog man pag= e, >> and the code base : >> >> - the auditObject ObjectClass is missing the reqEntryUUID AT >> - the auditContainer ObjectClass is not described in the man page >> - the auditModRDN ObjectClass is missing the reqMod AT >=20 > I think you mean slapo-auditlog, not slapo-accesslog? No, Emmanuel is definitely referring to slapo-accesslog. Ciao, Michael. --ms020708080809040305030308 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 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaX
Re: (ITS#8654) Option for LDAP client to bind to a local address.
daniel...@exfo.com wrote: > I am not sure what "a list of space-separated addresses" exactly means. Per= > haps one IPv4 IP address and one IPv6 address if both are available. My use= > case is either a local IPv4 or IPv6 address. Hmm, a dual-stack machine is the most likely use-case. This also raises the question of the IP address list os ordered and the caller can therefore give a preference for IPv4 or IPv6 (e.g. like postfix is doing it for out-going SMTP conns). Ciao, Michael.
Re: (ITS#8646) openldap aborts with ldap_first_entry (ld=0x5564, chain=0x6) at getentry.c:36
kavy...@gmail.com wrote: > Version: 2.4.33 Note that release 2.4.33 is 4,5 years old. Many fixes have been applied since then. Do you still experience the same problem with recent release 2.4.44? Ciao, Michael.
Re: (ITS#8640) its#8376
Please close this misdirected ITS.
(ITS#8376)
FWIW: The patch is still available here in openSUSE's package openldap2: https://build.opensuse.org/package/view_file/network:ldap/openldap2/0009-Fix-ldap-host-lookup-ipv6.patch?expand=1
(ITS#8640) its#8376
This is a cryptographically signed message in MIME format. --ms030807090208090401070408 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FWIW: The patch is still available here in openSUSE's package openldap2: https://build.opensuse.org/package/view_file/network:ldap/openldap2/0009-= Fix-ldap-host-lookup-ipv6.patch?expand=3D1 --ms030807090208090401070408 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 hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwNDE1MTQyNDU3WjAvBgkq hkiG9w0BCQQxIgQgFhRhx9iESA/YCDrgJ8dfKmO1eXAhqmcC8/bqIucwChgwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3
Re: (ITS#8634) OpenLDAP fails to build against OpenSSL 1.1
qua...@symas.com wrote: > Perhaps we should use this ITS to track removal of this code entirely from > OpenLDAP. +1 Ciao, Michael.
Re: (ITS#6545) delta-syncrepl rejects modification master accepted
on...@mistotebe.net wrote: > On Wed, Apr 05, 2017 at 04:14:12PM +0200, Michael Ströder wrote: >> on...@mistotebe.net wrote: >>> On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >>>> Thanks for the patch to provide a test script that just shows the same >>>> thing. >>>> >>>> I see two possible solutions: >>>> >>>> 1) replacing the same attribute twice in the same modify LDIF is illegal >>>> (as it was in older releases) >>> >>> AFAIK, LDAP doesn't forbid it so I don't see that going away. >> >> Yes, there's no text in RFC 4511 which forbids this: >> https://tools.ietf.org/html/rfc4511#section-4.6 >> >> However personally I consider LDAP clients sending modify requests like this >> to be >> broken/mis-behaving. (And I'd like to know which LDAP clients were causing >> this ITS.) > > I'm not saying it's common or good practice ;) > >> => There could be a slapd per-backend configuation directive to disallow it >> with a >> strong hint in the docs recommending to disallow it when using >> delta-syncrepl. >> >> Suggestion: >> disallow mod_attr_repeated > > In my view, that's more pain than it's worth. Hmm, I think slapd should be able to disallow a crazy modify request like this: dn: cn=foobar,dc=example,dc=com changetype: modify replace: description description: foobar1 - replace: description description: foobar2 - .. replace: description description: foobar1000 - Ciao, Michael.
Re: (ITS#6545) delta-syncrepl rejects modification master accepted
on...@mistotebe.net wrote: > On Wed, Apr 05, 2017 at 07:32:46AM -0400, Frank Swasey wrote: >> Thanks for the patch to provide a test script that just shows the same >> thing. >> >> I see two possible solutions: >> >> 1) replacing the same attribute twice in the same modify LDIF is illegal >> (as it was in older releases) > > AFAIK, LDAP doesn't forbid it so I don't see that going away. Yes, there's no text in RFC 4511 which forbids this: https://tools.ietf.org/html/rfc4511#section-4.6 However personally I consider LDAP clients sending modify requests like this to be broken/mis-behaving. (And I'd like to know which LDAP clients were causing this ITS.) => There could be a slapd per-backend configuation directive to disallow it with a strong hint in the docs recommending to disallow it when using delta-syncrepl. Suggestion: disallow mod_attr_repeated >> 2) the accesslog/syncrepl needs to record the final result, not every bit >> of the change. > > Two problems: > - the log is meant to record the request for review/statistics purposes > as well and should record the intent, not just the result > - the modification might fail, in that case you still need an accurate > record of the request IIRC slapo-accesslog was primarily implemented for delta-syncrepl. Personally I'm in the (ab)use-slapo-accesslog-as-auditlog camp. ;-) But still I'd consider an optimized changes list written to accesslog to be perfectly fine for security auditing because it would represent what caused the modification of the database content. Also note that not every failed modification is written to accesslog-DB anyway because most malformed write operations already fail in slapd's front-end (schema check etc.) and never reach the DB backend (and thus slapo-accesslog). So debugging errornous clients is something for which you have to use Wireshark etc. in most cases anyway. I'm not familiar with the inner workings of slapd but these things should be carefully considered when optimizing the changes list of a modify request: 1. constraint checking (slapo-unique and slapo-constraint) 2. impact on indexing 3. access control, especially with val=foo part in the ACL 1. and 2. are hopefully already done on the "resulting entry after the entire list of modifications is performed" (RFC 4511). Ciao, Michael.
