openldap-software March 2007

openldap-software@openldap.org

68 participants
83 discussions

Re: slapd-sql with unixodbc - userCertificate retrieval problem
by Pierangelo Masarati 08 Mar '07

08 Mar '07

Kevin Vargo wrote: > 3) another guy gave you the code in #3386 (a) -- sure, not as a > submitted patch, maybe? -- and if it were pulled into the codebase > this would work? Exactly, that should be the way to go. Unfortunately, that guy didn't submit a patch, but rather some hint (which, IMHO, would break other functionalities). Since storing certificates in back-sql for me doesn't even have a place in my todo list, and I'm the one developer that cares most about back-sql, either a solid patch comes in, or binary data will likely never be implemented. If you feel like preparing and submitting that patch, I'll be happy (time permitting) to review, test and eventually apply it to back-sql. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

debugging my problem
by Craig White 08 Mar '07

08 Mar '07

I am having a problem with an application and when I save, I am given this error in the logs... Mar 7 20:57:22 srv slapd[14570]: conn=1109156 op=4 MOD attr=sambaLogonScript sambaProfilePath cn uidNumber sambaPrimaryGroupSID sambaAcctFlags gecos userPassword sambaLMPassword uid sambaHomePath homeDirectory description objectClass gidNumber sambaDomainName gn sambaSID sambaNTPassword sambaHomeDrive sn mailLocalAddress calFBURL loginShell Mar 7 20:57:22 srv slapd[14570]: conn=1109156 op=4 RESULT tag=103 err=21 text=objectClass: value #7 invalid per syntax Does 'value #7' mean the 7th item in the MOD attr list in the line above... 1 sambaLogonScript 2 sambaProfilePath 3 cn 4 uidNumber 5 sambaPrimaryGroupSID 6 sambaAcctFlags 7 gecos Does this mean that there is something invalid in the gecos attribute? If not, I am logging at level 256, is there a logging level that would make this obvious to me? Craig

2 1

Re: slapd-sql with unixodbc - userCertificate retrieval problem
by Pierangelo Masarati 07 Mar '07

07 Mar '07

Kevin Vargo wrote: >> You don't need to tell back-sql if data is binary or not: it already >> knows how to deal with data based on their syntax. You need to tell the >> RDBMS that its' storing binary data, and store the certificate in the >> RDBMS as binary. If you store the certificate in base64, then back-sql >> (actually, the certificate's validator, back-sql yous passes octet >> strings around) doesn't know what to do with it. > > Right; I am storing it DER(BER) in a BLOB field now: > > > mysql> desc user_certificates; > +------------------+---------+------+-----+---------+----------------+ > | Field | Type | Null | Key | Default | Extra | > +------------------+---------+------+-----+---------+----------------+ > | id | int(11) | NO | PRI | NULL | auto_increment | > | person_id | int(11) | NO | | | | > | certificate_data | blob | YES | | NULL | | > +------------------+---------+------+-----+---------+----------------+ > 3 rows in set (0.16 sec) > > > Still yields: > > ==>backsql_get_attr_vals(): oc="inetOrgPerson" attr="userCertificate" keyval=4 > backsql_get_attr_vals(): number of values in query: 1 > backsql_get_attr_vals(): query="SELECT user_certificates.certificate_data AS userCertificate FROM persons,user_certificates WHERE persons.id=? AND persons.id=user_certificates.person_id ORDER BY userCertificate" keyval=4 > ================>>> certificateValidate > ================>>> certificateValidate: error:(218529960) > error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag > ================>>> certificateValidate: error:(218595386) > error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error > ================>>> certificateValidate: error:(0) > error:00000000:lib(0):func(0):reason(0) > > > pulling the data directly out of the database via Perl, the file verifies just fine with: > openssl x509 -noout -text -inform der -in ../tmp/tmpfile.tmp > > pulling it out with SELECT ... INTO OUTFILE yeilds the same SSL errors; diff'ing shows \s in the file that's bad...? > > based on what TIS#3113 indicated, it seemed like the guy had issues with how slapd was pulling it out of the database? > > It also seemed like the following note was consistent with that interpretation? > > [servers/slapd/back-sql/entry-id.c:744] > /* > * FIXME: what if a binary > * is fetched? > */ > ber_str2bv( row.cols[ i ], 0, 0, &bv ); This is surely part of the problem. In this sense, back-sql knowns nothing about BLOBs, and a patch for this would be welcome. >>> Note that this is the OpenSSL invoked by the X.509 validator >>> (assuming TLS was turned on), even though the certificate in question >>> is not being used for TLS. However, the normalization still fails, >>> even (as mentioned) if validation is disabled. I'm assuming the >>> normalization failure would be related, although I haven't gotten >>> there yet. >> >> TLS has nothing to do with this. OpenLDAP just needs to be compiled >> with ssl to have certificate handling routines around. > > It appears to choose the validator via TLS settings? I could certainly be missing something, but: > > [servers/slapd/schema_init.c] > #ifdef HAVE_TLS > static int certificateValidate( Syntax *syntax, struct berval *in ) > { > ...... > #else > #define certificateValidate sequenceValidate > #endif > > > or are you saying that HAVE_TLS is driven off of ssl compilation switches? From your previous message, I inferred you said that TLS had to be __configured__ in slapd.conf to enable certificate validation. I understand you meant it had to be configured at compile time. The latter is correct, so if that's what you meant then you were right. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: slapd-sql with unixodbc - userCertificate retrieval problem
by Pierangelo Masarati 07 Mar '07

07 Mar '07

Kevin Vargo wrote: > Right; except that in ITS#3113, you explicitly state that back-sql > should refuse binary data, I said that no ";binary" should be used. That's different from refusing binary data, don't you agree? p. > don't you? Granted, that was a while > back, however, I've not found mention of where that directive has > been obsoleted. As well the retrieval errors are consistent with > invalid binary->text conversion upon selection out of the database. > > Namely, error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong > tag error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested > asn1 error > > So, how do I (a) tell Back-SQL that the data is binary or (b) do > something else. You don't need to tell back-sql if data is binary or not: it already knows how to deal with data based on their syntax. You need to tell the RDBMS that its' storing binary data, and store the certificate in the RDBMS as binary. If you store the certificate in base64, then back-sql (actually, the certificate's validator, back-sql yous passes octet strings around) doesn't know what to do with it. > Note that this is the OpenSSL invoked by the X.509 validator > (assuming TLS was turned on), even though the certificate in question > is not being used for TLS. However, the normalization still fails, > even (as mentioned) if validation is disabled. I'm assuming the > normalization failure would be related, although I haven't gotten > there yet. TLS has nothing to do with this. OpenLDAP just needs to be compiled with ssl to have certificate handling routines around. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Syncrepl with SASL External - SOLVED
by Angela Gavazzi 07 Mar '07

07 Mar '07

I found out that the problem was double encrypting of the connection: It works now if I set TLSVerifyClient to max. allow on the consumer side. All stronger configurations end in: CA unknown. Thanks anyway Angela Here the concerning parts of the slapd.conf: ***************************************************************** master: ... ... TLSCACertificateFile /etc/ldap/certs/cacert.pem TLSCACertificatePath /etc/ldap/certs TLSCertificateFile /etc/ldap/certs/erde.aag_cert.pem TLSCertificateKeyFile /etc/ldap/certs/erde.aag_key.pem TLSVerifyClient demand ***************************************************************** slave: TLSCACertificateFile /etc/ldap/certs/cacert.pem TLSCACertificatePath /etc/ldap/certs TLSCertificateFile /etc/ldap/certs/mond.aag_cert.pem TLSCertificateKeyFile /etc/ldap/certs/mond.aag_key.pem ################## TLSVerifyClient demand ################## This has to be set to max allow.

3 3

Re: syncrepl updates from consumer
by Gregor Friedrich 07 Mar '07

07 Mar '07

Hi I read it also and for me it was clear it's not an active active sync...so the docu is n't so bad! Gregor

1 0

openldap 2.2 master and (many) openldap 2.0 slaves
by Cyrille Bollu 07 Mar '07

07 Mar '07

Hi all, just a quick question: Does an openldap 2.2 master replicates with an openldap 2.0 slave? I know that an openldap 2.2 slave cannot replicate with an openldap 2.0 master. (I just discovered it) but will it work the other way round? It's quite important for me to know if I can have some kind of compatibility between openldap 2.0 and 2.2 (or 2.3 maybe) because I have about 20 openldap servers and upgrading all of them during the same night would be ... well, I think you can imagine... Best regards, Cyrille Bollu Responsable système Fedasil - ICT tel: +32.2.213.43.49 gsm: +32.478.23.08.15

1 0

syncrepl updates from consumer
by John Drescher 07 Mar '07

07 Mar '07

I have just added a second openldap server 2.3.30 to my network and setup syncrepl in refreshOnly mode. I connected to the consumer ldap server using a ldap client but when I tried to make a change I got an error stating that I must have an update referral setup. After adding the updateref to my consumer slapd.conf and restarting that I get an error stating that "modifications require stronger authentication desc Strong(er) authentication required." Now if I try to add updatedn to the consumer slapd.conf I get the following error starting the ldap server: <updatedn> database already shadowed Here is the last bit of my slapd.conf from the consumer: syncrepl rid=100 provider="ldap://192.168.1.40:389" binddn="uid=syncuser,ou=People,dc=radimg,dc=pitt,dc=edu" bindmethod=simple credentials=###CHANGED### searchbase="dc=radimg,dc=pitt,dc=edu" filter="(objectClass=*)" attrs"*" schemachecking=off scope=sub type=refreshOnly interval=00:06:00:00 updateref ldap://192.168.1.40 -- John M. Drescher

3 5

Re: syncrepl updates from consumer
by Pierangelo Masarati 06 Mar '07

06 Mar '07

[please keep replies on the list] Matt Benjamin wrote: > Perangelo, > > Is that an accurate statement of what MirrorMode does? I had understood > that only one master was _allowed to be written to_ to maintain > consistency--hence the need for a load-balancer. According to recent commits and posts by Howard, mirror mode seems to allow writes to all masters under the assumption they have tightly sync'ed clocks (namely, under ntp with very low latency). See <http://www.openldap.org/lists/openldap-devel/200702/msg00019.html> and test050 in HEAD code. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: slapd-sql with unixodbc - userCertificate retrieval problem
by Pierangelo Masarati 06 Mar '07

06 Mar '07

Kevin Vargo wrote: > On Wed, 2006-06-07 at 17:31 +0200, Pierangelo Masarati wrote: > >> Store the certificate in the RDBMS in the form that is appropriate for >> its value. In fact, back-sql doesn't do any mucking on the value of >> your certificate; if you base64-encode it, back-sql cannot know. >> Moreover, back-sql is very poor at dealing with binary objects, so you >> might be off even if you succeed in storing the certificate in binary >> form. >> >> I guess a reasonable approach would be to use BLOB data type and make >> sure back-sql can handle it accordingly. >> >> p. > > Has anyone else had success using userCertificates? I've placed the > Base-64 encoded certificate data in the database. However upon attempted > retrieval, I get an error attempting to validate the attribute: > unable to validate value #0 of AttributeDescription userCertificate What the above message says is that it's pointless to store the certificate in the database in base64, because back-sql returns the value as is, and slapd expects it to be an octet string containing the certificate, not its base64 representation. > So I #undef'd the pretty/validate directive in back-sql.h (BACKSQL_PRETTY_VALIDATE) > but this only resulted in getting the normalization error: > unable to normalize value #0 of AttributeDescription userCertificate Same as above. Validators for certificates are already present in slapd, and, of course, they expect valid certificates. > Any ideas? As well, is there any documentation on writing validators? > I wasn't able to locate any so far. Write the certificate to the database as is, not base64 encoded, using a BLOB. And, there's no guarantee it works. As usual, if you succeed, patches are welcome. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software March 2007