[RADIATOR] "Expiration" attribute troubles
Hugh Irvine
hugh at open.com.au
Fri Jul 18 18:53:45 CDT 2008
Hello Andrew -
Further to this the latest Radiator 4.3 (plus patches) has this
change to the dictionary:
Changed the name of Expiration attribute (21) to Ascend-PW-Expiration to
prevent collisions with the Expiration check item. Also changed the
type to
string to be compatible with other RADIUS servers.
The only reference we could find to attribute 21 is the above old
Ascend definition, so that's what we've used.
We are not sure what happened with attribute 21 historically.
My previous suggestion still holds however.
regards
Hugh
On 10 Jul 2008, at 15:07, Hugh Irvine wrote:
>
> Hello Andrew -
>
> I have been doing some testing here, and when "Expiration" is
> specified as a "date" type, it does indeed require the number of
> seconds since Jan 1, 1970.
>
> This is when it is used as a reply attribute.
>
> However, there are some internal conflicts with "Expiration" as a
> check item which aren't going to be easy to resolve (this is what
> you show below).
>
> Therefore, I suggest you set up your LDAP field as something like
> "ACCOUNTEXPIRATION" and use the date in the format the Trapeze
> expects.
>
> Then you can use the following directly:
>
> AuthAttrDef ACCOUNTEXPIRATION, Trapeze-End-Date, reply
>
> Subsequently if any other device requires a different format, you
> can deal with it in a hook.
>
> hope that helps
>
> regards
>
> Hugh
>
>
> On 10 Jul 2008, at 05:54, Andrew D. Clark wrote:
>
>> On Wednesday 09 July 2008 12:02:27 am Hugh Irvine wrote:
>>> Hello Andrew -
>>>
>>> The Radiator dictionary has Expiration defined as a "date"
>>> attribute,
>>> which is expected to be the number of seconds since Jan 1, 1970.
>>>
>>> Hence the value that you are using is not being encoded properly
>>> when
>>> sent in the access accept.
>>>
>>> See section 15.1.1 in the Radiator 4.2 reference manual ("doc/
>>> ref.pdf").
>>>
>>> What format does your device expect to see as the value for the
>>> Expiration attribute?
>>>
>>> regards
>>>
>>> Hugh
>>
>> The device actually expects to see it as a date string and wants
>> it in a VSA
>>
>> VENDORATTR 14525 Trapeze-End-Date 6
>> string
>>
>> I was planning on converting it. Mainly I didn't want to push
>> device-specific
>> behavior into the campus LDAP directory RADIUS frontend, so that
>> other uses
>> for it aren't compromised. I run a RADIUS proxy for the device
>> and handle
>> the peculiarities there.
>> What is sort of interesting is that the RADIUS server (Radiator
>> 4.2) which
>> talks to the LDAP directory seems to be doing the conversion, but
>> not sending
>> out the converted value
>>
>> Tue Jul 8 11:37:14 2008: DEBUG: Expiration date converted to:
>> 1215536041
>>
>> Is a hook needed here or is there something in the configuration
>> that would
>> fix this?
>>
>> --
>> Andrew D. Clark
>> Network Operations Engineer
>> University of Minnesota, Networking/Telecom Services
>> 2218 University Ave SE
>> Minneapolis, MN 55414-3029
>> Phone: 612-626-4880
>>
>>
>>>
>>> On 9 Jul 2008, at 03:06, Andrew D. Clark wrote:
>>>> On Tuesday 08 July 2008 02:18:14 am Hugh Irvine wrote:
>>>>> Hello Andrew -
>>>>>
>>>>> Yes this is perfectly reasonable.
>>>>>
>>>>> I'll discuss the attribute collision with the developers.
>>>>>
>>>>> regards
>>>>>
>>>>> Hugh
>>>>
>>>> So this works a bit better now, but not quite correctly. Here's
>>>> the reply
>>>>
>>>> from the Radiator server fronting the Directory:
>>>>> Tue Jul 8 11:37:14 2008: DEBUG: Radius::AuthLDAP2 looks for match
>>>>> with adc
>>>>> [adc ]
>>>>> Tue Jul 8 11:37:14 2008: DEBUG: ValidFrom date converted to:
>>>>> 1215363121
>>>>> Tue Jul 8 11:37:14 2008: DEBUG: Expiration date converted to:
>>>>> 1215536041
>>>>> Tue Jul 8 11:37:14 2008: DEBUG: Radius::AuthLDAP2 ACCEPT: : adc
>>>>> [adc]
>>>>> Tue Jul 8 11:37:14 2008: DEBUG: AuthBy GROUP result: ACCEPT,
>>>>> Tue Jul 8 11:37:14 2008: DEBUG: Access accepted for adc
>>>>> Tue Jul 8 11:37:14 2008: DEBUG: Packet dump:
>>>>> *** Sending to 134.84.20.25 port 60509 ....
>>>>> Code: Access-Accept
>>>>> Identifier: 14
>>>>> Authentic: <144>J;N<194><198>v<15>o<218>H}<146><186><201><217>
>>>>> Attributes:
>>>>> MS-CHAP2-Success =
>>>>> "<1>S=3636045083C8C43EC0C1AC62DBB664AE79776A0A"
>>>>> Expiration = 2008-07-08 11:54:01
>>>>
>>>> And what I see on my end with radpwtst:
>>>>
>>>> Tue Jul 8 11:37:14 2008: DEBUG: Packet dump:
>>>> *** Received from 160.94.5.5 port 1645 ....
>>>>
>>>> Packet length = 77
>>>> 02 0e 00 4d 2d a6 ce 82 e3 a1 f6 88 a4 5b 75 43
>>>> 29 62 fd bc 1a 33 00 00 01 37 1a 2d 01 53 3d 33
>>>> 36 33 36 30 34 35 30 38 33 43 38 43 34 33 45 43
>>>> 30 43 31 41 43 36 32 44 42 42 36 36 34 41 45 37
>>>> 39 37 37 36 41 30 41 15 06 00 00 00 00
>>>> Code: Access-Accept
>>>> Identifier: 14
>>>> Authentic: -<166><206><130><227><161><246><136><164>[uC)
>>>> b<253><188>
>>>> Attributes:
>>>> MS-CHAP2-Success =
>>>> "<1>S=3636045083C8C43EC0C1AC62DBB664AE79776A0A"
>>>> Expiration = 0
>>>>
>>>> OK
>>>>
>>>> Both ends are running Radiator. Is one of them misbehaving?
>>>>
>>>> --
>>>> Andrew D. Clark
>>>> Network Operations Engineer
>>>> University of Minnesota, Networking/Telecom Services
>>>> 2218 University Ave SE
>>>> Minneapolis, MN 55414-3029
>>>> Phone: 612-626-4880
>>>
>>> NB:
>>>
>>> Have you read the reference manual ("doc/ref.html")?
>>> Have you searched the mailing list archive (www.open.com.au/
>>> archives/
>>> radiator)?
>>> Have you had a quick look on Google (www.google.com)?
>>> Have you included a copy of your configuration file (no secrets),
>>> together with a trace 4 debug showing what is happening?
>>> Have you checked the RadiusExpert wiki:
>>> http://www.open.com.au/wiki/index.php/Main_Page
>>
>>
>
>
>
> NB:
>
> Have you read the reference manual ("doc/ref.html")?
> Have you searched the mailing list archive (www.open.com.au/
> archives/radiator)?
> Have you had a quick look on Google (www.google.com)?
> Have you included a copy of your configuration file (no secrets),
> together with a trace 4 debug showing what is happening?
> Have you checked the RadiusExpert wiki:
> http://www.open.com.au/wiki/index.php/Main_Page
>
> --
> Radiator: the most portable, flexible and configurable RADIUS server
> anywhere. Available on *NIX, *BSD, Windows, MacOS X.
> Includes support for reliable RADIUS transport (RadSec),
> and DIAMETER translation agent.
> -
> Nets: internetwork inventory and management - graphical, extensible,
> flexible with hardware, software, platform and database independence.
> -
> CATool: Private Certificate Authority for Unix and Unix-like systems.
>
>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
NB:
Have you read the reference manual ("doc/ref.html")?
Have you searched the mailing list archive (www.open.com.au/archives/
radiator)?
Have you had a quick look on Google (www.google.com)?
Have you included a copy of your configuration file (no secrets),
together with a trace 4 debug showing what is happening?
Have you checked the RadiusExpert wiki:
http://www.open.com.au/wiki/index.php/Main_Page
--
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. Available on *NIX, *BSD, Windows, MacOS X.
Includes support for reliable RADIUS transport (RadSec),
and DIAMETER translation agent.
-
Nets: internetwork inventory and management - graphical, extensible,
flexible with hardware, software, platform and database independence.
-
CATool: Private Certificate Authority for Unix and Unix-like systems.
More information about the radiator
mailing list