I can articulate one particular item that
is probably your major issue.
By default, users in ADAM can not access
much of anything. We ACL’d down as part of “secure by default”
so they can’t see many objects in the naming context.
For the sake of testing, go ahead and add
the ADAM user you have created to cn=readers,cn=roles,<your naming context
name>
Once the ADAM user is in that group, are
they able to see the objects you would like them to see?
If yes, well, that’s one way to do it. J That group will let them
see many objects within that naming context. If you wanted to ACL down further,
you could create your own groups, add the user to that custom group instead of
cn=readers, then acl the appropriate subtrees for that group.
~Eric
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 16, 2004 4:44
PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [ActiveDir] Fw:
perl-ldap with ADAM
Joe,
Can
you point me to more info on setting the permissions of users? I've only
just begun working with LDAP a few days ago and am working with an instance I
installed and ldif files I wrote myself.
Thanks,
Sonya
|
"joe"
<[EMAIL PROTECTED]>
Sent
by: [EMAIL PROTECTED]
07/16/2004 02:17 PM
|
Please
respond to
[EMAIL PROTECTED]
|
|
|
To
|
<[EMAIL PROTECTED]>
|
|
cc
|
|
|
Subject
|
RE: [ActiveDir] Fw: perl-ldap with ADAM
|
|
Sounds like it is permissioning. If you don't
bind with an ID you aren't going to see anything unless you crank down all of
the permissions to nothing. Sounds like the ID you used had very little access.
You should doublecheck what your permissions are set as.
To put it another way, if ADSIEDIT is seeing things which
authenticates when it connects, but you can't see something with a raw LDAP API
call, it is almost certainly authentication.
joe
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Friday, July 16, 2004 4:16 PM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Fw: perl-ldap with ADAM
Hello,
I sent this help request to a perl-ldap list and it was indicated that the
problem may be ADAM specific. The detail are:
I have set up a MS ADAM instance named
cn=examplename,st=wv,c=us. On
install, the LostAndFound, Roles, and NTDS Quotas
objects were created
with dn's CN=LostAndFound,CN=examplename,ST=wv,C=us,
CN=NTDS
Quotas,CN=examplename,ST=wv,C=us, and
CN=Roles,CN=examplename,ST=wv,C=us.
This all displays successfully in ADAM ADSI Edit.
I then added via importing an ldif file a couple
of object instances with
dn's CN=WVAdmin,CN=examplename,ST=wv,C=us and
CN=WVAdmin2,CN=examplename,ST=wv,C=us. These
both also display
successfully in ADAM ADSI Edit.
So then I attempt to use perl-ldap to perform a
search like this:
use Net::LDAP;
$ldap = new Net::LDAP('localhost') or die
"$@";
$ldap->bind( version => 3 );
$mesg = $ldap->search ( base =>
"C=us",
filter => "objectClass=*",
) or die ("Failed on search.$!");
foreach $entry ($mesg->all_entries)
{
$entry->dump;
}
$ldap->unbind;
The result is no entries. I have also tried
narrowing the base to
CN=examplename,ST=wv,C=us with no benefit.
Additionally, I tried binding
to cn=WVAdmin,cn=examplename,st=wv,c=us which does
return a single result
with dn=examplename,st=wv,c=us.
Note that all of the above search attempts resulted in a return code of 0
indicating success.
Any ideas what could be the problem would be greatly appreciated.
Thank you,
Sonya
----- Forwarded by Sonya Lowry/stc on 07/16/2004 01:07 PM -----
|
Chris Ridd <[EMAIL PROTECTED]>
07/16/2004 10:55 AM
|
|
To
|
<[EMAIL PROTECTED]>
|
|
cc
|
<[EMAIL PROTECTED]>
|
|
Subject
|
Re: perl-ldap with ADAM
|
|
On 16/7/04 6:13 pm, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Chris,
> Thanks for your help. Currently, I am
binding with this line:
>
>
$ldap->bind("cn=WVAdmin,cn=examplename,st=wv,c=us");
You need to add the arguments:
password => 'something'
to the bind, as otherwise you will be binding with
a name and no password.
Typically that will succeed, but it'll be
considered the same as anonymous.
However you're using MAD, which doesn't really
implement LDAP in a very
standard way, so it might be doing things
differently.
> and the return code is 0 which I understand
indicates success. However,
> the search result is limited to the single
object
> 'cn=examplename,st=wv,c=us' despite the
presence of several objects with
> dn's like
cn=<name>,cn=examplename,st=wv,c=us.
>
> I've suspected that maybe I simply don't
understand the search mechanism.
> I had assumed that the base of
cn=examplename,st=wv,c=us would direct the
> search through elements with dn's ending with
the string '
> cn=examplename,st=wv,c=us' like
> cn=<name>,cn=examplename,st=wv,c=us.
Is this a correct assumption?
It isn't quite the right way to think about it, as
there are ways for the
search to process other entries too (eg by
following aliases).
Think of it like directories on a disk, except
that DNs are written
little-endian whereas file paths are written
big-endian. A subtree search
essentially searches subdirectories. (Unless
there's a link inside somewhere
that points to another subdirectory somewhere.)
Cheers,
Chris
