eg: would I have to add the table.
radcheck
id - - - - - - - - 4567
UserName - - user1
Attribute - - - Calling-Session-Id
op - - - - - - - :=
Value - - - - - 000bcdfxxx
I think this example is OK, but the op which should be '==' (':='
always matches and sets a freeradius parameter, I don't
wether setting
an Expiration attribute in radcheck normally implies a Session-Timeout
to be added to the access-accept messages, or not.
Yes.
If it doesn't work in SQL, try it in the users file.
Thank you for answer. I tried with the users file and got the same
behavior as with
Is there a way to dynamically attach the mac of the users pc to the
username who has logged in?
This way I can stop people sharing the same username/password
combination on different pc's.
Using the post-auth requests, you can add a Calling-Session-Id for the
concerned user in the radcheck
Hi again,
I'm sorry to post twice but as I'm not an english person I was
wondering wether what I asked was really clear. I'm not looking for a
complicated solution of any kind, but I'd like to know wether setting
an Expiration attribute in radcheck normally implies a Session-Timeout
to be added
When a user logs in 23 hours and 59 minutes after the first
connection, I expected freeradius to return the Session-Timeout
attribute in the access-accept (with value 60).
Actually it does not, so the user can stay connected well after the 24
hours limit.
So... what does the
Hi,
We're using freeradius 1.0.1 with postgresql.
We create users which expire 24 hours after first login. Currently we
do this by setting the Expiration attribute to be login-time + 24
hours in the radcheck table.
When a user logs in 23 hours and 59 minutes after the first
connection, I
6 matches
Mail list logo