July 2005 - Freeradius-Users - lists.freeradius.org

EAP-TTLS and PEAP auth problem ... sorry!!
by Gandalf the Gray 09 Jul '05

09 Jul '05

I forgot to explain the real problem! I cannot authenticate any user, try to connect to my network through a supplicant, both from Windows and from WPA-supplicant under Linux. It seems no EAP-challenge is really going on. this is the output from tre radius server after a try made by AEGIS client under windows XP, with PEAP MSCHAPv2. rad_recv: Access-Request packet from host 192.168.127.36:21646, id=105, length=131 User-Name = "attoo" Framed-MTU = 1400 Called-Station-Id = "00-12-D9-B3-26-90" Calling-Station-Id = "00-0C-30-28-A6-65" Message-Authenticator = 0xd58f44466d3cc004486c04c445cfc4e7 EAP-Message = 0x0202000a016174746f6f NAS-Port-Type = Wireless-802.11 NAS-Port = 507 Service-Type = Framed-User NAS-IP-Address = 192.168.127.36 NAS-Identifier = "appi" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 251 modcall[authorize]: module "preprocess" returns ok for request 251 modcall[authorize]: module "mschap" returns noop for request 251 rlm_realm: No '@' in User-Name = "attoo", skipping NULL due to config. modcall[authorize]: module "suffix" returns noop for request 251 rlm_eap: EAP packet type response id 2 length 10 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 251 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 251 modcall: group authorize returns updated for request 251 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 251 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 251 modcall: group authenticate returns handled for request 251 Sending Access-Challenge of id 105 to 192.168.127.36:21646 EAP-Message = 0x010300061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xfb61d0352bd2bf83c854f36b74c91b5c Finished request 251 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 192.168.127.36:21646, id=105, length=131 Sending duplicate reply to client appi:21646 - ID: 105 Re-sending Access-Challenge of id 105 to 192.168.127.36:21646 --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 251 ID 105 with timestamp 42c9343a One more time, thank you very much for your help!! Gtheg ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com

2 6

PEAP/mschapv2 fails first time
by Graham, Robert 09 Jul '05

09 Jul '05

I FINALLY got a user to authenicate against Active Directory via freeradius using PEAP and mschapv2. but I still have one issue. When the user first logons, the authenication fails. Approximately 60 seconds later the client tries to re-authenicate and it is succesful. The client (supplicant) is usingaegis client and both logon and desktop profiles are the same. Any ideas? Thanks Robert Graham ##### First attempt - Fails rad_recv: Access-Request packet from host 172.16.5.71:1645, id=216, length=85 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 EAP-Message = 0x0254000c017267726168616d Message-Authenticator = 0x4c68f470b712c5cfa9aaa11f5b1c796a Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 modcall[authorize]: module "chap" returns noop for request 0 modcall[authorize]: module "mschap" returns noop for request 0 rlm_realm: No '@' in User-Name = "rgraham", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_eap: EAP packet type response id 84 length 12 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 0 users: Matched DEFAULT at 159 users: Matched DEFAULT at 178 modcall[authorize]: module "files" returns ok for request 0 modcall: group authorize returns updated for request 0 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 0 modcall: group authenticate returns handled for request 0 Sending Access-Challenge of id 216 to 172.16.5.71:1645 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User EAP-Message = 0x015500061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x84485f7eb55cca67023eacb81d994f15 Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.16.5.71:1645, id=217, length=85 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 EAP-Message = 0x0255000c017267726168616d Message-Authenticator = 0x5d2642b8ac39dab2e5843136d6c000b1 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 1 modcall[authorize]: module "preprocess" returns ok for request 1 modcall[authorize]: module "chap" returns noop for request 1 modcall[authorize]: module "mschap" returns noop for request 1 rlm_realm: No '@' in User-Name = "rgraham", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 1 rlm_eap: EAP packet type response id 85 length 12 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 1 users: Matched DEFAULT at 159 users: Matched DEFAULT at 178 modcall[authorize]: module "files" returns ok for request 1 modcall: group authorize returns updated for request 1 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 1 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 1 modcall: group authenticate returns handled for request 1 Sending Access-Challenge of id 217 to 172.16.5.71:1645 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User EAP-Message = 0x015600061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xe51fa3798797b9cbba8120dadb9502b5 Finished request 1 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.16.5.71:1645, id=218, length=197 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 State = 0xe51fa3798797b9cbba8120dadb9502b5 EAP-Message = 0x0256006a198000000060160301005b01000057030142cf24c596baf77eb6d40e5ecd31431c5ade4c37b97ea2b6dec6cdbcb9cf2ca600003000390038003500160013000a00330032002f0066000500040065006400630062006000150012000900140011000800030100 Message-Authenticator = 0xfc92c9c33e4bddbd41d51a11e23cf5a5 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 2 modcall[authorize]: module "preprocess" returns ok for request 2 modcall[authorize]: module "chap" returns noop for request 2 modcall[authorize]: module "mschap" returns noop for request 2 rlm_realm: No '@' in User-Name = "rgraham", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 2 rlm_eap: EAP packet type response id 86 length 106 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 2 users: Matched DEFAULT at 159 users: Matched DEFAULT at 178 modcall[authorize]: module "files" returns ok for request 2 modcall: group authorize returns updated for request 2 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 2 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 (other): before/accept initialization TLS_accept: before/accept initialization rlm_eap_tls: <<< TLS 1.0 Handshake [length 005b], ClientHello TLS_accept: SSLv3 read client hello A rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello TLS_accept: SSLv3 write server hello A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0694], Certificate TLS_accept: SSLv3 write certificate A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0004], ServerHelloDone TLS_accept: SSLv3 write server done A TLS_accept: SSLv3 flush data TLS_accept:error in SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED modcall[authenticate]: module "eap" returns handled for request 2 modcall: group authenticate returns handled for request 2 Sending Access-Challenge of id 218 to 172.16.5.71:1645 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User EAP-Message = 0x0157040a19c0000006f1160301004a02000046030142cf24bbb4739647899b80df2849bfc7c01d957f7e4b20ad78ccef5f3eea721020b0a496491755673a49c197d244ca0ce91a17f69a14a81dceb61c83729637b46f00350016030106940b00069000068d0002cd308202c930820232a003020102020102300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e74206365 EAP-Message = 0x7274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d301e170d3034303132353133323631305a170d3035303132343133323631305a30819b310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f73743119301706035504031310526f6f74206365727469666963617465311f301d06092a864886f70d0109011610726f6f74406578616d706c652e636f6d30819f300d06092a864886f70d010101050003 EAP-Message = 0x818d0030818902818100dac525422bfedb082629a2cba44b3449c90d0ab462fb72c8434a782098863d7eb7d7e70028c2b7ad555a51cc756cf4fa1d7091615ab450d5289553ae6616aff014a55085d6b8fb4aee98638e426175cdd36c665c63cda177d34920eb30585edc8773999c2980f81ad4638bbbea1c82d054023db7ef24a3ec1c3f6241a903d7f30203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d0101040500038181007a2d921b1cf13bf2982a9178ec9ede6d88edc178a2e8bd40a0a06fb6f0769957884cd7084537083496fd184165293f583c8e8240eb68e042c94b15752e4c07e80d09 EAP-Message = 0x779afa3dd55c24fa54ac292d77205d1c2477ed30d59f57caf9bd21ff2a8d16cc0911c50e4f295763fcb60efa3c3d2d0e43850f6e6fbe284902f6e83503650003ba308203b63082031fa003020102020100300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c EAP-Message = 0x652e636f6d301e170d3034303132353133323630375a Message-Authenticator = 0x00000000000000000000000000000000 State = 0xedccee28bcd01e40e7fbdbcf6f8d3792 Finished request 2 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.16.5.71:1645, id=219, length=97 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 State = 0xedccee28bcd01e40e7fbdbcf6f8d3792 EAP-Message = 0x025700061900 Message-Authenticator = 0x701e017317c2b18676a16db523cb11f8 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 3 modcall[authorize]: module "preprocess" returns ok for request 3 modcall[authorize]: module "chap" returns noop for request 3 modcall[authorize]: module "mschap" returns noop for request 3 rlm_realm: No '@' in User-Name = "rgraham", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 3 rlm_eap: EAP packet type response id 87 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 3 users: Matched DEFAULT at 159 users: Matched DEFAULT at 178 modcall[authorize]: module "files" returns ok for request 3 modcall: group authorize returns updated for request 3 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 3 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: Received EAP-TLS ACK message rlm_eap_tls: ack handshake fragment handler eaptls_verify returned 1 eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED modcall[authenticate]: module "eap" returns handled for request 3 modcall: group authenticate returns handled for request 3 Sending Access-Challenge of id 219 to 172.16.5.71:1645 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User EAP-Message = 0x015802f71900170d3036303132343133323630375a30819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d30819f300d06092a864886f70d010101050003818d0030818902818100d4c5b19724f164acf1ffb189db1c8fbff4f14396ea7cb1e90f78d69451725377895dfe52ccb99b41e8 EAP-Message = 0x0ddeb58b127a943f4f58cbc562878192fbdc6fece9f871e7c130d35cf5188817e9b133249edd2a1c75d31043ae87553cec7a77ef26aa7d74281db9b77e17c6446c5dd9b188b43250ca0229963722a123a726b00b4027fd0203010001a381ff3081fc301d0603551d0e0416041468d36d3e1ee7bc9d5a057021c363da1365d1ade33081cc0603551d230481c43081c1801468d36d3e1ee7bc9d5a057021c363da1365d1ade3a181a5a481a230819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010 EAP-Message = 0x060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d820100300c0603551d13040530030101ff300d06092a864886f70d01010405000381810033c00b66b1e579ef73a06798252dab8d5e5511fc00fd276d80d12f834777c6743fdc2743fca1507704e4bc0979e4f60ac3ad9ee83e6f347369229d1f77229ba2e982359da563024a00163dba6d6c986c0bad28af85132ff8f0d76501bf1b7c2dff658ce1e62c01997b6e64e3e8d4373354ce9912847651539063b85bbc5485c516030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x9cc23d3db03cf891abd27c16d2d5620c Finished request 3 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.16.5.71:1645, id=220, length=397 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 State = 0x9cc23d3db03cf891abd27c16d2d5620c EAP-Message = 0x02580130198000000126160301005b01000057030142cf24c677dbaa4cc4a6d9e01d4444c9adb92118c10fabf3c18019476ef4904500003000390038003500160013000a00330032002f00660005000400650064006300620060001500120009001400110008000301001603010086100000820080d85771401f73751531033151ffecc8dc9cb2c054e011a9bb14eab63dcd718634046a6a569cca9919a9733dd2905cdb05c3799790fedd5b5ae92b9af233e980c41127359f65f488eb8784294478c93a05d0dcd63f36d1381a6b2ef17b640c3c5c84cab7bc9593768996e7e977432728cf3f7f0385a48b7bb2caf532213fe684dc1403010001011603 EAP-Message = 0x01003077f922d171ac9c1fcbff4e71695807789384d272d10a929e02ec9b470d1704df91baa49a6150b3e002c9023a7bfe5a24 Message-Authenticator = 0x751c8d4636dc8c6a188c2a9b6c31b30e Processing the authorize section of radiusd.conf modcall: entering group authorize for request 4 modcall[authorize]: module "preprocess" returns ok for request 4 modcall[authorize]: module "chap" returns noop for request 4 modcall[authorize]: module "mschap" returns noop for request 4 rlm_realm: No '@' in User-Name = "rgraham", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 4 rlm_eap: EAP packet type response id 88 length 253 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 4 users: Matched DEFAULT at 159 users: Matched DEFAULT at 178 modcall[authorize]: module "files" 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/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 005b], ClientHello TLS_accept: SSLv3 read client hello C rlm_eap_tls: >>> TLS 1.0 Handshake [length 004a], ServerHello TLS_accept: SSLv3 write server hello A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0694], Certificate TLS_accept: SSLv3 write certificate A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0004], ServerHelloDone TLS_accept: SSLv3 write server done A TLS_accept: SSLv3 flush data 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 Alert [length 0002], fatal bad_record_mac TLS Alert write:fatal:bad record mac TLS_accept:error in SSLv3 read certificate verify A rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails. In SSL Handshake Phase In SSL Accept mode eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED modcall[authenticate]: module "eap" returns handled for request 4 modcall: group authenticate returns handled for request 4 Sending Access-Challenge of id 220 to 172.16.5.71:1645 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User EAP-Message = 0x0159040a19c0000006f8160301004a02000046030142cf24bb669c93b7807d9dc6169aa7157b1b40224ff2916c074e3aaf0d89027f20b5607af1831f8fc1828c24c0614342ccc8b985f58ea4c388144474b31ffcd66f00350016030106940b00069000068d0002cd308202c930820232a003020102020102300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e74206365 EAP-Message = 0x7274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c652e636f6d301e170d3034303132353133323631305a170d3035303132343133323631305a30819b310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f73743119301706035504031310526f6f74206365727469666963617465311f301d06092a864886f70d0109011610726f6f74406578616d706c652e636f6d30819f300d06092a864886f70d010101050003 EAP-Message = 0x818d0030818902818100dac525422bfedb082629a2cba44b3449c90d0ab462fb72c8434a782098863d7eb7d7e70028c2b7ad555a51cc756cf4fa1d7091615ab450d5289553ae6616aff014a55085d6b8fb4aee98638e426175cdd36c665c63cda177d34920eb30585edc8773999c2980f81ad4638bbbea1c82d054023db7ef24a3ec1c3f6241a903d7f30203010001a317301530130603551d25040c300a06082b06010505070301300d06092a864886f70d0101040500038181007a2d921b1cf13bf2982a9178ec9ede6d88edc178a2e8bd40a0a06fb6f0769957884cd7084537083496fd184165293f583c8e8240eb68e042c94b15752e4c07e80d09 EAP-Message = 0x779afa3dd55c24fa54ac292d77205d1c2477ed30d59f57caf9bd21ff2a8d16cc0911c50e4f295763fcb60efa3c3d2d0e43850f6e6fbe284902f6e83503650003ba308203b63082031fa003020102020100300d06092a864886f70d010104050030819f310b30090603550406130243413111300f0603550408130850726f76696e63653112301006035504071309536f6d65204369747931153013060355040a130c4f7267616e697a6174696f6e31123010060355040b13096c6f63616c686f7374311b301906035504031312436c69656e742063657274696669636174653121301f06092a864886f70d0109011612636c69656e74406578616d706c EAP-Message = 0x652e636f6d301e170d3034303132353133323630375a Message-Authenticator = 0x00000000000000000000000000000000 State = 0x0ad62075ab40e530e4fdf3c40f89fb8c Finished request 4 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.16.5.71:1645, id=221, length=97 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 State = 0x0ad62075ab40e530e4fdf3c40f89fb8c EAP-Message = 0x025900061900 Message-Authenticator = 0x9aa9aff954adb9c89af11bfa651cdf5f 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 "chap" returns noop for request 5 modcall[authorize]: module "mschap" returns noop for request 5 rlm_realm: No '@' in User-Name = "rgraham", 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 89 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 5 users: Matched DEFAULT at 159 users: Matched DEFAULT at 178 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: Received EAP-TLS ACK message rlm_eap_tls: ack alert eaptls_verify returned 4 eaptls_process returned 4 rlm_eap_peap: EAPTLS_OTHERS rlm_eap: Handler failed in EAP/peap rlm_eap: Failed in EAP select modcall[authenticate]: module "eap" returns invalid for request 5 modcall: group authenticate returns invalid for request 5 auth: Failed to validate the user. Delaying request 5 for 1 seconds Finished request 5 Going to the next request Waking up in 6 seconds... rad_recv: Access-Request packet from host 172.16.5.71:1645, id=221, length=97 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 State = 0x0ad62075ab40e530e4fdf3c40f89fb8c EAP-Message = 0x025900061900 Message-Authenticator = 0x65dc2b9d224cd8b89f706f9007967d57 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 "chap" returns noop for request 6 modcall[authorize]: module "mschap" returns noop for request 6 rlm_realm: No '@' in User-Name = "rgraham", 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 89 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 6 users: Matched DEFAULT at 159 users: Matched DEFAULT at 178 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 not found in the list rlm_eap: Either EAP-request timed out OR EAP-response to an unknown EAP-request rlm_eap: Failed in handler modcall[authenticate]: module "eap" returns invalid for request 6 modcall: group authenticate returns invalid for request 6 auth: Failed to validate the user. Delaying request 6 for 1 seconds Finished request 6 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 221 to 172.16.5.71:1645 Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 216 with timestamp 42cf24bb Cleaning up request 1 ID 217 with timestamp 42cf24bb Cleaning up request 2 ID 218 with timestamp 42cf24bb Cleaning up request 3 ID 219 with timestamp 42cf24bb Cleaning up request 4 ID 220 with timestamp 42cf24bb Waking up in 3 seconds... --- Walking the entire request list --- Cleaning up request 6 ID 221 with timestamp 42cf24be Nothing to do. Sleeping until we see a request. ###### Second attempt - Sucessful rad_recv: Access-Request packet from host 172.16.5.71:1645, id=222, length=85 User-Name = "rgraham" Service-Type = Framed-User Framed-MTU = 1500 NAS-IP-Address = 172.16.5.71 NAS-Port = 24 EAP-Message = 0x025a000c017267726168616d Message-Authenticator = 0x47937c5549b4711ac931f218cc4187c2 Processing the authorize section of radiusd.conf {removed to shorten message} rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_peap: Received EAP-TLV response. rlm_eap_peap: Tunneled data is valid. rlm_eap_peap: Success rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 15 modcall: group authenticate returns ok for request 15 Sending Access-Accept of id 230 to 172.16.5.71:1645 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User MS-MPPE-Recv-Key = 0xf91ab77685c01a5a4200416067f7c4b9b1db050b6365ba8672ae0f6d8734245c MS-MPPE-Send-Key = 0x77360b38081590ee5e0d648a239cdcdc55478e7d44399ee654bfeb7145f807f8 EAP-Message = 0x03620004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "rgraham" Finished request 15 Going to the next request Waking up in 5 seconds... --- Walking the entire request list --- Cleaning up request 7 ID 222 with timestamp 42cf24fc Waking up in 1 seconds...

2 1

Chap password failing with Cisco
by Brent Smith 08 Jul '05

08 Jul '05

All- I am trying to get freeradius to authenticate chap for a ISDN backup call on a cisco. I am running version 1.0.1. I am in control of server and clients, so I know the passwords match, but the logs say they do not. Router setup: username ie_phx2 password 0 password users file: ie_phx2 Password == "password" Service-Type = Framed, Framed-Protocol = ppp, Cisco-Avpair += "multilink:max-links=6", Cisco-Avpair += "multilink:min-links=1", Cisco-Avpair += "multilink:load-threshhold=192", Cisco-Avpair += "lcp:interface-config=ip vrf forwarding VPDN-1444-ISDNBackup", Cisco-Avpair += "lcp:interface-config=ip unnumbered loop144", Cisco-Avpair += "lcp:send-secret=password" log: rad_recv: Access-Request packet from host XX.XX.XX.XX:1645, id=0, length=91 Framed-Protocol = PPP User-Name = "ie_phx2" CHAP-Password = 0x1906c1e965a82a39db372abde8f7455ee6 NAS-Port = 1 NAS-Port-Type = Virtual Called-Station-Id = "04082415687" Service-Type = Framed-User NAS-IP-Address = XX.XX.XX.XX Processing the authorize section of radiusd.conf modcall: entering group authorize for request 9 modcall[authorize]: module "preprocess" returns ok for request 9 rlm_chap: Setting 'Auth-Type := CHAP' modcall[authorize]: module "chap" returns ok for request 9 modcall[authorize]: module "mschap" returns noop for request 9 rlm_realm: No '@' in User-Name = "ie_phx2", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 9 rlm_eap: No EAP-Message, not doing EAP modcall[authorize]: module "eap" returns noop for request 9 users: Matched ie_phx2 at 147 modcall[authorize]: module "files" returns ok for request 9 modcall: group authorize returns ok for request 9 rad_check_password: Found Auth-Type CHAP auth: type "CHAP" Processing the authenticate section of radiusd.conf modcall: entering group Auth-Type for request 9 rlm_chap: login attempt by "ie_phx2" with CHAP password rlm_chap: Using clear text password password for user ie_phx2 authentication. rlm_chap: Pasword check failed modcall[authenticate]: module "chap" returns reject for request 9 modcall: group Auth-Type returns reject for request 9 auth: Failed to validate the user. Login incorrect (rlm_chap: Wrong user password): [ie_phx2/<CHAP-Password>] (from client c pe2.pop2 port 1) Delaying request 9 for 1 seconds Finished request 9 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Cleaning up request 8 ID 38 with timestamp 42c333c5 Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 0 to XX.XX.XX.XX:1645 Cisco-AVPair += "multilink:max-links=6" Cisco-AVPair += "multilink:min-links=1" Cisco-AVPair += "multilink:load-threshhold=192" Cisco-AVPair += "lcp:interface-config=ip vrf forwarding VPDN-1444-ISDNBackup\n ip unnumbered loop144" Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 9 ID 0 with timestamp 42c333ca Nothing to do. Sleeping until we see a request. Any idea why freeradius thinks the passwords don't match? Thanks -Brent Smith

2 2

Shipping freeradius and mysql
by Sonali Karmarkar 08 Jul '05

08 Jul '05

Hi, I am using freeradius 1.0.2 on mandrake 10.1. The question I want to post is about shipping freeradius to customers. I have written a script to install freeradius, mysql, java and my product. Every time I use the script, I run into different errors while installing freeradius. The errors range from rlm_sql drivers errors , rlm_token errors, sometimes c compiler settings on my system. What is the correct way to ship freeradius to the customer so that all the installation errors are taken care of ? Thanks and Regards Sonali

2 1

PEAP docs
by Albrecht, Robert-Manfred 08 Jul '05

08 Jul '05

Hello, some months I had a cool document describing the installation of freeradius for eap-peap (over wlan) with windows as client. I lost the url. Could anyone forward me the url ? Regard, Robert

2 1

Problems with the PEAP configuration
by Mario Alberto Cruz Gartner 08 Jul '05

08 Jul '05

Hi! I'd finally knew why the client (Xp-SP2) was sending the username "PEAP-MacAddress" to the radius. I have installed the "Cisco Aironet Client Utility" (and the aironet drivers), and this software changed the EAP methods on XP and sends the mentioned user instead of the real one when tries PEAP auth. Now, the real username comes to the radius, the authorize comes ok, but the authenticate returns "handled" and the client doesn't authenticates well. I was looking the debug output and now i don't see where i can dig for details. EAP/TLS works fine already. Maybe i'm misleading something? What i'm doing wrong? Again, thks a lot for your help, it's annoying answer to too many similar questions, i know, but i didn't find something to do now of this. AND, i was thinking on make an updated version of the guides so ppl with less exp (like me!) can read and don't disturb you. =)

1 1

High performance request remapping / rewriting
by Phil Mayers 08 Jul '05

08 Jul '05

All, We are looking to implement mac-based vlans with a radius backend. I'm hoping freeradius is the obvious choice, but I'm having a hard time seeing how to do what I need. What I'm looking to is feed FreeRadius from our host registration database. Each NAS (switch) may potentially have different VLANs on it, and each registered host may fall into a different vlan "type", so the radius server needs to map: (clientmac, nasipaddress) -> vlantag However, there are ~20k MAC addresses and ~1200 NASes (switches), so clearly I can't do this: DEFAULT Calling-Station-Id = "<mac0>", NAS-IP-Address = "<switch0>" DEFAULT Calling-Station-Id = "<mac0>", NAS-IP-Address = "<switch1>" DEFAULT Calling-Station-Id = "<mac0>", NAS-IP-Address = "<switch2>" ... DEFAULT Calling-Station-Id = "<mac20k>", NAS-IP-Address = "<switch1k>" ...because it's 20 million entries. The file as a users compiled to dbm is >4Gb :o( I wanted to do some kind of optimisation - the switches are grouped into zones in our database, and vlans are specific to these zones (normally a building), so actually something like: nasip -> zone (clientmac, zone) -> vlan ...but that's still too large, so maybe: nasip -> zone clientmac -> clienttype (there are 5 types - unreg, guest, roaming, home, blocked) (clienttype, zone) -> vlan ...which would be much smaller, but I can't see how you do this. I must admit to being somewhat confused about the request, check and reply items, but from what I can tell a "users" item consists of: username OR DEFAULT <space> [comma-separated items to check against request] <newline> [comma-separated items to add to reply] ...so even with Fall-Through=Yes you can never do this: DEFAULT NAS-IP-Address = blah Zone = "foo" DEFAULT Calling-Station-Id = "00-11-22-33-44-55", User-Password = "00-11-22-33-44-55" Kind = "guest" # Fallback - unknown hosts DEFAULT Calling-Station-Id =~ "^[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}-[0-9A-F]{2}$" , User-Password = `%{0}` Kind = "unreg" DEFAULT Zone = "foo", Kind = "unreg" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID := "1" DEFAULT Zone = "foo", Kind = "guest" Tunnel-Type = VLAN, Tunnel-Medium-Type = IEEE-802, Tunnel-Private-Group-ID := "2" ...because Zone and Kind are set in the reply, so can't be matched further down. rlm_attr_rewrite has the beginnings of what is needed, but a linear search through 20k regexps for the hosts, followed by 1k regexps for the switches clearly isn't going to work. Ideally an apache-like feature of DBM mapping is what's needed of something like: /etc/raddb/radiusd.conf: attr_rewrite nas2zone { attribute = NAS-IP-Address searchin = packet searchfor = "(.*)" replacewith = "%{dbm:nas2zone:%{1}}" new_attribute_name = "Zone" } ...and similarly for Calling-Station-Id -> kind The issue is that this needs to go very very fast - at peak times (e.g. say a reboot of a PC cluster during overnight maintenance) the DHCP servers get ~50 requests/second, so a radius server(s) would need to answer with similar performance. I originally tried to do this with rlm_sql direct to our registration database, but the performance was abominal (which is not an SQL issue) and eventually it hung the radius server anyway (rlm_sql_postgresql). In any event I was never super-keen on that for security reasons, though the fact it was instant-updating once a registration was processed was very handy. I'm assuming rlm_exec would have similar if not worse performance characterisitcs (spawning 50 processes a second during peak times does not strike me as overly sensible). Is there an rlm_socket: socket mac_vlan { path = "/var/run/mac_vlan.unixsock" wait = yes input_pairs = request output_pairs = reply } ...i.e. keep a persistent connection to something open. I'd appreciate any suggestions.

2 1

ippool corrections
by Marek Gradzki 08 Jul '05

08 Jul '05

Hi there! I have installed and run FreeRadius Server on Solaris 8 (x86 and sparc). Authorization and authentication works with LDAP protocol with OpenLDAP server. Accounting is processed by SQL database (PostgreSQL). I use these radius servers to perform AAA operations as a response to request send from device terminating PPPoE sessions. Also I have to use radius server feature to dynamically assign IP addresses to client sessions. So I have assumed that rlm_ippool module is right for this task. But unfortunately all sessions that are terminated in the box working with radius come to this device by the same port. So I had to rewrite a little bit rlm_ippool module to verify used ip addresses not only by nas device and nas port but also by user name. Unfortunately I have no opportunity to test this rewriten module in orther configurations. If anyone is interested in testing this module please email me, because I would like to be sure that this module will work in other configuration (maybe not everyone), no only in mine. Anyway I will have to verify my corrections because rlm_ippool_tools displays some strange informations on teh screen. mgradzki(a)ost.net.pl

2 1

"LOGIN INCORRECT" and "LOGIN OK"
by Bruno Machado 08 Jul '05

08 Jul '05

Hi friends There are a weird something happening here. This is our log about a user: Wed Jun 29 22:36:03 2005 : Auth: Login incorrect: [user(a)domain.com.br/<no User-Password attribute>] (from client 10.5.0.2 port 5060) Wed Jun 29 22:36:04 2005 : Auth: Login incorrect: [user(a)domain.com.br/<no User-Password attribute>] (from client 10.5.0.2 port 5060) Wed Jun 29 22:36:57 2005 : Auth: Login incorrect: [user(a)domain.com.br/<no User-Password attribute>] (from client 10.5.0.2 port 5060) Wed Jun 29 22:37:00 2005 : Auth: Login OK: [user(a)domain.com.br/<no User-Password attribute>] (from client 10.5.0.2 port 5060) Wed Jun 29 22:37:00 2005 : Auth: Login incorrect: [user(a)domain.com.br/<no User-Password attribute>] (from client 10.5.0.2 port 5060) I already tried to discover the problem, but I didn't find anything. We are using Radius in a VoIP system. If I configure my SIP client with user's informations, Radius allows my access to the system. Unfortunatly, when the data arrive from the SIP client's user, Radius deny it. Rarely Radius returns "LOGIN OK". Weird... Maybe the ADSL Router's user can be corrupting the data? And our system is working perfectly for the other users. Thanks for any comments. Bruno Machado _______________________________________________________ Yahoo! Acesso Grátis - Internet rápida e grátis. Instale o discador agora! http://br.acesso.yahoo.com/

2 1

class attribute wont pass
by Brian 08 Jul '05

08 Jul '05

Hello, I'm running freeradius 0.9.3 (I know.. it's old..), operating in a proxy configuration. I'm having issues with freeradius not passing the "class" attribute back to the NAS after receiving it from one of our proxy customers. I can't put the Class attribute in the user's file because the proxy customer uses different values per customer. We only have one customer that passes the class attribute to us, so this is the first instance where we are having this issue. I've tried changing the attribute value from "octet" to "string" in the dictionary file as was suggested previously on the mailing list, but it doesn't make a difference :-( Here is debug output from radiusd: rad_recv: Access-Request packet from host 63.110.xxx.xx:3401, id=75, length=211 User-Name = "user(a)realm.com" User-Password = "6875" NAS-IP-Address = 63.215.xx.xxx NAS-Port = 807 Service-Type = Framed-User Framed-Protocol = PPP Ascend-Data-Rate = 28800 Ascend-Calling-Id-Type-Of-Num = Unknown Ascend-Calling-Id-Number-Plan = Unknown Ascend-Xmit-Rate = 50667 Called-Station-Id = "317270xxxx" Calling-Station-Id = "317862xxxx" NAS-Identifier = "nas.ind.Level3.net" Acct-Session-Id = "483826947" NAS-Port-Type = Async Ascend-NAS-Port-Format = 4 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 73 modcall[authorize]: module "attr_filter" returns noop for request 73 rlm_realm: Looking up realm "realm.com" for User-Name = "user(a)realm.com" rlm_realm: Found realm "realm.com" rlm_realm: Proxying request from user user to realm realm.com rlm_realm: Adding Realm = "realm.com" rlm_realm: Preparing to proxy authentication request to realm "realm.com" modcall[authorize]: module "suffix" returns updated for request 73 users: Matched DEFAULT at 537 modcall[authorize]: module "files" returns ok for request 73 hints: Matched DEFAULT at 49 modcall[authorize]: module "preprocess" returns ok for request 73 modcall: group authorize returns updated for request 73 Sending Access-Request of id 1 to 63.174.xxx.xx:1645 User-Name = "user(a)realm.com" User-Password = "6875" NAS-IP-Address = 63.215.xx.xxx NAS-Port = 807 Service-Type = Framed-User Framed-Protocol = PPP Ascend-Data-Rate = 28800 Ascend-Calling-Id-Type-Of-Num = Unknown Ascend-Calling-Id-Number-Plan = Unknown Ascend-Xmit-Rate = 50667 Called-Station-Id = "317270xxxx" Calling-Station-Id = "317862xxxx" NAS-Identifier = "nas.ind.Level3.net" Acct-Session-Id = "483826947" NAS-Port-Type = Async Ascend-NAS-Port-Format = 4 Proxy-State = 0x3735 Waking up in 1 seconds... rad_recv: Access-Accept packet from host 63.174.xxx.xx:1645, id=1, length=218 Proxy-State = 0x3735 Service-Type = Framed-User Framed-Protocol = PPP Ascend-Data-Filter = "ip in forward tcp est" Ascend-Data-Filter = "ip in forward dstip 63.174.xxx.x/24 0" Ascend-Data-Filter = "ip in drop tcp dstport = 25" Ascend-Data-Filter = "ip in forward 0" Idle-Timeout = 1800 Session-Timeout = 21600 Propel-Accelerate = 1 X-Ascend-Idle-Limit = 1800 X-Ascend-Maximum-Time = 28800 Class = "IEAS1\005378602\003292" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 73 attr_filter: Matched entry DEFAULT at line 84 modcall[authorize]: module "attr_filter" returns updated for request 73 rlm_realm: Proxy reply, or no User-Name. Ignoring. modcall[authorize]: module "suffix" returns noop for request 73 users: Matched DEFAULT at 537 modcall[authorize]: module "files" returns ok for request 73 hints: Matched DEFAULT at 49 modcall[authorize]: module "preprocess" returns ok for request 73 modcall: group authorize returns updated for request 73 rad_check_password: Found Auth-Type rad_check_password: Auth-Type = Accept, accepting the user Login OK: [user(a)realm.com/6875] (from client acs223 port 807 cli 3178623267) Sending Access-Accept of id 75 to 63.110.xxx.xx:3401 Service-Type := Framed-User Framed-IP-Address := 255.255.255.254 Framed-IP-Netmask := 255.255.255.255 Framed-Protocol := PPP Ascend-Data-Filter = "ip in forward tcp est" Ascend-Data-Filter = "ip in forward dstip 63.174.xxx.x/24 0" Ascend-Data-Filter = "ip in drop tcp dstport = 25" Ascend-Data-Filter = "ip in forward 0" Session-Timeout = 21600 X-Ascend-Maximum-Time = 28800 Framed-Compression = Van-Jacobson-TCP-IP Idle-Timeout = 900 X-Ascend-Idle-Limit = 900 Finished request 73 -------- As you can see in the debug output, the freeradius server receives the class attribute from 63.174.xxx.xx, but when sending back to the NAS at 63.110.xxx.xx, the Class attribute is not being tagged on. Any help / direction would be greatly appreciated! Thanks. Brian Taylor

2 2