openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by alex.soloviov＠wildix.com 23 Jul '19

23 Jul '19

Ciao, Michael I understood the risks but how can I resolve my issue? My case I want to upgrade all servers step by step without lost data on = secondary LDAP servers For now when I add the new attribute to some item in LDAP then this item = lost on secondary servers. Moreover, replication stops after receiving the first item with unknown = data. So, I will lose not only one changed item and also all next I have a few hundred of LDAPs servers which should be updated one-by-one = and in this case, I will lose the data until upgrade all of them Thank you in advance. Best regards, Alex > On Jul 23, 2019, at 12:52, Michael Str=C3=B6der <michael(a)stroeder.com> = wrote: >=20 > On 7/23/19 9:10 AM, alex.soloviov(a)wildix.com wrote: >> Actually, I have the configuration with several LDAP server without = this =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: >> 5d36b192 UNKNOWN attributeDescription "TESTTYPE" inserted. >=20 > Mainly running a replication setup without consistent schema on all = replicas is asking for trouble. It may work in some niche cases. But in = most cases it will fail miserably. >=20 > =3D> Fix your setup. >=20 > Ciao, Michael. >=20

1 0

Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by michael＠stroeder.com 23 Jul '19

23 Jul '19

This is a cryptographically signed message in MIME format. --------------ms070709080204010000080303 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.soloviov(a)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. --------------ms070709080204010000080303 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 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTkwNzIzMDk1MjQwWjAvBgkqhkiG9w0BCQQxIgQglDZS mcsh/ke5yJcOr5EccmPn63SBEDX4hL+766mh+EwwbAYJKoZIhvcNAQkPMV8wXTALBglghkgB ZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBvQYJKwYBBAGCNxAEMYGvMIGsMIGX MQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJT QSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXMmHIQX8SWTc 7x5fq9i6IjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9E TyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlv biBhbmQgU2VjdXJlIEVtYWlsIENBAhBcyYchBfxJZNzvHl+r2LoiMA0GCSqGSIb3DQEBAQUA BIIBADDtE2ilDUGAqmLXDxhJc074QlnHUEtum+sJOcRQVeuG6vp8fFXtW2IpDemTaxUPUN75 9dlqwnloME1lwVlH7VoGi3MuSWCKGwDZ+CPvi+M6O2tnvZOwklD3qdaOVrvuqNQ6U5aV8uF0 /O86V8GdywWjA7gniTXvh5GXIxauZYfYENjObtCjXdxpRzbJkpFbODsfWr5krQfCaNC0kzEJ Odd+kbWg/FedTcR4m65BMwnLD5tQFDIe8OF4wduxMAqpPnnE61oTMfLweTS6rMD+UGDCc4Zg /bzWgRn3fo8rZZg05fbdYTaSUf8CQSfnhEY3zDUdkGqQz/FM/TIWQXP6ZbkAAAAAAAA= --------------ms070709080204010000080303--

1 0

Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by alex.soloviov＠wildix.com 23 Jul '19

23 Jul '19

Hello, Howard Thank you for a quick reply Actually, I have the configuration with several LDAP server without this = problem. But the version of these LDAPs is a bit less - 2.4.31.=20 On this installation when I changed the schema on the main server, on = secondary I see fully replicated data and warnings about unknown = attributes like: 5d36b192 UNKNOWN attributeDescription "TESTTYPE" inserted. Can I get the same behavior on the current/latest version? Thank you in advance. Best regards, Alex > On Jul 22, 2019, at 19:38, Howard Chu <hyc(a)symas.com> wrote: >=20 > alex.s(a)wildix.com wrote: >> Full_Name: Alex >> Version: 2.4.44+dfsg-5+deb9u2 >> OS: Debian 9 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (154.41.3.130) >>=20 >>=20 >> Looks like schemachecking parameter does not work properly >>=20 >> I have a few LDAPs >> On main LDAP server I changed the schema with an additional = attribute. >>=20 >> On the secondary LDAPs I have a problem with replication (does not = download >> items which have new attribute) >>=20 >> I have the following configuration on the secondary LDAP: >>=20 >> olcSyncrepl: {0}rid=3D001 provider=3Dldap://remote_ldap_addr = bindmethod=3Dsimple >> timeout=3D0 >> network-timeout=3D0 binddn=3D"cn=3Dadmin,dc=3Dexample" = credentials=3D"testPass" >> starttls=3Dno filter=3D"(objectclass=3D*)" searchbase=3D"dc=3Dexample" = scope=3Dsub >> schemachecking=3Doff type=3DrefreshAndPersist interval=3D00:00:02:00 = retry=3D"5 +" >>=20 >>=20 >> I have the following errors in syslog: >>=20 >> Jul 22 17:05:29 221100000e68 slapd[6838]: null_callback : error code = 0x50 >> Jul 22 17:05:29 221100000e68 slapd[6838]: syncrepl_entry: rid=3D001 = be_add >> uid=3D1326514,o=3Dcom0,dc=3Dexample failed (80) >> Jul 22 17:05:29 221100000e68 slapd[6838]: do_syncrepl: rid=3D001 rc = 80 retrying >> Jul 22 17:05:34 221100000e68 slapd[6838]: null_callback : error code = 0x50 >> Jul 22 17:05:34 221100000e68 slapd[6838]: syncrepl_entry: rid=3D001 = be_add >> uid=3D1326514,o=3Dcom0,dc=3Dexample failed (80) >> Jul 22 17:05:34 221100000e68 slapd[6838]: do_syncrepl: rid=3D001 rc = 80 retrying >> Jul 22 17:05:39 221100000e68 slapd[6838]: null_callback : error code = 0x50 >> Jul 22 17:05:39 221100000e68 slapd[6838]: syncrepl_entry: rid=3D001 = be_add >> uid=3D1326514,o=3Dcom0,dc=3Dexample failed (80) >> Jul 22 17:05:39 221100000e68 slapd[6838]: do_syncrepl: rid=3D001 rc = 80 retrying >=20 > syncrepl is ignoring the schema as you requested. However the = underlying backend is refusing > to store the entries that syncrepl passes to it. >=20 > In general, turning off schema checking is only safe for overriding = syntax validity checks > on known attributes. You still have to at least define the existence = of these attributes > on all participating servers. >=20 > --=20 > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by hyc＠symas.com 22 Jul '19

22 Jul '19

alex.s(a)wildix.com wrote: > Full_Name: Alex > Version: 2.4.44+dfsg-5+deb9u2 > OS: Debian 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (154.41.3.130) > > > Looks like schemachecking parameter does not work properly > > I have a few LDAPs > On main LDAP server I changed the schema with an additional attribute. > > On the secondary LDAPs I have a problem with replication (does not download > items which have new attribute) > > I have the following configuration on the secondary LDAP: > > olcSyncrepl: {0}rid=001 provider=ldap://remote_ldap_addr bindmethod=simple > timeout=0 > network-timeout=0 binddn="cn=admin,dc=example" credentials="testPass" > starttls=no filter="(objectclass=*)" searchbase="dc=example" scope=sub > schemachecking=off type=refreshAndPersist interval=00:00:02:00 retry="5 +" > > > I have the following errors in syslog: > > Jul 22 17:05:29 221100000e68 slapd[6838]: null_callback : error code 0x50 > Jul 22 17:05:29 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add > uid=1326514,o=com0,dc=example failed (80) > Jul 22 17:05:29 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying > Jul 22 17:05:34 221100000e68 slapd[6838]: null_callback : error code 0x50 > Jul 22 17:05:34 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add > uid=1326514,o=com0,dc=example failed (80) > Jul 22 17:05:34 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying > Jul 22 17:05:39 221100000e68 slapd[6838]: null_callback : error code 0x50 > Jul 22 17:05:39 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add > uid=1326514,o=com0,dc=example failed (80) > Jul 22 17:05:39 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying syncrepl is ignoring the schema as you requested. However the underlying backend is refusing to store the entries that syncrepl passes to it. In general, turning off schema checking is only safe for overriding syntax validity checks on known attributes. You still have to at least define the existence of these attributes on all participating servers. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#9056) Replication does not work with different schemas on primary and secondary LDAP
by alex.s＠wildix.com 22 Jul '19

22 Jul '19

Full_Name: Alex Version: 2.4.44+dfsg-5+deb9u2 OS: Debian 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (154.41.3.130) Looks like schemachecking parameter does not work properly I have a few LDAPs On main LDAP server I changed the schema with an additional attribute. On the secondary LDAPs I have a problem with replication (does not download items which have new attribute) I have the following configuration on the secondary LDAP: olcSyncrepl: {0}rid=001 provider=ldap://remote_ldap_addr bindmethod=simple timeout=0 network-timeout=0 binddn="cn=admin,dc=example" credentials="testPass" starttls=no filter="(objectclass=*)" searchbase="dc=example" scope=sub schemachecking=off type=refreshAndPersist interval=00:00:02:00 retry="5 +" I have the following errors in syslog: Jul 22 17:05:29 221100000e68 slapd[6838]: null_callback : error code 0x50 Jul 22 17:05:29 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add uid=1326514,o=com0,dc=example failed (80) Jul 22 17:05:29 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying Jul 22 17:05:34 221100000e68 slapd[6838]: null_callback : error code 0x50 Jul 22 17:05:34 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add uid=1326514,o=com0,dc=example failed (80) Jul 22 17:05:34 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying Jul 22 17:05:39 221100000e68 slapd[6838]: null_callback : error code 0x50 Jul 22 17:05:39 221100000e68 slapd[6838]: syncrepl_entry: rid=001 be_add uid=1326514,o=com0,dc=example failed (80) Jul 22 17:05:39 221100000e68 slapd[6838]: do_syncrepl: rid=001 rc 80 retrying

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 19 Jul '19

19 Jul '19

On Fri, Jul 19, 2019 at 02:30:48PM -0400, Greg Veldman wrote: > I'll submit an updated patch shortly to fix > this, as well as some documentation updates for issues pointed > out. I have generated an updated version of the patch, with the following changes from the original: - Avoid the side effects of short-circuit && - Point out the need for one initial authentication in the current window to verify clocks before the previous window logic kicks in - Document as a bug the lack of hash functions for the new schemes Updated patch: https://scinet.supercomputing.org/~gv/slapd-totp-v2.txt -- Greg Veldman

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 19 Jul '19

19 Jul '19

On Fri, Jul 19, 2019 at 07:21:35PM +0200, Ond??ej Kuzn??k wrote: > > if (chk_totp(&passwd_otp, &cred_otp, mech, text) == LUTIL_PASSWD_OK > > && lutil_passwd(&passwd_pass, &cred_pass, NULL, text) > > == LUTIL_PASSWD_OK) > > rc = LUTIL_PASSWD_OK; > > This only checks the password if OTP check passed, right? So if checking > the password takes a measurable amount of time, an attacker can see if > they hit the right OTP token without it being voided. Ah, yes, sorry I didn't quite catch what you were getting at previously there. I'll submit an updated patch shortly to fix this, as well as some documentation updates for issues pointed out. -- Greg Veldman

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by ondra＠mistotebe.net 19 Jul '19

19 Jul '19

On Fri, Jul 19, 2019 at 04:34:44PM +0000, gv(a)members.scinet.supercomputing.org wrote: > On Fri, Jul 19, 2019 at 05:58:37PM +0200, Ond??ej Kuzn??k wrote: >> BTW, why did you choose to check that the user has already logged in >> rather than "(told == 0 || t - 1 > told)"? > > There are two circumstances where a user may transmit a code > from the previous time window: > > 1. The time window rolls over as the code is being typed in > or transmitted over the network. > > 2. The clock on the user's prover is off. > > I made this condition because on the very first attempt at TOTP > auth, I wanted to be more strict about accepting expired codes > to ensure that the clock on the user's prover is in fact in sync > with the server. Since this implementation has no mechanism to > adjust for clock skew, if both clocks weren't in sync that would > cause many issues for the user down the road, and the possibility > of a false negative on the first attempt seemed a small price to > pay to ensure they were. OK, probably worth mentioning then. >> It might be better to check both the token and password independently >> and then return success iff both of them succeeded to avoid timing leaks >> of OTP success/failure? > > I do. The issue Quanah raised is in relation to the change > in chk_totp(). This is only called directly for the {TOTP1}, > {TOTP256}, and {TOTP512} schemes (e.g. TOTP only and no password). > If a password is in play, the checks use the new chk_totp_and_pw() > function, which does validate each piece independently: > > if (chk_totp(&passwd_otp, &cred_otp, mech, text) == LUTIL_PASSWD_OK > && lutil_passwd(&passwd_pass, &cred_pass, NULL, text) > == LUTIL_PASSWD_OK) > rc = LUTIL_PASSWD_OK; This only checks the password if OTP check passed, right? So if checking the password takes a measurable amount of time, an attacker can see if they hit the right OTP token without it being voided. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#7326) additional notes
by quanah＠symas.com 19 Jul '19

19 Jul '19

The related glibc bugs are: <https://sourceware.org/bugzilla/show_bug.cgi?id=12398> <https://sourceware.org/bugzilla/show_bug.cgi?id=12377> RedHat patched around this as noted in <https://bugzilla.redhat.com/show_bug.cgi?id=505105> Other useful information in <https://bugzilla.redhat.com/show_bug.cgi?id=699576> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#9055) contrib/slapd-modules/passwd/totp improvements
by gv＠members.scinet.supercomputing.org 19 Jul '19

19 Jul '19

On Fri, Jul 19, 2019 at 05:58:37PM +0200, Ond??ej Kuzn??k wrote: > BTW, why did you choose to check that the user has already logged in > rather than "(told == 0 || t - 1 > told)"? There are two circumstances where a user may transmit a code from the previous time window: 1. The time window rolls over as the code is being typed in or transmitted over the network. 2. The clock on the user's prover is off. I made this condition because on the very first attempt at TOTP auth, I wanted to be more strict about accepting expired codes to ensure that the clock on the user's prover is in fact in sync with the server. Since this implementation has no mechanism to adjust for clock skew, if both clocks weren't in sync that would cause many issues for the user down the road, and the possibility of a false negative on the first attempt seemed a small price to pay to ensure they were. > It might be better to check both the token and password independently > and then return success iff both of them succeeded to avoid timing leaks > of OTP success/failure? I do. The issue Quanah raised is in relation to the change in chk_totp(). This is only called directly for the {TOTP1}, {TOTP256}, and {TOTP512} schemes (e.g. TOTP only and no password). If a password is in play, the checks use the new chk_totp_and_pw() function, which does validate each piece independently: if (chk_totp(&passwd_otp, &cred_otp, mech, text) == LUTIL_PASSWD_OK && lutil_passwd(&passwd_pass, &cred_pass, NULL, text) == LUTIL_PASSWD_OK) rc = LUTIL_PASSWD_OK; -- Greg Veldman

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs