On 19/01/12 11:07, NdK wrote:
Il 19/01/2012 10:03, Phil Mayers ha scritto:
EAP: deinitialize previously used EAP method (25, PEAP) at EAP deinit
MPPE keys OK: 0 mismatch: 1
FAILURE
These (plus the timeout one) are the lines printed after FR have already
cloded session.
Yes.
Hmm. I see from your original email that Samba& ntlm_auth are succeeding.
Yup. I'm quite used to joining machines to AD... Already have about 100
clients and 5 servers, and this one is the one giving me troubles :(
There are a couple of buggy version of Samba out there that return
invalid response values, and generate these symptoms. Which version of
Samba are you running, and on what OS?
Samba 3.5.6 (latest packaged one) on Debian Squeeze. Once it's working,
I'll have to move the config to a ZeroShell box with Samba 3.5.10.
That version should be ok; we're on 3.5.4
I'm not sure what the problem is then. From your original post, the
authentication is failing at the *client*, in the inner EAP section.
This normally means the final MSCHAP response is invalid, which only
happens if some crypto has gone wrong somewhere.
Another problem I should fix is the fact that ZS's captive portal passes
user@realm credentials instead of realm\user ... rewriting w/ a simple
rule in hints file seems to block the rest, so I left it behind, for now.
You can't alter usernames in EAP. They are usually mixed into the
challenge/response data, and altering them in-flight means the
challenge/response will fail.
To be honest, there's too much going on in your setup; my advice would
be to create a new server (running 2.1.12) and use the default setup.
Test your EAP with eapol_test. Make small changes, storing the config
into version control at each step. Identify exactly which point the
failures start happening at.
Most people don't see this problem, so it's something specific to your
setup.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
