yet ANOTHER EAP-TTLS/PAP with OpenLDAP problem ...

[Sylvain Robitaille]

I appreciate all the replies so far.  I'm responding to several at once
here, in order of appearance in my mail spool ...


On Sat, 29 Mar 2008, Arran Cudbard-Bell wrote:

> I Noticed from that sample hash, your passwords have the correct {SSHA} 
> prefix, this means you should be able to use
>
>
> ldap {
> 	auto_header = yes
>
> }
>
> And the server will automatically write the hash to the correct
> internal attribute. ...

I will definitely give that a try on Monday morning.  I wasn't aware
that the ldap module also had an auto_header parameter.  I have it set
for the pap module already, but will try with the ldap module and report
back.

> I have no idea what password_radius_attribute is ?? Is that a legacy 
> configuration item ?

I don't think so.  I only learned about it this week, though that isn't
to suggest that it wasn't around previously.  I learned about this from
reading doc/rlm_ldap that ships with freeradius-server-2.0.3.  That file
says the following about this parameter:

#       password_radius_attribute: Defined the RADIUS attribute where
#       the extracted user password will be stored to. Can be used to
#       set it to NT-Password or any other similar attribute instead of
#       the default
#
#       default: User-Password
#
#       password_radius_attribute = "NT-Password"

> If your password is indeed stored in the LDAP 'userPassword' attribute
> which is the default then:
> ...
>                password_attribute = userPassword
> should suffice.

Agreed, but I wasn't able to get even radtest working against users in
LDAP with that.  I came to understand that this was because in that case
rlm_pap wasn't receiving the password in User-Password and therefore it
was comparing the plaintext password from the authentication request
with the encrypted password from the LDAP backend.  Of course that
wouldn't match.

> The other way you can do this is by using the LDAP module as an
> authentication module. When used in the authentication section it'll
> attempt to bind to the LDAP server using the users UID and Password. I
> wouldn't recommend it in your case though, as binds are comparatively
> slow, and it'll only work with PAP.

That is what we have in place now, with FreeRADIUS-1.1.6, and which
works, but indeed is giving us performance headaches.  I wasn't aware
that binds are slower than queries, though I suppose it makes sense that
they would be, and I don't doubt that a different configuration would
have it working better.


On Sat, 29 Mar 2008, Alan DeKok wrote:

> It really depends on what you're doing.  The recommendations against
> setting Auth-Type are there because almost everyone gets it wrong.
> There *are* situations where setting it is the right thing to do.  But
> it's almost always wrong...

I can accept that, and I'm not convinced that it's necessarily the
"best" way to get what I want in our installation (after all, what I
really want is the LDAP query to provide the *authorization*, and let
the authentication be done by the PAP module).  However, at the time
I did it, it seemed to be the only thing I was able to do to get it
working against LDAP data at all, after much research and trial and
error.  I din't feel I could argue very much with "it works".  ;-)

>> [ASIDE]
>>    With the older versions of FreeRADIUS we're having performance
>>    problems with the authentication.  ...
>
> Run it in debugging mode to see what the problem is. ...

To be honest, my interest now is primarily in getting the setup I've
been working on with 2.0.3 working correctly and replacing the old setup
with that.  I know I'm close and I feel that I'm aiming in a more
technically "correct" direction, so it seems better to me to focus my
efforts on that right now.

It might still be interesting just to _know_ what's slowing the RADIUS
server down, though.

> There isn't really a whole lot that can go wrong with the server.  If
> it's waiting more than 30 seconds to respond, then the likelihood is
> that it's doing DNS lookups, and DNS is broken.

Hrmmm...  I have "hostname_lookups = no" on both my existing (1.1.6)
installation and the new one I'm working on (2.0.3), but of course
*some* DNS lookups would still be expected (I have multiple LDAP servers
configured, by hostname, for example), and although I don't have any
other evidence that there is anything at all wrong with our DNS
resolvers, I have to admit that I hadn't even considered this
possibility, and it obviously shouldn't be overlooked.  I could rule it
out (or work around it) by setting up a caching resolver on the system.
I'll consider doing that if I'm no further ahead with 2.0.3 by the end
of Monday.

> You may need to install "sites-available/inner-tunnel".

I did.  I spotted the hanging sym-link, and references to it in earlier
discussion on this mailing list.  Once I'd gotten that done, I thought
I'd gotten it all in place, but I'm still stuck.  :-(

>>   WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm!
>> Cancelling invalid proxy request.
>>
>> Is this caused by the following in raddb/sites-*/inner-tunnel?
>
>  Yes.  The message is there to warn people about common
> misconfigurations.  Don't worry about it.

Thanks.

>> The text "User-Password" appears in exactly the following places in
>> my raddb directory (not counting comment lines):
>
> That's not the issue.  The issue is that the rlm_ldap module is
> reading the "userPassword" ldap field, and creating a User-Password
> attribute.  It could really be fixed.

By patching rlm_ldap, you mean, or by adjusting my configuration?

> It doesn't work because the PAP module isn't doing anything.  The PAP
> module *should* be taking the crypt'd password, and doing something
> useful with it.  (See "man rlm_pap")

Agreed.  I'm pretty sure that it was after reading "man rlm_pap" that I
went on a search that led me to the password_radius_attribute parameter in
my configuration for the ldap module (which I'm told in a later message
quoted below is not recognized by rlm_ldap anyway).  The exact sequence
of what I read when is a little blurry by now, I have to admit.

> Yes... because it's behaving differently.  See the debug output for
> what differences there are.

Ok, but what I'm stuck on is *why* the differences are there.  I don't
doubt I've done something wrong, but I'm unable to figure out what it is
that I've done wrong.

>> and radeapclient against a user in the users file (success using md5
>> as the default_eap_type, but not ttls),
>
> Because you're putting a clear-text password in the "users" file, not
> a SSHA encrypted blob like you're getting from LDAP.

Yes.

> Compare apples to apples, not apples to oranges.  If you put the
> *same* SSHA blob you get from ldap into the "users" file, then it
> would likely behave differently...

Ok, and then I'll need to put the blob in a SSHA-Password attribute,
correct?  (I will try this on Monday, if I haven't found or gotten an
answer to it already by then).  In which case I'm left still trying to
get the ldap module to do the same, which I thought I had done, but
perhaps haven't done correctly?


On Sat, 29 Mar 2008, Phil Mayers wrote:

> I don't have a copy of 2.0.3 handy, but this looks like a bug to me at
> ~line 383 of rlm_pap.c:
>
> case PW_PROXY_TO_REALM:
> {
>        REALM *realm = realm_find(vp->vp_strvalue);
>        if (realm && !realm->auth_pool) {
>                return RLM_MODULE_NOOP;
>        }
>        break;
> }

I've compared the above (from 2.0.3) with the same section of code in
rlm_pap.c from 1.1.6:

     384    case PW_PROXY_TO_REALM:
     385    {
     386            REALM *realm = realm_find(vp->strvalue, 0);
     387            if (realm &&
     388                (realm->ipaddr != htonl(INADDR_NONE))) {
     389                    return RLM_MODULE_NOOP;
     390            }
     391            break;
     392    }

> Shouldn't that be:
>
> if (realm && realm->auth_pool)
>
> i.e. if the realm is known/real *and* has servers i.e. isn't local,
> then no-op?

I would certainly be willing to act as a Guinea-Pig for this on Monday.
What you're saying makes sense to me and I'd certainly like to see that
the solution is this simple.  If no one says outright that the above
code (from 2.0.3) is correct as it is, I'll invert the condition on
Monday morning and try some more.


On Sat, 29 Mar 2008, Phil Mayers wrote:

> First things first - can I clarify that your goal is to have users,
> using EAP TTLS/PAP, authenticating against LDAP entries. The LDAP
> entries are of the form:
>
> dn: cn=j_doe,ou=...
> cn: j_doe
> userPassword: {SSHA}bhjqewhtqothethwe==
>
> Correct?

Yes.

> ...you've trimmed the debug lines above this - not helpful, ...

Sorry.  I didn't expect those lines would be helpful with identifying
the source of the problem.  They looked to me like "everything is normal
up to here ..."  I can repost that, if you think it would help.

> but I think I can see the problem:
>> ...
>> ++[ldap] returns ok
>> ++[expiration] returns noop
>> ++[logintime] returns noop
>> ++[pap] returns noop
>
> Notice that "pap" does a no-op here. As far as I can see, rlm_pap
> should update the request, ...

Your point above.  I'm nowhere near being a RADIUS expert (no way I
could have *found* that myself), but at least I feel I'm following
along ...  :-)

>>   WARNING: You set Proxy-To-Realm = LOCAL, but it is a LOCAL realm! 
>> Cancelling invalid proxy request.
>
> ...try removing the "Proxy-To-Realm" stuff - it's not needed in your
> case.

I can do that, but Alan's point above is that this message is harmless,
and is not relevant to my problem.  Either way is fine with me if I get
the intended result, though certainly "cleaner" is "better".

>>    Replacing User-Password in config items with Cleartext-Password. 
>> Please update your configuration so that the "known good" 
>> clear text password is in Cleartext-Password, and not in User-Password. 
>
> These warnings appear because the Auth-Type defaults to Local

because rlm_pap did a noop above?

>> auth: type Local
>> auth: user supplied User-Password does NOT match local User-Password
>> auth: Failed to validate the user.
>
> ...and the "Local" auth type is handled internally by the server core,
> and doesn't do the magic required to recognize the {SSHA} in the
> User-Password config item.

Right, that's rlm_pap's job.

>> Login incorrect: [j_doe/*SANITIZED*] (from client wireless-mcconnell 
>
> ...hence login fails.

and my users complain.  :-(

> Much later in your email, you list the output of a radtest against
> LDAP.  Because that isn't EAP-TTLS, there's no tunnel and thus the
> rlm_pap bug isn't triggered.

I think I'm still following ...

>> radeapclient against a user listed in the users file still performs the
>> ldap query for authorization (I actually don't want that; I'd like the
>> users file to over-ride the LDAP listing, if an entry is matched in the
>> users file), 
>
> In that case, you will need to configure the server appropriately - in older 
> versions of the server you'd do this:
>
> authorize {
>  preprocess
>  files
>  Autz-Type LDAP {
>    ldap
>  }
> }

Yes.

> ...and in users:
>
> j_doe	Cleartext-Password := "foo"
>
> DEFAULT	Calling-Station-Id == "0011.2233.4455", Auth-Type := Reject
>
> DEFAULT	Autz-Type := LDAP

Yes.

> ...or something like:
>
> authorize {
>  preprocess
>  redundant {
>    files
>    ldap
>  }
> }

I only learned about "redundant" this week.  I expect that will be
useful to me for listing multiple LDAP servers (with parallel copies of
the data), but no, I don't have this.

> ...in 2.x versions of the server you might want to use "unlang"

I'll re-read that, but will worry about this matter only after I get the
authentication working as I intend.

> In my opinion, radeapclient is not terribly useful.
>
> I would recommend compiling eapol_test from the "wpa_supplicant"
> package; it can do a full EAP TTLS/PAP request against a radius
> server.

Thanks.  I'll set that up for testing.

> As has been pointed out in another email, you have set:
>
> modules {
>  ldap {
>    ...
>    password_radius_attribute = "SSHA-Password"
>  }
> }

yes.

> "password_radius_attribute" is not a valid config item for the LDAP
> module; the ldap module will be ignoring it. You don't need it.

Ugh!  See above for where I learned about that parameter in the first
place (doc/rlm_ldap in the freeradius-server-2.0.3 source tree).  Here I
was under the impression that I was doing exactly as needed!  :-(
Indeed the string "password_radius_attribute" shows up _only_ in
doc/rlm_ldap, and not in any source (or header) files.  I should have
thought to check for that in the first place ...

To summarize, the main things I need to look at Monday are:

   - invert the PW_PROXY_TO_REALM test in rlm_pap.c, unless it's declared
     that the test is correct as it is.

   - confure "auto_header = yes" for the ldap module.

   - Consider adding a caching DNS resolver to the systems running RADIUS
     servers.

   - Test with an SSHA hash as the password in the users file, and
     understand exactly what attribute it needs to be in.  Make sure
     that the ldap module is placing the users' passwords in that
     attribute.

-- 
----------------------------------------------------------------------
Sylvain Robitaille                              syl at alcor.concordia.ca

Systems and Network analyst                       Concordia University
Instructional & Information Technology        Montreal, Quebec, Canada
----------------------------------------------------------------------