EAP-TLS User-Name not matching

[Huckle Berry]

On Thu, Jan 21, 2010 at 1:48 AM, Alan DeKok <aland at deployingradius.com>wrote:

>   If you're not going to bother reading the messages here, I don't see
> why you're asking questions.
>
>
>
I thought the golden rule around here was Don't Touch the Conf's, it should
just work. Using that information, I wanted to get everything working under
the default conf before I went making changes.

The other is issue is that this is a production environment I'm working in,
so I can only fiddle with it at night when no one's around and put it back
before morning, and even then it's only once or twice a week I can do this.
This is why I don't get to test every single suggestion the day it is
suggested. I will get to it eventually, but I have to guarantee no one is on
the network first. There is no funding for a test lab yet. So it may take a
few days for me to get output's for these.

So here is my current experiment, change "user" from the users file to read
"user at example.com Proxy-To-Realm := LOCAL, Auth-Type: EAP". What this has
done for me. Now after [pap] has finished I see this output, which looks
promising:
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP NAK
[eap] EAP-NAK asked for EAP-Type/tls
[eap] processing type tls
[tls] Requiring client certificate
[tls] Initiate
[tls] Start returned 1
++[eap] returns handled
Sending Access-Challenge of id 0 to 192.168.1.1 port 3085
    EAP-Message = 0x010300060d20
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0x5c8c8a805d8f877c3b23b024f6c52334
OR I see this after [pap] finishes:
Found Auth-Type = EAP
+- entering group authenticate {...}
[eap] Request found, released from the list
[eap] EAP/tls
[eap] processing type tls
[tls] Authenticate
[tls] processing EAP-TLS
  TLS Length 70
[tls] Length Included
[tls] eaptls_verify returned 11
[tls]     (other): before/accept initialization
[tls]     TLS_accept: before/accept initialization
[tls] <<< TLS 1.0 Handshake [length 0041], ClientHello
[tls]     TLS_accept: SSLv3 read client hello A
[tls] >>> TLS 1.0 Handshake [length 002a], ServerHello
[tls]     TLS_accept: SSLv3 write server hello A
[tls] >>> TLS 1.0 Handshake [length 01cf], Certificate
[tls]     TLS_accept: SSLv3 write certificate A
[tls] >>> TLS 1.0 Handshake [length 0088], CertificateRequest
[tls]     TLS_accept: SSLv3 write certificate request A
[tls]     TLS_accept: SSLv3 flush data
[tls]     TLS_accept: Need to read more data: SSLv3 read client certificate
A
In SSL Handshake Phase
In SSL Accept mode
[tls] eaptls_process returned 13
++[eap] returns handled
Sending Access-Challenge of id 0 to 192.168.1.1 port 3085
    EAP-Message =
0x0104029a0d8000000290160301002a0200002603014b58d66df2beab...
    EAP-Message =
0x654e66d7258c14a9f79bcf1c8ee70bd2b801f39057a0bcaa434ba517...
    EAP-Message =
0x391081d76569059c3613f16442bc0edad9d95016030100880d000080...
    Message-Authenticator = 0x00000000000000000000000000000000
    State = 0x5c8c8a805e88877c3b23b024f6c52334
Finished request 42.

The Windows host now states "Attempting to authenticate" as opposed to
"Vailidating Identity"/"Failed to vaildate identity" as it did before. And
the [tls] module is running now so this is obviously a step in the right
direction. Adding or removing a Cleartext-Password or Reply-Message didn't
affect the output greatly.

~Huckle Berry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20100121/0d412dc1/attachment.html>