Don't set Auth-Type to EAP.  The server will do that for you.  While it
isn't the problem in this case, it will prove problematic for you in the
future.  Don't do it.  Really.  Even in testing.

Now, a TLS Alert, Access Denied problem is described as such from the
SSL_alert_type_string(3) man page:

A valid certificate was received, but when access control was applied,
the sender decided not to proceed with negotiation. This message is
always fatal.

This means that your supplicant is deciding not to proceed with the
authentication for some reason.  You have to figure out why the
supplicant is refusing to complete the authentication.

--Mike

On Thu, 2004-09-16 at 11:41, Martin Pauly wrote:
> Hi everyone,
> 
> I have a trouble building an auth chain for a 
> wireless network using PEAP. 
> In general, it seems that Part 1 (creating the tunnel) 
> of the conversation is successful, but that I get stuck
> at the beginning of Part 2 (exchanging further EAP through 
> the tunnel).
> 
> - No client certificate should be required (thus PEAP)
> - Current supplicant is the one that comes with Windows XP SP2
>   (of course, it's set to do PEAP, without client cert)
> - Wireless AP is a Cisco AP 1210 with firmware 12.2.15 XR1
> 
> the users file is a 1-liner:
> 
> testuser      Auth-Type := EAP, User-Password == "blabla"
> 
> I know Auth-Type := EAP is not recommended, but for testing 
> purposes this should be ok?
> 
> eap.conf looks like:
> 
>       eap {
>               default_eap_type = peap
>               timer_expire     = 60
>               ignore_unknown_eap_types = no
>               cisco_accounting_username_bug = no
>               tls {
>                       private_key_password = *****
>                       private_key_file = ${raddbdir}/certs/key-radius-testserver.pem
>                       certificate_file = ${raddbdir}/certs/cert-radius-testserver.pem
>                       CA_file = ${raddbdir}/certs/unimr-ssl-ca.pem
>                       dh_file = ${raddbdir}/certs/dh
>                       random_file = /dev/urandom
>               }
> 
>               peap {
>                       #  The tunneled EAP session needs a default
>                       #  EAP type which is separate from the one for
>                       #  the non-tunneled EAP module.  Inside of the
>                       #  PEAP tunnel, we recommend using MS-CHAPv2,
>                       #  as that is the default type supported by
>                       #  Windows clients.
>                       default_eap_type = mschapv2
>                       copy_request_to_tunnel = yes
>                       use_tunneled_reply = no                 
>                       proxy_tunneled_request_as_eap = yes
>               }
> 
>               mschapv2 {
>               }
>       }
> 
> 
> Now the (hopefully) relevant parts from freeradius -X:
> [...]
> Module: Loaded eap 
>  eap: default_eap_type = "peap"
>  eap: timer_expire = 60
>  eap: ignore_unknown_eap_types = no
>  eap: cisco_accounting_username_bug = no
>  tls: rsa_key_exchange = no
>  tls: dh_key_exchange = yes
>  tls: rsa_key_length = 512
>  tls: dh_key_length = 512
>  tls: verify_depth = 0
>  tls: CA_path = "(null)"
>  tls: pem_file_type = yes
>  tls: private_key_file = "/etc/freeradius/certs/key-radius-testserver.pem"
>  tls: certificate_file = "/etc/freeradius/certs/cert-radius-testserver.pem"
>  tls: CA_file = "/etc/freeradius/certs/unimr-ssl-ca.pem"
>  tls: private_key_password = "omihnl"
>  tls: dh_file = "/etc/freeradius/certs/dh"
>  tls: random_file = "/dev/urandom"
>  tls: fragment_size = 1024
>  tls: include_length = yes
>  tls: check_crl = no
>  tls: check_cert_cn = "(null)"
> rlm_eap: Loaded and initialized type tls
>  peap: default_eap_type = "mschapv2"
>  peap: copy_request_to_tunnel = yes
>  peap: use_tunneled_reply = yes
>  peap: proxy_tunneled_request_as_eap = yes
> rlm_eap: Loaded and initialized type peap
>  mschapv2: with_ntdomain_hack = no
> rlm_eap: Loaded and initialized type mschapv2
> Module: Instantiated eap (eap) 
> [...]
> Ready to process requests.
> 
> [several EAP roundtrips to establish TLS tunnel, including cert exchange]
> 
> rad_recv: Access-Request packet from host 192.168.3.246:21645, id=33, length=331
>       User-Name = "testuser"
>       Framed-MTU = 1400
>       Called-Station-Id = "000d.295f.8f7d"
>       Calling-Station-Id = "000d.2911.9aea"
>       Service-Type = Login-User
>       Message-Authenticator = 0xb16f4e42c1a73a707e80bac33259fdbe
>       EAP-Message = 
> 0x020600c01980000000b61603010086100000820080126d2f1d87e507a1c90fb4a1b6f7a4566b6c2e0a41fe5658c88db97c2206e9fd6c9e02677fda6b7cf36a7f10e3cc916568206014da6bc36ee40bb0dedeb766a258fd43534304879deda3b9e3079e93b297b363f11b9e0f633654b6438607c149f4377f6cf268dc8ebab8cbb47d20b67d9fbf4274c31b2d56ee18ab5c96c86790140301000101160301002089707ff0e94f554b6169353940e4f67ba2e9928eecdfcb3f2f9b37a621b01387
>       NAS-Port-Type = Wireless-802.11
>       NAS-Port = 40
>       State = 0x5783c0c3fa13b02b175cf3614fb74d7d
>       NAS-IP-Address = 192.168.3.246
>       NAS-Identifier = "warz001"
>   Processing the authorize section of radiusd.conf
> modcall: entering group authorize for request 5
>   modcall[authorize]: module "preprocess" returns ok for request 5
>   modcall[authorize]: module "mschap" returns noop for request 5
>     rlm_realm: No '@' in User-Name = "testuser", looking up realm NULL
>     rlm_realm: No such realm "NULL"
>   modcall[authorize]: module "suffix" returns noop for request 5
>   rlm_eap: EAP packet type response id 6 length 192
>   rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
>   modcall[authorize]: module "eap" returns updated for request 5
>     users: Matched testuser at 1
>   modcall[authorize]: module "files" returns ok for request 5
> modcall: group authorize returns updated for request 5
>   rad_check_password:  Found Auth-Type EAP
> auth: type "EAP"
>   Processing the authenticate section of radiusd.conf
> modcall: entering group authenticate for request 5
>   rlm_eap: Request found, released from the list
>   rlm_eap: EAP/peap
>   rlm_eap: processing type peap
>   rlm_eap_peap: Authenticate
>   rlm_eap_tls: processing TLS
> rlm_eap_tls:  Length Included
>   eaptls_verify returned 11 
>   rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange  
>     TLS_accept: SSLv3 read client key exchange A 
>   rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001]  
>   rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished  
>     TLS_accept: SSLv3 read finished A 
>   rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001]  
>     TLS_accept: SSLv3 write change cipher spec A 
>   rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished  
>     TLS_accept: SSLv3 write finished A 
>     TLS_accept: SSLv3 flush data 
>     (other): SSL negotiation finished successfully 
> SSL Connection Established 
>   eaptls_process returned 13 
>   rlm_eap_peap: EAPTLS_HANDLED
>   modcall[authenticate]: module "eap" returns handled for request 5
> modcall: group authenticate returns handled for request 5
> Sending Access-Challenge of id 33 to 192.168.3.246:21645
>       EAP-Message = 
> 0x0107003119001403010001011603010020fc68cdae657b71421e8bcdef9a6d3507fc4feea540e897e360e085108d5f9989
>       Message-Authenticator = 0x00000000000000000000000000000000
>       State = 0x23280f4fc46231f36cdaf71794f3cb09
> Finished request 5
> Going to the next request
> --- Walking the entire request list ---
> Waking up in 3 seconds...
> rad_recv: Access-Request packet from host 192.168.3.246:21645, id=34, length=172
>       User-Name = "testuser"
>       Framed-MTU = 1400
>       Called-Station-Id = "000d.295f.8f7d"
>       Calling-Station-Id = "000d.2911.9aea"
>       Service-Type = Login-User
>       Message-Authenticator = 0xd324542513d19f3d9e78e1efca904c77
>       EAP-Message = 
> 0x02070021198000000017150301001241cdef1148ae6a67de93dff47a67850d1b79
>       NAS-Port-Type = Wireless-802.11
>       NAS-Port = 40
>       State = 0x23280f4fc46231f36cdaf71794f3cb09
>       NAS-IP-Address = 192.168.3.246
>       NAS-Identifier = "warz001"
>   Processing the authorize section of radiusd.conf
> modcall: entering group authorize for request 6
>   modcall[authorize]: module "preprocess" returns ok for request 6
>   modcall[authorize]: module "mschap" returns noop for request 6
>     rlm_realm: No '@' in User-Name = "testuser", looking up realm NULL
>     rlm_realm: No such realm "NULL"
>   modcall[authorize]: module "suffix" returns noop for request 6
>   rlm_eap: EAP packet type response id 7 length 33
>   rlm_eap: No EAP Start, assuming it's an on-going EAP conversation
>   modcall[authorize]: module "eap" returns updated for request 6
>     users: Matched testuser at 1
>   modcall[authorize]: module "files" returns ok for request 6
> modcall: group authorize returns updated for request 6
>   rad_check_password:  Found Auth-Type EAP
> auth: type "EAP"
>   Processing the authenticate section of radiusd.conf
> modcall: entering group authenticate for request 6
>   rlm_eap: Request found, released from the list
>   rlm_eap: EAP/peap
>   rlm_eap: processing type peap
>   rlm_eap_peap: Authenticate
>   rlm_eap_tls: processing TLS
> rlm_eap_tls:  Length Included
>   eaptls_verify returned 11 
>   eaptls_process returned 7 
>   rlm_eap_peap: EAPTLS_OK
>   rlm_eap_peap: Session established.  Decoding tunneled attributes.
>   rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal access_denied  
> TLS Alert read:fatal:access denied 
> rlm_eap_peap: No data inside of the tunnel.
>  rlm_eap: Handler failed in EAP/peap
>   rlm_eap: Failed in EAP select
>   modcall[authenticate]: module "eap" returns invalid for request 6
> modcall: group authenticate returns invalid for request 6
> auth: Failed to validate the user.
> 
> 
> So what's missing? Thanks for any hints
> Martin
-- 

--Mike

-----------------------------------
Michael Griego
Wireless LAN Project Manager
The University of Texas at Dallas



- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to