Re: Attach mac address to username

2005-04-02 Thread Joachim Bloche
 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 think that's
what we're looking for).

 Looking at radacct, I am receiving CallingStationID which appears to
 be the mac of the connecting client.

You're right, it is Calling-Station-Id, not session... apologizes.

 Would your suggestion be automatic or would I need to manually add the
 attribute.

I think you can do it automatically, provided your NAS sends
Calling-Station-Id with the authentication request. In this case you
may rewrite the post-auth request to add the row in radcheck (see
sql.conf). But I'm quite new to freeradius, and there may be 2 issues
: I'm not sure wether it's possible to use an INSERT in post-auth, and
I'm not sure wether the NAS will send the calling-station-id with the
authentication-request (but if it doesn't, there will be no
solution...). Anyway, this will be easy to check, but I have no radius
server for the week-end.

If this doesn't work, then you'll have to use a trigger or any other
mean, in order to insert the row in radcheck when the first accounting
start for this user occurs. This would be less convenient, but still
not very complicated.

Joachim

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Session-Timeout not set with pending Expiration

2005-04-01 Thread Joachim Bloche
  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 the DB. Here's the entry for a user in the users
file :

Fred  Auth-Type := Local, User-Password == hello2, Expiration :=
1 Apr 2005 23:59:00
Reply-Message = Hello %u

The Expiration attribute is used, as I get an access-reject if I set
it to any past date. But in the case the Expiration date is not past,
I still get an access-accept (ok) with no Session-Timeout (not ok).
The reply message is ok : Hello fred.

Il also tried with == in place of :=, it didn't work better.

I disabled SQL authorization, and use PAP for authentication. Here's
the ouptut of the server for a simple authentication request :

rad_recv: Access-Request packet from host 192.168.1.1:2175, id=54, length=44
User-Name = Fred
User-Password = hello2
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 2
  modcall[authorize]: module preprocess returns ok for request 2
users: Matched Fred at 94
radius_xlat:  'Hello Fred'
  modcall[authorize]: module files returns ok for request 2
modcall: group authorize returns ok for request 2
  rad_check_password:  Found Auth-Type Local
auth: type Local
auth: user supplied User-Password matches local User-Password
radius_xlat:  'Hello Fred'
Login OK: [Fred] (from client private-network-1 port 0)
Sending Access-Accept of id 54 to 192.168.1.1:2175
Reply-Message = Hello Fred
Finished request 2

I read all the doc I found (mostly, in the
/usr/local/share/freeradius-1.0.2/doc/ directory, freradius website, a
few articles and the mailing list) about attributes, variables,
operators, processing of config files and so on, but couldn't find
precisely how Expiration is used by the server. Is there a doc file I
would have missed ? Would it be useful to read the developpers'
mailing list ?

Thanks,

Joachim

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Attach mac address to username

2005-04-01 Thread Joachim Bloche
 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 table, only if doesn't already have
one.

This way, and provided your NAS sends this attribute with each
authentication request, only the user with correct MAC address will be
authorized.

Regards,

Joachim

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Session-Timeout not set with pending Expiration

2005-03-31 Thread Joachim Bloche
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 to the access-accept messages, or not. That's all :)

Regards,

Joachim

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: Session-Timeout not set with pending Expiration

2005-03-29 Thread Joachim Bloche
  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 server respond with?  What does debugging mode say?

I'ill give 2 detailed examples of what happens. We use the SQL schema
given with freeradius, and the configuration is a very easy one :

radius= select * from usergroup;
 id | username | groupname
+--+---
  2 | joachim  | users

The requests for authorization, accounting and so on are the one in
original postgresql.conf, we did not modify them.

Let's assume we are on 2005 March 29, 10:50:00. In radcheck we put :

radius= select * from radcheck;
 id | username | attribute  | op |value
+--+++--
  2 | joachim  | PASSWORD   | == | pwd_joachim
 12 | joachim  | Expiration | := | 28 Mar 2005 23:50:00

Then with NTradping we send an authentication request to our
freeradius, which answers as we guessed : Access-Reject,
Reply-Message=Password has expired.

If we now set :

radius= select * from radcheck;
 id | username | attribute  | op |value
+--+++--
  2 | joachim  | PASSWORD   | == | pwd_joachim
 12 | joachim  | Expiration | := | 29 Mar 2005 23:50:00

and resend an authentication request, we only get an Access-Accept,
with no attribute. This is where we expected to see a Session-Timeout
attribute, just like what happens when we set Login-Time in the
radcheck table.

You'll find what debugging mode says in this last example, at the end
of this mail. I'm sorry for the dump, but I could not guess whether
the request would be useful. I did not find any hint of what goes
wrong, but maybe this is just a normal behavior.

Joachim


Here's what debugging mode says for example where :

radius= select * from radcheck;
 id | username | attribute  | op |value
+--+++--
  2 | joachim  | PASSWORD   | == | pwd_joachim
 12 | joachim  | Expiration | := | 29 Mar 2005 23:50:00

and assuming the current date is 2005 March 29, 10:50:00

rad_recv: Access-Request packet from host 192.168.1.1:1571, id=17, length=53
User-Name = joachim
User-Password = pwd_joachim
NAS-Port = 5
  Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 16
  modcall[authorize]: module preprocess returns ok for request 16
radius_xlat:  'joachim'
rlm_sql (sql): sql_set_user escaped user -- 'joachim'
radius_xlat:  'SELECT id, UserName, Attribute, Value, Op ??FROM
radcheck ??WHERE Username = 'joachim' ??ORDER BY id'
rlm_sql (sql): Reserving sql socket id: 3
rlm_sql_postgresql: query: SELECT id, UserName, Attribute, Value, Op
??FROM radcheck ??WHERE Username = 'joachim' ??ORDER BY id
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: affected rows =
radius_xlat:  'SELECT radgroupcheck.id, radgroupcheck.GroupName,
??radgroupcheck.Attribute, radgroupcheck.Value,radgroupcheck.Op ??FROM
radgroupcheck, usergroup ??WHERE usergroup.Username = 'joachim' AND
usergroup.GroupName = radgroupcheck.GroupName ??ORDER BY
radgroupcheck.id'
rlm_sql_postgresql: query: SELECT radgroupcheck.id,
radgroupcheck.GroupName, ??radgroupcheck.Attribute,
radgroupcheck.Value,radgroupcheck.Op ??FROM radgroupcheck, usergroup
??WHERE usergroup.Username = 'joachim' AND usergroup.GroupName =
radgroupcheck.GroupName ??ORDER BY radgroupcheck.id
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: affected rows =
radius_xlat:  'SELECT id, UserName, Attribute, Value, Op ??FROM
radreply ??WHERE Username = 'joachim' ??ORDER BY id'
rlm_sql_postgresql: query: SELECT id, UserName, Attribute, Value, Op
??FROM radreply ??WHERE Username = 'joachim' ??ORDER BY id
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: affected rows =
radius_xlat:  'SELECT radgroupreply.id, radgroupreply.GroupName,
radgroupreply.Attribute, ??radgroupreply.Value, radgroupreply.Op
??FROM radgroupreply,usergroup ??WHERE usergroup.Username = 'joachim'
AND usergroup.GroupName = radgroupreply.GroupName ??ORDER BY
radgroupreply.id'
rlm_sql_postgresql: query: SELECT radgroupreply.id,
radgroupreply.GroupName, radgroupreply.Attribute,
??radgroupreply.Value, radgroupreply.Op ??FROM radgroupreply,usergroup
??WHERE usergroup.Username = 'joachim' AND usergroup.GroupName =
radgroupreply.GroupName ??ORDER BY radgroupreply.id
rlm_sql_postgresql: Status: PGRES_TUPLES_OK
rlm_sql_postgresql: affected rows =
rlm_sql (sql): Released sql socket id: 3
  modcall[authorize]: module sql returns ok for request 16
modcall: group authorize returns ok for request 16
auth: type Local
auth: user supplied User-Password matches local User-Password
Login OK: [joachim] (from client private-network-1 port 5)
Sending Access-Accept of id 17 to 

Session-Timeout not set with pending Expiration

2005-03-25 Thread Joachim Bloche
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 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. Is this a normal behavior ? Are we missing something ? Is
there a better way of achieving this ?

Thanks in advance for your help,

Joachim

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html