Unsupported Vendor Specific Attribute results in incorrect behavior of rc_avpair_gen()

KAVYA PRABHAKAR kavyamelinmaneprabhakar at gmail.com
Wed Jan 28 15:57:58 CET 2015


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 at lists.freeradius.org> wrote:

> Send Freeradius-Users mailing list submissions to
>         freeradius-users at 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 at lists.freeradius.org
>
> You can reach the person managing the list at
>         freeradius-users-owner at 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 at 4rf.com>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: RE: Unsupported Vendor Specific Attribute results in
>         incorrect       behavior of rc_avpair_gen()
> Message-ID:
>         <
> BDBDD5ED6A39F844B681BA6A63A8B0B8962D0146 at 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 at lists.freeradius.org
> [mailto:freeradius-users-bounces+amol.lad=4rf.com at 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 at 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 at deployingradius.com>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Unsupported Vendor Specific Attribute results in
>         incorrect       behavior of rc_avpair_gen()
> Message-ID: <D3E836CC-79D3-4DDE-9B35-72BA7164C77E at deployingradius.com>
> Content-Type: text/plain; charset=windows-1252
>
> On Jan 27, 2015, at 4:33 PM, Amol Lad <Amol.Lad at 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 at uhaul.com>
> To: freeradius-users at lists.freeradius.org
> Subject: Re: Ssha512 value
> Message-ID:
>         <fc.004c5613373db787004c5613372546b6.373e62a5 at 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 at lists.freeradius.org>
> writes:
> >
> >> On 22 Jan 2015, at 19:43, Robert Graham <robert_graham at 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 at 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 at freeradius.org>
> To: FreeRadius users mailing list
>         <freeradius-users at lists.freeradius.org>
> Subject: Re: Ssha512 value
> Message-ID: <D79B46AF-F91F-435D-A3CE-8C9E3F01A143 at freeradius.org>
> Content-Type: text/plain; charset=us-ascii
>
>
> > On 28 Jan 2015, at 08:06, Robert Graham <robert_graham at 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 at 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 at gmail.com>
> To: freeradius-users at lists.freeradius.org
> Subject: Error in Free Radius Integration with AD Server
> Message-ID:
>         <
> CADfQPaA8HGThqd1HineHCVcMbFXSDCiwEPaD+umpS586D3Q7Hw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> ---------- Forwarded message ----------
> From:  <owaisahmed19 at gmail.com>
> Date: Tuesday, January 27, 2015
> Subject: Error in Free Radius Integration with AD Server
> To: owaisahmed19 at 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 at 123
> 3. wbinfo -g
> 4. wbinfo -u
>
> When i start my Radius server in debug mode and run following command
>
> radtest owais welcome at 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 at 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 at 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 at 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 at yahoo.fr>
> To: "freeradius-users at lists.freeradius.org"
>         <freeradius-users at lists.freeradius.org>
> Subject: Chaining system authentication methods
> Message-ID:
>         <709928179.1687784.1422426332754.JavaMail.yahoo at 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
> *************************************************
>


More information about the Freeradius-Users mailing list