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

Re: RE: FreeRadius EAP-TLS issue
by Hamid Salim 16 Nov '05

16 Nov '05

I used OpenSSL, what are the special attributes that you mention? is it OID? Thanks. Hamid. Guy Davies wrote: >Hi Hamid, > >What CA did you use to create the client certs? If it was OpenSSL, did >you ensure that you included the special attributes that the MS >supplicant expects? There are a few HOWTO's around and they pretty much >all reference this special value. > >If you used the M$ Certificate Services, it is automatically added. > >Rgds, > >Guy > >-----Original Message----- >From: freeradius-users-bounces(a)lists.freeradius.org >[mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of >Brian A. Seklecki >Sent: 16 November 2005 17:02 >To: Hamid Salim >Cc: freeradius-users(a)lists.freeradius.org >Subject: Re: FreeRadius EAP-TLS issue > > >If it was regular TLS, i'd tell you to "openssl s_client -connect >foo:123 -cacert /blah". > >Are you sure that you have imported and "trusted" your CA's cetificate >on both the client and the server? > >This is when I let the other guys make suggestions. > >I was just curious of EAP-TLS with client certificates was simply a way >of delivering the username to the client, letting the client >authenticate the server and the server authenticate the identity of the >client, and then providing for another password based mechanism. > >Or if certificate TLS handshake was sufficient for authorization and >authentication... > >For example, Apache SSL can be told to verify client certificates, but >htaccess would still be required. > >With SMTP, client and server SSL verification can be compelled, but for >SMTP AUTH for relay, username/password authentication would still be >required. > > >~BAS > >On Wed, 16 Nov 2005, Hamid Salim wrote: > >> It should not be asking/expecting any userid/password pair. I have >> installed the certificates on the supplicant machine which should be >> sufficient to authenticate without any password requirements. I am not > >> sure why the certs are not working??? >> >> >> Brian A. Seklecki wrote: >> >> >>> >>> rlm_eap_tls: Received unexpected tunneled data after successful >>> handshake. >>> >>> ...that's what I get when I try an invalid password in my EAP + Cisco >> 1200 >>> + LDAP + PEAP/MS-CHAPv2 configuration. >>> >>> Let me ask...how is the client certificate method supposed to work? >>> >>> Is the username embeded the CN/CommonName attribute of the >>> certificate >> and >>> the user is prompted for a password which you setup in authenticate >{} ? >>> >>> Is that any more secure than using PEAP/MS-CHAPv2 ? >>> >>> ~BAS >>> >>> >>> On Wed, 16 Nov 2005, Hamid Salim wrote: >>> >>>> Hi, >>>> I am just wondering if anyone has encountered the same issue. I have > >>>> set up my enviornment for EAP-TLS, with windows XP SP2 as a >supplicant. >>>> For some reason I am getting: >>>> >>>> auth: Failed to validate the user. >>>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>>> client >>>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>>> >>>> complete listing is attached. I am using certificates and SSL >>>> session is created successfully, then why FreeRadius is expecting a >>>> userid/password? >>>> >>>> Any help will be appreciated. >>>> >>>> Thanks >>>> Hamid. >>>> >>>> ============= Complete Listing ================= Going to the next >>>> request Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, >>>> length=1247 >>>> User-Name = "radiustst" >>>> NAS-IP-Address = 129.10.56.156 >>>> Called-Station-Id = "00-20-a6-4a-12-21" >>>> Calling-Station-Id = "00-10-c6-38-af-7b" >>>> NAS-Identifier = "APtest3" >>>> State = 0xb9a67433435733a42f7cbd528aa6ae7a >>>> Framed-MTU = 1400 >>>> NAS-Port-Type = Wireless-802.11 >>>> EAP-Message = >>>> >> 0x020504510d800000044716030104170b000307000304000301308202fd30820266a0 >> 03 >>>> >> 020102020102300d06092a864886f70d01010405003054310b30090603550406130255 >> 53 >>>> >> 310b3009060355040813024d413120301e060355040a13174e6f727468656173746572 >> 6e >>>> >> 20556e6976657273697479311630140603550403130d45434541757468536572766572 >> 30 >>>> >> 1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b >> 30 >>>> >> 09060355040613025553310b3009060355040813024d413120301e060355040a13174e >> 6f >>>> >> 7274686561737465726e20556e69766572736974793112301006035504031309726164 >> 69 >>>> 7573 >>>> EAP-Message = >>>> >> 0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b998 >> 3d >>>> >> b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399 >> c3 >>>> >> 9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d >> 76 >>>> >> 9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175 >> a0 >>>> >> 47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d13 >> 04 >>>> >> 023000302c06096086480186f842010d041f161d4f70656e53534c2047656e65726174 >> 65 >>>> >> 64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f8281 >> 57 >>>> 2f5e >>>> EAP-Message = >>>> >> 0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf37 >> 43 >>>> >> 0ee64b68e9a158a4563054310b3009060355040613025553310b300906035504081302 >> 4d >>>> >> 413120301e060355040a13174e6f7274686561737465726e20556e6976657273697479 >> 31 >>>> >> 1630140603550403130d45434541757468536572766572820900cab77a537cadfaf330 >> 0d >>>> >> 06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e >> 2d >>>> >> 8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf >> 00 >>>> >> d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57da >> e0 >>>> c423 >>>> EAP-Message = >>>> >> 0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f274 >> 65 >>>> >> 1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000 >> f0 >>>> >> 70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df >> 74 >>>> >> 830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e >> 2f >>>> >> 30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e >> 69 >>>> >> 99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1 >> a3 >>>> >> 25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5f >> dd >>>> 8f7c >>>> EAP-Message = >>>> >> 0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d >> 80 >>>> >> af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf8698 >> 86 >>>> 11a6916269516c4e5b6bf006d943609a71740a4d3a60 >>>> Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae >>>> Processing the authorize section of radiusd.conf >>>> modcall: entering group authorize for request 8 >>>> modcall[authorize]: module "preprocess" returns ok for request 8 >>>> radius_xlat: >>>> >> >'/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>>> rlm_detail: >>>> >> /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% >> Y% >>>> m%d expands to >>>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>>> 15 >>>> modcall[authorize]: module "auth_log" returns ok for request 8 >>>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm >NULL >>>> rlm_realm: No such realm "NULL" >>>> modcall[authorize]: module "suffix" returns noop for request 8 >>>> rlm_eap: EAP packet type response id 5 length 253 >>>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>>> modcall[authorize]: module "eap" returns updated for request 8 >>>> users: Matched entry radiustst at line 54 >>>> modcall[authorize]: module "files" returns ok for request 8 >>>> modcall: group authorize returns updated for request 8 >>>> rad_check_password: Found Auth-Type EAP >>>> auth: type "EAP" >>>> Processing the authenticate section of radiusd.conf >>>> modcall: entering group authenticate for request 8 >>>> rlm_eap: Request found, released from the list >>>> rlm_eap: EAP/tls >>>> rlm_eap: processing type tls >>>> rlm_eap_tls: Authenticate >>>> rlm_eap_tls: processing TLS >>>> rlm_eap_tls: Length Included >>>> eaptls_verify returned 11 >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate >>>> chain-depth=1, error=0 >>>> --> User-Name = radiustst >>>> --> BUF-Name = ECEAuthServer >>>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer > >>>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer > >>>> --> verify return:1 >>>> chain-depth=0, >>>> error=0 >>>> --> User-Name = radiustst >>>> --> BUF-Name = radiustst >>>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst >>>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer > >>>> --> verify return:1 >>>> TLS_accept: SSLv3 read client certificate A >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange >>>> TLS_accept: SSLv3 read client key exchange A >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], CertificateVerify >>>> TLS_accept: SSLv3 read certificate verify 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 8 >>>> modcall: group authenticate returns handled for request 8 Sending >>>> Access-Challenge of id 71 to 129.10.56.156:6001 >>>> EAP-Message = >>>> >> 0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9 >> c2 >>>> 4322bdbd6ca0af149ba46d197f153a7f4f32 >>>> Message-Authenticator = 0x00000000000000000000000000000000 >>>> State = 0x70ed13d02f1854999ba5b4513143d53d >>>> Finished request 8 >>>> Going to the next request >>>> Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>>> length=167 >>>> User-Name = "radiustst" >>>> NAS-IP-Address = 129.10.56.156 >>>> Called-Station-Id = "00-20-a6-4a-12-21" >>>> Calling-Station-Id = "00-10-c6-38-af-7b" >>>> NAS-Identifier = "APtest3" >>>> State = 0x70ed13d02f1854999ba5b4513143d53d >>>> Framed-MTU = 1400 >>>> NAS-Port-Type = Wireless-802.11 >>>> EAP-Message = >>>> 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 >>>> Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 >>>> Processing the authorize section of radiusd.conf >>>> modcall: entering group authorize for request 9 >>>> modcall[authorize]: module "preprocess" returns ok for request 9 >>>> radius_xlat: >>>> >> >'/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>>> rlm_detail: >>>> >> /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% >> Y% >>>> m%d expands to >>>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>>> 15 >>>> modcall[authorize]: module "auth_log" returns ok for request 9 >>>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm >NULL >>>> rlm_realm: No such realm "NULL" >>>> modcall[authorize]: module "suffix" returns noop for request 9 >>>> rlm_eap: EAP packet type response id 6 length 33 >>>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>>> modcall[authorize]: module "eap" returns updated for request 9 >>>> users: Matched entry radiustst at line 54 >>>> modcall[authorize]: module "files" returns ok for request 9 >>>> modcall: group authorize returns updated for request 9 >>>> rad_check_password: Found Auth-Type EAP >>>> auth: type "EAP" >>>> Processing the authenticate section of radiusd.conf >>>> modcall: entering group authenticate for request 9 >>>> rlm_eap: Request found, released from the list >>>> rlm_eap: EAP/tls >>>> rlm_eap: processing type tls >>>> rlm_eap_tls: Authenticate >>>> rlm_eap_tls: processing TLS >>>> rlm_eap_tls: Length Included >>>> eaptls_verify returned 11 >>>> eaptls_process returned 7 >>>> rlm_eap_tls: Received unexpected tunneled data after successful >>>> handshake. >>>> rlm_eap: Handler failed in EAP/tls >>>> rlm_eap: Failed in EAP select >>>> modcall[authenticate]: module "eap" returns invalid for request 9 >>>> modcall: group authenticate returns invalid for request 9 >>>> auth: Failed to validate the user. >>>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>>> client >>>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) Delaying request 9 for > >>>> 1 seconds Finished request 9 Going to the next request Waking up in >>>> 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>>> length=167 >>>> Sending Access-Reject of id 72 to 129.10.56.156:6001 >>>> EAP-Message = 0x04060004 >>>> Message-Authenticator = 0x00000000000000000000000000000000 >>>> --- Walking the entire request list --- Waking up in 1 seconds... >>>> --- Walking the entire request list --- Cleaning up request 5 ID 68 >>>> with timestamp 437a661d Cleaning up request 6 ID 69 with timestamp >>>> 437a661d Cleaning up request 7 ID 70 with timestamp 437a661d >>>> Cleaning up request 8 ID 71 with timestamp 437a661d Cleaning up >>>> request 9 ID 72 with timestamp 437a661d Nothing to do. Sleeping >>>> until we see a request. >>>> - >>>> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html >>>> >>> >>> l8* >>> -lava >>> >>> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >>> >> > >l8* > -lava > >x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >- >List info/subscribe/unsubscribe? See >http://www.freeradius.org/list/users.html > >This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us. > > >

1 0

RE: FreeRadius EAP-TLS issue
by Guy Davies 16 Nov '05

16 Nov '05

Hi Hamid, What CA did you use to create the client certs? If it was OpenSSL, did you ensure that you included the special attributes that the MS supplicant expects? There are a few HOWTO's around and they pretty much all reference this special value. If you used the M$ Certificate Services, it is automatically added. Rgds, Guy -----Original Message----- From: freeradius-users-bounces(a)lists.freeradius.org [mailto:freeradius-users-bounces@lists.freeradius.org] On Behalf Of Brian A. Seklecki Sent: 16 November 2005 17:02 To: Hamid Salim Cc: freeradius-users(a)lists.freeradius.org Subject: Re: FreeRadius EAP-TLS issue If it was regular TLS, i'd tell you to "openssl s_client -connect foo:123 -cacert /blah". Are you sure that you have imported and "trusted" your CA's cetificate on both the client and the server? This is when I let the other guys make suggestions. I was just curious of EAP-TLS with client certificates was simply a way of delivering the username to the client, letting the client authenticate the server and the server authenticate the identity of the client, and then providing for another password based mechanism. Or if certificate TLS handshake was sufficient for authorization and authentication... For example, Apache SSL can be told to verify client certificates, but htaccess would still be required. With SMTP, client and server SSL verification can be compelled, but for SMTP AUTH for relay, username/password authentication would still be required. ~BAS On Wed, 16 Nov 2005, Hamid Salim wrote: > It should not be asking/expecting any userid/password pair. I have > installed the certificates on the supplicant machine which should be > sufficient to authenticate without any password requirements. I am not > sure why the certs are not working??? > > > Brian A. Seklecki wrote: > > >> >> rlm_eap_tls: Received unexpected tunneled data after successful >> handshake. >> >> ...that's what I get when I try an invalid password in my EAP + Cisco > 1200 >> + LDAP + PEAP/MS-CHAPv2 configuration. >> >> Let me ask...how is the client certificate method supposed to work? >> >> Is the username embeded the CN/CommonName attribute of the >> certificate > and >> the user is prompted for a password which you setup in authenticate {} ? >> >> Is that any more secure than using PEAP/MS-CHAPv2 ? >> >> ~BAS >> >> >> On Wed, 16 Nov 2005, Hamid Salim wrote: >> >>> Hi, >>> I am just wondering if anyone has encountered the same issue. I have >>> set up my enviornment for EAP-TLS, with windows XP SP2 as a supplicant. >>> For some reason I am getting: >>> >>> auth: Failed to validate the user. >>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>> client >>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>> >>> complete listing is attached. I am using certificates and SSL >>> session is created successfully, then why FreeRadius is expecting a >>> userid/password? >>> >>> Any help will be appreciated. >>> >>> Thanks >>> Hamid. >>> >>> ============= Complete Listing ================= Going to the next >>> request Waking up in 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, >>> length=1247 >>> User-Name = "radiustst" >>> NAS-IP-Address = 129.10.56.156 >>> Called-Station-Id = "00-20-a6-4a-12-21" >>> Calling-Station-Id = "00-10-c6-38-af-7b" >>> NAS-Identifier = "APtest3" >>> State = 0xb9a67433435733a42f7cbd528aa6ae7a >>> Framed-MTU = 1400 >>> NAS-Port-Type = Wireless-802.11 >>> EAP-Message = >>> > 0x020504510d800000044716030104170b000307000304000301308202fd30820266a0 > 03 >>> > 020102020102300d06092a864886f70d01010405003054310b30090603550406130255 > 53 >>> > 310b3009060355040813024d413120301e060355040a13174e6f727468656173746572 > 6e >>> > 20556e6976657273697479311630140603550403130d45434541757468536572766572 > 30 >>> > 1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b > 30 >>> > 09060355040613025553310b3009060355040813024d413120301e060355040a13174e > 6f >>> > 7274686561737465726e20556e69766572736974793112301006035504031309726164 > 69 >>> 7573 >>> EAP-Message = >>> > 0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b998 > 3d >>> > b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399 > c3 >>> > 9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d > 76 >>> > 9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175 > a0 >>> > 47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d13 > 04 >>> > 023000302c06096086480186f842010d041f161d4f70656e53534c2047656e65726174 > 65 >>> > 64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f8281 > 57 >>> 2f5e >>> EAP-Message = >>> > 0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf37 > 43 >>> > 0ee64b68e9a158a4563054310b3009060355040613025553310b300906035504081302 > 4d >>> > 413120301e060355040a13174e6f7274686561737465726e20556e6976657273697479 > 31 >>> > 1630140603550403130d45434541757468536572766572820900cab77a537cadfaf330 > 0d >>> > 06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e > 2d >>> > 8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf > 00 >>> > d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57da > e0 >>> c423 >>> EAP-Message = >>> > 0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f274 > 65 >>> > 1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000 > f0 >>> > 70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df > 74 >>> > 830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e > 2f >>> > 30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e > 69 >>> > 99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1 > a3 >>> > 25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5f > dd >>> 8f7c >>> EAP-Message = >>> > 0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d > 80 >>> > af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf8698 > 86 >>> 11a6916269516c4e5b6bf006d943609a71740a4d3a60 >>> Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae >>> Processing the authorize section of radiusd.conf >>> modcall: entering group authorize for request 8 >>> modcall[authorize]: module "preprocess" returns ok for request 8 >>> radius_xlat: >>> > '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>> rlm_detail: >>> > /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% > Y% >>> m%d expands to >>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>> 15 >>> modcall[authorize]: module "auth_log" returns ok for request 8 >>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>> rlm_realm: No such realm "NULL" >>> modcall[authorize]: module "suffix" returns noop for request 8 >>> rlm_eap: EAP packet type response id 5 length 253 >>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>> modcall[authorize]: module "eap" returns updated for request 8 >>> users: Matched entry radiustst at line 54 >>> modcall[authorize]: module "files" returns ok for request 8 >>> modcall: group authorize returns updated for request 8 >>> rad_check_password: Found Auth-Type EAP >>> auth: type "EAP" >>> Processing the authenticate section of radiusd.conf >>> modcall: entering group authenticate for request 8 >>> rlm_eap: Request found, released from the list >>> rlm_eap: EAP/tls >>> rlm_eap: processing type tls >>> rlm_eap_tls: Authenticate >>> rlm_eap_tls: processing TLS >>> rlm_eap_tls: Length Included >>> eaptls_verify returned 11 >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate >>> chain-depth=1, error=0 >>> --> User-Name = radiustst >>> --> BUF-Name = ECEAuthServer >>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> verify return:1 >>> chain-depth=0, >>> error=0 >>> --> User-Name = radiustst >>> --> BUF-Name = radiustst >>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst >>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> verify return:1 >>> TLS_accept: SSLv3 read client certificate A >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange >>> TLS_accept: SSLv3 read client key exchange A >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], CertificateVerify >>> TLS_accept: SSLv3 read certificate verify 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 8 >>> modcall: group authenticate returns handled for request 8 Sending >>> Access-Challenge of id 71 to 129.10.56.156:6001 >>> EAP-Message = >>> > 0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9 > c2 >>> 4322bdbd6ca0af149ba46d197f153a7f4f32 >>> Message-Authenticator = 0x00000000000000000000000000000000 >>> State = 0x70ed13d02f1854999ba5b4513143d53d >>> Finished request 8 >>> Going to the next request >>> Waking up in 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>> length=167 >>> User-Name = "radiustst" >>> NAS-IP-Address = 129.10.56.156 >>> Called-Station-Id = "00-20-a6-4a-12-21" >>> Calling-Station-Id = "00-10-c6-38-af-7b" >>> NAS-Identifier = "APtest3" >>> State = 0x70ed13d02f1854999ba5b4513143d53d >>> Framed-MTU = 1400 >>> NAS-Port-Type = Wireless-802.11 >>> EAP-Message = >>> 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 >>> Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 >>> Processing the authorize section of radiusd.conf >>> modcall: entering group authorize for request 9 >>> modcall[authorize]: module "preprocess" returns ok for request 9 >>> radius_xlat: >>> > '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>> rlm_detail: >>> > /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-% > Y% >>> m%d expands to >>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-200511 >>> 15 >>> modcall[authorize]: module "auth_log" returns ok for request 9 >>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>> rlm_realm: No such realm "NULL" >>> modcall[authorize]: module "suffix" returns noop for request 9 >>> rlm_eap: EAP packet type response id 6 length 33 >>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>> modcall[authorize]: module "eap" returns updated for request 9 >>> users: Matched entry radiustst at line 54 >>> modcall[authorize]: module "files" returns ok for request 9 >>> modcall: group authorize returns updated for request 9 >>> rad_check_password: Found Auth-Type EAP >>> auth: type "EAP" >>> Processing the authenticate section of radiusd.conf >>> modcall: entering group authenticate for request 9 >>> rlm_eap: Request found, released from the list >>> rlm_eap: EAP/tls >>> rlm_eap: processing type tls >>> rlm_eap_tls: Authenticate >>> rlm_eap_tls: processing TLS >>> rlm_eap_tls: Length Included >>> eaptls_verify returned 11 >>> eaptls_process returned 7 >>> rlm_eap_tls: Received unexpected tunneled data after successful >>> handshake. >>> rlm_eap: Handler failed in EAP/tls >>> rlm_eap: Failed in EAP select >>> modcall[authenticate]: module "eap" returns invalid for request 9 >>> modcall: group authenticate returns invalid for request 9 >>> auth: Failed to validate the user. >>> Login incorrect: [radiustst/<no User-Password attribute>] (from >>> client >>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) Delaying request 9 for >>> 1 seconds Finished request 9 Going to the next request Waking up in >>> 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>> length=167 >>> Sending Access-Reject of id 72 to 129.10.56.156:6001 >>> EAP-Message = 0x04060004 >>> Message-Authenticator = 0x00000000000000000000000000000000 >>> --- Walking the entire request list --- Waking up in 1 seconds... >>> --- Walking the entire request list --- Cleaning up request 5 ID 68 >>> with timestamp 437a661d Cleaning up request 6 ID 69 with timestamp >>> 437a661d Cleaning up request 7 ID 70 with timestamp 437a661d >>> Cleaning up request 8 ID 71 with timestamp 437a661d Cleaning up >>> request 9 ID 72 with timestamp 437a661d Nothing to do. Sleeping >>> until we see a request. >>> - >>> List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html >>> >> >> l8* >> -lava >> >> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >> > l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavours to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

1 0

Re: FreeRadius EAP-TLS issue
by Hamid Salim 16 Nov '05

16 Nov '05

I am not sure if I completly follow: ">If it was regular TLS, i'd tell you to "openssl s_client -connect foo:123 >-cacert /blah". > >Are you sure that you have imported and "trusted" your CA's cetificate on >both the client and the server?" But I used 'how to EAP/TLS' from the FreeRadius web site. It is my understanding (which may be incorrect) that I do not need a passoword. It is something real simple that i have overlooked, but ofcourse challenging to discover! Any comments/help appreciated. Hamid. Brian A. Seklecki wrote: > >If it was regular TLS, i'd tell you to "openssl s_client -connect foo:123 >-cacert /blah". > >Are you sure that you have imported and "trusted" your CA's cetificate on >both the client and the server? > >This is when I let the other guys make suggestions. > >I was just curious of EAP-TLS with client certificates was simply a way of >delivering the username to the client, letting the client authenticate the >server and the server authenticate the identity of the client, and then >providing for another password based mechanism. > >Or if certificate TLS handshake was sufficient for authorization and >authentication... > >For example, Apache SSL can be told to verify client certificates, but >htaccess would still be required. > >With SMTP, client and server SSL verification can be compelled, but for >SMTP AUTH for relay, username/password authentication would still be >required. > > >~BAS > >On Wed, 16 Nov 2005, Hamid Salim wrote: > >> It should not be asking/expecting any userid/password pair. I have >> installed the certificates on the supplicant machine which should be >> sufficient to authenticate without any password requirements. I am not >> sure why the certs are not working??? >> >> >> Brian A. Seklecki wrote: >> >> >>> >>> rlm_eap_tls: Received unexpected tunneled data after successful >>> handshake. >>> >>> ...that's what I get when I try an invalid password in my EAP + Cisco >> 1200 >>> + LDAP + PEAP/MS-CHAPv2 configuration. >>> >>> Let me ask...how is the client certificate method supposed to work? >>> >>> Is the username embeded the CN/CommonName attribute of the certificate >> and >>> the user is prompted for a password which you setup in authenticate {} ? >>> >>> Is that any more secure than using PEAP/MS-CHAPv2 ? >>> >>> ~BAS >>> >>> >>> On Wed, 16 Nov 2005, Hamid Salim wrote: >>> >>>> Hi, >>>> I am just wondering if anyone has encountered the same issue. I have >>>> set up my enviornment for EAP-TLS, with windows XP SP2 as a supplicant. >>>> For some reason I am getting: >>>> >>>> auth: Failed to validate the user. >>>> Login incorrect: [radiustst/<no User-Password attribute>] (from client >>>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>>> >>>> complete listing is attached. I am using certificates and SSL session >>>> is created successfully, then why FreeRadius is expecting a >>>> userid/password? >>>> >>>> Any help will be appreciated. >>>> >>>> Thanks >>>> Hamid. >>>> >>>> ============= Complete Listing ================= >>>> Going to the next request >>>> Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, >>>> length=1247 >>>> User-Name = "radiustst" >>>> NAS-IP-Address = 129.10.56.156 >>>> Called-Station-Id = "00-20-a6-4a-12-21" >>>> Calling-Station-Id = "00-10-c6-38-af-7b" >>>> NAS-Identifier = "APtest3" >>>> State = 0xb9a67433435733a42f7cbd528aa6ae7a >>>> Framed-MTU = 1400 >>>> NAS-Port-Type = Wireless-802.11 >>>> EAP-Message = >>>> >> 0x020504510d800000044716030104170b000307000304000301308202fd30820266a003 >>>> >> 020102020102300d06092a864886f70d01010405003054310b3009060355040613025553 >>>> >> 310b3009060355040813024d413120301e060355040a13174e6f7274686561737465726e >>>> >> 20556e6976657273697479311630140603550403130d4543454175746853657276657230 >>>> >> 1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b30 >>>> >> 09060355040613025553310b3009060355040813024d413120301e060355040a13174e6f >>>> >> 7274686561737465726e20556e6976657273697479311230100603550403130972616469 >>>> 7573 >>>> EAP-Message = >>>> >> 0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b9983d >>>> >> b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399c3 >>>> >> 9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d76 >>>> >> 9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175a0 >>>> >> 47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d1304 >>>> >> 023000302c06096086480186f842010d041f161d4f70656e53534c2047656e6572617465 >>>> >> 64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f828157 >>>> 2f5e >>>> EAP-Message = >>>> >> 0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf3743 >>>> >> 0ee64b68e9a158a4563054310b3009060355040613025553310b3009060355040813024d >>>> >> 413120301e060355040a13174e6f7274686561737465726e20556e697665727369747931 >>>> >> 1630140603550403130d45434541757468536572766572820900cab77a537cadfaf3300d >>>> >> 06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e2d >>>> >> 8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf00 >>>> >> d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57dae0 >>>> c423 >>>> EAP-Message = >>>> >> 0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f27465 >>>> >> 1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000f0 >>>> >> 70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df74 >>>> >> 830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e2f >>>> >> 30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e69 >>>> >> 99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1a3 >>>> >> 25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5fdd >>>> 8f7c >>>> EAP-Message = >>>> >> 0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d80 >>>> >> af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf869886 >>>> 11a6916269516c4e5b6bf006d943609a71740a4d3a60 >>>> Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae >>>> Processing the authorize section of radiusd.conf >>>> modcall: entering group authorize for request 8 >>>> modcall[authorize]: module "preprocess" returns ok for request 8 >>>> radius_xlat: >>>> >> '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>>> rlm_detail: >>>> >> /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y% >>>> m%d expands to >>>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115 >>>> modcall[authorize]: module "auth_log" returns ok for request 8 >>>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>>> rlm_realm: No such realm "NULL" >>>> modcall[authorize]: module "suffix" returns noop for request 8 >>>> rlm_eap: EAP packet type response id 5 length 253 >>>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>>> modcall[authorize]: module "eap" returns updated for request 8 >>>> users: Matched entry radiustst at line 54 >>>> modcall[authorize]: module "files" returns ok for request 8 >>>> modcall: group authorize returns updated for request 8 >>>> rad_check_password: Found Auth-Type EAP >>>> auth: type "EAP" >>>> Processing the authenticate section of radiusd.conf >>>> modcall: entering group authenticate for request 8 >>>> rlm_eap: Request found, released from the list >>>> rlm_eap: EAP/tls >>>> rlm_eap: processing type tls >>>> rlm_eap_tls: Authenticate >>>> rlm_eap_tls: processing TLS >>>> rlm_eap_tls: Length Included >>>> eaptls_verify returned 11 >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate >>>> chain-depth=1, >>>> error=0 >>>> --> User-Name = radiustst >>>> --> BUF-Name = ECEAuthServer >>>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>>> --> verify return:1 >>>> chain-depth=0, >>>> error=0 >>>> --> User-Name = radiustst >>>> --> BUF-Name = radiustst >>>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst >>>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>>> --> verify return:1 >>>> TLS_accept: SSLv3 read client certificate A >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange >>>> TLS_accept: SSLv3 read client key exchange A >>>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], CertificateVerify >>>> TLS_accept: SSLv3 read certificate verify 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 8 >>>> modcall: group authenticate returns handled for request 8 >>>> Sending Access-Challenge of id 71 to 129.10.56.156:6001 >>>> EAP-Message = >>>> >> 0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9c2 >>>> 4322bdbd6ca0af149ba46d197f153a7f4f32 >>>> Message-Authenticator = 0x00000000000000000000000000000000 >>>> State = 0x70ed13d02f1854999ba5b4513143d53d >>>> Finished request 8 >>>> Going to the next request >>>> Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>>> length=167 >>>> User-Name = "radiustst" >>>> NAS-IP-Address = 129.10.56.156 >>>> Called-Station-Id = "00-20-a6-4a-12-21" >>>> Calling-Station-Id = "00-10-c6-38-af-7b" >>>> NAS-Identifier = "APtest3" >>>> State = 0x70ed13d02f1854999ba5b4513143d53d >>>> Framed-MTU = 1400 >>>> NAS-Port-Type = Wireless-802.11 >>>> EAP-Message = >>>> 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 >>>> Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 >>>> Processing the authorize section of radiusd.conf >>>> modcall: entering group authorize for request 9 >>>> modcall[authorize]: module "preprocess" returns ok for request 9 >>>> radius_xlat: >>>> >> '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>>> rlm_detail: >>>> >> /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y% >>>> m%d expands to >>>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115 >>>> modcall[authorize]: module "auth_log" returns ok for request 9 >>>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>>> rlm_realm: No such realm "NULL" >>>> modcall[authorize]: module "suffix" returns noop for request 9 >>>> rlm_eap: EAP packet type response id 6 length 33 >>>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>>> modcall[authorize]: module "eap" returns updated for request 9 >>>> users: Matched entry radiustst at line 54 >>>> modcall[authorize]: module "files" returns ok for request 9 >>>> modcall: group authorize returns updated for request 9 >>>> rad_check_password: Found Auth-Type EAP >>>> auth: type "EAP" >>>> Processing the authenticate section of radiusd.conf >>>> modcall: entering group authenticate for request 9 >>>> rlm_eap: Request found, released from the list >>>> rlm_eap: EAP/tls >>>> rlm_eap: processing type tls >>>> rlm_eap_tls: Authenticate >>>> rlm_eap_tls: processing TLS >>>> rlm_eap_tls: Length Included >>>> eaptls_verify returned 11 >>>> eaptls_process returned 7 >>>> rlm_eap_tls: Received unexpected tunneled data after successful >>>> handshake. >>>> rlm_eap: Handler failed in EAP/tls >>>> rlm_eap: Failed in EAP select >>>> modcall[authenticate]: module "eap" returns invalid for request 9 >>>> modcall: group authenticate returns invalid for request 9 >>>> auth: Failed to validate the user. >>>> Login incorrect: [radiustst/<no User-Password attribute>] (from client >>>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>>> Delaying request 9 for 1 seconds >>>> Finished request 9 >>>> Going to the next request >>>> Waking up in 6 seconds... >>>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>>> length=167 >>>> Sending Access-Reject of id 72 to 129.10.56.156:6001 >>>> EAP-Message = 0x04060004 >>>> Message-Authenticator = 0x00000000000000000000000000000000 >>>> --- Walking the entire request list --- >>>> Waking up in 1 seconds... >>>> --- Walking the entire request list --- >>>> Cleaning up request 5 ID 68 with timestamp 437a661d >>>> Cleaning up request 6 ID 69 with timestamp 437a661d >>>> Cleaning up request 7 ID 70 with timestamp 437a661d >>>> Cleaning up request 8 ID 71 with timestamp 437a661d >>>> Cleaning up request 9 ID 72 with timestamp 437a661d >>>> Nothing to do. Sleeping until we see a request. >>>> - >>>> List info/subscribe/unsubscribe? See >> http://www.freeradius.org/list/users.html >>>> >>> >>> l8* >>> -lava >>> >>> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >>> >> > >l8* > -lava > >x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >

1 0

Re: FreeRadius EAP-TLS issue
by Brian A. Seklecki 16 Nov '05

16 Nov '05

If it was regular TLS, i'd tell you to "openssl s_client -connect foo:123 -cacert /blah". Are you sure that you have imported and "trusted" your CA's cetificate on both the client and the server? This is when I let the other guys make suggestions. I was just curious of EAP-TLS with client certificates was simply a way of delivering the username to the client, letting the client authenticate the server and the server authenticate the identity of the client, and then providing for another password based mechanism. Or if certificate TLS handshake was sufficient for authorization and authentication... For example, Apache SSL can be told to verify client certificates, but htaccess would still be required. With SMTP, client and server SSL verification can be compelled, but for SMTP AUTH for relay, username/password authentication would still be required. ~BAS On Wed, 16 Nov 2005, Hamid Salim wrote: > It should not be asking/expecting any userid/password pair. I have > installed the certificates on the supplicant machine which should be > sufficient to authenticate without any password requirements. I am not > sure why the certs are not working??? > > > Brian A. Seklecki wrote: > > >> >> rlm_eap_tls: Received unexpected tunneled data after successful >> handshake. >> >> ...that's what I get when I try an invalid password in my EAP + Cisco > 1200 >> + LDAP + PEAP/MS-CHAPv2 configuration. >> >> Let me ask...how is the client certificate method supposed to work? >> >> Is the username embeded the CN/CommonName attribute of the certificate > and >> the user is prompted for a password which you setup in authenticate {} ? >> >> Is that any more secure than using PEAP/MS-CHAPv2 ? >> >> ~BAS >> >> >> On Wed, 16 Nov 2005, Hamid Salim wrote: >> >>> Hi, >>> I am just wondering if anyone has encountered the same issue. I have >>> set up my enviornment for EAP-TLS, with windows XP SP2 as a supplicant. >>> For some reason I am getting: >>> >>> auth: Failed to validate the user. >>> Login incorrect: [radiustst/<no User-Password attribute>] (from client >>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>> >>> complete listing is attached. I am using certificates and SSL session >>> is created successfully, then why FreeRadius is expecting a >>> userid/password? >>> >>> Any help will be appreciated. >>> >>> Thanks >>> Hamid. >>> >>> ============= Complete Listing ================= >>> Going to the next request >>> Waking up in 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=71, >>> length=1247 >>> User-Name = "radiustst" >>> NAS-IP-Address = 129.10.56.156 >>> Called-Station-Id = "00-20-a6-4a-12-21" >>> Calling-Station-Id = "00-10-c6-38-af-7b" >>> NAS-Identifier = "APtest3" >>> State = 0xb9a67433435733a42f7cbd528aa6ae7a >>> Framed-MTU = 1400 >>> NAS-Port-Type = Wireless-802.11 >>> EAP-Message = >>> > 0x020504510d800000044716030104170b000307000304000301308202fd30820266a003 >>> > 020102020102300d06092a864886f70d01010405003054310b3009060355040613025553 >>> > 310b3009060355040813024d413120301e060355040a13174e6f7274686561737465726e >>> > 20556e6976657273697479311630140603550403130d4543454175746853657276657230 >>> > 1e170d3035313130353232323335345a170d3036313130353232323335345a3050310b30 >>> > 09060355040613025553310b3009060355040813024d413120301e060355040a13174e6f >>> > 7274686561737465726e20556e6976657273697479311230100603550403130972616469 >>> 7573 >>> EAP-Message = >>> > 0x74737430819f300d06092a864886f70d010101050003818d0030818902818100b9983d >>> > b3e72f80fd974f9bcd64081d573fdd27b19089405b696d873f87467ff80a312ef7b399c3 >>> > 9e9e7018e1aa29203251c40dd6af46d060d1211405bea1888d058da35230f55d7dc27d76 >>> > 9e0234824d78d5d1b5edf8d39f8ab78255e6cca753424cd0713339a02cf315fbcb6175a0 >>> > 47fa233d9f64d6f936f5e3a403bcca93ab0203010001a381e23081df30090603551d1304 >>> > 023000302c06096086480186f842010d041f161d4f70656e53534c2047656e6572617465 >>> > 64204365727469666963617465301d0603551d0e04160414b77dd4b0207270418f828157 >>> 2f5e >>> EAP-Message = >>> > 0x3353216fe55f3081840603551d23047d307b801463d38ab984dc364e31383d1ecf3743 >>> > 0ee64b68e9a158a4563054310b3009060355040613025553310b3009060355040813024d >>> > 413120301e060355040a13174e6f7274686561737465726e20556e697665727369747931 >>> > 1630140603550403130d45434541757468536572766572820900cab77a537cadfaf3300d >>> > 06092a864886f70d0101040500038181003cbaf9e576319601ba75222ef4fed8cd584e2d >>> > 8aea2f25788bff348f53a699ecab5cb50143f369e7a59da5ba5212105e4d1b642f56cf00 >>> > d04efcb911239047393875024e5e4a17b0ac8f87d165c81a5fcfbe2f2a67ee6c7e57dae0 >>> c423 >>> EAP-Message = >>> > 0x4a3f81753b0817b63f117a0b28c1ca43e1cb31142b47103caef9f28c01860b49f27465 >>> > 1000008200805d53b3419d272d68175ae404a9a51774f148420e7832d39ceaa311a000f0 >>> > 70ebf121d27c6f8b15369ab4bc9a1edadd2abd1caace3378f6a9f6623e6f9cb95085df74 >>> > 830c3e22638bd8e3a63938c9ea8b93895aca23aa131f728ffab7c0cee86b7ed10ced5e2f >>> > 30ad19df6cd83a0ac6564a9b833b284b52ff9355741efc7b3e360f0000820080131f2e69 >>> > 99c156d32b83cb27036db11e9c3571b66d7ab062208a03daf1afb9b3c4a326a09663c1a3 >>> > 25a3b846a2a34d4cfbdcbd432a18017a9ece2744de377c964649ac146466ee4b71fa5fdd >>> 8f7c >>> EAP-Message = >>> > 0x1272df4226eb2805f9268ae2a2e0d0664ced1a8868bada17475dc7889cb73634641d80 >>> > af384311d0b2b9e87c7bde4227a47d14030100010116030100202a0a0a3102caaf869886 >>> 11a6916269516c4e5b6bf006d943609a71740a4d3a60 >>> Message-Authenticator = 0x1e4e290a1071052212513c61bfa25dae >>> Processing the authorize section of radiusd.conf >>> modcall: entering group authorize for request 8 >>> modcall[authorize]: module "preprocess" returns ok for request 8 >>> radius_xlat: >>> > '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>> rlm_detail: >>> > /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y% >>> m%d expands to >>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115 >>> modcall[authorize]: module "auth_log" returns ok for request 8 >>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>> rlm_realm: No such realm "NULL" >>> modcall[authorize]: module "suffix" returns noop for request 8 >>> rlm_eap: EAP packet type response id 5 length 253 >>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>> modcall[authorize]: module "eap" returns updated for request 8 >>> users: Matched entry radiustst at line 54 >>> modcall[authorize]: module "files" returns ok for request 8 >>> modcall: group authorize returns updated for request 8 >>> rad_check_password: Found Auth-Type EAP >>> auth: type "EAP" >>> Processing the authenticate section of radiusd.conf >>> modcall: entering group authenticate for request 8 >>> rlm_eap: Request found, released from the list >>> rlm_eap: EAP/tls >>> rlm_eap: processing type tls >>> rlm_eap_tls: Authenticate >>> rlm_eap_tls: processing TLS >>> rlm_eap_tls: Length Included >>> eaptls_verify returned 11 >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 030b], Certificate >>> chain-depth=1, >>> error=0 >>> --> User-Name = radiustst >>> --> BUF-Name = ECEAuthServer >>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> verify return:1 >>> chain-depth=0, >>> error=0 >>> --> User-Name = radiustst >>> --> BUF-Name = radiustst >>> --> subject = /C=US/ST=MA/O=Northeastern University/CN=radiustst >>> --> issuer = /C=US/ST=MA/O=Northeastern University/CN=ECEAuthServer >>> --> verify return:1 >>> TLS_accept: SSLv3 read client certificate A >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], ClientKeyExchange >>> TLS_accept: SSLv3 read client key exchange A >>> rlm_eap_tls: <<< TLS 1.0 Handshake [length 0086], CertificateVerify >>> TLS_accept: SSLv3 read certificate verify 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 8 >>> modcall: group authenticate returns handled for request 8 >>> Sending Access-Challenge of id 71 to 129.10.56.156:6001 >>> EAP-Message = >>> > 0x010600350d800000002b1403010001011603010020c76c26e20a3f56cdad1183c5e9c2 >>> 4322bdbd6ca0af149ba46d197f153a7f4f32 >>> Message-Authenticator = 0x00000000000000000000000000000000 >>> State = 0x70ed13d02f1854999ba5b4513143d53d >>> Finished request 8 >>> Going to the next request >>> Waking up in 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>> length=167 >>> User-Name = "radiustst" >>> NAS-IP-Address = 129.10.56.156 >>> Called-Station-Id = "00-20-a6-4a-12-21" >>> Calling-Station-Id = "00-10-c6-38-af-7b" >>> NAS-Identifier = "APtest3" >>> State = 0x70ed13d02f1854999ba5b4513143d53d >>> Framed-MTU = 1400 >>> NAS-Port-Type = Wireless-802.11 >>> EAP-Message = >>> 0x020600210d8000000017150301001267dd17534e604a647897732130f58409b115 >>> Message-Authenticator = 0xce216e15de7058166ce90f8cde7d5094 >>> Processing the authorize section of radiusd.conf >>> modcall: entering group authorize for request 9 >>> modcall[authorize]: module "preprocess" returns ok for request 9 >>> radius_xlat: >>> > '/opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115' >>> rlm_detail: >>> > /opt/radiusd/var/log/radius/radacct/%{Client-IP-Address}/auth-detail-%Y% >>> m%d expands to >>> /opt/radiusd/var/log/radius/radacct/129.10.56.156/auth-detail-20051115 >>> modcall[authorize]: module "auth_log" returns ok for request 9 >>> rlm_realm: No '@' in User-Name = "radiustst", looking up realm NULL >>> rlm_realm: No such realm "NULL" >>> modcall[authorize]: module "suffix" returns noop for request 9 >>> rlm_eap: EAP packet type response id 6 length 33 >>> rlm_eap: No EAP Start, assuming it's an on-going EAP conversation >>> modcall[authorize]: module "eap" returns updated for request 9 >>> users: Matched entry radiustst at line 54 >>> modcall[authorize]: module "files" returns ok for request 9 >>> modcall: group authorize returns updated for request 9 >>> rad_check_password: Found Auth-Type EAP >>> auth: type "EAP" >>> Processing the authenticate section of radiusd.conf >>> modcall: entering group authenticate for request 9 >>> rlm_eap: Request found, released from the list >>> rlm_eap: EAP/tls >>> rlm_eap: processing type tls >>> rlm_eap_tls: Authenticate >>> rlm_eap_tls: processing TLS >>> rlm_eap_tls: Length Included >>> eaptls_verify returned 11 >>> eaptls_process returned 7 >>> rlm_eap_tls: Received unexpected tunneled data after successful >>> handshake. >>> rlm_eap: Handler failed in EAP/tls >>> rlm_eap: Failed in EAP select >>> modcall[authenticate]: module "eap" returns invalid for request 9 >>> modcall: group authenticate returns invalid for request 9 >>> auth: Failed to validate the user. >>> Login incorrect: [radiustst/<no User-Password attribute>] (from client >>> testradius-ap-1 port 0 cli 00-10-c6-38-af-7b) >>> Delaying request 9 for 1 seconds >>> Finished request 9 >>> Going to the next request >>> Waking up in 6 seconds... >>> rad_recv: Access-Request packet from host 129.10.56.156:6001, id=72, >>> length=167 >>> Sending Access-Reject of id 72 to 129.10.56.156:6001 >>> EAP-Message = 0x04060004 >>> Message-Authenticator = 0x00000000000000000000000000000000 >>> --- Walking the entire request list --- >>> Waking up in 1 seconds... >>> --- Walking the entire request list --- >>> Cleaning up request 5 ID 68 with timestamp 437a661d >>> Cleaning up request 6 ID 69 with timestamp 437a661d >>> Cleaning up request 7 ID 70 with timestamp 437a661d >>> Cleaning up request 8 ID 71 with timestamp 437a661d >>> Cleaning up request 9 ID 72 with timestamp 437a661d >>> Nothing to do. Sleeping until we see a request. >>> - >>> List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html >>> >> >> l8* >> -lava >> >> x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8 >> > l8* -lava x.25 - minix - bitnet - plan9 - 110 bps - ASR 33 - base8

1 0

Attribute question
by Jorge Pomoro 16 Nov '05

16 Nov '05

Hi, is there an attribute for limit the numbers of connections of one user? and after the last connection no longer the user can connect thanks

1 0

[Was: Problem with rlm_mschap from CVS] rlm_mschap: Unknown expansion string
by Luca Corti 16 Nov '05

16 Nov '05

Hello, I've checked out the exec.c fixes, but now there seem to be problems with variables passwed to ntlm_auth. Processing the authenticate section of radiusd.conf modcall: entering group MS-CHAP for request 30 rlm_mschap: No User-Password configured. Cannot create LM-Password. rlm_mschap: No User-Password configured. Cannot create NT-Password. rlm_mschap: Told to do MS-CHAPv2 for myuser with NT-Password radius_xlat: '--username=myuser' radius_xlat: Running registered xlat function of module mschap for string 'Challenge:-00' rlm_mschap: Unknown expansion string "Challenge:-00" radius_xlat: '--challenge=' radius_xlat: Running registered xlat function of module mschap for string 'NT-Response:-00' rlm_mschap: Unknown expansion string "NT-Response:-00" radius_xlat: '--nt-response=' hex decode of failed! (only got 0 bytes) Exec-Program output: Exec-Program: returned: 1 rlm_mschap: External script failed. rlm_mschap: FAILED: MS-CHAP2-Response is incorrect modcall[authenticate]: module "mschap" returns reject for request 30 modcall: leaving group MS-CHAP (returns reject) for request 30 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns reject for request 30 modcall: leaving group authenticate (returns reject) for request 30 auth: Failed to validate the user. PEAP: Got tunneled reply RADIUS code 3 MS-CHAP-Error = "\006E=691 R=1" EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Processing from tunneled session code 0x813a1d0 3 MS-CHAP-Error = "\006E=691 R=1" EAP-Message = 0x04060004 Message-Authenticator = 0x00000000000000000000000000000000 PEAP: Tunneled authentication was rejected. rlm_eap_peap: FAILURE Here is my ntlm_auth configuration: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username={Stripped-User-Name:-%{User-Name:-None}} --challenge={mschap:Challenge:-00} --nt-response={mschap:NT-Response:-00}" thanks -- Luca Corti PGP Key ID 1F38C091 BOFH excuse of the moment: The keyboard isn't plugged in

4 7

"Pool-Name" check item causes Access-Reject
by Gerret Apelt 16 Nov '05

16 Nov '05

Hi List, My setup: Debian Sarge (2.6.8) Debian package freeradius-mysql 1.0.5-2 FreeRADIUS Version 1.0.5, for host , built on Oct 16 2005 at 11:56:56 I am successfully authentiating dialup users with Freeradius; the users live in a MySQL db. Their IP addresses are assigned by a Patton RAS's internal pool. I want to take this task away from the RAS and have Freeradius ippool take over. Associating a pool with a user is causing that user's access request to be rejected wher it worked before. Following the docs, I have the files db.ipindex and db.ippol set up, and the main_pool is configured in radiusd.conf. user 'gerret' is the gunea pig with the following radcheck table entries: | 1354 | gerret | User-Password | == | testpw | | 1491 | gerret | Pool-Name | == | main_pool | Now here's the tail of two "radtest gerret testpw localhost 0 testing123" runs: 1) With row 1491 not present: modcall[authorize]: module "sql" returns ok for request 2 modcall: group authorize returns ok for request 2 rad_check_password: Found Auth-Type Local auth: type Local auth: user supplied User-Password matches local User-Password Login OK: [gerret] (from client localhost port 0) 2) with boths rows present: rlm_sql (sql): No matching entry in the database for request from user [gerret] rlm_sql (sql): Released sql socket id: 3 modcall[authorize]: module "sql" returns notfound for request 1 modcall: group authorize returns ok for request 1 auth: No authenticate method (Auth-Type) configuration found for the request: Rejecting the user auth: Failed to validate the user. Login incorrect: [gerret/testpw] (from client localhost port 0) Delaying request 1 for 1 seconds Finished request 1 I have tried setting explicit "Auth-Type = Local" in an additional radcheck item to no avail. All mysql queries return the same data in both cases. *cry for help* thanks guys Gerret

2 1

Odd problem (FreeRadius 1.0.5 / MSSQL 2000 / Fedora Core 3)
by Matt 16 Nov '05

16 Nov '05

We have the exact same configuration working on another system, but have been unable to get it to work correctly on this Fedora Core 3 system. We are using rlm_sql to have FreeRadius talk to our MSSQL 2000 database. That works. The odd part is on the Fedora Core 3 system it seems to be having issues reading the shared secret. When I start the server in debug mode I get: rlm_sql (sql: Read entry nasname=216.240.101.102,shortname=auth1.virtdom.com,secret=8Y Well this is all good, but the secret is not "8Y". In fact it's more something like cP83ufJu32 The fields are all nvarchar in the database (ip, shortname, secret)... yet ip and shortname display correctly. If I go into the C code for the rlm_sql module and put row[8] in place of row[5] in the debug I get the same thing, even though row[8] has the description of the NAS. If I use tsql to connect to the database and do a select * from my NAS table, all the data comes out right. It seems like something in freeradius is mangeling the sharedsecret. Can anyone shed light on this?

1 1

client configuration with max6000
by Danny Zenzano 16 Nov '05

16 Nov '05

i m working with the max6000-lucent and the freeradius 1.0.0-5 but in the client file i can see a list of NAS: # The nastype tells 'checkrad.pl' which NAS-specific method to # use to query the NAS for simultaneous use. # # Permitted NAS types are: # # cisco # computone # livingston # max40xx # multitech # netserver # pathras # patton # portslave # tc # usrhiper # other # for all other types which of the options I must choose? i configure something like this: client 192.1.1.1 { # secret and password are mapped through the "secrets" file. secret = secret shortname = Ras # the following three fields are optional, but may be used by # checkrad.pl for simultaneous usage checks nastype = other #login = RasViva #password = vivaMMS }

2 1

Login incorrect- RAS autentication
by Danny Zenzano 16 Nov '05

16 Nov '05

hi, I am trying to make work an RAS(lucent-max6000) with the freeRADIUS,I configure the MAX6000, and the radius obtains an authentication order from the RAS, but as result I obtain a login error message. somebody could help me? this is the result: Ready to process requests. rad_recv: Access-Request packet from host 192.168.1.3:1812, id=51, length=72 rad_recv: Access-Request packet from host 192.168.1.3:1812, id=52, length=78 User-Name = "bridge-RAS-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User User-Name = "initial-banner-RAS" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User rad_recv: Access-Request packet from host 192.168.1.3:1812, id=53, length=64 User-Name = "banner" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User State = 0x Login incorrect: [initial-banner-RAS/ascend] (from client RAS port 0) Login incorrect: [banner/ascend] (from client RAS port 0) Login incorrect: [bridge-RAS-1/ascend] (from client RAS port 0) rad_recv: Access-Request packet from host 192.168.1.3:1812, id=54, length=66 User-Name = "ipxroute-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User Login incorrect: [ipxroute-1/ascend] (from client RAS port 0) rad_recv: Access-Request packet from host 192.168.1.3:1812, id=55, length=63 Sending Access-Reject of id 51 to 192.168.1.3:1812 Sending Access-Reject of id 52 to 192.168.1.3:1812 Sending Access-Reject of id 53 to 192.168.1.3:1812 User-Name = "dovbs-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User rad_recv: Access-Request packet from host 192.168.1.3:1812, id=56, length=68 Login incorrect: [dovbs-1/ascend] (from client RAS port 0) User-Name = "appleroute-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User Login incorrect: [appleroute-1/ascend] (from client RAS port 0) rad_recv: Access-Request packet from host 192.168.1.3:1812, id=57, length=70 User-Name = "initial-banner" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User Login incorrect: [initial-banner/ascend] (from client RAS port 0) Sending Access-Reject of id 54 to 192.168.1.3:1812 Sending Access-Reject of id 55 to 192.168.1.3:1812 Sending Access-Reject of id 56 to 192.168.1.3:1812 Sending Access-Reject of id 57 to 192.168.1.3:1812 rad_recv: Access-Request packet from host 10.40.4.35:2328, id=12, length=44 User-Name = "root" User-Password = "viva123" Login OK: [root/viva123] (from client ZenzanoPC port 0) Sending Access-Accept of id 12 to 10.40.4.35:2328 rad_recv: Access-Request packet from host 192.168.1.3:1812, id=60, length=71 rad_recv: Access-Request packet from host 192.168.1.3:1812, id=61, length=74 User-Name = "route-RAS-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User User-Name = "ipxroute-RAS-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User rad_recv: Access-Request packet from host 192.168.1.3:1812, id=62, length=76 rad_recv: Access-Request packet from host 192.168.1.3:1812, id=63, length=69 rad_recv: Access-Request packet from host 192.168.1.3:1812, id=64, length=76 rad_recv: Access-Request packet from host 192.168.1.3:1812, id=65, length=75 User-Name = "appleroute-RAS-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User rad_recv: Access-Request packet from host 192.168.1.3:1812, id=66, length=72 User-Name = "pools-RAS" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User User-Name = "permconn-RAS-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User State = 0x rad_recv: Access-Request packet from host 192.168.1.3:1812, id=67, length=78 User-Name = "frdlink-RAS-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User State = 0x rad_recv: Access-Request packet from host 192.168.1.3:1812, id=68, length=64 User-Name = "bridge-RAS-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User User-Name = "initial-banner-RAS" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User User-Name = "banner" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User State = 0x Login incorrect: [permconn-RAS-1/ascend] (from client RAS port 0) Login incorrect: [pools-RAS/ascend] (from client RAS port 0) Login incorrect: [ipxroute-RAS-1/ascend] (from client RAS port 0) Login incorrect: [frdlink-RAS-1/ascend] (from client RAS port 0) Login incorrect: [bridge-RAS-1/ascend] (from client RAS port 0) Login incorrect: [initial-banner-RAS/ascend] (from client RAS port 0) Login incorrect: [appleroute-RAS-1/ascend] (from client RAS port 0) Login incorrect: [banner/ascend] (from client RAS port 0) Login incorrect: [route-RAS-1/ascend] (from client RAS port 0) rad_recv: Access-Request packet from host 192.168.1.3:1812, id=69, length=63 User-Name = "dovbs-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User Login incorrect: [dovbs-1/ascend] (from client RAS port 0) rad_recv: Access-Request packet from host 192.168.1.3:1812, id=70, length=66 Sending Access-Reject of id 60 to 192.168.1.3:1812 Sending Access-Reject of id 61 to 192.168.1.3:1812 Sending Access-Reject of id 62 to 192.168.1.3:1812 Sending Access-Reject of id 63 to 192.168.1.3:1812 Sending Access-Reject of id 64 to 192.168.1.3:1812 rad_recv: Access-Request packet from host 192.168.1.3:1812, id=71, length=68 Sending Access-Reject of id 65 to 192.168.1.3:1812 Sending Access-Reject of id 66 to 192.168.1.3:1812 Sending Access-Reject of id 67 to 192.168.1.3:1812 Sending Access-Reject of id 68 to 192.168.1.3:1812 User-Name = "ipxroute-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User User-Name = "appleroute-1" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User rad_recv: Access-Request packet from host 192.168.1.3:1812, id=72, length=70 Login incorrect: [appleroute-1/ascend] (from client RAS port 0) User-Name = "initial-banner" User-Password = "ascend" NAS-IP-Address = 192.168.1.3 NAS-Port = 0 NAS-Port-Type = Virtual Service-Type = Outbound-User Login incorrect: [ipxroute-1/ascend] (from client RAS port 0) Login incorrect: [initial-banner/ascend] (from client RAS port 0) Sending Access-Reject of id 69 to 192.168.1.3:1812 Sending Access-Reject of id 70 to 192.168.1.3:1812 Sending Access-Reject of id 71 to 192.168.1.3:1812 Sending Access-Reject of id 72 to 192.168.1.3:1812

3 3