Re: Multiple Password Prompts
As I'm troubleshooting this, I generated another question in my head. This time I'll give some freeradius debug (see blocks between "*********"): Here's an exerpt from first try (failure): rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(cn=anonymous)' radius_xlat: 'o=sometree' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=sometree, with filter (cn=anonymous) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user anonymous authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 4 modcall: group authorize returns updated for request 4 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 4 rlm_eap: Request found, released from the list rlm_eap: EAP/ttls rlm_eap: processing type ttls rlm_eap_ttls: 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 ********** modcall[authenticate]: module "eap" returns handled for request 4 modcall: group authenticate returns handled for request 4 Sending Access-Challenge of id 186 to 192.168.3.2:1024 Here's an exerpt from the second attempt (success): rlm_ldap: - authorize rlm_ldap: performing user authorization for anonymous radius_xlat: '(cn=anonymous)' radius_xlat: 'o=sometree' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in o=sometree, with filter (cn=anonymous) rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user anonymous authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" 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/ttls rlm_eap: processing type ttls rlm_eap_ttls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included *********** eaptls_verify returned 11 eaptls_process returned 7 *********** rlm_eap_ttls: Session established. Proceeding to decode tunneled attributes. Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 modcall[authorize]: module "preprocess" returns ok for request 5 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 5 rlm_ldap: - authorize rlm_ldap: performing user authorization for doe_john I looked back through some of the output, and it seems that each time it fails I get "eaptls_process returned 13", but when it is succeeds I get "eaptls_process returned 7". Anyone know what 7 and 13 represent (please don't say 'sucess' or 'failure'...i'm hoping it more meaningful than that). Also, anyone know what the rlm_eap_tls messages mean that accompany the 'returned 13' block? Thanks for any help! ----- Original Message ----- From: ragan_davis@colstate.edu Date: Thursday, August 4, 2005 6:40 pm Subject: Multiple Password Prompts
Hi,
The Odyssey Client prompts at least twice for the password. Once connected, clients can roam across different AP's within the same WLAN with no problems. Has anyone else experienced this problem with a similar configuration?
Running Environment:
-- Freeradius Server = Gentoo Linux running FreeRADIUS v1.0.2 -- User DB = Novell NetWare 6.5 SP3 w/ eDirectory 8.7.3.5 (LDAP) -- Wireless Switch = Cisco Airespace 4100 WLAN Switch with WLAN configured for WPA-TKIP using dynamic key exchange -- Wireless AP = Cisco 1000 Series AP's (was Airespace) -- Wireless Client = Funk Odyssey Client v4.0.1 on Windows XP configured for WPA-TKIP and EAP-TTLS
We have captured debug output on the Odyssey Client, on the Airespace WLAN switch, and on FreeRADIUS, as well as an ethereal sniff on the freeradius interface on the radius server. I can provide these as well as freeradius configs if needed.
Thanks!
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
ragan_davis@colstate.edu wrote:
As I'm troubleshooting this, I generated another question in my head. This time I'll give some freeradius debug (see blocks between "*********"):
Here's an exerpt from first try (failure): ... Sending Access-Challenge of id 186 to 192.168.3.2:1024
That doesn't look like a failure to me. The supplicant may stop talking to the server, and start a new session, but the server thinks everything's OK.
I looked back through some of the output, and it seems that each time it fails I get "eaptls_process returned 13", but when it is succeeds I get "eaptls_process returned 7". Anyone know what 7 and 13 represent (please don't say 'sucess' or 'failure'...i'm hoping it more meaningful than that).
From src/modules/rlm_eap/types/rlm_eap_tls.h: typedef enum { EAPTLS_INVALID = 0, /* invalid, don't reply */ EAPTLS_REQUEST, /* request, ok to send, invalid to receive */ EAPTLS_RESPONSE, /* response, ok to receive, invalid to send */ EAPTLS_SUCCESS, /* success, send success */ EAPTLS_FAIL, /* fail, send fail */ EAPTLS_NOOP, /* noop, continue */ EAPTLS_START, /* start, ok to send, invalid to receive */ EAPTLS_OK, /* ok, continue */ EAPTLS_ACK, /* acknowledge, continue */ EAPTLS_FIRST_FRAGMENT, /* first fragment */ EAPTLS_MORE_FRAGMENTS, /* more fragments, to send/receive */ EAPTLS_LENGTH_INCLUDED, /* length included */ EAPTLS_MORE_FRAGMENTS_WITH_LENGTH, /* more fragments with length */ EAPTLS_HANDLED /* tls code has handled it */ } eaptls_status_t; So I don't see any particular reason why one session would succeed and the other would fail.
Also, anyone know what the rlm_eap_tls messages mean that accompany the 'returned 13' block?
Information about internal TLS stuff. There are a *lot* of TLS packets that go back and forth. At this point, the only thing I can suggest is to put a packet capture on the net somewhere. That might give more information. Alan DeKok.
participants (2)
-
Alan DeKok -
ragan_davis@colstate.edu