Menu
▾
▴
perl-ldap-dev
|
From: Rafael C. <Raf...@li...> - 2001-05-03 09:14:37
|
Hello,
I use Net::LDAP v0.23
Here is an example of an LDIF file:
===============
dn: uid=rco, ou=People, dc=company, dc=com
changetype: modify
add: telephonenumber
telephoneNumber: +41 21 056 00 00
===============
This causes a problem to Net::LDAP::LDIF->_read_one_cmd since the attribut
name use on the "add:" line is not EXACTLY the same as on the next line.
In other words, the AttributeType used on the mod-spec ("add:..." line) is
enterley in lowercase, and the AttributeType used on the attrval-spec is
with mixed case (telephonenumber vs telephoneNumber).
A first warning is issued on line 280 of Net::LDAP::LDIF ($attr is not equal
to $lastattr), and then, the message sent to the server is wrong:
Net::LDAP=HASH(0x8c76b04) sending:
0000 30 118: SEQUENCE {
0002 02 1: INTEGER = 2
0005 66 113: [APPLICATION 6] {
0007 04 38: STRING = 'uid=rco, ou=People, dc=company, dc=com'
002F 30 71: SEQUENCE {
0031 30 24: SEQUENCE {
0033 0A 1: ENUM = 0
0036 30 19: SEQUENCE {
0038 04 15: STRING = 'telephonenumber'
0049 31 0: SET {
004B : }
004B : }
004B : }
004B 30 43: SEQUENCE {
004D 0A 1: ENUM = 0
0050 30 38: SEQUENCE {
0052 04 15: STRING = 'telephonenumber'
0063 31 19: SET {
0065 04 17: STRING = '+41 21 056 00 00 '
0078 : }
0078 : }
0078 : }
0078 : }
0078 : }
0078 : }
In my case I solved the problem putting case insensitive attribute names in
lowercase everywhere. Whet do you think? Is it really important?
Cheers
Rafael
|
|
From: Chris R. <chr...@me...> - 2001-05-03 09:39:27
|
Rafael Corvalan <Raf...@li...> wrote:
> Hello,
>
> I use Net::LDAP v0.23
>
> Here is an example of an LDIF file:
>
> ===============
> dn: uid=rco, ou=People, dc=company, dc=com
> changetype: modify
> add: telephonenumber
> telephoneNumber: +41 21 056 00 00
> ===============
>
> This causes a problem to Net::LDAP::LDIF->_read_one_cmd since the attribut
> name use on the "add:" line is not EXACTLY the same as on the next line.
> In other words, the AttributeType used on the mod-spec ("add:..." line) is
> enterley in lowercase, and the AttributeType used on the attrval-spec is
> with mixed case (telephonenumber vs telephoneNumber).
>
> A first warning is issued on line 280 of Net::LDAP::LDIF ($attr is not
> equal to $lastattr), and then, the message sent to the server is wrong:
[...]
> In my case I solved the problem putting case insensitive attribute names
> in lowercase everywhere. Whet do you think? Is it really important?
It is clearly a bug, and could be easily fixed by doing a uc() on the
various names.
The text after the add/delete/replace is defined to be an
AttributeDescription, ie an attribute name with options like ;binary and
;lang-en_US. So the code needs to account for that too, which it does not
appear to.
However, I'm not sure what that means. For example:
dn: uid=rco, ou=People, dc=company, dc=com
changetype: modify
add: telephoneNumber;work
telephoneNumber;home: +41 21 056 00 00
That's legal in the LDIF spec, but I'm not sure it makes sense. If you omit
the ;home it is still legal, and still doesn't make a lot of sense.
I *suspect* you are meant to ignore any options on the add/delete/replace
line. Anyone else?
> Cheers
> Rafael
>
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-05-03 09:52:39
|
On Thu, May 03, 2001 at 10:39:15AM +0100, Chris Ridd wrote: > The text after the add/delete/replace is defined to be an > AttributeDescription, ie an attribute name with options like ;binary and > ;lang-en_US. So the code needs to account for that too, which it does not > appear to. > > However, I'm not sure what that means. For example: > > dn: uid=rco, ou=People, dc=company, dc=com > changetype: modify > add: telephoneNumber;work > telephoneNumber;home: +41 21 056 00 00 > > That's legal in the LDIF spec, but I'm not sure it makes sense. If you omit > the ;home it is still legal, and still doesn't make a lot of sense. Right, that does not make sense. > I *suspect* you are meant to ignore any options on the add/delete/replace > line. Anyone else? I suspect you are right. Graham. |
|
From: Graham B. <gb...@po...> - 2001-05-03 10:20:31
|
On Thu, May 03, 2001 at 10:51:15AM +0100, Graham Barr wrote: > On Thu, May 03, 2001 at 10:39:15AM +0100, Chris Ridd wrote: > > > The text after the add/delete/replace is defined to be an > > AttributeDescription, ie an attribute name with options like ;binary and > > ;lang-en_US. So the code needs to account for that too, which it does not > > appear to. > > > > However, I'm not sure what that means. For example: > > > > dn: uid=rco, ou=People, dc=company, dc=com > > changetype: modify > > add: telephoneNumber;work > > telephoneNumber;home: +41 21 056 00 00 > > > > That's legal in the LDIF spec, but I'm not sure it makes sense. If you omit > > the ;home it is still legal, and still doesn't make a lot of sense. But is this legal ? dn: uid=rco, ou=People, dc=company, dc=com changetype: modify add: telephoneNumber;work telephoneNumber;home: +41 21 056 00 00 telephoneNumber;work: +41 21 056 00 00 Graham. |
|
From: Chris R. <chr...@me...> - 2001-05-03 10:30:26
|
Graham Barr <gb...@po...> wrote: > On Thu, May 03, 2001 at 10:51:15AM +0100, Graham Barr wrote: >> On Thu, May 03, 2001 at 10:39:15AM +0100, Chris Ridd wrote: >> >> > The text after the add/delete/replace is defined to be an >> > AttributeDescription, ie an attribute name with options like ;binary >> > and ;lang-en_US. So the code needs to account for that too, which it >> > does not appear to. >> > >> > However, I'm not sure what that means. For example: >> > >> > dn: uid=rco, ou=People, dc=company, dc=com >> > changetype: modify >> > add: telephoneNumber;work >> > telephoneNumber;home: +41 21 056 00 00 >> > >> > That's legal in the LDIF spec, but I'm not sure it makes sense. If you >> > omit the ;home it is still legal, and still doesn't make a lot of >> > sense. > > But is this legal ? > > dn: uid=rco, ou=People, dc=company, dc=com > changetype: modify > add: telephoneNumber;work > telephoneNumber;home: +41 21 056 00 00 > telephoneNumber;work: +41 21 056 00 00 > > Graham. > > I'd still say 'no', because of the presence of the ;home value. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-05-03 10:34:25
|
On Thu, May 03, 2001 at 11:30:10AM +0100, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Thu, May 03, 2001 at 10:51:15AM +0100, Graham Barr wrote: > >> On Thu, May 03, 2001 at 10:39:15AM +0100, Chris Ridd wrote: > >> > >> > The text after the add/delete/replace is defined to be an > >> > AttributeDescription, ie an attribute name with options like ;binary > >> > and ;lang-en_US. So the code needs to account for that too, which it > >> > does not appear to. > >> > > >> > However, I'm not sure what that means. For example: > >> > > >> > dn: uid=rco, ou=People, dc=company, dc=com > >> > changetype: modify > >> > add: telephoneNumber;work > >> > telephoneNumber;home: +41 21 056 00 00 > >> > > >> > That's legal in the LDIF spec, but I'm not sure it makes sense. If you > >> > omit the ;home it is still legal, and still doesn't make a lot of > >> > sense. > > > > But is this legal ? > > > > dn: uid=rco, ou=People, dc=company, dc=com > > changetype: modify > > add: telephoneNumber;work > > telephoneNumber;home: +41 21 056 00 00 > > telephoneNumber;work: +41 21 056 00 00 > > I'd still say 'no', because of the presence of the ;home value. So you are saying that the attributes options on the add line are ignored, but all subsequent lines must have the same options Graham. |
|
From: Chris R. <chr...@me...> - 2001-05-03 10:49:51
|
Graham Barr <gb...@po...> wrote: > On Thu, May 03, 2001 at 11:30:10AM +0100, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > On Thu, May 03, 2001 at 10:51:15AM +0100, Graham Barr wrote: >> >> On Thu, May 03, 2001 at 10:39:15AM +0100, Chris Ridd wrote: >> >> >> >> > The text after the add/delete/replace is defined to be an >> >> > AttributeDescription, ie an attribute name with options like ;binary >> >> > and ;lang-en_US. So the code needs to account for that too, which it >> >> > does not appear to. >> >> > >> >> > However, I'm not sure what that means. For example: >> >> > >> >> > dn: uid=rco, ou=People, dc=company, dc=com >> >> > changetype: modify >> >> > add: telephoneNumber;work >> >> > telephoneNumber;home: +41 21 056 00 00 >> >> > >> >> > That's legal in the LDIF spec, but I'm not sure it makes sense. If >> >> > you omit the ;home it is still legal, and still doesn't make a lot >> >> > of sense. >> > >> > But is this legal ? >> > >> > dn: uid=rco, ou=People, dc=company, dc=com >> > changetype: modify >> > add: telephoneNumber;work >> > telephoneNumber;home: +41 21 056 00 00 >> > telephoneNumber;work: +41 21 056 00 00 >> >> I'd still say 'no', because of the presence of the ;home value. > > So you are saying that the attributes options on the add line > are ignored, but all subsequent lines must have the same options > > Graham. No, I'm suggesting that the options mentioned on the add/delete/replace line should "match" the options specified in the values. Match might mean is a "supertype" of, in the sense of RFC 2251 section 4.1.5. But it might not :-) However if you took the alternate definition I suggested (ignore the options mentioned on the add/delete/replace line) then your example would make sense. Is anyone looking at updating RFC 2849? It'd be worth getting some comments from them. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-05-03 10:53:41
|
On Thu, May 03, 2001 at 11:49:36AM +0100, Chris Ridd wrote: > Graham Barr <gb...@po...> wrote: > > On Thu, May 03, 2001 at 11:30:10AM +0100, Chris Ridd wrote: > >> Graham Barr <gb...@po...> wrote: > >> > On Thu, May 03, 2001 at 10:51:15AM +0100, Graham Barr wrote: > >> >> On Thu, May 03, 2001 at 10:39:15AM +0100, Chris Ridd wrote: > >> >> > >> >> > The text after the add/delete/replace is defined to be an > >> >> > AttributeDescription, ie an attribute name with options like ;binary > >> >> > and ;lang-en_US. So the code needs to account for that too, which it > >> >> > does not appear to. > >> >> > > >> >> > However, I'm not sure what that means. For example: > >> >> > > >> >> > dn: uid=rco, ou=People, dc=company, dc=com > >> >> > changetype: modify > >> >> > add: telephoneNumber;work > >> >> > telephoneNumber;home: +41 21 056 00 00 > >> >> > > >> >> > That's legal in the LDIF spec, but I'm not sure it makes sense. If > >> >> > you omit the ;home it is still legal, and still doesn't make a lot > >> >> > of sense. > >> > > >> > But is this legal ? > >> > > >> > dn: uid=rco, ou=People, dc=company, dc=com > >> > changetype: modify > >> > add: telephoneNumber;work > >> > telephoneNumber;home: +41 21 056 00 00 > >> > telephoneNumber;work: +41 21 056 00 00 > >> > >> I'd still say 'no', because of the presence of the ;home value. > > > > So you are saying that the attributes options on the add line > > are ignored, but all subsequent lines must have the same options > > > > Graham. > > No, I'm suggesting that the options mentioned on the add/delete/replace > line should "match" the options specified in the values. Match might mean > is a "supertype" of, in the sense of RFC 2251 section 4.1.5. But it might > not :-) Well the current code requires an exact match. > However if you took the alternate definition I suggested (ignore the > options mentioned on the add/delete/replace line) then your example would > make sense. But it causes problems for the code :( I think for now I will leave it as-is, just fix the case problem. Graham. |
|
From: Kurt D. Z. <Ku...@Op...> - 2001-05-03 15:47:17
|
At 02:39 AM 5/3/01, Chris Ridd wrote: >I *suspect* you are meant to ignore any options on the add/delete/replace >line. Anyone else? Actually for any: add: FOO BAR: xxxx FOO should be equivalent to BAR. Kurt |
|
From: Chris R. <chr...@me...> - 2001-05-03 16:01:56
|
"Kurt D. Zeilenga" <Ku...@Op...> wrote: > At 02:39 AM 5/3/01, Chris Ridd wrote: >> I *suspect* you are meant to ignore any options on the add/delete/replace >> line. Anyone else? > > Actually for any: > > add: FOO > BAR: xxxx > > > FOO should be equivalent to BAR. What do you mean by "equivalent" - BAR must be a subtype of FOO? Cheers, Chris |
|
From: Kurt D. Z. <Ku...@Op...> - 2001-05-03 16:34:37
|
At 09:01 AM 5/3/01, Chris Ridd wrote:
>"Kurt D. Zeilenga" <Ku...@Op...> wrote:
>> At 02:39 AM 5/3/01, Chris Ridd wrote:
>>> I *suspect* you are meant to ignore any options on the add/delete/replace
>>> line. Anyone else?
>>
>> Actually for any:
>>
>> add: FOO
>> BAR: xxxx
>>
>>
>> FOO should be equivalent to BAR.
>
>What do you mean by "equivalent" -
I mean that they refer to same attribute type and have the same
set of options. Most LDIF implementations however only consider
attribute descriptions which differ by case alone as being equivalent.
However, one could allow:
- alternative attribute type names
CN vs 2.5.4.3
- differing option order
For example, the following are equivalent:
2.5.4.3;lang-en;binary
CN;binary;lang-en
I note that the latter is the proper form as NAMEs are preferred
over OIDs and options should be presented in ascending order.
>BAR must be a subtype of FOO?
No! That would make FOO and BAR non-equivalent types and hence
non-equivalent attribute descriptions.
|
|
From: Fox <ld...@cd...> - 2001-05-03 19:36:47
|
Hi,
I am trying to authenticate from perl-ldap via sasl to an openldap 2.07
server and I am getting a "Strong authentication not supported" error
message each time. This all works just fine with a regular bind without
sasl. Openldap is compiled with sasl, md5 support and the works.
My perl script, openldap configuration, openldap slapd.conf, openldap debug
results are below.
Does any have an idea what is happening? I can give more details if you
just let me know.
Thanks,
Fox
Here is my perl script:
#!/usr/bin/perl
use Net::LDAP;
use Authen::SASL;
$sasl = Authen::SASL->new('CRAM-MD5', password => 'mypassword');
$ldap = Net::LDAP->new('leconte.mckee.com') or die "$@";
$mesg = $ldap->bind('cn=Manager,dc=mckee,dc=com', sasl => $sasl, version =>
3);
print $mesg->error . "\n";
Here are the debug results from openldap v2.07 w(-d 1):
@(#) $OpenLDAP: slapd 2.0.7-Release (Thu May 3 15:12:17 EDT 2001) $
ro...@le...:/usr/local/src/openldap-2.0.7/servers/slapd
daemon_init: listen on ldap:///
daemon_init: 1 listeners to open...
ldap_url_parse(ldap:///)
daemon: socket() failed errno=22 (Invalid argument)
daemon: initialized ldap:///
daemon_init: 1 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
/opt/openldap/etc/openldap/slapd.conf: line 15: unknown directive
"cachesize" ou
tside backend info and database definitions (ignored)
/opt/openldap/etc/openldap/slapd.conf: line 16: unknown directive
"dbcachesize"
outside backend info and database definitions (ignored)
slapd startup: initiated.
slapd starting
ldap_pvt_gethostbyname_a: host=leconte.mckee.com, r=0
connection_get(9): got connid=0
connection_read(9): checking for input on id=0
ber_get_next
ber_get_next: tag 0x30 len 48 contents:
do_bind
ber_get_next
ber_get_next on fd 9 failed errno=11 (Resource temporarily unavailable)
ber_scanf fmt ({iat) ber:
ber_scanf fmt ({a) ber:
ber_scanf fmt (}}) ber:
do_sasl_bind: dn (cn=Manager,dc=mckee,dc=com) mech CRAM-MD5
send_ldap_result: conn=0 op=0 p=3
send_ldap_response: msgid=1 tag=97 err=7
ber_flush: 14 bytes to sd 9
<== slap_sasl_bind: rc=7
connection_get(9): got connid=0
connection_read(9): checking for input on id=0
ber_get_next
ber_get_next on fd 9 failed errno=0 (Success)
connection_read(9): input error=-2 id=0, closing.
connection_closing: readying conn=0 sd=9 for close
connection_close: conn=0 sd=9
Here is the script I used to compile openldap v2.07:
LDFLAGS=-L/opt/openssl/lib CPPFLAGS=-I/opt/openssl/include \
./configure --prefix=/opt/openldap --with-cyrus-sasl --enable-spasswd --enab
le-crypt --with-tls
make depend
make
make install
Here is my slapd.conf:
# $OpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.8.8.4 2000/08/26 17:06:18
kurt Exp $
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /opt/openldap/etc/openldap/schema/core.schema
# Global schemas added by Charles
include /opt/openldap/etc/openldap/schema/cosine.schema
include /opt/openldap/etc/openldap/schema/inetorgperson.schema
# Local schemas added by Charles
include /opt/openldap/etc/openldap/schema/local.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /opt/openldap/var/slapd.pid
argsfile /opt/openldap/var/slapd.args
# Load dynamic backend modules:
# modulepath /opt/openldap/libexec/openldap
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# Global stuff added by Charles
defaultaccess none
#######################################################################
# ldbm database definitions
#######################################################################
database ldbm
suffix "dc=mckee, dc=com"
rootdn "cn=Manager, dc=mckee, dc=com"
index employeeNumber eq
index cn eq,subinitial,subany
index givenName subinitial
index displayName subinitial
index uid eq
index mckeeSecondaryUids eq
index sn eq,subinitial
index employeeType eq
index mckeeEmploymentStatus eq
index mckeeSSN eq
index mckeeUnixNumber eq
# Performance stuff added by Charles
cachesize 20000
dbcachesize 100000000
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw mypassword
# The database directory MUST exist prior to running slapd AND
# should only be accessable by the slapd/tools. Mode 700 recommended.
directory /opt/openldap/var/openldap-ldbm
# Indices to maintain
index objectClass eq
|
|
From: Fox <ld...@cd...> - 2001-05-03 21:55:31
|
By creating an /etc/sasldb with saslpasswd I was able to now get the error message "no secret in database" rather than "Strong authentication not supported". I tried creating a user of cn=Manager,dc=mckee,dc=com and just a plain Manager account and I still can't authenticate via sasl. There are three openldap options for slapd.conf: sasl-host sasl-realm sasl-secprops The server where I have the ldap server and /etc/sasldb is leconte.mckee.com. Should I set my sasl-realm and sasl-host both to leconte.mckee.com, or should I leave one empty. Is there any documentation I can read to get a clue how to do this, for I am clueless..? Thanks, Fox ####################################################################### # ldbm database definitions ####################################################################### database ldbm suffix "dc=mckee, dc=com" rootdn "cn=Manager, dc=mckee, dc=com" |
|
From: Graham B. <gb...@po...> - 2001-05-03 09:50:50
Attachments:
ldif.pat
|
On Thu, May 03, 2001 at 11:14:19AM +0200, Rafael Corvalan wrote:
> Hello,
>
> I use Net::LDAP v0.23
>
> Here is an example of an LDIF file:
>
> ===============
> dn: uid=rco, ou=People, dc=company, dc=com
> changetype: modify
> add: telephonenumber
> telephoneNumber: +41 21 056 00 00
> ===============
>
> This causes a problem to Net::LDAP::LDIF->_read_one_cmd since the attribut
> name use on the "add:" line is not EXACTLY the same as on the next line.
> In other words, the AttributeType used on the mod-spec ("add:..." line) is
> enterley in lowercase, and the AttributeType used on the attrval-spec is
> with mixed case (telephonenumber vs telephoneNumber).
>
> A first warning is issued on line 280 of Net::LDAP::LDIF ($attr is not equal
> to $lastattr), and then, the message sent to the server is wrong:
This is a bug. Please try the attached patch.
Graham.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X