The comments you refer are these ones? "... # This module is the *Microsoft* implementation of MS-CHAPv2 # in EAP. There is another (incompatible) implementation # of MS-CHAPv2 in EAP by Cisco, which FreeRADIUS does not # currently support. mschapv2 { } ..." But I also tried with TTLS using secureW2 supplicant and the log was similar. "... rad_recv: Access-Request packet from host 192.168.2.1 port 1645, id=24, length=155 User-Name = "al00001" Service-Type = Framed-User Framed-MTU = 1500 Called-Station-Id = "00-1E-BD-62-B9-81" Calling-Station-Id = "00-1B-38-92-39-A0" EAP-Message = 0x0203000c01616c3030303031 Message-Authenticator = 0xe63d66c15b1b53a1fe27f788de329cc3 NAS-Port-Type = Ethernet Cisco-NAS-Port = "GigabitEthernet0/1" NAS-Port = 50001 NAS-IP-Address = 192.168.2.1 +- entering group authorize ++[preprocess] returns ok rlm_realm: No '@' in User-Name = "al00001", skipping NULL due to config. ++[suffix] returns noop rlm_realm: No '\' in User-Name = "al00001", skipping NULL due to config. ++[ntdomain] returns noop ++[mschap] returns noop expand: %{Stripped-User-Name} -> expand: %{User-Name} -> al00001 expand: %{%{User-Name}:-none} -> al00001 expand: %{%{Stripped-User-Name}:-%{%{User-Name}:-none}} -> al00001 rlm_sql (sql): sql_set_user escaped user --> 'al00001' rlm_sql (sql): Reserving sql socket id: 2 expand: SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, UserName, Attribute, Value, Op FROM radcheck WHERE Username = 'al00001' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 5 rlm_sql (sql): User found in radcheck table expand: SELECT id, UserName, Attribute, Value, Op FROM radreply WHERE Username = '%{SQL-User-Name}' ORDER BY id -> SELECT id, UserName, Attribute, Value, Op FROM radreply WHERE Username = 'al00001' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 5 expand: SELECT GroupName FROM radusergroup WHERE UserName='%{SQL-User-Name}' ORDER BY priority -> SELECT GroupName FROM radusergroup WHERE UserName='al00001' ORDER BY priority rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 1 expand: SELECT id, GroupName, Attribute, Value, op FROM radgroupcheck WHERE GroupName = '%{Sql-Group}' ORDER BY id -> SELECT id, GroupName, Attribute, Value, op FROM radgroupcheck WHERE GroupName = 'Alunos' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 0 , fields = 5 rlm_sql (sql): User found in group Alunos expand: SELECT id, GroupName, Attribute, Value, op FROM radgroupreply WHERE GroupName = '%{Sql-Group}' ORDER BY id -> SELECT id, GroupName, Attribute, Value, op FROM radgroupreply WHERE GroupName = 'Alunos' ORDER BY id rlm_sql_postgresql: Status: PGRES_TUPLES_OK rlm_sql_postgresql: query affected rows = 1 , fields = 5 rlm_sql (sql): Released sql socket id: 2 ++[sql] returns ok ++[files] returns noop rlm_eap: EAP packet type response id 3 length 12 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation ++[eap] returns updated rad_check_password: Found Auth-Type EAP auth: type "EAP" +- entering group authenticate rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 ++[eap] returns handled Sending Access-Challenge of id 24 to 192.168.2.1 port 1645 Tunnel-Private-Group-Id:0 := "2" EAP-Message = 0x010400061520 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x8bd2c0948bd6d5c8bc5a33e2381bcef4 Finished request 1. Going to the next request Waking up in 0.9 seconds. Waking up in 4.0 seconds. Cleaning up request 1 ID 24 with timestamp +77 Ready to process requests. ..." What eap configuration should I use to allow this Cisco equipment authenticate in freeradius (if any)? Is this a Cisco "configuration issue? Thx, Nelson Vale Seg, 2008-07-28 às 20:20 +0200, Alan DeKok escreveu:
nf-vale wrote:
The same clients connected to the Cisco Swicth that it's authenticating in the same freeradius server can not authenticate because freeradius is trying EAP-TLS instead of EAP-PEAP:
RADIUS doesn't work that way.
FreeRADIUS *offers* an EAP type when the client starts connecting. The client *chooses* a different one, if it doesn't like the offer.
Saying "it doesn't work because of TLS versus PEAP" is equivalent to saying "the EAP supplicant does not support PEAP".
The problem you're running into looks a lot like the problem described in the comments in eap.conf.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html