Help configuring FreeRADIUS on OS X Server - ERROR: (2) mschap: ERROR: (null): status = eServerError

[Alan DeKok]

On Dec 4, 2018, at 8:38 PM, Eric Wittle <eric at wittle.net> wrote:
> If you look at the “Appendix A” section below, you’ll see the debug output (just the packet part, I skipped the config dump, since I’ve sent it already earlier in this thread). It sure looks to me like a successful authentication against OpenDirectory, because of the following at the end:
> 
> “(1) Login OK: [eric/<via Auth-Type = mschap>] (from client router.wittle.net port 0)
> (1) Sent Access-Accept Id 45 from 192.168.1.2:1812 to 192.168.1.1:59532 length 0” 

  That's not good enough.  As you noted earlier, the reply also needs an MS-CHAP-Challenge.  Which it doesn't have.

  So... if you read the debug output, is there an MS-CHAP-Challenge?

> Despite that success, the VPN still reports authentication failure. If my install and configuration is already successfully authenticating against OpenDirectory based on the debug output, what would I learn by running a test without OpenDirectory?

  You would be able to track down exactly where the problem is.

  Right now, you have: (a) FreeRADIUS config, (b) correct password, (c) MS-CHAP authentication, (d) OpenDirectory, and (e) the NAS / VPN concentrator.

  Where is the problem?  You don't know.  The usual process to solve a complex problem is to make the problem simpler.  Eventually you narrow the problem down to just one thing.  Which is then either misconfigured, or misbehaving.

  You *cannot* look at just the Access-Accept, and say "well, it's all fine!".  You already know that the VPN is complaining about no MS-CHAP-Challenge.  And if you read the debug output, you know FreeRADIUS isn't sending one.  Which is should.

  So... maybe the issue os OpenDirectory, or the FreeRADIUS to OpenDirectory integration.

> I thought it a natural next step to look at what successful output meant from this configuration, and whether it was different than successful output from the prior version, which is accepted by the VPN client. I’m not sure why you disagree.

  I don't disagree.  But you're doing the classic flailing around, without really understanding the problem, or narrowing it down:

- looking at the detail file logs, not the debug logs
- looking at the VPN logs
- etc.

  Don't try a bunch of unrelated / useless things.  Read the debug log.  Narrow down the problem.

>> b) with OpenDirectory, but using radtest to send MS-CHAP packets.
>> 
>> i.e. skip the NAS entirely.  Just use RADIUS test tools, and look at the RADIUS debug messages.
> 
> OK, I thought I’d try that, since you suggested it, but again I’m not sure what that is supposed to tell me if the debug output of running with an actual request from the VPN is returning a success code. So I tried it. Here’s the command I used:
> 
> /usr/local/bin/radtest -x -t chap eric <password> 127.0.0.1 0 <secret> 1 192.168.1.1

  At this point I'm going to have to ask that you start paying attention.  Running a test with CHAP is *not* the same thing as running a test with MS-CHAP.  They're different.

  And radtest *can* use MS-CHAP.  The "radtest -h" output shows this.

> The server debug output showed a failure, but it was because of allegedly a secret mismatch. Here’s the output from the server in debug mode:
> 
> "rad_recv: Access-Request packet from host 127.0.0.1 port 64369, id=137, length=81
> Received packet from 127.0.0.1 with invalid Message-Authenticator!  (Shared secret is incorrect.) Dropping packet without response.”

  Yes, that's a shared secret error.

> I thought that was odd, because I’m not seeing anything about secret mismatches when I’m using the actual VPN client.

  Because it's coming from a different IP address.  Note that if you READ the debug output, it shows that the packet is received from 127.0.0.1.  And not 192.168.1.1.

  AND if you read the "radtest -h" output, you will see that you supplied 127.0.0.1 as the server IP, and 192.168.1.1 as at the "nasname".  i.e. NOT the source IP address of the packet.

> So I fired up the 2.2.10 radius install that is working, and it fails the same way with a secret mismatch.

  Because 127.0.0.1 != 192.168.1.1.

  This should be fairly straightforward.  If you want to send packets FROM 192.168.1.1, then you must send packets FROM that IP.

  If you send packets FROM 127.0.0.1, then you must use the shared secret for 127.0.0.1.  See the "clients.conf" file, and look for the client that defines 127.0.0.1.  When sending packets using "radtest" from localhost, use the shared secret from THAT, and not the shared secret for 192.168.1.1.

> Furthermore, because part of the Apple instructions for migrating from their version to the one they recommend people install from OpenSource includes steps to dump the clients data from the existing database and import it into the new database, I still have the tmp file that is generated as part of that process. Here’s the single line from my one client:
> 
> 1,192.168.1.1,router.wittle.net,other,,<secret>,,
> 
> And yes, the <secret> value in the temp file is the same as the secret value I provided to radtest.

  Which is the wrong shared secret.

  You are going over the same thing repeatedly, without paying attention to how things work.  Please take a step back and pay attention.

>> Maybe there's a problem with the OpenDirectory integration in v3.  I don't think so, because others use it, and Apple has instructions for using it.  So it should work.
> 
> I’m not clear that anyone who uses Apple Server is using FreeRADIUS 3.0. As far as I know, I’m running the most recent version of Apple Server that doesn’t remove support for FreeRADIUS entirely, and that is running FreeRADIUS 2.2.10. You might want to read Apple’s instructions for how to install FreeRADIUS 3.0 in their migration guide for migrating services to OpenSource that they published because they’ve removed most of the components of Apple Server in the versions that shipped this fall. If you do, you’ll see at least two egregious errors in their installation instructions. The first is in how to set configuration options for talloc; they specify a configuration command with an argument of “-without-gettext”, which is an invalid argument; it has to be “—without-gettext”. The second, later, is instructions to change the ownership of the plist file with “chmod root:wheel”. If someone knows how to change ownership with chmod rather than chown, I’d be happy to see it.

   Those are both typos, and fairly straightforward ones.  They're not errors which *break* things.

> Since Apple can’t get the FreeRADIUS instructions for building correct, and they’re on version 1.2 of the migration guide without correcting them, I’m not sure I’d assume there are a bunch of FreeRADIUS OpenDirectory installations out there. Given that they have two egregious errors in the build instructions, my confidence in their configuration instructions being completely accurate is low. I’m pretty sure their instructions state to uncomment a specific line in an entire section that ships commented out, for example. That last one is from memory, I haven’t gone back and confirmed. But I will when I finally get this working. Once it is working, I’ll file a bug with Apple so that hopefully they can update the migration guide, and someone else can benefit from the large amount of time I’ve spent on this, and whatever help I end up getting from this list.

  I've been trying to help you.  So far it's not been easy.  You're working *really* hard at doing the wrong thing.  Take a step back.

> Appendix A - Appears to be debug output from a successful authentication
> ========================================================

  And as was noted in earlier messages, it's missing an MS-CHAP-Success attribute in the reply.

  You can't just post the same thing over and over, expecting that it will magically solve the problem.  It won't.

  Read this message a few times.  Take a step back, and *change your approach*.  Do one thing.  If it doesn't work, ask a question.  If it works, do another thing.

  Break the problem down into pieces.  Don't post messages where you try multiple things, and then waste time discovering "bugs", because you got something wrong.  It's frustrating for you, and for us.

  The problem shouldn't be that difficult to track down and/or fix.  But if you waste hours looking at the *wrong shared secret*, those are hours you could have spent more productively.

  Alan DeKok.