13 LDAP queries for one authorize!

[Phil Mayers]

On Sat, 2007-08-25 at 21:12 +0200, Turbo Fredriksson wrote:
> Quoting Phil Mayers <p.mayers at imperial.ac.uk>:
> 
> >> > 2) INNER Auth part ensures that the ldap module is only called for the
> >> > INNER part of the check...not for everything else. also very very useful
> >> > as it stops outer ID junk and debris from being checked.
> >> 
> >> What IS 'the INNER part' (may depend on the answer on my first question
> >> above) as opposed to 'the outer'? In context I get the general idea, but
> >> the actual definition on INNER and OUTER?
> >
> > You're getting hung up on the specifics, which is probably my fault for
> > giving minimal info; Autz-Type is a general mechanism. Please see
> > doc/Autz-Type for more info.
> 
> I'm only slightly wiser from reading that... Shouldn't 'eap' and 'mschap'
> be in this Authz-Type to then?

No


> ----- s n i p ----
> authorize {
>         preprocess
>         auth_log
>         chap
>         mschap
>         digest
>         IPASS
>         suffix
>         realmpercent
>         ntdomain
>         eap
>         files
>         Autz-Type INNER {
>                 ldap
>         }
> }
> ----- s n i p ----
> 
> 
> What I don't understand is why everything is done so many times! The
> 'authorize' section is done a whole bunch of times, just to authenticate
> ONE user [request].

No. The authorize section is run once per request.

What you are missing is that EAP authentication usually involved two
authentication algorithms - an outer versus an inner - and always
involves MANY request-response pairs, like so (this is just an
indicative example - it's more complex than this):

Nas 1: Access-Request EAP-Message (eap-type=foo)
Srv 1: Access-Challenge EAP-Message (eap-nak, try type PEAP)
Nas 2: Access-Request EAP-Message (eap-type=PEAP)
Srv 2: Access-Challenge EAP-Message (first bit of server TLS setup)
Nas 3: Access-Request EAP-Message (first bit of client TLS setup)
Srv 3: Access-Challenge EAP-Message (complete TLS setup)
Nas 4: Access-Request EAP-Message TLS-encrypted(EAP-MSCHAP start)
Srv 4: Access-Challenge EAP-Message TLS-encrypted(EAP-MSCHAP challenge)
Nas 5: Access-Request EAP-Message TLS-encrypted(EAP-MSCHAP reponse)
Srv 5: Access-Challenge EAP-Message TLS-encrypted(EAP-MSCHAP ok)
Nas 6: Access-Request EAP-Message TLS-encrypted(EAP-done?)
Srv 6: Access-Accept EAP-Message TLS-encrypted(EAP-done?)

If you look at the request/response pairs 4 & 5, these are the "inner"
request. The way FreeRadius handles these is after TLS-decryprting them,
it "proxies" them to itself.

When you say:

DEFAULT	FreeRadius-Proxied-To == 127.0.0.1, Autz-Type := INNER

...and this:

authorize {
  preprocess
  eap
  files
  Autz-Type INNER {
    ldap
  }
}

...what you are instructing the server is to to this:

 * for each request, run the modules
   * preprocess
   * eap
   * files
   * if the Autz-Type is set, then run the modules inside there

 * inside the "files" request, if this request is an EAP "proxied to
myself" request, set the Autz-Type

Clear?
 

> If I have undestood the Authz-Type file correctly (which I'm quite sure
> I haven't), I'd put the whole 'authorize' section in a 'Authz-Type' section!

Well no, obviously not - that would be pointless.

For dealing with the EAP inner versus outer requests, one would
normally run the bar minimum modules directly in authorize (preprocess,
eap, files) then run the rest of the modules only for the inner auth
type

The upcoming FreeRadius 2.0 handles this better.