Can an EAP-over-RADIUS request ever result in an Access-Reject?
aland at deployingradius.com
Tue Jan 28 13:45:20 CET 2020
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.
More information about the Freeradius-Users