Re: OpenLDAP configuration
On Thursday 28 July 2011 16:35:25 you wrote: /etc/init.d/slapd stop cd /etc/openldap rm -Rf slapd.d mkdir slapd.d slaptest -f slapd.conf -F slapd.d chown -R ldap:ldap slapd.d /etc/init.d/slapd start I know it beats the object of being able to make runtime changes to cn=config, but with lack of readable documentation, and the fact that I'm in test mode only, trying to learn OpenLDAP, this is the way I do it. Great idea, so let's try to manage it like that... But my critism on the whole thing is, that -it seems- the new config system is cn=config, and it is so poor documented. There are so less howtos and other stuff in the web using cn=config. One of my problems are to get the replication (n-way multi master with sasl and kerberos auth) working with the new configuration system, but I found none else having a configuration like mine. regards Andreas -- = _ / ___/Andreas Laesser / //_// // Signal Proc. Speech Communication Lab. __/ /___/ / __Graz University of Technology /___////__ Inffeldgasse 12 | A-8010 Graz | Austria http://www.spsc.tugraz.at Tel: +43 (0)316 873 -4443 Fax: DW 104439 = signature.asc Description: This is a digitally signed message part.
Re: OpenLDAP configuration
Andreas Laesser wrote: On Thursday 28 July 2011 16:35:25 you wrote: /etc/init.d/slapd stop cd /etc/openldap rm -Rf slapd.d mkdir slapd.d slaptest -f slapd.conf -F slapd.d chown -R ldap:ldap slapd.d /etc/init.d/slapd start I know it beats the object of being able to make runtime changes to cn=config, but with lack of readable documentation, and the fact that I'm in test mode only, trying to learn OpenLDAP, this is the way I do it. Great idea, so let's try to manage it like that... But my critism on the whole thing is, that -it seems- the new config system is cn=config, and it is so poor documented. There are so less howtos and other stuff in the web using cn=config. So you're unable to read slapd-config(5)? Or the Admin Guide? When a (hypothetical) document says: digits are characters in the range 0-9, e.g. '5' do you really need a HowTo spelling out the rest of the possible values? One of my problems are to get the replication (n-way multi master with sasl and kerberos auth) working with the new configuration system, but I found none else having a configuration like mine. regards Andreas -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP configuration
On 29/07/2011 08:47, Andreas Laesser wrote: But my critism on the whole thing is, that -it seems- the new config system is cn=config, and it is so poor documented. There are so less howtos and other stuff in the web using cn=config. My criticism is not about missing documentation. I think there is enough of that, and what missing could be added. My criticism, if slapd.conf will be removed, is about the added complexity that will be imposed forcing the use of cn=config on all the people that don't need the benefits it gives. I already stated the reasons for which I strongly prefer simple text configuration files for service deamons, so I won't repeat it here. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: OpenLDAP configuration
In my point of view, if the reason is only for resolve configuration change, it's a workaround and not a solution. look samba and smb.conf file management. I can read and write this file when smb deamon run, why slapd cannot made same think ? --- Stéphane PURNELLE Admin. Systèmes et Réseaux Service Informatique Corman S.A. Tel : 00 32 (0)87/342467 openldap-technical-boun...@openldap.org wrote on 29/07/2011 11:51:04: Simone Piccardi picca...@truelite.it Envoyé par : openldap-technical-boun...@openldap.org 29/07/2011 12:04 A openldap-technical@openldap.org cc Objet Re: OpenLDAP configuration On 29/07/2011 08:47, Andreas Laesser wrote: But my critism on the whole thing is, that -it seems- the new config system is cn=config, and it is so poor documented. There are so less howtos and other stuff in the web using cn=config. My criticism is not about missing documentation. I think there is enough of that, and what missing could be added. My criticism, if slapd.conf will be removed, is about the added complexity that will be imposed forcing the use of cn=config on all the people that don't need the benefits it gives. I already stated the reasons for which I strongly prefer simple text configuration files for service deamons, so I won't repeat it here. Simone -- Simone Piccardi Truelite Srl picca...@truelite.it (email/jabber) Via Monferrato, 6 Tel. +39-347-103243350142 Firenze http://www.truelite.it Tel. +39-055-7879597Fax. +39-055-736
Re: invalid syntax when teletexstring
2011/7/29 Howard Chu h...@symas.com: Howard Chu wrote: Erwann ABALEA wrote: Do you have any document or pointer to understand the task of converting to/from T.61, and incompatible character sets you talked about? I Googled for this, but I'm not sure of what I found (what I found reminds me of old character sets we used many years ago in France for the Minitel, with G1/G2 character groups, etc, not that far from VT consoles). You can reference this old draft; I wrote Appendix A and B to document the mapping as we understood it at that time. These Appendices were dropped from the final version because it was considered futile to attempt to document the T.61 character encoding rules. http://tools.ietf.org/html/draft-ietf-ldapbis-strprep-00#appendix-A You can also read libldap/t61.c; the code has been present in every OpenLDAP release since 2002 but is not compiled or used. This Guide has a pretty good discussion of the issues. http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt The section on Character Sets is particularly relevant. The section on Comparing DNs is somewhat relevant, though in fact OpenLDAP has already solved this problem (for all the string types besides T61String) by doing all matching in UTF-8. Thank you for the pointers. I appreciate Peter's writings, and already read this text, some time ago, but wasn't focused on T.61 then. OpenSSL in its 1.0.0 version internally stores the named in UTF8, semi-normalized form (useless spaces removed, everything is converted to lowercase, but no NFC/NFD normalization is done). I'm reading now libldap/t61.c. I just read the IETF draft, and the numerous tables... What a mess. X.680 has a reference to T.61 recommendation, which was deleted some years ago, and I'm not clever enough to make Google find a copy of the standard. It can't be bought anymore from ITU, but it's still referenced by later standards. Nice. Meanwhile, I still haven't found the Czech CSCA certificate, but I know what to do with the remaining 1% uncertainty. The CN field is encoded as T61String, to hold the CSCA_CZ value. That fits well within the 7bits limit. If everything is internally converted to UTF8 and t61.c seems to provide a lossless T.61 to UTF8 conversion, why isn't it used? -- Erwann.
Memory usage (ITS 6660): Is there a patch to 2.4.23 version to fix the problem ?
Dear list members, i am running openlda 2.4.23 and i am facing memory usage problems (ITS 6660). I am not given the option to change to 2.4.23. Is there a patch to fix this problem? Thanks once more.
Re: invalid syntax when teletexstring
Erwann ABALEA wrote: 2011/7/29 Howard Chuh...@symas.com: Howard Chu wrote: Erwann ABALEA wrote: Do you have any document or pointer to understand the task of converting to/from T.61, and incompatible character sets you talked about? I Googled for this, but I'm not sure of what I found (what I found reminds me of old character sets we used many years ago in France for the Minitel, with G1/G2 character groups, etc, not that far from VT consoles). You can reference this old draft; I wrote Appendix A and B to document the mapping as we understood it at that time. These Appendices were dropped from the final version because it was considered futile to attempt to document the T.61 character encoding rules. http://tools.ietf.org/html/draft-ietf-ldapbis-strprep-00#appendix-A You can also read libldap/t61.c; the code has been present in every OpenLDAP release since 2002 but is not compiled or used. This Guide has a pretty good discussion of the issues. http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt The section on Character Sets is particularly relevant. The section on Comparing DNs is somewhat relevant, though in fact OpenLDAP has already solved this problem (for all the string types besides T61String) by doing all matching in UTF-8. Thank you for the pointers. I appreciate Peter's writings, and already read this text, some time ago, but wasn't focused on T.61 then. OpenSSL in its 1.0.0 version internally stores the named in UTF8, semi-normalized form (useless spaces removed, everything is converted to lowercase, but no NFC/NFD normalization is done). I'm reading now libldap/t61.c. I just read the IETF draft, and the numerous tables... What a mess. X.680 has a reference to T.61 recommendation, which was deleted some years ago, and I'm not clever enough to make Google find a copy of the standard. It can't be bought anymore from ITU, but it's still referenced by later standards. Nice. The 1988 edition is still downloadable. http://www.itu.int/rec/T-REC-T.61-198811-S/en It also references T.51: http://www.itu.int/rec/T-REC-T.51/en Unfortunately the 1993 edition of T.61 is gone. Meanwhile, I still haven't found the Czech CSCA certificate, but I know what to do with the remaining 1% uncertainty. The CN field is encoded as T61String, to hold the CSCA_CZ value. That fits well within the 7bits limit. Then you should just be using PrintableString. You're required to use the least-inclusive string type, after all. If everything is internally converted to UTF8 and t61.c seems to provide a lossless T.61 to UTF8 conversion, why isn't it used? Because it's incomplete. It only handles the original 333 character repertoire of T.61, it doesn't handle shift-in/shift-out to other character sets. I believe in the last version of T.61 there was support for Japanese (JIS), Chinese, and Greek. So quite a lot more logic and tables needs to be added, and it looks like a lot of work for something nobody should actually be using. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Version
hi folks, i just wonder what are the most common versions of openldap you have running on production systems right now. Thanks in advance.
SSL server certificate that has an intermediary certificate in the chain
I have searched the faq-o-matic, google, the admin guide, and I cannot find any documentation that will allow me to set up my OpenLDAP 2.4.25 server using an SSL certificate that was issued from a CA that uses intermediate certificates (by, which I mean to indicate any commercial SSL cert company currently selling certs). Apache has the SSLCertificateChainFile directive to handle this. OpenLDAP seems to be lacking this functionality. I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file. Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients? -- Frank Swasey| http://www.uvm.edu/~fcs Sr Systems Administrator| Always remember: You are UNIQUE, University of Vermont |just like everyone else. I am not young enough to know everything. - Oscar Wilde (1854-1900) signature.asc Description: OpenPGP digital signature
Re: invalid syntax when teletexstring
2011/7/29 Howard Chu h...@symas.com: Erwann ABALEA wrote: [...] I'm reading now libldap/t61.c. I just read the IETF draft, and the numerous tables... What a mess. X.680 has a reference to T.61 recommendation, which was deleted some years ago, and I'm not clever enough to make Google find a copy of the standard. It can't be bought anymore from ITU, but it's still referenced by later standards. Nice. The 1988 edition is still downloadable. http://www.itu.int/rec/T-REC-T.61-198811-S/en One click further... Sorry, I read Superseded for the 1988 edition, and Withdrawn for the 1993 one, and didn't realize I could click on the 1988 link to download this edition. It also references T.51: http://www.itu.int/rec/T-REC-T.51/en Unfortunately the 1993 edition of T.61 is gone. Even more, it is displayed as Never published. Meanwhile, I still haven't found the Czech CSCA certificate, but I know what to do with the remaining 1% uncertainty. The CN field is encoded as T61String, to hold the CSCA_CZ value. That fits well within the 7bits limit. Then you should just be using PrintableString. You're required to use the least-inclusive string type, after all. Howard, you're very good. But you too can make mistakes :) 1. PrintableString is inadequate (because of the underscore character). 2. It's not *my* certificate, it's the Czech Republic certificate used to issue passports that will be verified by every other country. I don't work for them, I'm french :) (OK, I don't know where you live either) 3. And the you're required to use the least-inclusive string type statement is wrong, there's no such requirement, nowhere, everybody's free to use UTF8String even when PrintableString could be used (it's even RECOMMENDED to do so). The good option would have been to use UTF8String, for sure. But they already produced passports, and changing the root certificate of this importance is not an easy task. Instead, RFC4518 states that non-Unicode strings are to be translated to Unicode, even TeletexString. The reader is warned that it is NOT RECOMMENDED to use such encoding, and that no standard conversion rules between them exists, but this conversion is *not* optional. If everything is internally converted to UTF8 and t61.c seems to provide a lossless T.61 to UTF8 conversion, why isn't it used? Because it's incomplete. It only handles the original 333 character repertoire of T.61, it doesn't handle shift-in/shift-out to other character sets. I believe in the last version of T.61 there was support for Japanese (JIS), Chinese, and Greek. So quite a lot more logic and tables needs to be added, and it looks like a lot of work for something nobody should actually be using. If the support for JIS, Chinese, and Greek characters were to be included in the 1993 edition, and this edition has never been published, couldn't it be possible to ignore them? X.680 (1997 edition) also references the 1988 edition of T.61, and if no newer edition is present, then it still must be used, right? Is an incomplete (but documented) support for T61String really worse than no support for it at all? Even if literature tells that no perfect support can exist? -- Erwann.
Re: invalid syntax when teletexstring
Erwann ABALEA wrote: 2011/7/29 Howard Chuh...@symas.com: Then you should just be using PrintableString. You're required to use the least-inclusive string type, after all. Howard, you're very good. But you too can make mistakes :) 1. PrintableString is inadequate (because of the underscore character). Ah, right. If everything is internally converted to UTF8 and t61.c seems to provide a lossless T.61 to UTF8 conversion, why isn't it used? Because it's incomplete. It only handles the original 333 character repertoire of T.61, it doesn't handle shift-in/shift-out to other character sets. I believe in the last version of T.61 there was support for Japanese (JIS), Chinese, and Greek. So quite a lot more logic and tables needs to be added, and it looks like a lot of work for something nobody should actually be using. If the support for JIS, Chinese, and Greek characters were to be included in the 1993 edition, and this edition has never been published, couldn't it be possible to ignore them? X.680 (1997 edition) also references the 1988 edition of T.61, and if no newer edition is present, then it still must be used, right? Actually Japanese and Chinese are already specified in the 1988 edition. Greek is mentioned there but is lacking a specification of which escape code to use. Probably it's defined elsewhere, like a later version of ISO 2022 or somesuch. Is an incomplete (but documented) support for T61String really worse than no support for it at all? Even if literature tells that no perfect support can exist? In the security arena, yes. E.g. if we accept a T61String that uses escape codes, we will not normalize it correctly to UTF-8. From there we would be giving definitive yes/no results to matches, based on invalid comparisons. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: invalid syntax when teletexstring
Could we accept some safe subset of T.61 and reject the rest? As long as we don't need to translate back... -- Hallvard
Re: invalid syntax when teletexstring
Hallvard B Furuseth wrote: Could we accept some safe subset of T.61 and reject the rest? As long as we don't need to translate back... Perhaps. The original post in this thread was complaining about a plain attribute value as well as a certificate DN. Obviously LDAPv3 requires strings to be provided in UTF-8; one has to wonder if the client was performing an LDAPv2 Bind. If we tie string normalization behavior to the session protocol version, then that means we would also need to be able translate back from UTF-8 to T.61. Clearly we are not going to add any support for LDAPv2 at this late date. At this point I think all the facts and resources have been laid out. Patches welcome, if anyone wants to pursue it further. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: invalid syntax when teletexstring
Hallvard B Furuseth wrote: Nope, base64 is just part of LDIF format, which is only relevant on the client side. OpenLDAP does not support the TeletexString syntax. LDAPv3 requires all strings to be in UTF-8, so there's no reason for OpenLDAP to support TeletexString syntax. Such support would be fragile, since there's no unique mapping from LDAPv3's usual UTF-8 character encoding to TeletexString's T.61 character encoding. IRIC there are a bunch of conflicting T.61 encoding variants too. Still, I don't know why that makes it possible to store such a cert, since certs are binary. You could file an ITS with a request for support, and enclose the cert so there will be something to test it with. anax writes: If you base64-encode the string? suomi On 2011-07-26 13:39, Vangelis Karatsiolis wrote: Hi, while trying to store an attribute with syntax DistinguishedName containing a TeletexString on an OpenLDAP 2.4.23 there are errors in the normalization process and the attribute cannot be stored due to invalid syntax (21). A certificate containing such a subjectDN is also not possible to be stored. Is it possible to deactivate this in this version of OpenLDAP, for example through configuration or during the compilation? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SSL server certificate that has an intermediary certificate in the chain
On 7/29/11 3:09 PM, Philip Guenther wrote: On Fri, 29 Jul 2011, Francis Swasey wrote: I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file. Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients? It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option? Well, I never looked at it that way. Yes, adding the intermediate certificate to the file pointed to by the TLSCACertificateFile option on the OpenLDAP server appears to have worked. Thanks, Frank
Re: SSL server certificate that has an intermediary certificate in the chain
Frank Swasey wrote: On 7/29/11 3:09 PM, Philip Guenther wrote: On Fri, 29 Jul 2011, Francis Swasey wrote: I have tried placing both the server certificate and the intermediate certificate in the same file. OpenLDAP won't start if I put the intermediate certificate first, and openssl fails to verify the certificate chain if I put the server certificate first in the file. Have I missed something obvious or has OpenLDAP really forced me into the position of needing to add the intermediate certificate from my SSL CA Vendor into my trusted store on all my clients? It's a CA cert; have you tried adding it to the file specified by the TLSCACertificateFile option? Well, I never looked at it that way. Yes, adding the intermediate certificate to the file pointed to by the TLSCACertificateFile option on the OpenLDAP server appears to have worked. Amaazing what trouble you could save yourself if you actually read the documentation. http://www.openldap.org/doc/admin24/tls.html#Server%20Configuration Section 16.2.1.1 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
