Hello, i try to use the Expiration Feature to get control over the Password lifetime of our Users. The idea was to set a date maybe 90 Day from last Passwordchange. This worked well, Users got denied but ive tested this feature only with a few Days ahead from now. Now i found out that if i set this to more than a Month from now that some of our Devices rejects the Access while i can see in the Radius Log that they where supplied with a Access-Accept. I guess that some of our older Devices got Problems with the releated Session-Timeout value which is in the Access-Accept reply too. Is there a way to not send Session-Timeout Data to these or all Devices ? In my setup i dont think that i need this because my goal is not to Disconnect a User, only to block him from logging in. Maybe there is a better solution to get this "feature" :) Im not sure if the Expiration Feature is the right thing for this task. Kind Regards, Sven
What all Attributes are supported depends on the NAS implementation. So there could be some session terminal attribute supported by your NAS, if you are using chillispot you have option to return WISPr-Session-Terminate-Time. Chillspot then just terminates user session at the timestamp returned by radius (as WISPr-Session-Terminate-Time). In any case if you want to not use (or selectively return Session-Timeout) then you can do it in unlang. Like you can keep a list of MAC addresses (for which Session-Timeout will be returned) in sql table and do a lookup. If lookup returns true then add Session-Timeout to your reply else dont. On Wed, Feb 4, 2015 at 5:26 PM, Sven <freeradius@fragnet.org> wrote:
Hello,
i try to use the Expiration Feature to get control over the Password lifetime of our Users.
The idea was to set a date maybe 90 Day from last Passwordchange. This worked well, Users got denied but ive tested this feature only with a few Days ahead from now.
Now i found out that if i set this to more than a Month from now that some of our Devices rejects the Access while i can see in the Radius Log that they where supplied with a Access-Accept.
I guess that some of our older Devices got Problems with the releated Session-Timeout value which is in the Access-Accept reply too.
Is there a way to not send Session-Timeout Data to these or all Devices ? In my setup i dont think that i need this because my goal is not to Disconnect a User, only to block him from logging in.
Maybe there is a better solution to get this "feature" :) Im not sure if the Expiration Feature is the right thing for this task.
Kind Regards, Sven - List info/subscribe/unsubscribe? See http://www.freeradius.org/ list/users.html
On Feb 4, 2015, at 6:56 AM, Sven <freeradius@fragnet.org> wrote:
i try to use the Expiration Feature to get control over the Password lifetime of our Users.
The idea was to set a date maybe 90 Day from last Passwordchange. This worked well, Users got denied but ive tested this feature only with a few Days ahead from now.
Now i found out that if i set this to more than a Month from now that some of our Devices rejects the Access while i can see in the Radius Log that they where supplied with a Access-Accept.
That’s easy to fix. Add this in the post-auth section: if (reply:Session-Timeout && (reply:Session-Timeout > 259200)) { update reply { Session-Timeout := 259200 } } That should fix the problem. The user will be disconnected after 30 days, and will reconnect. Ones who still have valid accounts will get another 30 days of access.
Maybe there is a better solution to get this "feature" :) Im not sure if the Expiration Feature is the right thing for this task.
Expiration is the correct thing to use. The problem is that many NASes are buggy. Alan DeKok.
On 04.02.2015 16:40, Alan DeKok wrote:
On Feb 4, 2015, at 6:56 AM, Sven <freeradius@fragnet.org> wrote: i try to use the Expiration Feature to get control over the Password lifetime of our Users.
The idea was to set a date maybe 90 Day from last Passwordchange. This worked well, Users got denied but ive tested this feature only with a few Days ahead from now.
Now i found out that if i set this to more than a Month from now that some of our Devices rejects the Access while i can see in the Radius Log that they where supplied with a Access-Accept.
That’s easy to fix. Add this in the post-auth section:
if (reply:Session-Timeout && (reply:Session-Timeout > 259200)) { update reply { Session-Timeout := 259200 } }
That should fix the problem. The user will be disconnected after 30 days, and will reconnect. Ones who still have valid accounts will get another 30 days of access.
Thank you, that helped me alot :) -sven
participants (3)
-
Alan DeKok -
Mrinal K -
Sven