Hi All -
I have some silly questions about ActiveLdap. I'm a pretty new Ruby
programmer, so I may be doing foolish things...
I am trying to connect to and search for records on my ldap server. I have
installed activeldap using gem. My test ruby program looks like this:
::
require 'rubygems'
require 'log4r'
require 'active_ldap'
class Entry < ActiveLdap::Base
ldap_mapping :dn_attribute=>"cn"
end
ActiveLdap::Base.establish_connection(
:host => "ldap-server.domain",
:port => 389,
:bind_dn => "ou=A,ou=B,ou=c,ou=D,o=E,c=US"
)
entry = Entry.find("krwightm")
::
When I run this, I get:
/var/lib/gems/1.8/gems/ruby-activeldap-0.8.1/lib/active_ldap/base.rb:531:in
`find_one': Couldn't find Device with DN=krwightm (cn=krwightm)
(ActiveLdap::EntryNotFound)
If I perform the same query with the command-line tool ldapsearch:
ldapsearch -x -LLL -h ldap-server.domain -p 389 -b
"ou=A,ou=B,ou=C,ou=D,o=E,c=US" "(cn=krwightm)"
I find exactly one entry with cn=krwightm in my ldap. Am I doing everything
correctl in my rubyprogram? From the docs and usage available I think so,
but again I don't know Ruby so well :). Is there a way to verify that my
bind succeeds? Even changing the last line of my program to be:
entry = Entry.find("*")
returns the error.
Thanks much for any guidance,
Reid
The ldapsearch line is setting both a treebase and a search filter. Neither
is present in your ActiveLDAP query. In addition you're passing what you
think is a filter string to Entry.find, whereas it's looking for a DN. (Both
queries are binding anonymously, which is unusual, but you'd have gotten a
different message from ldapsearch if that were a problem.)
Look into the Net::LDAP library on Rubyforge, also installable as a gem. It
has a reasonably complete rdoc, including some theory of how LDAP queries
work.
···
On 5/1/07, Reid Wightman <krwightm@gmail.com> wrote:
Hi All -
I have some silly questions about ActiveLdap. I'm a pretty new Ruby
programmer, so I may be doing foolish things...
I am trying to connect to and search for records on my ldap server. I
have
installed activeldap using gem. My test ruby program looks like this:
::
require 'rubygems'
require 'log4r'
require 'active_ldap'
class Entry < ActiveLdap::Base
ldap_mapping :dn_attribute=>"cn"
end
ActiveLdap::Base.establish_connection(
:host => "ldap-server.domain",
:port => 389,
:bind_dn => "ou=A,ou=B,ou=c,ou=D,o=E,c=US"
)
entry = Entry.find("krwightm")
::
When I run this, I get:
/var/lib/gems/1.8/gems/ruby-activeldap-0.8.1
/lib/active_ldap/base.rb:531:in
`find_one': Couldn't find Device with DN=krwightm (cn=krwightm)
(ActiveLdap::EntryNotFound)
If I perform the same query with the command-line tool ldapsearch:
ldapsearch -x -LLL -h ldap-server.domain -p 389 -b
"ou=A,ou=B,ou=C,ou=D,o=E,c=US" "(cn=krwightm)"
Hi,
You need to add some configurations.
In <2af793440705011250u575c7d7fw7a753655053bc6f8@mail.gmail.com>
"ActiveLdap questions" on Wed, 2 May 2007 04:50:31 +0900,
class Entry < ActiveLdap::Base
ldap_mapping :dn_attribute=>"cn"
ldap_mapping :dn_attribute=>"cn", :prefix => ""
end
ActiveLdap::Base.establish_connection(
:host => "ldap-server.domain",
:port => 389,
:bind_dn => "ou=A,ou=B,ou=c,ou=D,o=E,c=US"
Perhaps, you wanted to specify search base not bind DN. You
need to use :base not :bind_dn for that propose:
:base => "ou=A,ou=B,ou=c,ou=D,o=E,c=US"
)
entry = Entry.find("krwightm")
::
When I run this, I get:
/var/lib/gems/1.8/gems/ruby-activeldap-0.8.1/lib/active_ldap/base.rb:531:in
`find_one': Couldn't find Device with DN=krwightm (cn=krwightm)
(ActiveLdap::EntryNotFound)
Uhm, is your class name really Entry? It seems that your
class name is Device.
Thanks,
···
"Reid Wightman" <krwightm@gmail.com> wrote:
--
kou
Hi,
In <3a94cf510705011421r694abd13sf641b441d2f9d313@mail.gmail.com>
"Re: ActiveLdap questions" on Wed, 2 May 2007 06:21:17 +0900,
Look into the Net::LDAP library on Rubyforge, also installable as a gem. It
has a reasonably complete rdoc, including some theory of how LDAP queries
work.
But Net::LDAP doesn't support START_TLS. I think Net::LDAP
is a low level library rather than ActiveLdap. To modify
a LDAP entry, I prefer
someone = User.find("someone")
someone.description = "Who am I?"
someone.save
rather than
ldap.search(:base => "...", :filter => "cn=someone") do |someone|
if someone.description.empty?
ops = [[:add, :description, "Who am I?"]]
else
ops = [[:replace, :description, "Who am I?"]]
end
ldap.modify :dn => dnsomeone.dn, :operations => ops
end
ActiveLdap has a framework to support Net::LDAP as backend
but Net::LDAP doesn't have enough functions such as
START_TLS support.
Thanks,
···
"Francis Cianfrocca" <garbagecat10@gmail.com> wrote:
--
kou
But Net::LDAP doesn't support START_TLS.
Net::LDAP does support TLS connections (typically over port 636). It doesn't
currently support the STARTTLS verb, but this is planned.
I think Net::LDAP
is a low level library rather than ActiveLdap. To modify
a LDAP entry, I prefer
someone = User.find("someone")
someone.description = "Who am I?"
someone.save
That's really quite a good point. Early on in the development of Net::LDAP,
I thought quite hard about how to make a far-simplified interface to
directory functionality. Some of LDAP's weirdness can be wrapped up, but
some of it is quite hard to do away with. In particular, I tried to solve
the problem of writing LDAP filters by using a search-oriented interface.
But everyone who works with LDAP seems to be quite invested in standard
filters, especially Microsoft, so it seemed like a low-value effort.
Does ActiveLDAP solve this problem by reading the root DSE records and
guessing about things like the treebase, the supported authentication models
and the schema? Or does it require configuration entries to be made
somewhere in the user application?
At the end of the day, I observed what people were doing with Net::LDAP, and
it seems for the most part to be bind-authentication against Active
Directory (and some group-membership querying). Actually maintaining
directory information, as in your example, seems to be a rare use case
indeed. (Most people seem to manage directory data with existing native
tools and with workflow applications tied to HR and CRM apps.) I appreciate
your insights, and if anyone disagrees with me, I'd very much like to hear
from you.
···
On 5/1/07, Kouhei Sutou <kou@cozmixng.org> wrote:
Hi,
In <3a94cf510705011743g3d71b501sfffc66183e519445@mail.gmail.com>
"Re: ActiveLdap questions" on Wed, 2 May 2007 09:43:47 +0900,
>
>
> But Net::LDAP doesn't support START_TLS.
Net::LDAP does support TLS connections (typically over port 636). It doesn't
currently support the STARTTLS verb, but this is planned.
Yes. I know. And I already submitted a patch for supporting
START_TLS 6 months ago:
http://rubyforge.org/tracker/index.php?func=detail&aid=6345&group_id=143&atid=633
That's really quite a good point. Early on in the development of Net::LDAP,
I thought quite hard about how to make a far-simplified interface to
directory functionality. Some of LDAP's weirdness can be wrapped up, but
some of it is quite hard to do away with. In particular, I tried to solve
the problem of writing LDAP filters by using a search-oriented interface.
But everyone who works with LDAP seems to be quite invested in standard
filters, especially Microsoft, so it seemed like a low-value effort.
Does ActiveLDAP solve this problem by reading the root DSE records and
guessing about things like the treebase, the supported authentication models
and the schema? Or does it require configuration entries to be made
somewhere in the user application?
I'm sorry. I don't understand what is the problem but
ActiveLdap uses root DSE to get schema information and
construct accessores dynamically. ActiveLdap doesn't require
any configurations for that.
Thanks,
···
"Francis Cianfrocca" <garbagecat10@gmail.com> wrote:
On 5/1/07, Kouhei Sutou <kou@cozmixng.org> wrote:
--
kou
Somehow I missed that patch. I just added it to Net::LDAP. Sync to head
revision to try it. Thanks, Kouhei.
···
On 5/1/07, Kouhei Sutou <kou@cozmixng.org> wrote:
Yes. I know. And I already submitted a patch for supporting
START_TLS 6 months ago:
http://rubyforge.org/tracker/index.php?func=detail&aid=6345&group_id=143&atid=633