You can use the "hints" file to do what you want. It does *not* say you can only use prefix & suffix matching.
I was referring to the following in the sample hints file: # Matching can take place with the the Prefix and Suffix # attributes, just like in the "users" file. # These attributes operate ONLY on the username, though. And this in the doc/README file: Customize the /etc/raddb/hints file. This file is used to give users a different login type based on a prefix/suffix of their loginname. For example, logging in as "user" may result in a rlogin session to a Unix system, and logging in as "Puser" could start a PPP session. Is there another document that describes matching on other attributes and how to add new attributes to the request. I think these paragraphs need updating. Are you saying I can do this in hints: DEFAULT Cisco-AVPair == "", My-Group := "RadioIP-MAU" DEFAULT Cisco-AVPair == "ssid=(.*)", My-Group := "Wireless %{1}" DEFAULT My-Group := "Unknown source" That is, does hints work just like the users file, except it adds any new attributes to the request? If so, this is exactly what I need! If the syntax or usage is off, can you correct me. Thanks Alan.
"Garber, Neal" <Neal.Garber@energyeast.com> wrote:
You can use the "hints" file to do what you want. It does *not* say you can only use prefix & suffix matching.
I was referring to the following in the sample hints file:
Which says you *can* use them. It doesn't say you *can'*t use anything else.
DEFAULT Cisco-AVPair == "", My-Group := "RadioIP-MAU" DEFAULT Cisco-AVPair == "ssid=(.*)", My-Group := "Wireless %{1}" DEFAULT My-Group := "Unknown source"
The first line matches a request. The second, and subsequent lines, add attributes to the request. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Gurus, I will use the class attribute to pass information from Authentication to Accounting Processes. I'm doing this in my users file: DEFAULT Auth-Type := Accept Class = "DDF%{ContractInfo}" Where ContractInfo is a number like '123456' In the hints file on the accounting server, I try to evaluate, using DEFAULT Acct-Status-Type =~".*", Class =~"^DDF(.*)" ContractInfo = "%{1}", Fall-Through = Yes But the class will be expanded to something like %{Class} -> 0x44444631323334...., which does not match ^DDF.* For testing, I started my hints file with DEFAULT Acct-Status-Type =~".*" Class = "DDF:123456", Fall-Through = Yes But the same, it will be expanded to %{Class} -> 0x44444631323334.... As a workaround, I'm currently matching on the hex value, which works, but does not look nice and my ContractInfoHex has to be evaluated later.... DEFAULT Acct-Status-Type =~".*", Class =~"^0x444446(.*)" ContractInfoHex = "%{1}", Fall-Through = Yes What's wrong here? I'd expect, that the class attribute would be readable in hints file. A second Issue: The proxy server beween me and the NAS will request a second radius server in case I have previously accepted the Request. If this second server Accepts the call and adds a class to the accept packet, than it comes to the situation, that I will see the two classes hitting my accounting server. Beside the proxy-state, the order of attributes is not guaranteed... Will DEFAULT Acct-Status-Type =~".*", Class =~"^DDF:(.*)" Match my class, or will it see the first class in the packet and will then not macht? How can I match for multiple instances of a single attribute? Wold an entry in attr file help... Like this one?: DEFAULT ... Class =~"^0x444446.*" Thank you. Stefan
But the class will be expanded to something like %{Class} -> 0x44444631323334...., which does not match ^DDF.*
The Class attribute is defined in the RFCs and the dictionary files as type "octets", which are coerced to their 0xaabbcc representation before string operations (e.g. regexp, database insert) are performed. If you're sure you'll only have ascii, you can edit dictionary.rfc2865 and change the type of Class from "octets" to "string"
A second Issue:
The proxy server beween me and the NAS will request a second radius server in case I have previously accepted the Request.
? The request will be authenticated twice?
If this second server Accepts the call and adds a class to the accept packet, than it comes to the situation, that I will see the two classes
Is that permitted under the RFCs?
hitting my accounting server. Beside the proxy-state, the order of attributes is not guaranteed... Will DEFAULT Acct-Status-Type =~".*", Class =~"^DDF:(.*)" Match my class, or will it see the first class in the packet and will then not macht? How can I match for multiple instances of a single attribute?
It should match; IIRC the regexp will try all all instances of an attribute and stop on first match.
Wold an entry in attr file help... Like this one?:
DEFAULT ... Class =~"^0x444446.*"
Thank you.
Stefan
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thank you, Phil,
But the class will be expanded to something like %{Class} -> 0x44444631323334...., which does not match ^DDF.*
The Class attribute is defined in the RFCs and the dictionary files as type "octets", which are coerced to their 0xaabbcc representation before string operations (e.g. regexp, database insert) are performed.
If you're sure you'll only have ascii, you can edit dictionary.rfc2865 and change the type of Class from "octets" to "string"
I was thinking about this, but found, that it is more complex in troubleshooting situations, where I'd be able to distinguish the classes if I'm using octets.
A second Issue:
The proxy server beween me and the NAS will request a second
radius server
in case I have previously accepted the Request.
? The request will be authenticated twice?
Yes, Twice. In the first step at a Billing System and if this accepts, the request will be send to a customer RADIUS Server.
If this second server Accepts the call and adds a class to the accept packet, than it comes to the situation, that I will see the two classes
Is that permitted under the RFCs?
I Don't see any reason, why not. Each of the servers has the 'right' to append classes to the accept and the client must put the classes into the accounting packets. As the clients are not allowed to interprete (or filter) the classes (and even Proxy servers aren't) I will be hit by all classes, sent to the client in all accepts.
hitting my accounting server. Beside the proxy-state, the order of attributes is not guaranteed... Will DEFAULT Acct-Status-Type =~".*", Class =~"^DDF:(.*)" Match my class, or will it see the first class in the packet and will then not macht? How can I match for multiple instances of a single attribute?
It should match; IIRC the regexp will try all all instances of an attribute and stop on first match.
It does not. I've checked it using hints file: DEFAULT Acct-Status-Type =~".*" Class += "0x313131", Class += "0x323232", Fall-Through = Yes DEFAULT Class =~"^0x313131" Fall-Through = Yes Will Match on line 8 DEFAULT Acct-Status-Type =~".*" Class += "0x323232", Class += "0x313131", Fall-Through = Yes DEFAULT Class =~"^0x313131" Fall-Through = Yes Does not match
Wold an entry in attr file help... Like this one?:
DEFAULT ... Class =~"^0x444446.*"
Thank you.
participants (4)
-
Alan DeKok -
Garber, Neal -
Phil Mayers -
Stefan A.