Re: logging failed login attempts

Dale E. Reed Jr. ( (no email) )
Wed, 14 May 1997 12:53:12 -0700

Josh Hillman wrote:
>
> Is it possible to store the radius info for failed login attempts in
> the
> SQL database under a tablename of "BadCalls" or something? The Calls
> table
> is great for successful sessions, but unless RadiusNT is run from the
> command prompt (or by having accounting go to a text file), there's no
> way
> of finding out why some people may be having problems logging in from
> time
> to time. If it's possible, keeping these separate from the normal
> calls in
> Calls would be a good idea so that the Calls table doesn't get
> cluttered
> with (null) for usernames, etc...

This is already in RadiusNT 2.2. A peak from the manual, although its
sort of
unformatted ugly:

------------------------

Logging

You can enabled ODBC logging to allow RadiusNT to log information to the
database.
This information can be very useful in debugging or problem solving.
You can also
do reporting and gather statistics to find out any possible problems
RadiusNT may
be having.

The log table, described above, is very simply. The main field is the
RadLogMsgID
field, which tells what the error is. If the error has a user
associated with it,
the username will be stored in the username field. Lastly, the data
field contains
information, which is specific to the type of log message. For example,
a type 0
generic message or type 1 generic error will have a description of what
it is in
the data field (and typically the username field is blank). However,
for a type 4
message of bad password, the username field will be the username entered
and the
data field will be the password the user entered.

Below is a list and description of the RadLogMsgIDs:

RadLogMsgID Log Message Description
0 Generic Log Message This is a generic log message which does not a
pre-defined RadLogMsgID. This will be informational only, and is
not an error.
1 Generic Error Message This is a generic error message which does not a
pre-defined RadLogMsgID. This is typically a recoverable error.
10 User Not Found The username was not found in the database.
11 Bad Password The username was found in the database, but the password
was wong.
12 Expired Account The user’s account is expired.
13 Overdue Account The user’s account is overdue (Balance is larger than
allowed)
14 Concurrency Limit The user is already logged in the maximum allowed
time.
15 Time Limit The user does not have any time left to use.
19 No Service Defaults The user’s service does not have any defined
RADIUS attributes,
and the service type does not have any defined RADIUS attributes.
50 Unauthorized Requst A RADIUS request was received from a RADIUS
client who is not authorized to send requests.
51 No Username A RADIUS request did not have a username attribute.
52 No Password A RADIUS request did not have a password attribute.
53 Digest Mismatch A RADIUS request did not have a correct digest. This
is typically because the secret
used by the NAS does not match the secret RadiusNT has for the NAS.
60 Parse Error The data RadiusNT was trying to parse was in error.
100 CHAP not allowed The user authenticate using CHAP, but the user’s
Password is "UNIX" or "WINNT".
For these two cases, the user must use PAP.

The table is:

RadLogs
RadLogMsgID integer Related Log Message Identifier from RadLogMsgs
LogDate datetime The date of the message
UserName varchar(32) The associated username (if one exists)
Data varchar(50) Additional data, dependent on the Log Message ID


-- Dale E. Reed Jr.  (daler@iea.com)_________________________________________________________________       IEA Software, Inc.      |  RadiusNT, Emerald, and NT FAQs Internet Solutions for Today  |    http://www.emerald.iea.com