Can an EAP-over-RADIUS request ever result in an Access-Reject?

[Alan DeKok]

On Jan 28, 2020, at 5:20 AM, Joe Garcia <joe27256 at gmail.com> wrote:
> 
> Alan DeKok <aland at deployingradius.com> wrote:
> 
>> The Message-Authenticator is calculated from the RADIUS shared secret.  i.e.
>> the secret shared between the RADIUS client and server.
>> 
>> It has nothing to do with the users password.
> 
> It does if it's being used as a generic EAP-TTLS authentication
> mechanism and the client just has a username+password, i.e. the RADIUS
> shared secret is the same as the password used with EAP-TTLS. In other
> words the client is being told to authenticate with EAP-TTLS and given
> a username + password, they don't have, or even know, that there's a
> second, different password to use with RADIUS vs. whatever they're
> running over EAP-TTLS.

  I'm not sure I understand that run-on sentence.

  But from what I do, the configuration is *deliberately* broken.  Plus, if you're asking questions, it helps to ask the RIGHT questions.  It's annoying to discover that the question you asked isn't *really* the question you want answered.

  No, RADIUS and EAP-TTLS aren't broken.  No, they're not designed by idiots.  Yes, if you *deliberately* break them, they will break.

  Don't throw rocks through your office windows and then complain that they're broken.

> I realize the answer is probably "don't do that, then", but the server
> is a third-party service that can't be changed.

  Tell them they're idiots, and that their idiotic decisions have made it impossible to do anything intelligent.

  Alan DeKok.