Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
On Mon, 2006-03-27 at 23:30 +0300, Alexander Gattin wrote: Today I have finally managed to make openldap (slapd) work with TLS/SSL. Initially I tried DSA certs, and this always resulted in SSL handshake failure (no shared cipher), despite all my efforts, including different clients (pam_ldap, ldapsearch, openssl s_client) and attempt to trace root cause of the issue (I used slapd -d 65535, s_client's debug, tcpdump, then ssldump...). never had too much problem setting up either start_TLS or ldaps security altho I've always used RSA I think. Theres a fair amount of info at the faq-o-matic over at openldap.org (some ppl cant stand faq-o-matic tho), and plenty of old war stories on the web - might be worth looking at the itss site over at stanford. otherwise, give me a yell and I'll help if I can. Ultimately, with the same cert/key pair, s_server succeeded with s_client (where slapd didn't). Well, for this I used ldaps:///, because ldap:///+TLS can't work with s_client AFAIU. But anyway this clearly shows there's something wrong with slapd, as s_server works OK under the same conditions... might be worth asking on the openldap mailing list and/or submitting a bug report. Then I created RSA cert of almost the same contents (RSA had email while DSA hadn't) and bitlength. This surprisingly enabled s_client to succeed. I suspect bug in slapd's handling of SSL_CTX or DH params... I'd love to have more time to check and report it. :( It looks like bug is in libnss-ldap, or libpam-ldap, not in su, but this has to be proven first. Soon I'll be close to this. getting there... ;) G -- Greg Matthews 01491 692445 Head of UNIX/Linux, iTSS Wallingford -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
Hi! On Mon, Mar 06, 2006 at 09:55:23AM +, Greg Matthews wrote: yes, you can have a number of different CA certs depending on what you are connecting to. Dropping them into a directory means the ldap tools will be able to use them (after the symbolic links have been set up). Today I have finally managed to make openldap (slapd) work with TLS/SSL. Initially I tried DSA certs, and this always resulted in SSL handshake failure (no shared cipher), despite all my efforts, including different clients (pam_ldap, ldapsearch, openssl s_client) and attempt to trace root cause of the issue (I used slapd -d 65535, s_client's debug, tcpdump, then ssldump...). Ultimately, with the same cert/key pair, s_server succeeded with s_client (where slapd didn't). Well, for this I used ldaps:///, because ldap:///+TLS can't work with s_client AFAIU. But anyway this clearly shows there's something wrong with slapd, as s_server works OK under the same conditions... Then I created RSA cert of almost the same contents (RSA had email while DSA hadn't) and bitlength. This surprisingly enabled s_client to succeed. I suspect bug in slapd's handling of SSL_CTX or DH params... I'd love to have more time to check and report it. :( It looks like bug is in libnss-ldap, or libpam-ldap, not in su, but this has to be proven first. Soon I'll be close to this. -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
On Mon, 2006-03-06 at 00:43 +0200, Alexander Gattin wrote: I first heard about TLS_CACERTDIR from you. What is it usually used for? Having different CA trusted by user gathered in one place? yes, you can have a number of different CA certs depending on what you are connecting to. Dropping them into a directory means the ldap tools will be able to use them (after the symbolic links have been set up). It looks like bug is in libnss-ldap, or libpam-ldap, not in su, but this has to be proven first. ok OK, so you don't use samba schemas, neither do smbldap-* tools... samba integration is on my todo list. BTW, what tools do you use for user/group account maintenance? ldapscripts? i use some perl scripts that are based on some code I found on the web and then heavily modified. Its not great but it works. Really only useful for adding and deleting, modifications are best done via a browser/editor like GQ or JXplorer (GQ is best but development is stalled, JXplorer is Java and works cross-platform) or one of the web browser based utils. GREG P.S. thanks for your help, Greg. -- Greg Matthews 01491 692445 Head of UNIX/Linux, iTSS Wallingford -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
Hi! On Thu, Mar 02, 2006 at 09:56:03AM +, Greg Matthews wrote: sorry for the long silence, It's me who had to be sorry, actually, as I didn't have enough time to work on the bug. just trying to reproduce this bug and the symptoms seem to have changed, I dont get a segfault but su is still failing: with TLS_CACERTDIR: $ su - Sorry. $ with TLS_CACERT: $ su - Password: # I first heard about TLS_CACERTDIR from you. What is it usually used for? Having different CA trusted by user gathered in one place? It looks like bug is in libnss-ldap, or libpam-ldap, not in su, but this has to be proven first. current pkg versions on debian sarge host: libnss-ldap 238-1 libpam-ldap 178-1sarge1 wrt schemas, I assume you mean the relevant objectclasses for my user object? In this case I am using the rather restrictive account, with posixAccount and shadowAccount. The server is using the following schema files: OK, so you don't use samba schemas, neither do smbldap-* tools... BTW, what tools do you use for user/group account maintenance? ldapscripts? P.S. thanks for your help, Greg. -- WBR, xrgtn -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
On Thu, 2006-03-02 at 00:52 +0200, Alexander Gattin wrote: Hi! On Mon, Feb 27, 2006 at 07:20:45AM +0100, Christian Perrier wrote: P.S. The requred infrastructure will be ready soon. And now, one month later? And now, *two* months later? :-) Oh, yeah, now it's 2 months closer to completion ;) Actually, a lot of different and I'd say boring job found me meanwhile, but in rare free time I did some experiments. WRT the bug, I'd like to know what schemes etc. did the bug submitter use. Greg? Hi... sorry for the long silence, change of job etc... just trying to reproduce this bug and the symptoms seem to have changed, I dont get a segfault but su is still failing: with TLS_CACERTDIR: $ su - Sorry. $ with TLS_CACERT: $ su - Password: # current pkg versions on debian sarge host: libnss-ldap 238-1 libpam-ldap 178-1sarge1 wrt schemas, I assume you mean the relevant objectclasses for my user object? In this case I am using the rather restrictive account, with posixAccount and shadowAccount. The server is using the following schema files: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/locking.schema include /usr/local/etc/openldap/schema/solaris.schema include /usr/local/etc/openldap/schema/DUAConfig.schema include /usr/local/etc/openldap/schema/automount.schema include /usr/local/etc/openldap/schema/eduperson.schema but locking, solaris and eduperson are not being used. Another datapoint: if I strace the su - I do actually get prompted for a password (without strace I get an instant Sorry.), and the error su: Authentication failure G -- Greg Matthews 01491 692445 Head of UNIX/Linux, iTSS Wallingford -- This message (and any attachments) is for the recipient only. NERC is subject to the Freedom of Information Act 2000 and the contents of this email and any reply you make may be disclosed by NERC unless it is exempt from release under the Act. Any material supplied to NERC may be stored in an electronic records management system. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
Hi! On Mon, Feb 27, 2006 at 07:20:45AM +0100, Christian Perrier wrote: P.S. The requred infrastructure will be ready soon. And now, one month later? And now, *two* months later? :-) Oh, yeah, now it's 2 months closer to completion ;) Actually, a lot of different and I'd say boring job found me meanwhile, but in rare free time I did some experiments. WRT the bug, I'd like to know what schemes etc. did the bug submitter use. Greg? -- WBR, xrgtn
Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
P.S. The requred infrastructure will be ready soon. And now, one month later? And now, *two* months later? :-)
Bug#277767: [Pkg-shadow-devel] Bug#277767: Progress on this bug report?
On Fri, Jan 06, 2006 at 06:45:01PM +0100, Christian Perrier wrote: Alexander, have you made any progress in trying to reproduce this bug report? This is su segfaults using encrypted LDAP which needs some LDAP setup to be worked on... nope, not yet. The only additional information I can provide at the moment is that I saw coredumps/crashes using LDAP-NSS several months ago (in rpc or services DB, AFAIR). P.S. The requred infrastructure will be ready soon. And now, one month later? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
