January 2015 - Freeradius-Users - lists.freeradius.org

Member De-Registration
by George Innocent 30 Jan '15

30 Jan '15

Hello Members; How does one De-Register from the User group email lists -- Regards: George Innocent.

2 1

Re: authenticating a guest domain/ntlm_auth in a different AD
by Rui Ribeiro 29 Jan '15

29 Jan '15

Thanks Mathew, my missing piece was exactly I was no getting I could call the module/mschap as domain2 in unlang. Stupid, because I am doing things like that with linelog. Thanks a million. Regards, Rui > > Message: 6 > Date: Thu, 29 Jan 2015 17:34:53 +0000 > From: Matthew Newton <mcn4(a)leicester.ac.uk> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: authenticating a guest domain/ntlm_auth in a different AD > Message-ID: <20150129173453.GB24929(a)rootmail.cc.le.ac.uk> > Content-Type: text/plain; charset=us-ascii > > On Thu, Jan 29, 2015 at 03:54:52PM +0000, Rui Ribeiro wrote: > > I would like to authenticate a guest domain in a different AD in FR3. I > ... > > The ideia of having to mschap configurations is for calling ntlm_auth > with > > a different Windows DOMAIN. > > OK. > > > most specifically, this not works. Is it wiser to build a new FR to the > > guest domain. > > You can do it all in one copy of FreeRADIUS. No need to run it > twice. There are many ways to do this. You will need to make sure > that the AD domains trust each other as your RADIUS server will > (normally) only be joined to one domain, so will send all auth > requests to that one. > > You could add something like > > --domain=%{Realm} > > to your existing ntlm_auth command line, but you probably want to > do some sanity checks on the realm first in unlang. > > > Another method similar to how we've done here in the past would be > to define two instances of the mschap module. So in > mods-available/mschap, copy the > > mschap { > ... > } > > section, and call it e.g. > > mschap domain2 { > ... > } > > Update the domain2 ntlm_auth one with your new domain. > > > Then you need to use work out which one to use - either code this > with if() in unlang, or use the call 'suffix' in authorize{} > (which is enabled by default). > > Then you should be able to update your authenticate{} section from > > Auth-Type MS-CHAP { > mschap > } > > to something like > > Auth-Type MS-CHAP { > if (Realm =~ /(a)my.second.realm$/) { > domain2 > } > else { > mschap > } > } > > If you can't get it working, post the full FreeRADIUS debug output > (radiusd -X) to the list, otherwise nobody can tell what's going > wrong. > > Matthew > > > -- > Matthew Newton, Ph.D. <mcn4(a)le.ac.uk> > > Systems Specialist, Infrastructure Services, > I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom > > For IT help contact helpdesk extn. 2253, <ithelp(a)le.ac.uk> > > > >

1 0

authenticating a guest domain/ntlm_auth in a different AD
by Rui Ribeiro 29 Jan '15

29 Jan '15

Hi, I would like to authenticate a guest domain in a different AD in FR3. I setup up with quite success the guest domain, however when it comes to configure chap, somewhat I cannot get it how to make mschap have too different configurations depending how the domain is called. I tried mschap.newdomain as I saw in some post over here, and it did not work out. The ideia of having to mschap configurations is for calling ntlm_auth with a different Windows DOMAIN. most specifically, this not works. Is it wiser to build a new FR to the guest domain. unlang if (domain == "xxxx" ) { domain.xxxx } mschap module mschap.xxxx -- Regards, -- Rui Ribeiro Senior Sysadm ISCTE-IUL https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

2 1

802.1X Invalid packet code 4 sent to authentication
by Julien Bamberger 29 Jan '15

29 Jan '15

Hello, I have a problem between a microswitch microsens ( generation 6 ethernet switches) which is configured in the mode 802.1X and my serveur freeradius debian (2.1.12+dfsg-1.2). I use EAP/TLS witch mac address. I have this message : Thu Jan 29 11:26:30 2015 : Debug: Invalid packet code 4 sent to authentication port from client 192.168.83.105 port 45804 : IGNORED Thu Jan 29 11:26:30 2015 : Info: Ready to process requests. Thu Jan 29 11:28:15 2015 : Debug: Invalid packet code 4 sent to authentication port from client 192.168.83.105 port 45804 : IGNORED Thu Jan 29 11:28:15 2015 : Info: Ready to process requests. Thu Jan 29 11:28:16 2015 : Debug: Invalid packet code 4 sent to authentication port from client 192.168.83.105 port 52149 : IGNORED Thu Jan 29 11:28:16 2015 : Info: Ready to process requests. Thu Jan 29 11:28:19 2015 : Debug: Invalid packet code 4 sent to authentication port from client 192.168.83.105 port 52149 : IGNORED Thu Jan 29 11:28:19 2015 : Info: Ready to process requests. I suppose it is the paquet format between the microswitch microsens and freeradius. Any ideas? My test are okay between my freeradius and my switch cisco 2960G. Thank's you. Regards. Julien.

4 3

Error in Free Radius Integration with AD Server
by owais ahmad 29 Jan '15

29 Jan '15

---------- Forwarded message ---------- From: <owaisahmed19(a)gmail.com> Date: Tuesday, January 27, 2015 Subject: Error in Free Radius Integration with AD Server To: owaisahmed19(a)gmail.com Hello, This is regarding error in free radius authentication with AD Server. Brief outline of the environment is as follows: Free Radius 2.1.12 is installed on RHEL 6.5. AD Server is installed in windows 2008 R2. Samba 3 has been used to integrate Linux with Windows Commands which work fine: 1. wbinfo -a username%password 2. ntlm_auth --request-nt-key --domain=ITBATEST.COM --username=owais --password=welcome@123 3. wbinfo -g 4. wbinfo -u When i start my Radius server in debug mode and run following command radtest owais welcome@123 localhost 0 testing123 I am getting error. Sending Access-Request of id 164 to 127.0.0.1 port 1812 User-Name = "owais" User-Password = "welcome@123" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Message-Authenticator = 0x00000000000000000000000000000000 rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=164, length=20 Radiusd -X output is as below: Ready to process requests. rad_recv: Access-Request packet from host 127.0.0.1 port 57549, id=164, length=75 User-Name = "owais" User-Password = "welcome@123" NAS-IP-Address = 127.0.0.1 NAS-Port = 0 Message-Authenticator = 0x9c76aaf83e1ff8534b0d8a83ac0f1fd3 # Executing section authorize from file /etc/raddb/sites-enabled/default +- entering group authorize {...} [ntlm_auth] expand: --username=%{mschap:User-Name} -> --username=owais [ntlm_auth] expand: --password=%{User-Password} -> --password=welcome@123 Exec-Program output: NT_STATUS_OK: Success (0x0) Exec-Program-Wait: plaintext: NT_STATUS_OK: Success (0x0) Exec-Program: returned: 0 ++[ntlm_auth] returns ok ++[preprocess] returns ok ++[chap] returns noop ++[mschap] returns noop ++[digest] returns noop [suffix] No '@' in User-Name = "owais", looking up realm NULL [suffix] No such realm "NULL" ++[suffix] returns noop [eap] No EAP-Message, not doing EAP ++[eap] returns noop ++[files] returns noop ++[expiration] returns noop ++[logintime] returns noop [pap] WARNING! No "known good" password found for the user. Authentication may fail because of this. ++[pap] returns noop ERROR: No authenticate method (Auth-Type) found for the request: Rejecting the user Failed to authenticate the user. Using Post-Auth-Type Reject # Executing group from file /etc/raddb/sites-enabled/default +- entering group REJECT {...} [attr_filter.access_reject] expand: %{User-Name} -> owais attr_filter: Matched entry DEFAULT at line 11 ++[attr_filter.access_reject] returns updated Delaying reject of request 0 for 1 seconds Going to the next request Waking up in 0.8 seconds. Sending delayed reject for request 0 Sending Access-Reject of id 164 to 127.0.0.1 port 57549 Waking up in 4.9 seconds. Cleaning up request 0 ID 164 with timestamp +5 Ready to process requests. Would appreciate your help. _____________________________________ Sent from http://freeradius.1045715.n5.nabble.com -- Regards, Owais

3 3

radius client with multiple IPs
by Stefano Zanmarchi 28 Jan '15

28 Jan '15

Hallo, probaby a silly question, but man clients.conf didn't solve my doubts. I need to setup a new client with 3 IP addresses in clients.conf. Can I simply add more ipaddr fields like this: client myWLC { ipaddr = 192.168.1.211 ipaddr = 192.168.7.4 ipaddr = 192.168.210.210 require_message_authenticator = yes secret = .... virtual_server = eduroam nastype = other } or do I need 3 "client myWLC" entries, one for each IP? Thanks in advance for your help, Stefano

2 4

Ssha512 value
by Robert Graham 28 Jan '15

28 Jan '15

Upgraded FR to the 3.0.x release and the password shows that it is ssha512 but where in the code does the salt get pulled from? and where do I configure it? Sent from my Android device

3 7

Re: Unsupported Vendor Specific Attribute results in incorrect behavior of rc_avpair_gen()
by KAVYA PRABHAKAR 28 Jan '15

28 Jan '15

Hi, I am using Freeradius version3 where radsec works. I want to add one of the VSA with user access level as 15. I edited dictionary file(/usr/local.etc/raddb) giving Attribute information as ATTRIBUTE <attribute name> <value> <type> After doin above changes restarted FR services. In the response from FR server, I am not seeing this attribute value being set. Kindly help me, to understand what I am doing wrong. Thanks, Kavya On Wed, Jan 28, 2015 at 11:55 AM, < 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: Unsupported Vendor Specific Attribute results in > incorrect behavior of rc_avpair_gen() (Amol Lad) > 2. Re: Unsupported Vendor Specific Attribute results in > incorrect behavior of rc_avpair_gen() (Alan DeKok) > 3. Re: Ssha512 value (Robert Graham) > 4. Re: Ssha512 value (Arran Cudbard-Bell) > 5. Error in Free Radius Integration with AD Server (owais ahmad) > 6. Chaining system authentication methods (Sautron Nick) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 27 Jan 2015 21:33:09 +0000 > From: Amol Lad <Amol.Lad(a)4rf.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: RE: Unsupported Vendor Specific Attribute results in > incorrect behavior of rc_avpair_gen() > Message-ID: > < > BDBDD5ED6A39F844B681BA6A63A8B0B8962D0146(a)4rf-nz-orion.local.4rf.com> > Content-Type: text/plain; charset="us-ascii" > > I'm not sure if I fully understand you. It's _not_ possible to add every > possible VSA in the client dictionary. It's possible that "this" radius > client is in a network with many other devices all authenticated by a > common RADIUS server. Other devices might support VSAs that this device > will not understand. > > I'm only trying to implement below recommendation in RFC 5080: > > A configuration flag such as "treat unknown attributes as > reject" can be exposed to the system administrator. If the flag is > set to true, then Access-Accepts containing unknown attributes are > treated as Access-Rejects. If the flag is set to false, then unknown > attributes in Access-Accepts are silently ignored. > > Unfortunately with current library "bug" of discarding all known > attributes if any unknown VSA is present in the end of the list, I cannot > support "silently ignore" portion of above statement > > Amol > > -----Original Message----- > From: freeradius-users-bounces+amol.lad=4rf.com(a)lists.freeradius.org > [mailto:freeradius-users-bounces+amol.lad=4rf.com@lists.freeradius.org] > On Behalf Of Alan DeKok > Sent: Wednesday, 28 January 2015 2:57 a.m. > To: FreeRadius users mailing list > Subject: Re: Unsupported Vendor Specific Attribute results in incorrect > behavior of rc_avpair_gen() > > On Jan 26, 2015, at 10:52 PM, Amol Lad <Amol.Lad(a)4rf.com> wrote: > > The problem is still there; as my embedded client does not recognize > Cisco-AVPair and it is last in the list, rc_avpair_gen() returns NULL. > > Then add Cisco-AVPair to the dictionaries. > > > Why do you think return NULL from below is not wrong? Why should caller > return NULL if rc_avpair_gen returns NULL? > > For a host of reasons. > > In an embedded system, you want to produce the packet you expect, with > all of the attributes you want. Silently discarding an attribute means > that the client does unexpected, and unknown things. > > In an embedded system, you control which attributes get created. > There's no editable configuration file that an administrator can screw up > by mistyping an attribute. So if your code is doesn't generate the correct > attribute... it's a bug. Fix your code, rather than trying to push the > library into working around it. > > If the library did as you wanted, you'd still be posting here. "Hi, I > asked the library to create 4 attributes, and it only created 4. That's a > bug. Why does it do that?" > > Fix your code to create *valid* attributes. It's as simple as that. > > Alan DeKok. > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > The information in this email communication (inclusive of attachments) is > confidential to 4RF Limited and the intended recipient(s). If you are not > the intended recipient(s), please note that any use, disclosure, > distribution or copying of this information or any part thereof is strictly > prohibited and that the author accepts no liability for the consequences of > any action taken on the basis of the information provided. If you have > received this email in error, please notify the sender immediately by > return email and then delete all instances of this email from your system. > 4RF Limited will not accept responsibility for any consequences associated > with the use of this email (including, but not limited to, damages > sustained as a result of any viruses and/or any action or lack of action > taken in reliance on it). > > > ------------------------------ > > Message: 2 > Date: Tue, 27 Jan 2015 17:00:28 -0500 > From: Alan DeKok <aland(a)deployingradius.com> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: Unsupported Vendor Specific Attribute results in > incorrect behavior of rc_avpair_gen() > Message-ID: <D3E836CC-79D3-4DDE-9B35-72BA7164C77E(a)deployingradius.com> > Content-Type: text/plain; charset=windows-1252 > > On Jan 27, 2015, at 4:33 PM, Amol Lad <Amol.Lad(a)4rf.com> wrote:] > > I'm not sure if I fully understand you. It's _not_ possible to add every > possible VSA in the client dictionary. It's possible that "this" radius > client is in a network with many other devices all authenticated by a > common RADIUS server. Other devices might support VSAs that this device > will not understand. > > Yes. > > > I'm only trying to implement below recommendation in RFC 5080: > > > > A configuration flag such as "treat unknown attributes as > > reject" can be exposed to the system administrator. If the flag is > > set to true, then Access-Accepts containing unknown attributes are > > treated as Access-Rejects. If the flag is set to false, then unknown > > attributes in Access-Accepts are silently ignored. > > That recommendation is for packets received from the network. It is NOT > for attributes read from a configuration file. > > > Unfortunately with current library "bug" of discarding all known > attributes if any unknown VSA is present in the end of the list, I cannot > support "silently ignore" portion of above statement > > Patches are welcome. > > The problem is that your previous messages used examples of attributes > read from configuration files. So it?s natural to assume that?s what you > meant. So? my recommendations were for attributes read from configuration > files. > > If you?re now talking about attributes read from a packet? that?s > different. And my recommendations are different. > > Alan DeKok. > > > > ------------------------------ > > Message: 3 > Date: Tue, 27 Jan 2015 18:06:49 -0700 > From: "Robert Graham" <robert_graham(a)uhaul.com> > To: freeradius-users(a)lists.freeradius.org > Subject: Re: Ssha512 value > Message-ID: > <fc.004c5613373db787004c5613372546b6.373e62a5(a)fc.uhaul.com> > Content-Type: text/plain; charset=UTF-8 > > We were able to get the output of the salt in hex form, but getting it to > concatenate is a whole other problem. When I do research on the web and > tried all possible examples of the query, still would not give me the > information that I need. > > If I have a column that has the hashed password and a column that has a > salt that is in hexfomat... how would the > > update control { > SSHA2-512-Password =: "0x%{sql:SELECT what is the proper context to > concatenate the hashed pw in hex and the salt in hex > > Robert Graham > > > FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> > writes: > > > >> On 22 Jan 2015, at 19:43, Robert Graham <robert_graham(a)uhaul.com> > wrote: > >> > >> Upgraded FR to the 3.0.x release and the password shows that it is > >ssha512 > >> but where in the code does the salt get pulled from? and where do I > >> configure it? > > > >There is no separate salt attribute. > > > >update control { > > SSHA2-512-Password := "0x%{sql:query to get hash in hex > concatenated > >with salt in hex}" > >} > >pap > > > >For salted hashes it's always <hash><salt>. The hash part is determined > >by the expected length > >of the hash. So for SHA512 the first 64 bytes of the hash/salt > >concatenation are assumed to be > >the hash, and the rest is assumed to be the salt. > > > >The code takes the salt part, creates the concatenation of > ><password><salt> and passes that to > >SHA512, the result of that is then compared to <hash>. > > > >If you can't figure out how to get the hash in hex form, the server will > >accept base64 as an > >alternative, but you should then do: > > > >update control { > > Password-With-Header := "{ssha512}%{sql:query to get hash > concatenated > >with salt in base64}" > >} > >pap > > > >The PAP module will then use heuristics to determine the correct encoding > >(hex or base64 or none), > >and normalise the <hash><salt> to binary data. > > > >Note: You can't just concatenate two base64 strings. If they're stored > >that way in the db they > >would have to be separately decoded and the result concatenated. > > > >-Arran > > > >Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> > >FreeRADIUS development team > > > >FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 > > > >- > >List info/subscribe/unsubscribe? See > >http://www.freeradius.org/list/users.html > > > > > ------------------------------ > > Message: 4 > Date: Wed, 28 Jan 2015 09:13:07 +0700 > From: Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> > To: FreeRadius users mailing list > <freeradius-users(a)lists.freeradius.org> > Subject: Re: Ssha512 value > Message-ID: <D79B46AF-F91F-435D-A3CE-8C9E3F01A143(a)freeradius.org> > Content-Type: text/plain; charset=us-ascii > > > > On 28 Jan 2015, at 08:06, Robert Graham <robert_graham(a)uhaul.com> wrote: > > > > We were able to get the output of the salt in hex form, but getting it to > > concatenate is a whole other problem. When I do research on the web and > > tried all possible examples of the query, still would not give me the > > information that I need. > > > > If I have a column that has the hashed password and a column that has a > > salt that is in hexfomat... how would the > > > > update control { > > SSHA2-512-Password =: "0x%{sql:SELECT what is the proper context to > > concatenate the hashed pw in hex and the salt in hex > > > If it's easier you can do it in two queries, but it's less efficient. > > i.e. > > update control { > Tmp-String-0 := "%{sql:SELECT hash FROM <table> WHERE <clause>}" > Tmp-String-1 := "%{sql:SELECT salt FROM <table> WHERE <clause>}" > } > > update control { > SSHA2-512-Password := > "0x%{control:Tmp-String-0}%{control:Tmp-String-1}" > } > > -Arran > > Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> > FreeRADIUS development team > > FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 > > > > ------------------------------ > > Message: 5 > Date: Wed, 28 Jan 2015 11:23:39 +0530 > From: owais ahmad <owaisahmed19(a)gmail.com> > To: freeradius-users(a)lists.freeradius.org > Subject: Error in Free Radius Integration with AD Server > Message-ID: > < > CADfQPaA8HGThqd1HineHCVcMbFXSDCiwEPaD+umpS586D3Q7Hw(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > ---------- Forwarded message ---------- > From: <owaisahmed19(a)gmail.com> > Date: Tuesday, January 27, 2015 > Subject: Error in Free Radius Integration with AD Server > To: owaisahmed19(a)gmail.com > > > Hello, > This is regarding error in free radius authentication with AD Server. > Brief outline of the environment is as follows: > Free Radius 2.1.12 is installed on RHEL 6.5. AD Server is installed in > windows 2008 R2. Samba 3 has been used to integrate Linux with Windows > > Commands which work fine: > 1. wbinfo -a username%password > 2. ntlm_auth --request-nt-key --domain=ITBATEST.COM --username=owais > --password=welcome@123 > 3. wbinfo -g > 4. wbinfo -u > > When i start my Radius server in debug mode and run following command > > radtest owais welcome@123 localhost 0 testing123 > > I am getting error. > > Sending Access-Request of id 164 to 127.0.0.1 port 1812 > User-Name = "owais" > User-Password = "welcome@123" > NAS-IP-Address = 127.0.0.1 > NAS-Port = 0 > Message-Authenticator = 0x00000000000000000000000000000000 > rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=164, > length=20 > > > Radiusd -X output is as below: > > Ready to process requests. > rad_recv: Access-Request packet from host 127.0.0.1 port 57549, id=164, > length=75 > User-Name = "owais" > User-Password = "welcome@123" > NAS-IP-Address = 127.0.0.1 > NAS-Port = 0 > Message-Authenticator = 0x9c76aaf83e1ff8534b0d8a83ac0f1fd3 > # Executing section authorize from file /etc/raddb/sites-enabled/default > +- entering group authorize {...} > [ntlm_auth] expand: --username=%{mschap:User-Name} -> --username=owais > [ntlm_auth] expand: --password=%{User-Password} -> > --password=welcome@123 > Exec-Program output: NT_STATUS_OK: Success (0x0) > Exec-Program-Wait: plaintext: NT_STATUS_OK: Success (0x0) > Exec-Program: returned: 0 > ++[ntlm_auth] returns ok > ++[preprocess] returns ok > ++[chap] returns noop > ++[mschap] returns noop > ++[digest] returns noop > [suffix] No '@' in User-Name = "owais", looking up realm NULL > [suffix] No such realm "NULL" > ++[suffix] returns noop > [eap] No EAP-Message, not doing EAP > ++[eap] returns noop > ++[files] returns noop > ++[expiration] returns noop > ++[logintime] returns noop > [pap] WARNING! No "known good" password found for the user. Authentication > may fail because of this. > ++[pap] returns noop > ERROR: No authenticate method (Auth-Type) found for the request: Rejecting > the user > Failed to authenticate the user. > Using Post-Auth-Type Reject > # Executing group from file /etc/raddb/sites-enabled/default > +- entering group REJECT {...} > [attr_filter.access_reject] expand: %{User-Name} -> owais > attr_filter: Matched entry DEFAULT at line 11 > ++[attr_filter.access_reject] returns updated > Delaying reject of request 0 for 1 seconds > Going to the next request > Waking up in 0.8 seconds. > Sending delayed reject for request 0 > Sending Access-Reject of id 164 to 127.0.0.1 port 57549 > Waking up in 4.9 seconds. > Cleaning up request 0 ID 164 with timestamp +5 > Ready to process requests. > > > Would appreciate your help. > > > > > _____________________________________ > Sent from http://freeradius.1045715.n5.nabble.com > > > > > -- > Regards, > Owais > > > ------------------------------ > > Message: 6 > Date: Wed, 28 Jan 2015 06:25:32 +0000 (UTC) > From: Sautron Nick <sautronnick(a)yahoo.fr> > To: "freeradius-users(a)lists.freeradius.org" > <freeradius-users(a)lists.freeradius.org> > Subject: Chaining system authentication methods > Message-ID: > <709928179.1687784.1422426332754.JavaMail.yahoo(a)mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > Hello everyone, > > I wonder if it is possible to establish a chaining system authentication > methods. > In my case I would need to have the peap method first and then the TTLS > method. > > example: > - An unauthenticated client > - The server offers to the method peap > - The method is not compatible according to the customer > - The server offers to the TTLS method > - Authenticated Client > > Thank you to enlighten me about it > S.Nick > > > > ------------------------------ > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html > > End of Freeradius-Users Digest, Vol 117, Issue 75 > ************************************************* >

2 1

Chaining system authentication methods
by Sautron Nick 28 Jan '15

28 Jan '15

Hello everyone, I wonder if it is possible to establish a chaining system authentication methods. In my case I would need to have the peap method first and then the TTLS method. example: - An unauthenticated client - The server offers to the method peap - The method is not compatible according to the customer - The server offers to the TTLS method - Authenticated Client Thank you to enlighten me about it S.Nick

4 7

Unsupported Vendor Specific Attribute results in incorrect behavior of rc_avpair_gen()
by Amol Lad 27 Jan '15

27 Jan '15

Hi, I’m using freeradius client library 1.1.6 with radius server version 2.2.6. The “users” file on server has an entry for user “abcd” as below: abcd Cleartext-Password := "xyz" Service-Type = Framed-Management, Management-Privilege-level = 4, Vendor-Specific = "14817", The dictionary file on client does not have entry for Vendor-Specific attribute value “14817” so this is an unsupported vendor-specific attribute I’ve found that if an unsupported Vendor-Specific attribute is last in the list of attributes then rc_avpair_gen function (avpair.c) returns NULL below: Sendserver.c: rc_send_server: line 367 if (length > 0) { data->receive_pairs = rc_avpair_gen(rh, NULL, recv_auth->data, ←- data->receive_pairs is NULL length, 0); } else { data->receive_pairs = NULL; } The problem lies in rc_avpair_gen function. As Vendor-Specific is last and unsupported so “pair” will be NULL before below fragment returns if (attribute == PW_VENDOR_SPECIFIC) { if (attrlen < 4) { rc_log(LOG_ERR, "rc_avpair_gen: received VSA " "attribute with invalid length"); goto shithappens; } memcpy(&lvalue, ptr, 4); vendorpec = ntohl(lvalue); if (rc_dict_getvend(rh, vendorpec) == NULL) { /* Warn and skip over the unknown VSA */ rc_log(LOG_WARNING, "rc_avpair_gen: received VSA " "attribute with unknown Vendor-Id %d", vendorpec); return pair; ←- This will be NULL } /* Process recursively */ return rc_avpair_gen(rh, pair, ptr + 4, attrlen - 4, vendorpec); } As a result, below fragment will return NULL as well. Thus recursion unwinds by returning “pair” NULL even if valid attributes are also present /* Advance to the next attribute and process recursively */ if (length != attrlen) { pair = rc_avpair_gen(rh, pair, ptr + attrlen, length - attrlen, vendorpec); if (pair == NULL) ←-- Recursion unwinds and all invocations return NULL return NULL; } Please advise how it can be addressed? Why is check [if (pair == NULL) return NULL;] needed above? Can’t we just continue with the function and return from the end of the function? Thanks Amol Lad Software Architect 4RF Limited DDI: +64 4 498 7024 Tel: +64 4 499 6000 Mobile: +64 21 257 6610 Fax: +64 4 473 4447 Web: www.4rf.com Email: amol.lad(a)4rf.com The information in this email communication (inclusive of attachments) is confidential to 4RF Limited and the intended recipient(s). If you are not the intended recipient(s), please note that any use, disclosure, distribution or copying of this information or any part thereof is strictly prohibited and that the author accepts no liability for the consequences of any action taken on the basis of the information provided. If you have received this email in error, please notify the sender immediately by return email and then delete all instances of this email from your system. 4RF Limited will not accept responsibility for any consequences associated with the use of this email (including, but not limited to, damages sustained as a result of any viruses and/or any action or lack of action taken in reliance on it).

2 7