On Thu, Jan 21, 2010 at 1:48 AM, Alan DeKok <al...@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 "u...@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
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html