Thank you both for this clarification -
It was my mistake, in that when I tried to do:
1: $ldap->add(
'cn='.$myUserObject{cn}.',uid='.${myUserObject}{uid}.',o=att.com',
$myUserObject) # FAILS
As Dieter explains, " the superior distinguished name of the new entry does not
exist "
(ie. cn=$UserName,uid=$UserId,o=att.com), whereas with :
2: $ldap->add( 'uid='.${myUserObject}{uid}.',o=att.com', $myUserObject) #
SUCCEEDS
The superior DN (o=att.com) does exist.
What confused me is that when I list user objects their DNs all print out as
"cn=$user_name,uid=$user_id,o=att.com" ;
I thought that "cn" is just an attribute as is "uid", and by definition, when
creating
a new object, the object that contains cn and uid does not exist ? So I still
don't
quite understand the difference.
So it seems the Net::LDAP issue (very minor bug) is that in case 1 above,
Net::LDAP gets this response:
"
LDAP::process
Net::LDAP=HASH(0xca22c0) received:23 bytes
30 15 02 01 02 69 10 0A 01 20 04 09 6F 3D 61 74 0....i... ..o=at
74 2E 63 6F 6D 04 00 __ __ __ __ __ __ __ __ __ t.com..
0000 21: SEQUENCE {
0002 1: INTEGER = 2
0005 16: [APPLICATION 9] {
0007 1: ENUM = 32
000A 9: STRING = 'o=att.com'
0015 0: STRING = ''
0017 : }
0017 : }
"
And Net::LDAP returns an error status mesg with "resultCode=>32" for the case
#1 add() ;
$VAR1 = bless( {
'parent' => bless( {
'net_ldap_version' => 3,
'net_ldap_scheme' => 'ldap',
'net_ldap_debug' => 1,
'net_ldap_socket' => bless(
\*Symbol::GEN1, 'IO::Socket::INET' ),
'net_ldap_onerror' => sub { "DUMMY" },
'net_ldap_host' => 'localhost',
'net_ldap_uri' => 'localhost',
'net_ldap_resp' => {},
'net_ldap_mesg' => {},
'net_ldap_async' => 0,
'net_ldap_port' => '389',
'net_ldap_refcnt' => 1
}, 'Net::LDAP' ),
'errorMessage' => '',
'ctrl_hash' => undef,
'resultCode' => 32,
'callback' => undef,
'mesgid' => 2,
'matchedDN' => 'o=att.com',
'controls' => undef,
'raw' => undef
}, 'Net::LDAP::Add' );
but I think it should also be returning an "errorMessage=>'no such object'" in
this case,
whereas it returned an empty string in errorMessage - an error string would
have greatly
helped in diagnosing the problem and correcting my mistake.
Thanks & Regards,
Jason
On Friday 17 October 2008 08:28:42 Dieter Kluenter wrote:
> Jason Vas Dias <[EMAIL PROTECTED]> writes:
>
> > Please excuse me if I am misunderstanding something (I'm an LDAP newbie) -
> > but is this a Net::LDAP bug:
> >
> > Supplying an extra attribute to the "dn" of a Net::LDAP::add request,
> > as with:
> >
> > $ldap->add(
> > 'cn='.$myUserObject{cn}.',uid='.${myUserObject}{uid}.',o=att.com',
> > $myUserObject) # FAILS
> >
> > results in an error response with an error code of 32 and an empty error
> > message - while removing the "cn=" portion of the DN allows the add to
> > succeed:
> >
> > $ldap->add( 'uid='.${myUserObject}{uid}.',o=att.com', $myUserObject) #
> > SUCCEEDS
> >
> > It seems to me that if the "FAILS" request contains a bad DN, Net::LDAP
> > ought to
> > detect this and report a "Bad DN" error message, as it does for other types
> > of bad dn .
>
> Error code 32 is 'no such object', that is, the superior distinguished
> name of the new entry does not exist. For more information RFC-4511,
> section 4.1.9 Result Message. In your particular case you want to add
> an object
> dn: cn=some user,uid=some user,o=att.com
> but the superior object of this DN 'uid=some user,o=att.com' does not
> exist. The error is not Net::LDAP related but due to poor tree design.
> You should probably read
> http://www.openldap.org/doc/admin24/
> and some basics on how to design a directory tree and directory
> objects.
>
> -Dieter
>
> --
> Dieter Klünter | Systemberatung
> http://www.dpunkt.de/buecher/2104.html
> GPG Key ID:8EF7B6C6
> 53°08'09,95"N
> 10°08'02,42"E
On Friday 17 October 2008 10:24:51 Graham Barr wrote:
> On Oct 16, 2008, at 6:46 PM, Jason Vas Dias wrote:
> > Please excuse me if I am misunderstanding something (I'm an LDAP
> > newbie) -
> > but is this a Net::LDAP bug:
> >
> > Supplying an extra attribute to the "dn" of a Net::LDAP::add request,
> > as with:
> >
> > $ldap->add( 'cn='.$myUserObject{cn}.',uid='.${myUserObject}
> > {uid}.',o=att.com', $myUserObject) # FAILS
> >
> > results in an error response with an error code of 32 and an empty
> > error
> > message - while removing the "cn=" portion of the DN allows the add
> > to succeed:
>
> What code were you using to get the error message ? In you example you
> are not capturing the response.
>
> It does look like your server is returning an empty message, but if
> you use
>
>
> $mesg = $ldap->add( ....
>
> warn $mesg->error if $mesg->code;
>
> you should see
>
> "No such attribute"
>
> Graham.
>
>
