- Freeradius-Users - lists.freeradius.org

Re: 802.1x & kerberos (Fixed Subject Line)
by Reynolds, Walter 12 Oct '07

12 Oct '07

Yes Ivan, I apologize for pasting an incomplete image command from my test machine. --- Walt Reynolds Principal Systems Security Development Engineer Information Technology Central Services University of Michigan (734) 615-9438 > -----Original Message----- Date: Fri, 12 Oct 2007 15:26:50 +0100 From: <tnt(a)kalik.co.yu> Subject: RE: Freeradius-Users Digest, Vol 30, Issue 48 To: "FreeRadius users mailing list" <freeradius-users(a)lists.freeradius.org> Message-ID: <n4B28c5h.1192199210.5441340.tnt(a)kalik.co.yu> Content-Type: text/plain; charset=ISO-8859-2 >> > DEFAULT Freeradius-Proxied-To == 127.0.0.1 >> > Fall-Through = Yes >> >> That entry does nothing. >I agree it does nothing for authentication, but this will be part of >the solution to get accounting records based on the inner identity and >not the outer with TTLS > >Has something changes in recent code that makes this unnecessary? > No. You probably want: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1 User-Name = `%{User-Name}` Ivan Kalik Kalik Informatika ISP > From: freeradius-users-bounces(a)lists.freeradius.org [mailto:freeradius- > users-bounces(a)lists.freeradius.org] On Behalf Of freeradius-users- > request(a)lists.freeradius.org > Sent: Friday, October 12, 2007 12:34 PM > To: freeradius-users(a)lists.freeradius.org > Subject: Freeradius-Users Digest, Vol 30, Issue 51 > > Send Freeradius-Users mailing list submissions to > freeradius-users(a)lists.freeradius.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freeradius.org/mailman/listinfo/freeradius-users > or, via email, send a message with subject or body 'help' to > freeradius-users-request(a)lists.freeradius.org > > You can reach the person managing the list at > freeradius-users-owner(a)lists.freeradius.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Freeradius-Users digest..." > > > Today's Topics: > > 1. Re: Freeradius-Users Digest, Vol 30, Issue 48 (Alan DeKok) > 2. RE: Freeradius-Users Digest, Vol 30, Issue 48 (tnt(a)kalik.co.yu) > 3. Re: rlm_realm doesn't strip the username (Tomasz Zieleniewski) > 4. Re: FATAL: Thread create failed: Cannot allocate memory > (A.L.M.Buxey(a)lboro.ac.uk) > 5. Re: Darwin DirectoryServices (warnnings) (Alan DeKok) > 6. Using freeradius and 802.1x for ssign VLAN X > (lvizcardof(a)unsa.edu.pe) > 7. Re: rlm_realm doesn't strip the username (tnt(a)kalik.co.yu) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 12 Oct 2007 16:23:33 +0200 > From: Alan DeKok <aland(a)deployingradius.com> > Subject: Re: Freeradius-Users Digest, Vol 30, Issue 48 > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Message-ID: <470F8365.9050603(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Reynolds, Walter wrote: > ... > >>> DEFAULT Freeradius-Proxied-To == 127.0.0.1 > >>> Fall-Through = Yes > >> That entry does nothing. > > I agree it does nothing for authentication, but this will be part of > > the solution to get accounting records based on the inner identity > and > > not the outer with TTLS > > I don't see why. > > > http://www.mail-archive.com/freeradius- > users(a)lists.freeradius.org/msg02045.html > > Which doesn't mention an entry like the one quoted above. > > > Has something changes in recent code that makes this unnecessary? > > I would first like to know why that entry does anything. It > certainly > doesn't set the User-Name. So it doesn't have anything to do with > fixing the anonymous accounting issue. > > Alan DeKok. > > > ------------------------------ > > Message: 2 > Date: Fri, 12 Oct 2007 15:26:50 +0100 > From: <tnt(a)kalik.co.yu> > Subject: RE: Freeradius-Users Digest, Vol 30, Issue 48 > To: "FreeRadius users mailing list" > <freeradius-users(a)lists.freeradius.org> > Message-ID: <n4B28c5h.1192199210.5441340.tnt(a)kalik.co.yu> > Content-Type: text/plain; charset=ISO-8859-2 > > >> > DEFAULT Freeradius-Proxied-To == 127.0.0.1 > >> > Fall-Through = Yes > >> > >> That entry does nothing. > >I agree it does nothing for authentication, but this will be part of > the solution to get accounting records based on the inner identity and > not the outer with TTLS > > > >Has something changes in recent code that makes this unnecessary? > > > > No. You probably want: > > DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1 > User-Name = `%{User-Name}` > > Ivan Kalik > Kalik Informatika ISP > > > > ------------------------------ > > Message: 3 > Date: Fri, 12 Oct 2007 16:51:49 +0200 > From: "Tomasz Zieleniewski" <tzieleniewski(a)gmail.com> > Subject: Re: rlm_realm doesn't strip the username > To: freeradius-users(a)lists.freeradius.org > Cc: aland(a)deployingradius.com > Message-ID: > <5fd52d7a0710120751s1eb4ba67x402a733a1a98f055(a)mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thank you Alan > > I updated to 2.0.0-pre2. But now I have some errors and I can' tcheck > again:) > Now when my NAS sends the Accounting request or I try to run 'radtest' > tool, > the verification fails. > I didn't change anything in the configuration and in the database. I > have > the same NAS configuration. > I get the following error in the debug mode: > > Ignoring request to authentication address * 1812 from unknown client > 127.0.0.1 port 37391 > > Please point me what do I missed:) > > Best regards > tomasz > > Tomasz Zieleniewski wrote: > > > I am using radius version 2.0.0-pre0. > > > I have the following problem that when I receive the Accounting- > Request > > > with the username whose domain part is not checked with any of my > realm > > > defined in the proxy.conf file. The username is not stripped. > > > I use the suffix rule for domain: 'username@domain" in my realm > module > > > and I inoke it in preacct in radiusd.conf. > > > I have the DEFAULT realm defined and it doesn't have the nostrip > option > > > activated. > > > So I think when there is no domain match the username should also > be > > > stripped?? > > > > Likely, yes. What does debug mode say? > > > > You could also try running CVS head, which has a number of fixes > over > > 2.0-pre0. > > > > Alan DeKok. > > > > > > ------------------------------ > > > > Message: 10 > > Date: Fri, 12 Oct 2007 10:16:43 -0300 > > From: "Sergio Belkin" <sebelk(a)gmail.com> > > Subject: Re: TLS fatal access_denied > > To: "FreeRadius users mailing list" > > <freeradius-users(a)lists.freeradius.org> > > Message-ID: > > <8c6f7f450710120616t48014e18g8c02184fdaef6b97(a)mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > 2007/10/11, tnt(a)kalik.co.yu <tnt(a)kalik.co.yu>: > > > How sure are you that you are using EAP-TTLS? > > > > > > > rlm_eap: EAP NAK > > > > rlm_eap: EAP-NAK asked for EAP-Type/peap <== > > > > > > Ivan Kalik > > > Kalik Informatika ISP > > > > > > - > > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > > > > > > I am pretty sure because I has default_eap_type = ttls. I've just > > fixed, it was a problem of certificates... > > > > thanks- > > > > -- > > -- > > Sergio Belkin - > > > > > > ------------------------------ > > > > - > > List info/subscribe/unsubscribe? See > > http://www.freeradius.org/list/users.html > > > > > > End of Freeradius-Users Digest, Vol 30, Issue 49 > > ************************************************ > > >

1 0

Using freeradius and 802.1x for ssign VLAN X
by lvizcardof＠unsa.edu.pe 12 Oct '07

12 Oct '07

Hi, I use freeradius-1.0.4-1.FC4.1 version in a PC Linux Fedora Core 4. I form the file uses: lucy Auth-Type := EAP, User-Password == "lucy" Service-Type = Framed-User, Tunne-type = VLAN, Tunnel-medium-type = IEEE-802, Tunnel-Private-Group-Id = 2 I have this problem: The user "lucy" should to access to vlan 2. But for default it user access to the vlan 1. I don't know how to do for the user "lucy" access to vlan 2 This is the configuration of file eap.conf ================== eap { default_eap_type =tls timer_expire = 60 ignore_unknown_eap_types = no md5 { } leap { } gtc { auth_type = PAP } tls { private_key_password = whatever private_key_file = ${raddbdir}/certs/cert-srv.pem certificate_file = ${raddbdir}/certs/cert-srv.pem CA_file = ${raddbdir}/certs/demoCA/cacert.pem dh_file = ${raddbdir}/certs/dh random_file = ${raddbdir}/certs/random fragment_size = 1024 include_length = yes } ttls { default_eap_type = md5 use_tunneled_reply = yes } peap { default_eap_type = mschapv2 } mschapv2 { } } ============== If any know how resolv this, please write me. ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

3 2

Re: rlm_realm doesn't strip the username
by Tomasz Zieleniewski 12 Oct '07

12 Oct '07

Thank you Alan I updated to 2.0.0-pre2. But now I have some errors and I can' tcheck again:) Now when my NAS sends the Accounting request or I try to run 'radtest' tool, the verification fails. I didn't change anything in the configuration and in the database. I have the same NAS configuration. I get the following error in the debug mode: Ignoring request to authentication address * 1812 from unknown client 127.0.0.1 port 37391 Please point me what do I missed:) Best regards tomasz Tomasz Zieleniewski wrote: > > I am using radius version 2.0.0-pre0. > > I have the following problem that when I receive the Accounting-Request > > with the username whose domain part is not checked with any of my realm > > defined in the proxy.conf file. The username is not stripped. > > I use the suffix rule for domain: 'username@domain" in my realm module > > and I inoke it in preacct in radiusd.conf. > > I have the DEFAULT realm defined and it doesn't have the nostrip option > > activated. > > So I think when there is no domain match the username should also be > > stripped?? > > Likely, yes. What does debug mode say? > > You could also try running CVS head, which has a number of fixes over > 2.0-pre0. > > Alan DeKok. > > > ------------------------------ > > Message: 10 > Date: Fri, 12 Oct 2007 10:16:43 -0300 > From: "Sergio Belkin" <sebelk(a)gmail.com> > Subject: Re: TLS fatal access_denied > To: "FreeRadius users mailing list" > <freeradius-users(a)lists.freeradius.org> > Message-ID: > <8c6f7f450710120616t48014e18g8c02184fdaef6b97(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > 2007/10/11, tnt(a)kalik.co.yu <tnt(a)kalik.co.yu>: > > How sure are you that you are using EAP-TTLS? > > > > > rlm_eap: EAP NAK > > > rlm_eap: EAP-NAK asked for EAP-Type/peap <== > > > > Ivan Kalik > > Kalik Informatika ISP > > > > - > > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > > > > I am pretty sure because I has default_eap_type = ttls. I've just > fixed, it was a problem of certificates... > > thanks- > > -- > -- > Sergio Belkin - > > > ------------------------------ > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > > > End of Freeradius-Users Digest, Vol 30, Issue 49 > ************************************************ >

2 2

RE: Freeradius-Users Digest, Vol 30, Issue 48
by Reynolds, Walter 12 Oct '07

12 Oct '07

-- Walt Reynolds Principle Systems Security Development Engineer Information Technology Central Services University of Michigan (734) 615-9438 > -----Original Message----- > > Message: 5 > Date: Fri, 12 Oct 2007 10:45:11 +0200 > From: Alan DeKok <aland(a)deployingradius.com> > Subject: Re: 802.1x & kerberos > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Message-ID: <470F3417.8040308(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Lisa Besko wrote: > > Thanks for the help so far. Part of the problem is we have probably > > tried so many things we probably messed something up along the way > don't > > remember what is is. > > Stop right there. If you don't keep track of what you're doing, you > will NEVER get it to work. > > Throw away everything you've done, and start with all of the default > configuration files. Then, proceed with the following steps: > > 1) Configure EAP-TTLS > i.e. the "tls" and "ttls" sub-sections of eap.conf > > 2) Put the following at the TOP of the "users" file: > > bob Cleartext-Password := "bob" > > 3) Start the server in debug mode > > 4) validate that you can log in with "bob" using radtest (i.e. PAP) > > 5) validate that EAP-TTLS works with username/password "bob" and "bob" > > 6) Configure kerberos in radiusd.conf. > > 7) Delete the "bob" entry in the "users" file. > > 8) Replace it with: > > DEFAULT Auth-Type = Kerberos > > And it WILL work. > ... > > authenticate { > > Auth-Type PAP { > > pap > > } > > > > Auth-Type kerberos { > > krb5 > > } > > } > > If you don't list "eap" there, it won't work. Again, throw away your > existing configuration files, and start from the default ones. > > users: > > DEFAULT Freeradius-Proxied-To == 127.0.0.1 > > Fall-Through = Yes > > That entry does nothing. I agree it does nothing for authentication, but this will be part of the solution to get accounting records based on the inner identity and not the outer with TTLS http://www.mail-archive.com/freeradius-users@lists.freeradius.org/msg02045.… Has something changes in recent code that makes this unnecessary? > > > DEFAULT Auth-Type := Kerberos > > Fall-Through = 1 > > An earlier message in this thread said "Auth-Type = Kerberos". What > you have above is different. PLEASE follow instructions carefully. > > Alan DeKok. > >

3 2

Windows XP caches uid and password
by Sergio Belkin 12 Oct '07

12 Oct '07

Hi, I have this problem, I have a radiusd configured with eap-ttls. It worked fine with windows clients when uses "radius plain users" (not from unix nor ldap). When I enable ldap, Windows insists in using the test user i.e. it doesnt show me the login dialog box again. I tried rebooting windows and restarting freeradius para it doesn't worked yet. is there a way from radius for force to windows to renegotiate session? Debugging output: Cleaning up request 3 ID 149 with timestamp 470f75f1 Nothing to do. Sleeping until we see a request. rad_recv: Access-Request packet from host 10.30.1.151:1030, id=150, length=98 User-Name = "test" Calling-Station-Id = "00-0e-35-bf-51-18" EAP-Message = 0x020100090174657374 Framed-MTU = 1287 NAS-IP-Address = 192.168.1.1 NAS-Port = 0 NAS-Port-Type = Wireless-802.11 Message-Authenticator = 0x0ed6c4d76237da8d14c7a6fab645acb0 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 = "test", 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 1 length 9 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 4 modcall[authorize]: module "files" returns notfound for request 4 rlm_ldap: - authorize rlm_ldap: performing user authorization for test radius_xlat: '(uid=test)' radius_xlat: 'ou=people,dc=palermo,dc=edu' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=people,dc=palermo,dc=edu, with filter (uid=test) request done: ld 0x5555557c9300 msgid 6 rlm_ldap: object not found or got ambiguous search result rlm_ldap: search failed rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns notfound for request 4 rlm_pap: WARNING! No "known good" password found for the user. Authentication may fail because of this. modcall[authorize]: module "pap" returns noop for request 4 modcall: leaving 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: 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 4 modcall: leaving group authenticate (returns handled) for request 4 Sending Access-Challenge of id 150 to 10.30.1.151 port 1030 EAP-Message = 0x010200061520 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x512563ac40f384cfa352c98a7960069d Finished request 4 Going to the next request Thanks in advance! -- -- Sergio Belkin -

2 1

TLS fatal access_denied
by Sergio Belkin 12 Oct '07

12 Oct '07

Hi I am using eap-ttls and when I try to connect from Windows XP the ouput in radius server iis as follows: Waking up in 3 seconds... rad_recv: Access-Request packet from host 10.30.1.151:1031, id=55, length=113 User-Name = "test" Calling-Station-Id = "00-0e-35-bf-51-18" EAP-Message = 0x020200060319 Framed-MTU = 1287 NAS-IP-Address = 192.168.1.1 NAS-Port = 0 NAS-Port-Type = Wireless-802.11 State = 0x496c1c12e0905d753f98f90dc4b0c2b2 Message-Authenticator = 0x11ec47975956d7defc19bff62d79430e Processing the authorize section of radiusd.conf modcall: entering group authorize for request 26 modcall[authorize]: module "preprocess" returns ok for request 26 modcall[authorize]: module "chap" returns noop for request 26 modcall[authorize]: module "mschap" returns noop for request 26 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 26 rlm_eap: EAP packet type response id 2 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 26 users: Matched entry test at line 62 modcall[authorize]: module "files" returns ok for request 26 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 26 modcall: leaving group authorize (returns updated) for request 26 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 26 rlm_eap: Request found, released from the list rlm_eap: EAP NAK rlm_eap: EAP-NAK asked for EAP-Type/peap rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 26 modcall: leaving group authenticate (returns handled) for request 26 Sending Access-Challenge of id 55 to 10.30.1.151 port 1031 Reply-Message = "Hola test" EAP-Message = 0x010300061920 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xea0d4efbb9ef49d8de3c3f6d3ebc1769 Finished request 26 Going to the next request Waking up in 3 seconds... rad_recv: Access-Request packet from host 10.30.1.151:1031, id=56, length=187 User-Name = "test" Calling-Station-Id = "00-0e-35-bf-51-18" EAP-Message = 0x0203005019800000004616030100410100003d0301470fd5afa0768f1bf04970318849fc7a7839fb43ed9ed9cfe0317b2564ef140200001600040005000a000900640062000300060013001200630100 Framed-MTU = 1287 NAS-IP-Address = 192.168.1.1 NAS-Port = 0 NAS-Port-Type = Wireless-802.11 State = 0xea0d4efbb9ef49d8de3c3f6d3ebc1769 Message-Authenticator = 0x123ab7c62b0dcf0192516c84f15ed8a5 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 27 modcall[authorize]: module "preprocess" returns ok for request 27 modcall[authorize]: module "chap" returns noop for request 27 modcall[authorize]: module "mschap" returns noop for request 27 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 27 rlm_eap: EAP packet type response id 3 length 80 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 27 users: Matched entry test at line 62 modcall[authorize]: module "files" returns ok for request 27 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 27 modcall: leaving group authorize (returns updated) for request 27 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 27 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 0041], 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 0516], 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: Need to read more data: 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 27 modcall: leaving group authenticate (returns handled) for request 27 Sending Access-Challenge of id 56 to 10.30.1.151 port 1031 Reply-Message = "Hola test" EAP-Message = 0x0104040a19c000000573160301004a020000460301470e8458d181472ae6cb4c0cfd0aec460eabff70cefd31a7148291ed16b1d08720d5575fe66c35bfc84e095a83aa4e3a30c0134dc29308b7af2417fd43f32a0a9900040016030105160b00051200050f00050c30820508308203f0a003020102020109300d06092a864886f70d010104050030818e310b3009060355040613024152311530130603550407130c4275656e6f73204169726573311f301d060355040a1316556e6976657273696461642064652050616c65726d6f31273025060355040b131e446570617274616d656e746f20646520436f6d756e69636163696f6e6573311e301c06 EAP-Message = 0x035504031315436572746966696361746520417574686f72697479301e170d3037303130343230303132325a170d3131303130333230303132325a30818d310b3009060355040613024152311530130603550407130c4275656e6f73204169726573311f301d060355040a1316556e6976657273696461642064652050616c65726d6f31273025060355040b131e446570617274616d656e746f20646520436f6d756e69636163696f6e6573311d301b06035504031314737065637472756d2e70616c65726d6f2e65647530820122300d06092a864886f70d01010105000382010f003082010a02820101009fb7de37d68086cd8ddaccf857dc922a55 EAP-Message = 0x69d7105ec847db6bbe727aea4e583562dbc26949b48ef40cb17c256cf16ed6f6c3f5a605300ecc9329eaaee6e885a29d0078a07f3e436bed28c75db21f09f5ea85e6e8f65d00082ca44e7778f490ef7bbec2c6180d537dae3efec79ad3729a2410969902b3a92912e41e18294937c985e87c3f3504b039d84af22c0ab958a2104d41a299fcf28ee2c400ebc2d3b4e4071d697e2454b05e9145f3b87b806b50f4cd0efb13039c33ed3829cbf25f9af6a1a9537aa97ed42882694511cfc27014a7ce9d36cfdb93a0f68af3662823b2d70dbedd445b15f5e07444fc105e4a257548cce119b14166b663b4f68245c1191f0203010001a382016e3082016a30 EAP-Message = 0x090603551d1304023000301106096086480186f8420101040403020640300b0603551d0f0404030205e0302c06096086480186f842010d041f161d50616c65726d6f2047656e657261746564204365727469666963617465301d0603551d0e0416041424fcec6f0e868f46fc8e3d117be23c01307355203081bb0603551d230481b33081b08014fd77533bb6a66d1e3b48bfb5d21501d829ddf469a18194a4819130818e310b3009060355040613024152311530130603550407130c4275656e6f73204169726573311f301d060355040a1316556e6976657273696461642064652050616c65726d6f31273025060355040b131e446570617274616d65 EAP-Message = 0x6e746f20646520436f6d756e69636163696f6e657331 Message-Authenticator = 0x00000000000000000000000000000000 State = 0xfed980e3ba92486eab6d27db87544c2d Finished request 27 Going to the next request Waking up in 3 seconds... rad_recv: Access-Request packet from host 10.30.1.151:1031, id=57, length=113 User-Name = "test" Calling-Station-Id = "00-0e-35-bf-51-18" EAP-Message = 0x020400061900 Framed-MTU = 1287 NAS-IP-Address = 192.168.1.1 NAS-Port = 0 NAS-Port-Type = Wireless-802.11 State = 0xfed980e3ba92486eab6d27db87544c2d Message-Authenticator = 0x5915220b581acc2913bea0a58a74cc9e Processing the authorize section of radiusd.conf modcall: entering group authorize for request 28 modcall[authorize]: module "preprocess" returns ok for request 28 modcall[authorize]: module "chap" returns noop for request 28 modcall[authorize]: module "mschap" returns noop for request 28 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 28 rlm_eap: EAP packet type response id 4 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 28 users: Matched entry test at line 62 modcall[authorize]: module "files" returns ok for request 28 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 28 modcall: leaving group authorize (returns updated) for request 28 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 28 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 28 modcall: leaving group authenticate (returns handled) for request 28 Sending Access-Challenge of id 57 to 10.30.1.151 port 1031 Reply-Message = "Hola test" EAP-Message = 0x0105017919001e301c06035504031315436572746966696361746520417574686f72697479820101303206096086480186f84201040425162368747470733a2f2f777777732e70616c65726d6f2e6564752f63612f63726c2e70656d300d06092a864886f70d01010405000382010100b2f0e85d815bfc024ef1b5269faa0a99de6bcbd537ab0f36e2bbf79afa4d1d958901c0a6df5fda13dd248cc05421f38b3aa82aede606a05ab6808ea86c631ce3d6a91fc2d3a2d956671c5014adc013c264e18e7fef1b82fa8f5e965b5f112888b10f416d4ce35a37bea4486d9f2060a5c541421d2ca1d0546423ad507ad67219a2f5a3459719204113de574dc7 EAP-Message = 0x1a1e154877647e7d5110a038d05249277e7db298b4f5929ae3075bcb26a2de63d0fcb0bb09d93909e8ed2cc4bec19e499b5891750feb425d1f9dbafb9fcae681a02b0d683e72bfd0bd27c5abbf893cb51802f952165410eeb912f334863f020c800f061227a39529cf7c65bb81ae508610ca7b16030100040e000000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x93350c01179beee7339c64d8cb40746f Finished request 28 Going to the next request Waking up in 3 seconds... rad_recv: Access-Request packet from host 10.30.1.151:1031, id=58, length=429 User-Name = "test" Calling-Station-Id = "00-0e-35-bf-51-18" EAP-Message = 0x0205014019800000013616030101061000010201004f6f2b51d96df9fbce202c27dd64b32fe239c2a7b872b49ecf206faa1fb11ae27d604a3092aa39bccf5f27bdabaf03cf119a217884a1b1611d8251a084dbe9a0e3968f17de1e27aa49398f5e5f10990c64be22a7d770e16e0682ab0e17092e1670c19fa1cba57d818c5f2da5af546eafec6d8d1852763970120e3ad1fc5df15e55fc6e086384280137f2208411f01816d81f4042a954efd8355e9f0ee89cd174e3d00438e89589b9bdf10d4a5851c51c738a5489a47ee5bcf3664f79b67a64949ef50dcfc382917654f1c6da2faa96e8b3d91212a589f65a7f4cc7c6d06b06604af7de927d28f6d4 EAP-Message = 0xd9ac56a2752efc9126c03a21226807ea7faa601a37a3c56a1403010001011603010020f8b221aeffd0aa7bcad9675b55a4d07cdc6c363cd9a5b4a10da12349cd425557 Framed-MTU = 1287 NAS-IP-Address = 192.168.1.1 NAS-Port = 0 NAS-Port-Type = Wireless-802.11 State = 0x93350c01179beee7339c64d8cb40746f Message-Authenticator = 0x4469eb9d0d17398edd90a2e638bf0b99 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 29 modcall[authorize]: module "preprocess" returns ok for request 29 modcall[authorize]: module "chap" returns noop for request 29 modcall[authorize]: module "mschap" returns noop for request 29 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 29 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 29 users: Matched entry test at line 62 modcall[authorize]: module "files" returns ok for request 29 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 29 modcall: leaving group authorize (returns updated) for request 29 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 29 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 0106], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully SSL Connection Established eaptls_process returned 13 rlm_eap_peap: EAPTLS_HANDLED modcall[authenticate]: module "eap" returns handled for request 29 modcall: leaving group authenticate (returns handled) for request 29 Sending Access-Challenge of id 58 to 10.30.1.151 port 1031 Reply-Message = "Hola test" EAP-Message = 0x01060031190014030100010116030100209b2cb1197db813a76c4e9ba9e135b4ae047a186da5890006b757c6f3f387f10c Message-Authenticator = 0x00000000000000000000000000000000 State = 0xad86ab92847abf65daa2c4174fcaa327 Finished request 29 Going to the next request Waking up in 3 seconds... rad_recv: Access-Request packet from host 10.30.1.151:1031, id=59, length=140 User-Name = "test" Calling-Station-Id = "00-0e-35-bf-51-18" EAP-Message = 0x0206002119800000001715030100121e4a51c221fd4fcdf3d307619f1676963db5 Framed-MTU = 1287 NAS-IP-Address = 192.168.1.1 NAS-Port = 0 NAS-Port-Type = Wireless-802.11 State = 0xad86ab92847abf65daa2c4174fcaa327 Message-Authenticator = 0x4a9ed2d5270ef65cd5444a241c322946 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 30 modcall[authorize]: module "preprocess" returns ok for request 30 modcall[authorize]: module "chap" returns noop for request 30 modcall[authorize]: module "mschap" returns noop for request 30 rlm_realm: No '@' in User-Name = "test", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 30 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 30 users: Matched entry test at line 62 modcall[authorize]: module "files" returns ok for request 30 rlm_pap: Found existing Auth-Type, not changing it. modcall[authorize]: module "pap" returns noop for request 30 modcall: leaving group authorize (returns updated) for request 30 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 30 rlm_eap: Request found, released from the list rlm_eap: EAP/peap rlm_eap: processing type peap rlm_eap_peap: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Length Included eaptls_verify returned 11 eaptls_process returned 7 rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal access_denied TLS Alert read:fatal:access denied rlm_eap_peap: No data inside of the tunnel. rlm_eap: Handler failed in EAP/peap rlm_eap: Failed in EAP select modcall[authenticate]: module "eap" returns invalid for request 30 modcall: leaving group authenticate (returns invalid) for request 30 auth: Failed to validate the user. Delaying request 30 for 1 seconds Finished request 30 Going to the next request Waking up in 3 seconds... Why can this happen? Thanks in advance! -- -- Sergio Belkin -

2 2

rlm_realm doesn't strip the username
by Tomasz Zieleniewski 12 Oct '07

12 Oct '07

Hi, <http://www.freeradius.org/list/users.html> I am using radius version 2.0.0-pre0. I have the following problem that when I receive the Accounting-Request with the username whose domain part is not checked with any of my realm defined in the proxy.conf file. The username is not stripped. I use the suffix rule for domain: 'username@domain" in my realm module and I inoke it in preacct in radiusd.conf. I have the DEFAULT realm defined and it doesn't have the nostrip option activated. So I think when there is no domain match the username should also be stripped?? I kindly ask for your support. Wait forward for your feedback Best regards Tomasz

2 1

Error in accounting_stop_query when AcctSessionId is longer than 32characters like defined in the database.
by Tomasz Zieleniewski 12 Oct '07

12 Oct '07

Hi, I am using radius 2.0.0-pre0. I encountered following issue. My NAS (radiusclient-ng) sends Accounting requests wich contains AcctSessionId longer than defined in the database which is 32 charaters. When Accounting-Request with Acct-Status-Type:Start arrives to radius the stored record contains the cut parameter. And when there comes the Accounting-Request with Acct-Status-Type:Stop the comparison between AcctSessionId stored in the database always gives negative result. I think there are two solutions, one can increase the column size in the database or change the accounting_stop_query. I am using mysql database. Wating for your feedback. Cheers Tomasz

2 1

Re: 802.1x & kerberos
by Giobbi Piero 12 Oct '07

12 Oct '07

Hi. Saw this in the list and i allways wondered how to test this, how do you do it? I don't have any devices that uses EAP so.. > 5) validate that EAP-TTLS works with username/password "bob" and "bob" thx.

3 2

RE: Simultaneous-Use and PEAP doesn't work correctly.
by Marcotte, Tyler 12 Oct '07

12 Oct '07

Hi, You said it's a bug in 1.x. I just tried the latest code in the cvs repository (2.0 I believe) and I still get the same problem. After the PEAP failure, it sends an Access-Challenge rather than an Access-Reject. Am I missing anything else here? Thank you in advance. Regards, -Tyler > > Marcotte, Tyler wrote: > > > I've configured Simultaneous-Use on my freeradius server and have > it > > configured to use PEAP as an authentication method. Users can > authenticate > > perfectly well, however when the Simultaneous-Use limit is exceeded, > it > > only half works. The user is not allowed on, the PEAP message is set > to > > FAILURE, but no Access-Reject is ever sent. I have also tried with > md5 > > authentication and it works as expected. Unfortunately, md5 > authentication > > is not an option. What I really need is for that Reject to be sent > back > > after the user logs on too many times. > > > > It's a bug in 1.x. Set "reject_delay = 0". > > > > Alan DeKok > > "reject_delay = 0" is already set. If I check out the version from cvs > will it have this problem fixed? > > -Tyler > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html

3 8