- Freeradius-Users - lists.freeradius.org

how to
by Manel Berencia Trull 15 Oct '07

15 Oct '07

I use radius cistron And i need move to freeradius with mysql (radius cistron not support ippool) With the old radius use a file users And have user DEFAULT Auth-Type = Accept , Simultaneous-Use = 9999, Called-Station-Id == "908274060" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-IP-Address = 149.6.17.128+, Framed-IP-Netmask = 255.255.255.255, Framed-Routing = None, Framed-Compression = Van-Jacobson-TCP-IP, Framed-MTU = 1500, Fall-Through = 1 Any user called this number accepted. Hot to put in mysql this Thanks

2 1

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

15 Oct '07

One more time radius looping log but in the zipped form. (hope this time will arive) -tomasz On 10/14/07, Tomasz Zieleniewski <tzieleniewski(a)gmail.com> wrote: > > I forgot to attach the file. > > On 10/14/07, Tomasz Zieleniewski <tzieleniewski(a)gmail.com> wrote: > > > > I moved from database configuration to clients.conf file for pre-2.0.02and there is a strange situation because radius falls into the loop. > > Detailed log from this in the attached file. > > I used radtest for testing. > > > > Cheers > > tomasz > > > > On 10/13/07, tnt(a)kalik.co.yu <tnt(a)kalik.co.yu> wrote: > > > > > > I can't see anything wrong. Try to replace the localhost entry in home > > > server with an IP address of the real interface. It might be that > > > there > > > is a problem when home server and client have the same IP address. > > > > > > Ivan Kalik > > > Kalik Informatika ISP > > > > > > > > > Dana 13/10/2007, "Tomasz Zieleniewski" < tzieleniewski(a)gmail.com > > > > piše: > > > > > > >Alan and what about this previous error: > > > >Ignoring request to authentication address * 1812 from unknown client > > > > 127.0.0.1 port 37391. > > > >I am using database with the same configuration for 2.0.0-pre0 and > > > pre2 and > > > >in case of pre0 it work without any problem. > > > > > > > >Tomasz > > > > > > > >On 10/13/07, Alan DeKok < aland(a)deployingradius.com> wrote: > > > >> > > > >> Tomasz Zieleniewski wrote: > > > >> > I forgot about the atachment:) > > > >> > > > >> In which the server never receives a request. > > > >> > > > >> That part of the code was re-written recently, and may have > > > issues in > > > >> CVS head. I'll take a look. > > > >> > > > >> Alan DeKok. > > > >> - > > > >> List info/subscribe/unsubscribe? See > > > >> http://www.freeradius.org/list/users.html > > > >> > > > > > > > > > > > > > > - > > > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > > > > > > > > > >

1 0

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

14 Oct '07

I wasn't able to find anything meaningful so I attached the whole output in the log file. Bests Tomasz On 10/12/07, tnt(a)kalik.co.yu <tnt(a)kalik.co.yu> wrote: > > radiusd -X of the server startup. > > Ivan Kalik > Kalik Informatika ISP > > > Dana 12/10/2007, "Tomasz Zieleniewski" <tzieleniewski(a)gmail.com> piše: > > >I do not use clients.conf file, I use database. > > > >When I switch to my previous build 2.0.0-pre0 it works. > >When I run 2.0.0-pre2 it doesn't. > >I use the same configuration. > > > >Cheers > >tomasz > > > >On 10/12/07, tnt(a)kalik.co.yu <tnt(a)kalik.co.yu> wrote: > >> > >> Add this to clients.conf: > >> > >> client 127.0.0.1 { > >> secret = testing123 > >> shortname = localhost > >> } > >> > >> Ivan Kalik > >> Kalik Informatika ISP > >> > >> > >> > >> Dana 12/10/2007, "Tomasz Zieleniewski" <tzieleniewski(a)gmail.com> > pi�e: > >> > >> >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 > >> >> ************************************************ > >> >> > >> > > >> > > >> > >> - > >> List info/subscribe/unsubscribe? See > >> http://www.freeradius.org/list/users.html > >> > > > > >

4 8

Re: Problem with LDAP and Groups
by Bryan Evege 14 Oct '07

14 Oct '07

freeradius-users-request(a)lists.freeradius.org wrote: > 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: Problem with LDAP and Groups (Alan DeKok) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Oct 2007 09:58:49 +0200 > From: Alan DeKok <aland(a)deployingradius.com> > Subject: Re: Problem with LDAP and Groups > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Message-ID: <470DD7B9.9040607(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Bryan Evege wrote: > >> Here's the problem. When a user logs in and is a member of more than >> one group radius only uses the first one to match. I've included the >> users file below. >> > > In which you tell it to stop matching after the first one. > > >> DEFAULT Ldap-Group == packeteer_read_only,User-Profile := >> "uid=packeteer_read_only,ou=profiles,ou=radius,dc=csctus,dc=net", >> Auth-Type := LDAP >> Fall-Through = no >> > > See "man users" for the meaning of Fall-Through. Then, change this to > "yes". > > Alan DeKok. > > > ------------------------------ > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > End of Freeradius-Users Digest, Vol 30, Issue 40 > ************************************************ > Thank you for the reply. If I change the fall through to yes it still matches as many groups as the user is in. How can I tell freeradius which attributes to send back? It only sends back the attributes of the last group it finds. For example, bevege is a member of the following groups, packetshapper, cisco_priv_15, cisco_priv_1, linux. Here is what happens when I try to log into one of the packet shappers. I get the attributes for the cisco_priv_1 because it's last in the list and I can't logon. I f I change all of the users groups to fall-through=no the packetshapper allows me to login but then the cisco profiles don't work because it never makes it to them. Basically this setup works fine if you're only in one group! What's the point of groups if you can only be in one. Any help would be appreciated. _*Radius -X -A output *_freeradius-users-request(a)lists.freeradius.org wrote: > 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: Problem with LDAP and Groups (Alan DeKok) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Oct 2007 09:58:49 +0200 > From: Alan DeKok <aland(a)deployingradius.com> > Subject: Re: Problem with LDAP and Groups > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Message-ID: <470DD7B9.9040607(a)deployingradius.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Bryan Evege wrote: >> Here's the problem. When a user logs in and is a member of more than >> one group radius only uses the first one to match. I've included the >> users file below. > > In which you tell it to stop matching after the first one. > >> DEFAULT Ldap-Group == packeteer_read_only,User-Profile := >> "uid=packeteer_read_only,ou=profiles,ou=radius,dc=csctus,dc=net", >> Auth-Type := LDAP >> Fall-Through = no > > See "man users" for the meaning of Fall-Through. Then, change this to > "yes". > > Alan DeKok. > > > ------------------------------ > > - > List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html > > > End of Freeradius-Users Digest, Vol 30, Issue 40 > ************************************************ Thank you for the reply. If I change the fall through to yes it still matches as many groups as the user is in. How can I tell freeradius which attributes to send back? It only sends back the attributes of the last group it finds. radius -X -A output rad_recv: Access-Request packet from host 10.17.71.10:4852, id=68, length=58 User-Name = "bevege" User-Password = "xxxxxxx" Service-Type = Login-User NAS-IP-Address = 10.17.71.10 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 rlm_realm: No '@' in User-Name = "bevege", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(uid=bevege)' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to localhost:389, authentication 0 rlm_ldap: bind as cn=Manager,dc=csctus,dc=net/xxxxx to localhost:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (uid=bevege) rlm_ldap: ldap_release_conn: Release Id: 0 radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=acct_disabled)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap: object not found or got ambiguous search result (user is not a memeber) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in uid=bevege,ou=Atlanta,ou=users,ou=radius,dc=csctus,dc=net, with filter (objectclass=*) rlm_ldap::groupcmp: Group acct_disabled not found ????or user not a member (this is true) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=packeteer_read_only)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap: object not found or got ambiguous search result rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in uid=bevege,ou=Atlanta,ou=users,ou=radius,dc=csctus,dc=net, with filter (objectclass=*) rlm_ldap::groupcmp: Group packeteer_read_only not found ????or user not a member (this is true) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=Packeteer)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap::ldap_groupcmp: User found in group Packeteer (this is true) rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry DEFAULT at line 162 (this is correct.) rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=netscreen)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap: object not found or got ambiguous search result rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in uid=bevege,ou=Atlanta,ou=users,ou=radius,dc=csctus,dc=net, with filter (objectclass=*) rlm_ldap::groupcmp: Group netscreen not found ????or user not a member (this is correct) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=cisco_priv_15)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap::ldap_groupcmp: User found in group cisco_priv_15 (this is correct) rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry DEFAULT at line 168 (this is correct) rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=cisco_priv_1)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap::ldap_groupcmp: User found in group cisco_priv_1 (this is correct) rlm_ldap: ldap_release_conn: Release Id: 0 users: Radius -X -A output rad_recv: Access-Request packet from host 10.17.71.10:4852, id=68, length=58 User-Name = "bevege" User-Password = "xxxxxxx" Service-Type = Login-User NAS-IP-Address = 10.17.71.10 Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module "preprocess" returns ok for request 0 rlm_realm: No '@' in User-Name = "bevege", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(uid=bevege)' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: attempting LDAP reconnection rlm_ldap: (re)connect to localhost:389, authentication 0 rlm_ldap: bind as cn=Manager,dc=csctus,dc=net/xxxxx to localhost:389 rlm_ldap: waiting for bind result ... rlm_ldap: Bind was successful rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (uid=bevege) rlm_ldap: ldap_release_conn: Release Id: 0 radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=acct_disabled)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap: object not found or got ambiguous search result (user is not a memeber) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in uid=bevege,ou=Atlanta,ou=users,ou=radius,dc=csctus,dc=net, with filter (objectclass=*) rlm_ldap::groupcmp: Group acct_disabled not found ????or user not a member (this is true) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=packeteer_read_only)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap: object not found or got ambiguous search result rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in uid=bevege,ou=Atlanta,ou=users,ou=radius,dc=csctus,dc=net, with filter (objectclass=*) rlm_ldap::groupcmp: Group packeteer_read_only not found ????or user not a member (this is true) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=Packeteer)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap::ldap_groupcmp: User found in group Packeteer (this is true) rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry DEFAULT at line 162 (this is correct.) rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=netscreen)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap: object not found or got ambiguous search result rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in uid=bevege,ou=Atlanta,ou=users,ou=radius,dc=csctus,dc=net, with filter (objectclass=*) rlm_ldap::groupcmp: Group netscreen not found ????or user not a member (this is correct) rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=cisco_priv_15)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap::ldap_groupcmp: User found in group cisco_priv_15 (this is correct) rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry DEFAULT at line 168 (this is correct) rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=cisco_priv_1)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap::ldap_groupcmp: User found in group cisco_priv_1 (this is correct) rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry DEFAULT at line 171 (this is correct) rlm_ldap: Entering ldap_groupcmp() radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' radius_xlat: '(&(uid=bevege)(objectclass=radiusprofile))' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (&(radiusGroupName=netscreen)(&(uid=bevege)(objectclass=radiusprofile))) rlm_ldap: object not found or got ambiguous search result rlm_ldap: ldap_release_conn: Release Id: 0 rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in uid=bevege,ou=Atlanta,ou=users,ou=radius,dc=csctus,dc=net, with filter (objectclass=*) rlm_ldap::groupcmp: Group netscreen not found ????or user not a member (this is correct) rlm_ldap: ldap_release_conn: Release Id: 0 users: Matched entry DEFAULT at line 177 (this is odd, why is it matching on the last Group in the users file, DEFAULT Auth-Type := Reject Reply-Message = "Please call the helpdesk.") modcall[authorize]: module "files" returns ok for request 0 rlm_ldap: - authorize rlm_ldap: performing user authorization for bevege radius_xlat: '(uid=bevege)' radius_xlat: 'ou=users,ou=radius,dc=csctus,dc=net' rlm_ldap: ldap_get_conn: Checking Id: 0 rlm_ldap: ldap_get_conn: Got Id: 0 rlm_ldap: performing search in ou=users,ou=radius,dc=csctus,dc=net, with filter (uid=bevege) rlm_ldap: performing search in uid=cisco_priv_1,ou=profiles,ou=radius,dc=csctus,dc=net, with filter (objectclass=radiusprofile) rlm_ldap: extracted attribute Cisco-AVPair from generic item Cisco-AVPair ="priv-lvl=1" (why does it choose only this attribute to send back?) rlm_ldap: Added password {MD5}xxxxxxxxxxxxxxxx== in check items rlm_ldap: looking for check items in directory... rlm_ldap: looking for reply items in directory... rlm_ldap: user bevege authorized to use remote access rlm_ldap: ldap_release_conn: Release Id: 0 modcall[authorize]: module "ldap" returns ok for request 0 modcall: leaving group authorize (returns ok) for request 0 rad_check_password: Found Auth-Type Reject rad_check_password: Auth-Type = Reject, rejecting user (I believe this is because it matches line 177 last which has Auth-Type reject) auth: Failed to validate the user. Delaying request 0 for 1 seconds Finished request 0 Going to the next request --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Waking up in 1 seconds... --- Walking the entire request list --- Sending Access-Reject of id 68 to 10.17.71.10 port 4852 Reply-Message = "Please call the helpdesk." Waking up in 4 seconds... --- Walking the entire request list --- Cleaning up request 0 ID 68 with timestamp 470e2326 Nothing to do. Sleeping until we see a request. Users file for reference 156 DEFAULT Ldap-Group == acct_disabled, Auth-Type := Reject 157 Reply-Message = "Account disabled. Please call the helpdesk." 158 159 DEFAULT Ldap-Group == packeteer_read_only,User-Profile := "uid=packeteer_read_only,ou=profiles,ou=radius,dc=csctus,dc=net", Auth-Type := LDAP 160 Fall-Through = yes 161 162 DEFAULT Ldap-Group == Packeteer,User-Profile := "uid=Packeteer,ou=profiles,ou=radius,dc=csctus,dc=net", Auth-Type := LDAP 163 Fall-Through = yes 164 165 DEFAULT Ldap-Group == netscreen,User-Profile := "uid=netscreen,ou=profiles,ou=radius,dc=csctus,dc=net", Auth-Type := LDAP 166 Fall-Through = yes 167 168 DEFAULT Ldap-Group == cisco_priv_15,User-Profile := "uid=cisco_priv_15,ou=profiles,ou=radius,dc=csctus,dc=net", Auth-Type := LDAP 169 Fall-Through = yes 170 171 DEFAULT Ldap-Group == cisco_priv_1,User-Profile := "uid=cisco_priv_1,ou=profiles,ou=radius,dc=csctus,dc=net", Auth-Type := LDAP 172 Fall-Through = yes 173 174 DEFAULT Ldap-Group == netscreen,User-Profile := "uid=netscreen,ou=profiles,ou=radius,dc=csctus,dc=net", Auth-Type := LDAP 175 Fall-Through = no 176 177 DEFAULT Auth-Type := Reject 178 Reply-Message = "Please call the helpdesk." 179 180 DEFAULT Auth-Type = System 181 fall-Through = 1ed entry DEFAULT at line 171 (this is correct)

3 2

Darwin DirectoryServices (warnnings)
by Arran Cudbard-Bell 13 Oct '07

13 Oct '07

Hi, Running radiusd 2.0pre2 (cvs head) Just checked the system logs on one of our radius servers, and i'm seeing some strange error messages from directory services. Oct 12 12:02:50 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 675 open references when the warning limit is 500. Oct 12 12:03:00 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 675 open references when the warning limit is 500. Oct 12 12:18:37 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 700 open references when the warning limit is 500. Oct 12 12:18:40 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 700 open references when the warning limit is 500. Oct 12 12:35:25 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 725 open references when the warning limit is 500. Oct 12 12:36:25 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 725 open references when the warning limit is 500. Oct 12 12:49:30 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 750 open references when the warning limit is 500. Oct 12 12:49:35 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 750 open references when the warning limit is 500. Oct 12 13:05:07 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 775 open references when the warning limit is 500. Oct 12 13:05:49 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 775 open references when the warning limit is 500. Oct 12 13:20:15 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 800 open references when the warning limit is 500. Oct 12 13:21:00 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 800 open references when the warning limit is 500. Oct 12 13:35:59 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 825 open references when the warning limit is 500. Oct 12 13:36:42 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 825 open references when the warning limit is 500. Oct 12 13:45:22 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 850 open references when the warning limit is 500. Oct 12 13:46:34 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 850 open references when the warning limit is 500. Oct 12 13:59:09 wolverine DirectoryService[54]: Potential VM growth in DirectoryService since client PID: 9179, has 875 open references when the warning limit is 500. PID 9179 is radiusd. So it would seem that radiusd has an ever increasing number of references (though I have no idea what it means in this context), against the DirectoryServices Deamon. With API debugging on I see Oct 12 14:15:28 wolverine DirectoryService[54]: Client PID: 9179, has 896 open references. Oct 12 14:15:28 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsOpenDirService(), Server Used : Result: 0, Duration: 223.47 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsFindDirNodes(), Server Used : Result: 0, Duration: 106.71 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client PID: 9179, has 897 open references. Oct 12 14:15:28 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsOpenDirNode(), Search Used : Result: 0, Duration: 28.95 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client PID: 0, has 12 open references. Oct 12 14:15:28 wolverine DirectoryService[54]: Internal Dispatch, API: dsOpenDirNode(), NetInfo Used : Result: 0, Duration: 86.25 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Internal Dispatch, API: dsGetRecordList(), NetInfo Used : Result: 0, Duration: 1254.36 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client PID: 0, has 13 open references. Oct 12 14:15:28 wolverine DirectoryService[54]: Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : Result: 0, Duration: 29.37 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Internal Dispatch, API: dsGetRecordList(), LDAPv3 Used : Result: 0, Duration: 14146.63 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsGetRecordList(), Search Used : Result: 0, Duration: 16787.38 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client PID: 9179, has 896 open references. Oct 12 14:15:28 wolverine DirectoryService[54]: Client PID: 0, has 12 open references. Oct 12 14:15:28 wolverine DirectoryService[54]: Ref table dealloc callback, API Call: dsCloseDirNode(), PlugIn Used: NetInfo, Result: 0, Duration: 76.38 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Internal Dispatch, API: dsCloseDirNode(), NetInfo Used : Result: 0, Duration: 2.55 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client PID: 0, has 11 open references. Oct 12 14:15:28 wolverine DirectoryService[54]: Ref table dealloc callback, API Call: dsCloseDirNode(), PlugIn Used: LDAPv3, Result: 0, Duration: 12.99 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : Result: 0, Duration: 3.03 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Ref table dealloc callback, API Call: dsCloseDirNode(), PlugIn Used: Search, Result: 0, Duration: 1597.26 usec Oct 12 14:15:28 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsCloseDirNode(), Search Used : Result: 0, Duration: 2.37 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client PID: 9179, has 897 open references. Oct 12 14:16:15 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsOpenDirService(), Server Used : Result: 0, Duration: 190.35 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsFindDirNodes(), Server Used : Result: 0, Duration: 99.75 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client PID: 9179, has 898 open references. Oct 12 14:16:15 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsOpenDirNode(), Search Used : Result: 0, Duration: 76.86 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client PID: 0, has 12 open references. Oct 12 14:16:15 wolverine DirectoryService[54]: Internal Dispatch, API: dsOpenDirNode(), NetInfo Used : Result: 0, Duration: 101.01 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Internal Dispatch, API: dsGetRecordList(), NetInfo Used : Result: 0, Duration: 1476.36 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client PID: 0, has 13 open references. Oct 12 14:16:15 wolverine DirectoryService[54]: Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : Result: 0, Duration: 28.98 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Internal Dispatch, API: dsGetRecordList(), LDAPv3 Used : Result: 0, Duration: 13866.31 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsGetRecordList(), Search Used : Result: 0, Duration: 16742.50 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client PID: 9179, has 897 open references. Oct 12 14:16:15 wolverine DirectoryService[54]: Client PID: 0, has 12 open references. Oct 12 14:16:15 wolverine DirectoryService[54]: Ref table dealloc callback, API Call: dsCloseDirNode(), PlugIn Used: NetInfo, Result: 0, Duration: 82.14 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Internal Dispatch, API: dsCloseDirNode(), NetInfo Used : Result: 0, Duration: 2.34 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client PID: 0, has 11 open references. Oct 12 14:16:15 wolverine DirectoryService[54]: Ref table dealloc callback, API Call: dsCloseDirNode(), PlugIn Used: LDAPv3, Result: 0, Duration: 12.99 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Internal Dispatch, API: dsCloseDirNode(), LDAPv3 Used : Result: 0, Duration: 2.49 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Ref table dealloc callback, API Call: dsCloseDirNode(), PlugIn Used: Search, Result: 0, Duration: 1156.36 usec Oct 12 14:16:15 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsCloseDirNode(), Search Used : Result: 0, Duration: 3.06 usec Oct 12 14:16:26 wolverine DirectoryService[54]: Client PID: 9179, has 898 open references. Oct 12 14:16:26 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsOpenDirService(), Server Used : Result: 0, Duration: 233.04 usec Oct 12 14:16:26 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsFindDirNodes(), Server Used : Result: 0, Duration: 106.62 usec Oct 12 14:16:26 wolverine DirectoryService[54]: Client PID: 9179, has 899 open references. Oct 12 14:16:26 wolverine DirectoryService[54]: Client: radiusd, PID: 9179, API: dsOpenDirNode(), Search Used : Result: 0, Duration: 25.83 usec Oct 12 14:16:26 wolverine DirectoryService[54]: Client PID: 0, has 12 open references. Oct 12 14:16:26 wolverine DirectoryService[54]: Internal Dispatch, API: dsOpenDirNode(), NetInfo Used : Result: 0, Duration: 92.43 usec Oct 12 14:16:26 wolverine DirectoryService[54]: Internal Dispatch, API: dsGetRecordList(), NetInfo Used : Result: 0, Duration: 1470.36 usec Oct 12 14:16:26 wolverine DirectoryService[54]: Client PID: 0, has 13 open references. Oct 12 14:16:26 wolverine DirectoryService[54]: Internal Dispatch, API: dsOpenDirNode(), LDAPv3 Used : Result: 0, Duration: 31.86 usec Anyone have any idea whats going on .... Could this explain the possible memory leak in radiusd, that only seems to appear on Darwin ? -- Arran Cudbard-Bell (A.Cudbard-Bell(a)sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900

2 2

peap/eap tls authentication
by Dorota Kupis 12 Oct '07

12 Oct '07

Hello, I'm not familiar with freeradius yet. I read some HOWTOs and I do try to make wireless Windows XP talk to Radius server. I have an AP 1131. I have managed to make this configuration work with cisco ACS in the past, so AP part should be OK. I do send the output from radiusd -X Hope somebody can help me to point out which parts of configuration should I look into and what possible problems could be. Thanks for your understanding. Dorota

3 6

Retrieving the clients (NASes) from SQL (FreeRADIUS 1.1.0)
by Carlos A. Carnero Delgado 12 Oct '07

12 Oct '07

Hello, does FreeRADIUS 1.1.0 supports reading the NAS list from SQL? I'm using this rather old version because it's the one supplied by my Ubuntu version, and, if possible, I wouldn't like to use another. Of course, if I must, I will. Thanks a lot, Carlos. -- <nick> grah windows just crashed again, unstable crap. <yukito> Windows isn't unstable, it's just spontaneous.

3 3

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