[RADIATOR] "Expiration" attribute troubles
Hugh Irvine
hugh at open.com.au
Thu Jul 10 00:07:44 CDT 2008
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.
More information about the radiator
mailing list