Ruby-net-ldap fail

[Bruno Sousa]

Hi,
I am using ruby-net-ldap to connect to a Active Directory server.
The problem is that it only works for users that are in "Users"
Organization unit.
(See attachment) ==> it can connect with joe user. But it fails to
connect with users from OU "terceiros" for example.

why is that?
Is there a better gem for that?

here is the code:
1 require 'rubygems'
2 require 'net/ldap'
3
4 ldap = Net::LDAP.new
5 ldap.host = "10.1.0.32"
6 ldap.port = "389"
7
8 us = "userhere"
9 ps = "passwordhere"
10
11 ldap.authenticate us, ps
12
13 puts ldap.bind
14 puts ldap.get_operation_result.message


regards

Attachments:
http://www.ruby-forum.com/attachment/3918/Untitled.png

 

[Ben Bleything]

Hi,
I am using ruby-net-ldap to connect to a Active Directory server.
The problem is that it only works for users that are in "Users"
Organization unit.
(See attachment) ==> it can connect with joe user. But it fails to
connect with users from OU "terceiros" for example.

why is that?

Likely because the server wants a full DN and ruby-net-ldap is
assuming ou=Users,dc=... behind the scenes. Try to auth using the
full DN, I'll bet it's going to work.

Is there a better gem for that?

There is a better library, yes. http://ruby-ldap.sourceforge.net/

Ben

 

[Glen Holcomb]

Likely because the server wants a full DN and ruby-net-ldap is
assuming ou=3DUsers,dc=3D... behind the scenes. Try to auth using the
full DN, I'll bet it's going to work.


There is a better library, yes. http://ruby-ldap.sourceforge.net/

Ben

In my experience you need to provide (e-mail address removed) as the
username when connecting to AD.

--=20
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can=92t hear a word you=92re saying."

-Greg Graffin (Bad Religion)

 

[brabuhr]

Likely because the server wants a full DN and ruby-net-ldap is
assuming ou=3DUsers,dc=3D... behind the scenes. =A0Try to auth using the
full DN, I'll bet it's going to work.

In an Active Directory environment you can also use the user's UPN
instead of his DN for the bind username.

 

[Glen Holcomb]

In an Active Directory environment you can also use the user's UPN
instead of his DN for the bind username.

Yep, UPN that's the term I couldn't remember so constructed with written
gesticulations.

--=20
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can=92t hear a word you=92re saying."

-Greg Graffin (Bad Religion)

 

[Ben Bleything]

In an Active Directory environment you can also use the user's UPN
instead of his DN for the bind username.

Ahh cool. I've never really worked with AD except to sync it with
openldap so I'm not really familiar with such things.

Ben

 

[Bruno Sousa]

Ahh cool. I've never really worked with AD except to sync it with
openldap so I'm not really familiar with such things.

Ben

I got it working with ruby-ldap.
Is it necessary to specify the organization unit? It's working ONLY if I
specify it:

require "ldap"
require "pp"

$HOST = '10.1.0.3'
$PORT = 389

conn = LDAP::Conn.new($HOST, $PORT)
conn.bind('cn=somebody,ou=terceiros,dc=intranet,dc=example,dc=com',password='secret')

 

[Ben Bleything]

I got it working with ruby-ldap.
Is it necessary to specify the organization unit? It's working ONLY if I
specify it:

Yes, as mentioned before you need to provide the full path (DN) or
similar so that the ldap server can find your user. When you don't,
it assumes you mean ou=Users.

Ben

 

[Bruno Sousa]

Yes, as mentioned before you need to provide the full path (DN) or
similar so that the ldap server can find your user. When you don't,
it assumes you mean ou=Users.

Ben

Is it a library limitation? Or it really should work like this?
I imagined it should work as when you log in windows computers:
username, passwod and Domain. No need for OUs

 

[Ben Bleything]

Is it a library limitation? Or it really should work like this?
I imagined it should work as when you log in windows computers:
username, passwod and Domain. No need for OUs

No, this is How LDAP Works=99. Remember that Active Directory is like
LDAP++... it does things that LDAP doesn't do natively, like
recursively searching the tree for users.

Ben

 

[Glen Holcomb]

Is it a library limitation? Or it really should work like this?
I imagined it should work as when you log in windows computers:
username, passwod and Domain. No need for OUs

You are forgetting that when you log into a Windows computer you have to
specify the domain. That info plus your username become the authentication
string. Microsoft just hides it well.

--=20
"Hey brother Christian with your high and mighty errand, Your actions speak
so loud, I can=92t hear a word you=92re saying."

-Greg Graffin (Bad Religion)

 

[brabuhr]

Is it a library limitation? Or it really should work like this?
I imagined it should work as when you log in windows computers:
username, passwod and Domain. No need for OUs

You could provide your own function to search the tree based
on username to get the DN and then use that to bind.
But then either your directory would need to allow an anonymous
connection search rights or you would need a service account
for the script to use. You would also need to consider the
possibility of duplicate usernames with different DNs (this is
less of an issue in Active Directory since AD is in some ways
still a flat domain with a simulated hierarchy bolted on).
A production implementation would probably want to cache rather
than run an extra search for every authentication request.

Alternatively, you could attempt to authenticate the user in all
possible OUs until one works or all have failed.

Or finally, you can use UPNs if you don't mind being non-portable
to any other LDAP implementations. This is what I do in my own
corporate apps (despite the bad taste it leaves in my mouth).
I've done a couple of variations:
* Ask for "Username" and append the UPN suffix
* Ask for "UPN" and pass it through
* Ask for "Email Address" and hope they enter their
canonical address and not a special alias