Check LDAP password with SHA512

[Alan DeKok]

On Feb 2, 2016, at 7:13 PM, Will W. <will at damagesinc.net> wrote:
> 
> both accounts are read only administrators..... both have bind rights, both
> accounts are being used in other places for LDAP authentication.

  That may be so.  But... FreeRADIUS isn't an LDAP server.  And we didn't implement an LDAP client.  We just use the normal LDAP APIs.

  If a *NORMAL LDAP QUERY* returns "no data", then the problem is (a) the query, or (b) the permissions of the user doing the query.

  As such, and fix is mostly LDAP.  Not FreeRADIUS.  We don't run your LDAP server, and we don't have access to it.  All we know is that normal LDAP queries return data.

  We've been trying to convince you of that, and are having a hard time.  This is common.  Everyone blames FreeRADIUS for everything.  It's still inappropriate and frustrating for us.

> I am following everyones instructions, here is a recap since I came here
> for help.
> problem 1 needed help with LDAP and SHA512, resolution not supported on
> version 2.x and goto version 3.x

  Version 2 has been officially end of life for over a year.

> problem 2 went to version 3.0.11, had an issue with /dev/urandom,

  You were apparently the only one who used the "random" thing in the LDAP module configuration.  That's why no one ever saw it before.

> resolution was told there was a bug and pushed a fix goto 3.1.0
> problem 3 told to change auth order in default fie, posted radiusd -X out
> put and config, resolution none
> problem 4 went to version 3.1.0, for unknow_error message with
> /dev/urandom, and fixed an issue on the OS side regrading gnutls and
> openssl as Ubuntu and Debian both seem to be baking gnutls into their
> latest brews. Now that the freeradius server I have had to build from
> source can connect over SSL, I am back to the same problem I can not
> authenticate a user on LDAP. resolution being told I can not follow
> instructions

  And the bugs were fixed within a day, once you gave us the right information.

  We've been responsive to your questions.

> Where have I not followed instruction, I have made several course
> correction with shrewd comments and that is fine it gets the problem fixed,
> however the problem is not fixed and I am still having the issue of not
> being able to authenticate a users password with all the documentation and
> instruction I have received.

  Please suggest to us how we can fix an LDAP database so that it returns the correct data.

  When we don't have access to the LDAP database.

  ...

  We can't.  *You* need to do it.  It's been hard for us to convince you that this is the case.

> Seeing how this LDAP system is working on all my systems  in various forms
> and I am using the same user account to bind, what is so different with
> this setup?

  Ask your LDAP database.

> Secondly if it isn't rocket science then you should be able to explain it
> to anyone, especially since all the modification, which have been minimal
> were direct by people from your group and by group I am referring to people
> with @deployingradius.com individuals.

  There's only one person with an email address at that domain: me.

  If you want to berate me, do it directly.

> I am not trying to be rude and I
> have been reading all the documentation I can get my hands on, however I am
> still stuck.

  You did a number of things wrong.  Which were against all existing documentation.

  You then argued for a number of email messages.  It took a while for us to convince you that the FreeRADIUS error messages were meaningful.

> Coming to the e-mail threads has been a last resort of sorts.
> As this project started I never planned to build from source or need to do
> a git pull request to get things working smoothly, but here we are.
> 
> I am just asking for help.

  We're trying to help you.  You're resisting.  Stop it.

  Alan DeKok.