|
RADIUS accounting packets can be divided
into: |
-
Accounting-Start packet
contains userid, nas-identifier/ipaddress,
plus other information received from the
NAS.
- Accounting-Stop record contains userid,
nas-identifier/ipaddress, plus other
information received from the NAS.
- Accounting-On record contains nas-identifier/ipaddress
record and indicates that a particular NAS
has restarted.
- Accounting-Off record contains nas-identifier/ipaddress
record and indicates that a particular NAS
has been shutdown.
- Accounting-Interim record is an
accounting record that could be received
from the NAS. This record is sent
periodically by the NAS for each user that
is logged on at the NAS. This feature is
generally supported in newer versions of
NAS.
|
|
The following issues are
important to consider when collecting accounting
information made available through RADIUS: In
rare cases, records could be lost during
transmission and may never reach the RADIUS
server. |
- The RADIUS server is not notified if the
NAS aborts.
- If the authentication and accounting
requests are received from a RADIUS Proxy,
then the other ISP may not forward
accounting-on, off records.
- ISDN supports multiple sessions and each
session generates an accounting start/stop
pair of records. There is an accounting
attribute called multi-session identifier
that clearly identifies such multi-session
records. Check for the multi-session
identifier in addition to the session
identifier to calculate the number of
sessions.
|
|
|
Working With a State Server |
|
Internet Authentication Service (IAS)
performs authentication using a database that is
configured at the IAS server site. This
authentication database could be the user
database for a Microsoft® Windows NT®/Windows®
2000 Domain or it could draw upon the user
information obtained from the Windows 2000
Active Directory The following diagram
illustrates a typical configuration that shows
how IAS interacts with authentication databases
such as a Windows Domain user database or Active
Directory. The diagram also shows how IAS could
interact with a state server that is provided by
a third party. The primary purpose of a state
server is to limit the number of simultaneous
logon sessions a single user can run. |
|
|
|
There are two points of interaction between
IAS and the state server. One interaction takes
place when IAS receives an authentication
request from the NAS. The state server provides
information from its database to determine
whether to accept or deny the request. The other
interaction takes place when IAS receives
accounting records from the NAS. The state
server uses these accounting records to update
its database.
|
|
State Server Design Considerations |
|
Depending on your design, you may need a
server to track the users that are currently
logged onto the network. The main challenge with
the state server is keeping the information in
the state server database in-sync with who is
actually logged on. If the information in the
state server is out of sync, users may succeed
in having multiple sessions when they aren't
authorized to do so. Also, users who do not have
multiple sessions could be inadvertently
penalized. The following should be taken into
consideration in implementing the state server: |
- The state server must make the decision
online in a few seconds. For this reason the
state server requires a scalable
infrastructure that can support many updates
and queries per second. Relational databases
are not appropriate for such large queries
with simultaneous updates. Relational
databases are primarily built to keep data
consistent and to provide a consistent view
of the data to all consumers. They are not
built for quick updates.
- Transactional consistency on updates
between multiple objects is not important.
This is because the state server can
tolerate a small window of opportunity.
However, transactional consistency of a
single update is important to reduce the
chances of leaving the state server in an
inconsistent state if one of the RADIUS
servers is shut down in the middle of the
update.
- Persistence (saving the state of the
network to persistent storage) is not
important because the persistent information
will quickly fall out of sync with the
actual state of the network.
- If ISDN or other forms of multilink are
supported on the network, the state server
should be able to handle scenarios that use
these features.
|
|
One possible design is to implement both an
Extension DLL and an Authorization DLL. Each of
these DLLs can communicate over the network with
a database. The Authorization DLL can update the
database with information about who is currently
logged onto the network. The Extension DLL can
query the database for this information to
decide whether to accept or reject a particular
user's authentication request; if the user is
already logged on, the request is rejected.
|
|
The advantage of having the Authorization
DLL update the state-server database is that the
Authorization DLL has access to more information
about the authenticated user. The Authorization
DLL has access to all of the authorization
attributes from the IAS Authorization mechanism.
For example, some users may have authorizations
that allow them to have multiple sessions. The
state server should treat such users as a
special case.
|
|
|
Requirements |
|
SBRadChk.dll supports IAS. IAS is supported
on Microsoft® Windows® 2000 Server and Windows®
.NET Server. It is also supported on Microsoft®
Windows NT® Server version 4.0 with the
installation of the Windows NT Option Pack or
Microsoft Commercial Internet Service (MCIS). |
| |
|
|
|
Terms & Conditions |
Privacy Policy |
Return Policy
|
|
|
|
