Re: Unsupported Vendor Specific Attribute results in incorrect behavior of rc_avpair_gen()
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@lists.freeradius.org> wrote:
Send Freeradius-Users mailing list submissions to freeradius-users@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@lists.freeradius.org
You can reach the person managing the list at freeradius-users-owner@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@4rf.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: RE: Unsupported Vendor Specific Attribute results in incorrect behavior of rc_avpair_gen() Message-ID: < BDBDD5ED6A39F844B681BA6A63A8B0B8962D0146@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@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@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@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Unsupported Vendor Specific Attribute results in incorrect behavior of rc_avpair_gen() Message-ID: <D3E836CC-79D3-4DDE-9B35-72BA7164C77E@deployingradius.com> Content-Type: text/plain; charset=windows-1252
On Jan 27, 2015, at 4:33 PM, Amol Lad <Amol.Lad@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@uhaul.com> To: freeradius-users@lists.freeradius.org Subject: Re: Ssha512 value Message-ID: <fc.004c5613373db787004c5613372546b6.373e62a5@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@lists.freeradius.org> writes:
On 22 Jan 2015, at 19:43, Robert Graham <robert_graham@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@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@freeradius.org> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: Ssha512 value Message-ID: <D79B46AF-F91F-435D-A3CE-8C9E3F01A143@freeradius.org> Content-Type: text/plain; charset=us-ascii
On 28 Jan 2015, at 08:06, Robert Graham <robert_graham@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@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@gmail.com> To: freeradius-users@lists.freeradius.org Subject: Error in Free Radius Integration with AD Server Message-ID: < CADfQPaA8HGThqd1HineHCVcMbFXSDCiwEPaD+umpS586D3Q7Hw@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1
---------- Forwarded message ---------- From: <owaisahmed19@gmail.com> Date: Tuesday, January 27, 2015 Subject: Error in Free Radius Integration with AD Server To: owaisahmed19@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@yahoo.fr> To: "freeradius-users@lists.freeradius.org" <freeradius-users@lists.freeradius.org> Subject: Chaining system authentication methods Message-ID: <709928179.1687784.1422426332754.JavaMail.yahoo@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 *************************************************
Please don’t respond to digest messages. It’s impolite. Start your own thread by sending a new message to the list. On Jan 28, 2015, at 9:57 AM, KAVYA PRABHAKAR <kavyamelinmaneprabhakar@gmail.com> wrote:
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>
Which just defines the attribute name. It doesn’t tell FreeRADIUS to send the attribute to the client.
After doin above changes restarted FR services. In the response from FR server, I am not seeing this attribute value being set.
Exactly.
Kindly help me, to understand what I am doing wrong.
Put the attribute into a configuration file. In v3, see raddb/mods-config/files/authorize There are *hundreds* of examples of this, and lots of documentation. Alan DeKok.
participants (2)
-
Alan DeKok -
KAVYA PRABHAKAR