Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

ldap search not returning a value #58

Closed
cam-stitt opened this Issue · 16 comments

5 participants

Cameron Stitt Steven Xu Ernie Brodeur ELLIOTTCABLE Andreas Falk
Cameron Stitt

Hey,

Having some trouble understanding how this is supposed to work. I have the user authenticating against AD as discussed in #40 & #57 but I cannot get the ldap to perform a search. When I attempt to perform a search through the console it is returning false or nil, depending on how I perform the search. Below is what i think should be working:

@login = "#{login}@#{ldap.base.gsub('dc=', '').gsub(',', '.')}"
filter = Net::LDAP::Filter.eq('dn', @login)
ldap_entry = nil
@ldap.search(:filter => filter) {|entry| ldap_entry = entry}

ldap_entry is nil after doing this.

Any ideas?

Steven Xu
Collaborator

Sounds like the search just isn't returning anything. Are you sure the dn you're looking for actually exists on the LDAP server?

Print out @login and make sure a record actually exists with that dn and that the record is findable with that query given the authentication parameters (admin login vs. anonymous login).

Cameron Stitt

I am 100% sure as it is my dn. It also successfully binds when I test that.

Cameron Stitt

Update:

I noticed in the below method that it just uses @login without doing the username build. However if I use console and change it to match my username build it still doesn't work.

def search_for_login
    DeviseLdapAuthenticatable::Logger.send("LDAP search for login: #{@attribute}=#{@login}")
    filter = Net::LDAP::Filter.eq(@attribute.to_s, @login.to_s)
    ldap_entry = nil
    @ldap.search(:filter => filter) {|entry| ldap_entry = entry}
    ldap_entry
end
Cameron Stitt

Another update.

I ran the search directly on net/ldap using the connection and it returned an error code of 1 which I think is "Operations Error". I can't find the "meaning" of this error apart from that it could be to do with anonymous login? Do you have any knowledge in regards to this?

Steven Xu
Collaborator

I am 100% sure as it is my dn. It also successfully binds when I test that.

What do you mean by it binds successfully when you test it. How are you testing it, and what seems to be the problem with duplicating those results in net/ldap (and in turn this gem)?

Cameron Stitt

What I mean is that the following works successfully:

@ldap.auth 'username', 'password'
@ldap.bind

I think the issue that I am having is out of the scope of this gem. I am currently using Windows (I know, you don't have to tell me) and believe that the issue I am having is due to one of the following:

  • Windows doesn't like you querying ldap. I get an error when i try to do it through windows explorer that matches the error code that is being returned
  • OR it is that I need to get the Admin login from the administrators of our AD/LDAP server. It is managed externally and would require some chasing up.

Thanks for your help

Cameron Stitt cam-stitt closed this
Cameron Stitt

Issue has been resolved. The issue seems to be that my ldap.yml config was not as precise as it needed to be. Furthermore, as I am authenticating against AD i needed to set my attribute to sAMAccountName as this is the attribute that holds the 'username'.

Steven Xu
Collaborator
Ernie Brodeur

My problem is close, but cannot be solved by adjusting the ldap string or ldap server (I have no admin access to it, and I cannot provide a user to search with).

As far as I can tell, the method dn does an anonymous search, which my AD server will reject every single time.

@Cairio140 I currently have a patch for this, I'll push it this weekend when I have some time.

Basically if the server returns no anonymous searching (like many corporate AD tree's do), try a basic login and if that succeeds move on, else fail.

so, to me this issue isn't closed:)

Steven Xu
Collaborator

@erniebrodeur:

This is what basically happens now.

1) Search by attribute (searching with admin credentials if available). For AD, this is often something like samaccountname, which you have to custom set in the configuration.
2) If the attribute search turns up a result, get the dn from that result and bind against the password provided.
3) If the attribute search doesn't turn up a result, use the username builder to generate a dn and bind.

Basically if the server returns no anonymous searching (like many corporate AD tree's do), try a basic login and if that succeeds move on, else fail.

Your description talks about a "basic login", which I'm not familiar with. How would it be different from our fallback dn builder?

In any case, I hope the above has provided a little more context. I'm sure when I look at your patch, it'll make sense to me what you did. Please be sure that it works with the tests or at least leave a note to the effect that it doesn't.

Steven Xu cairo140 reopened this
Ernie Brodeur
ELLIOTTCABLE

Hey! I have no idea who any of you are, or what this project does, but @GitHub has been sending me notifications for this issue nonetheless. Since I’m involved, against my will, I thought I would just add the following:

Right-o, good try, chaps! Keep up the good work, and make this project ship-shape! Quite!

Edit: Oh. Hahaha. You used the @‌name “‌@login‌”. Which I own, apparently. But, since it’s now a ‘reserved word,’ @GitHub won’t allow me to actually log in to that account, to unfollow this issue. FML.

Cameron Stitt

Closing this as my problem that opened the issue was resolved some time ago.

Cameron Stitt cam-stitt closed this
Andreas Falk

@erniebrodeur how did things end up for you? I'm trying to perform a manual search through net-ldap to try to locate my problem.

l = Net::LDAP.new
l.host = <host>
l.port = <port>
l.auth <user>, <pass>
l.bind # returns true

f = Net::LDAP::Filter.eq('sAMAccountName', <accountname>)
l.search(filter: f) { |entry| puts entry} # returns nil and doesn't print anything

Anyone has any tips where to look next or what could be the problem?

Ernie Brodeur

@luuse I never revisited this to be honest. I still have my slightly hacked version in place. Since I didn't need searching, just authentication against our local AD tree, I didn't get as far as making searching work. Sorry I can't be more of a help.

Andreas Falk

My problems seems to be caused by not setting config.ldap_use_admin_to_bind = true in the initializer file causing it to not authenticate before performing the search (totally expected, just me reading the documentation properly ;).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.