Re: (ITS#5203) [LDAP: error code 32 - No Such Object];
by quanah＠zimbra.com
--On Friday, October 26, 2007 10:53 AM +0000 hiremath47(a)gmail.com wrote:
> Full_Name: Siddeshawr
> Version: Version 2.8
> OS:
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (203.92.60.81)
The ITS system is for bug reports, not usage questions. Please use
openldap-software(a)openldap.org for questions you have about using OpenLDAP.
I will also note that "2.8" is not a valid OpenLDAP release.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years, 1 month
(ITS#5203) [LDAP: error code 32 - No Such Object];
by hiremath47＠gmail.com
Full_Name: Siddeshawr
Version: Version 2.8
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (203.92.60.81)
Hi,
If I try to add the following entry into the LDAP
'uid=seal_koa/denage(a)denimvage.com'
javax.naming.NameNotFoundException: [LDAP: error code 32 - No Such Object];
remaining name
at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3013)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2934)
at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2740)
at com.sun.jndi.ldap.LdapCtx.c_lookup(LdapCtx.java:998)
at com.sun.jndi.toolkit.ctx.ComponentContext.c_resolveIntermediate_nns(ComponentContext.java:152)
at com.sun.jndi.toolkit.ctx.AtomicContext.c_resolveIntermediate_nns(AtomicContext.java:342)
at com.sun.jndi.toolkit.ctx.ComponentContext.p_resolveIntermediate(ComponentContext.java:381)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_createSubcontext(ComponentDirContext.java:311)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:248)
at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.createSubcontext(PartialCompositeDirContext.java:236)
at javax.naming.directory.InitialDirContext.createSubcontext(InitialDirContext.java:176)
Please suggest on the same.
Regards,
Siddeshwar
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au
I have now tried:
security tls=128 sasl=128
It didn't work. All the commands below work without
the 'security' option.
ldapsearch -x -ZZ -D "uid=openldap,dc=auth,dc=lubemobile,dc=com,dc=au" -w "$(ssu cat /etc/libnss-ldap.secret)" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)"
ldap_bind: Confidentiality required (13)
additional info: SASL confidentiality required
Which, when I think about it may be reasonable. I am
apparently saying I require a sasl ssf of 128, and
obviously I don't have that. This was a surprise
though:
ldapsearch -ZZ -U "openldap" -b "dc=pwd,dc=lubemobile,dc=com,dc=au" "(uid=it)"
ldap_sasl_interactive_bind_s: Confidentiality required (13)
additional info: SASL confidentiality required
Is that a bug?
Anyway, bugs aside, assuming I now have some idea how it
works its useless for my application. I want to insist
that userPassword to be encrypted when sent and received,
be that via CRAM-MD5 or friends or by using TLS, but clear
text is fine for the rest of the information in the ldap
database, and in fact anonymous connections unencrypted
connections are the rule for VPN access. The 'security'
option applies to all connections.
Anyway, to state the problem as clearly as I can, I can't
see how to do the following combination of things:
. Allow anonymous access over unencrypted connections
for the bulk of the database.
. Allow simple binds, but they must be over encrypted
connections to protect userPassword.
. Allow sasl binds over unencrypted connections, but
the must not use clear text.
. Not particularly relevant to me, but it would be
nice to allow sasl binds using clear text if they
are over an encrypted connection.
The patch does this of course, but if there is some other
way then the patch is irrelevant, except perhaps from a
usability point of view.
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au
On Thu, 2007-10-25 at 16:33 -0700, Howard Chu wrote:
> There are no shortcuts when it comes to security. If you don't take the time
> to understand it you'll get it wrong, period. That's true of all systems, no
> matter how simple or complex - if you don't take the time to understand the
> system's security requirements, you will screw up. As in your example above,
> which should use "auth" access, not "read" access.
I am not sure I agree, but to borrow your words a
discussion about short cuts to security seems
irrelevant to this ITS, as is whether I made a typo
in my example.
The rather long winded rant is relevant in one minor way
(sorry about the length). In your original counter
example, you said correctly "slap_auxprop_lookup" is
doing an internal search and thus doesn't expose the
password. The fact that I would have to know that in
order to realise that "acl ... by tls_ssf=" doesn't do
what I want is what I was railing against. It is purely
a technical detail. When plain text is used, the
password is sent over the connection. The fact happens
not to be the copy in the slapd database (and thus as
you say the copy in the database is infinitely secure)
is irrelevant to me, the user.
You said that if "you don't take the time to understand
[the] security [model], you will get it wrong, period".
Well there is room for movement at both ends. You can
insist the user spends a long time understanding slapd's
security model, or you can make the model easier to
understand. I think the patch does the latter. If you
think I am wrong, ie it makes slapd configuration harder
to understand, then by all means reject it.
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by hyc＠symas.com
russell-openldap(a)stuart.id.au wrote:
> On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote:
>> Using ACLs to enforce this requirement is the wrong approach though. You
>> should just use the "security" directive instead. With your approach you're
>> missing the fact that SASL may not have sent any password at all to slapd
>> (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a
>> constraint that makes no sense.
>
> So you are saying:
>
> security sasl=128 simple_bind=128
>
> would achieve that? I guess it would.
>
> However, with the patch applied this would have the same
> effect, with the addition that if some other authorisation
> mechanism were introduced (eg pam), it would fail unless
> it was encrypted or I explicitly allowed it.
>
> acl <password-stuff>
> by tls_ssf=128 ... read
> by sasl_ssf=128 ... read
> by * none
>
> This may look icky to you, but to someone who is just
> trying to deploy slapd it means there is one less
> slapd.conf option I have to get my head around.
There are no shortcuts when it comes to security. If you don't take the time
to understand it you'll get it wrong, period. That's true of all systems, no
matter how simple or complex - if you don't take the time to understand the
system's security requirements, you will screw up. As in your example above,
which should use "auth" access, not "read" access.
> <rant>
>
> Perhaps ease of configuration doesn't seem so important.
> But I was at a talk given by Andrew Tridgell about why
> he wrote tdb instead of using just using openldap.
> Answer: because it took him 3 days to get slapd
> configured and working. 3 days is an impressively
> short time going on my experiences with it. He actually
> said it wasn't because slapd had bugs, or slapd was too
> slow, or slapd didn't have a feature. It was just
> because in the final analysis, he could not see the
> typical samba user being able to make the thing work.
He should have come and talked to us. (In fact, since then, he has. We've
shown how easily a canned Samba config can be setup, and we'll be
collaborating closely on schema issues and other things down the road.)
> When something is hard to configure typically the doco
> is blamed. But that is often wrong and is wrong in the
> case of openldap. The blame lies with the design of
> the system. The programmers fail to see the
> configuration of the system as another interface. They
> will put hours of work into designing an API, and
> devote 100's of lines of code to making sure that API
> is easy to use, that it hides the complexities of its
> implementation. Yet they ignore configuration, which
> in effect another API - it is the interface between
> the users and the program.
You presume a lot here. Configuration in OpenLDAP 2.3 and 2.4 is a lot more
rational than it ever was in prior releases, and that's because it has been
the focus of considerable attention. The fact that your old methods still
work, allowing you to limp along without reading about all the new methods, is
a testament to the care that was taken in building the configuration enhancements.
> If it had of been an API presented to other
> programmers, I bet the original designer who of thought
> "how can I hide all this behind a simple, clean, easy
> to understand interface". But he didn't, and so now
> openldap deservedly has the reputation as one of the
> harder pieces of open source software to get up and
> going. As a consequence it is deployed a lot less
> than it should be.
Nonsense. The primary reason OpenLDAP has a bad reputation in some circles is
because distros like RedHat continued to bundle obsolete versions years after
they had been dropped by the Project, and so a vast number of users were never
exposed to the myriad improvements made over time. Regardless, OpenLDAP usage
is still growing, and it looks like the growth will continue to accelerate.
None of this discussion is relevant to this ITS.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 1 month
Re: (ITS#5195) ssf not available during sasl bind
by russell-openldap＠stuart.id.au
On Thu, 2007-10-25 at 05:18 -0700, Howard Chu wrote:
> Using ACLs to enforce this requirement is the wrong approach though. You
> should just use the "security" directive instead. With your approach you're
> missing the fact that SASL may not have sent any password at all to slapd
> (e.g., when using DIGEST-MD5 or an OTP mechanism). As such, you're imposing a
> constraint that makes no sense.
So you are saying:
security sasl=128 simple_bind=128
would achieve that? I guess it would.
However, with the patch applied this would have the same
effect, with the addition that if some other authorisation
mechanism were introduced (eg pam), it would fail unless
it was encrypted or I explicitly allowed it.
acl <password-stuff>
by tls_ssf=128 ... read
by sasl_ssf=128 ... read
by * none
This may look icky to you, but to someone who is just
trying to deploy slapd it means there is one less
slapd.conf option I have to get my head around.
<rant>
Perhaps ease of configuration doesn't seem so important.
But I was at a talk given by Andrew Tridgell about why
he wrote tdb instead of using just using openldap.
Answer: because it took him 3 days to get slapd
configured and working. 3 days is an impressively
short time going on my experiences with it. He actually
said it wasn't because slapd had bugs, or slapd was too
slow, or slapd didn't have a feature. It was just
because in the final analysis, he could not see the
typical samba user being able to make the thing work.
When something is hard to configure typically the doco
is blamed. But that is often wrong and is wrong in the
case of openldap. The blame lies with the design of
the system. The programmers fail to see the
configuration of the system as another interface. They
will put hours of work into designing an API, and
devote 100's of lines of code to making sure that API
is easy to use, that it hides the complexities of its
implementation. Yet they ignore configuration, which
in effect another API - it is the interface between
the users and the program.
Like most projects openldap uses many libraries to do
its thing. But makes no attempt to hide that from the
user. In order to configure openldap you have to
understand ldap, sasl, tls, berkley db, but whats
worse you have to understand how they interact with
each other within openldap. For example, ssf is a sasl
concept. simple_bind is an ldap concept. But the
"security" option has "simple_bind=<ssf_factor>", so
suddenly you have to know both, even if you have no
intention of using one of them. Ick, ick, ick.
If it had of been an API presented to other
programmers, I bet the original designer who of thought
"how can I hide all this behind a simple, clean, easy
to understand interface". But he didn't, and so now
openldap deservedly has the reputation as one of the
harder pieces of open source software to get up and
going. As a consequence it is deployed a lot less
than it should be.
</rant>
16 years, 1 month
Re: (ITS#5202) ldapsearch -E pr segfault
by kurt＠OpenLDAP.org
On Oct 25, 2007, at 9:35 PM, hyc(a)symas.com wrote:
> That doesn't make any sense, the fix for ITS#5100 is not in 2.3.38.
After double checking, this issue is the result of a local source
merge issue.
I withdraw this ITS.
-- Kurt
16 years, 1 month
Re: (ITS#5202) ldapsearch -E pr segfault
by hyc＠symas.com
ando(a)sys-net.it wrote:
> kurt(a)OpenLDAP.org wrote:
>> Full_Name: Kurt Zeilenga
>> Version: 2.3.38
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (75.141.229.206)
>>
>>
>> Here's a stack trace; the command was:
>> % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn
>> .
>> .
>> (gdb) where
>> #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6
>> #1 0x0053172b in free () from /lib/tls/libc.so.6
>> #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149
>> #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260
>> #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285
>> #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0,
>> count=-1) at common.c:1250
>> #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794
>>
>> It's done the bind ok by this stage but never gets as far as sending the search
>> request.
>
> I think this could be a consequence of fixing ITS#5100: probably,
> ldapsearch's call of ldap_control_free() was incorrectly relying on its
> broken behavior.
That doesn't make any sense, the fix for ITS#5100 is not in 2.3.38.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 1 month
Re: (ITS#5202) ldapsearch -E pr segfault
by ando＠sys-net.it
kurt(a)OpenLDAP.org wrote:
> Full_Name: Kurt Zeilenga
> Version: 2.3.38
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.141.229.206)
>
>
> Here's a stack trace; the command was:
> % ldapsearch -x -E pr=2/noprompt -b "o=test2,o=test" -s one "cn=*" cn
> .
> .
> (gdb) where
> #0 0x005303d4 in _int_free () from /lib/tls/libc.so.6
> #1 0x0053172b in free () from /lib/tls/libc.so.6
> #2 0x004201e3 in ber_memfree_x (p=0x805405d, ctx=0x0) at memory.c:149
> #3 0x001d85e8 in ldap_control_free (c=0xbfe3ecd0) at controls.c:260
> #4 0x001d8669 in ldap_controls_free (controls=0x9c801c8) at controls.c:285
> #5 0x0804f703 in tool_server_controls (ld=0x9c76550, extra_c=0xbfe3ece0,
> count=-1) at common.c:1250
> #6 0x0804b910 in main (argc=14, argv=0xbfe40e44) at ldapsearch.c:794
>
> It's done the bind ok by this stage but never gets as far as sending the search
> request.
I think this could be a consequence of fixing ITS#5100: probably,
ldapsearch's call of ldap_control_free() was incorrectly relying on its
broken behavior.
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
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
---------------------------------------
16 years, 1 month
Re: (ITS#5202) ldapsearch -E pr segfault
by quanah＠zimbra.com
--On Thursday, October 25, 2007 5:11 PM +0000 kurt(a)OpenLDAP.org wrote:
> Full_Name: Kurt Zeilenga
> Version: 2.3.38
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (75.141.229.206)
Brandon Hume also sees this behavior:
/opt/csw/bin/ldapsearch -x -b dc=bofh,dc=ca -h localhost -E pr=2
'(objectclass=*)' dn
# search result
search: 2
result: 0 Success
control: 1.2.840.113556.1.4.319 false MAkCAQAEBAIAAAA=
control: 1.2.840.113556.1.4.319 false MAkCAQAEBP////8=
Press [size] Enter for the next {2|size} entries.
Where obviously that second value is bogus.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
16 years, 1 month
