RADIUS is one of the most widely used distributed security/authentication
protocols in use today. It originally gained popularity with ISP's, where
it got its name (Remote Authentication Dial In User Service). Because of
its inherent architectural advantages, it has become widely used in other
network environments, including wireless and the general corporate intranet.
The RADIUS client-server architecture provides an open and scalable solution
that is broadly supported by a large vendor base. RADIUS provides a widely
accepted standard protocol anywhere network access servers (NAS) must
authenticate users prior to granting access to a protected network.
Web server access authentication has evolved along somewhat different lines,
with no clear standard. Companies that authenticate users to access their
networks (ISP/RAS dialup users, secure tunnel connections, etc) often make
use of RADIUS protocol based servers. These companies are often in a situation
where they must keep a separate user database, and use a separate procedure,
to authenticate the same users to access their web servers.
User authentication for IIS web servers is typically based on the NT
username/password. Individual users gain access to a particular protected
directory by 'logging in' to an NT user account. This scheme is both non-standard
and redundant in instances where there is a pre-existing RADIUS based
authentication infrastructure. In addition, special precautions are necessary
to assure that the NT username/password is not used for purposes other than
access to intended web-based facilities.
When a user of the web site encounters a RadIIS protected directory, he is
presented with the standard Basic Authentication prompt screen. Instead of
an NT username/password, the user will enter the username/password that will
be sent to RADIUS for authentication.
As this prompt is part of the Basic Authorization protocol, it is supported
by all versions of the major browsers. This includes Netscape and MS Internet
Explorer.
RadIIS maps any number of username/passwords to a single NT username/password
(just as all anonymous users are mapped to a single 'default' username/password).
This username/password pair is specified in the ini file. This dramatically
reduces the CAL requirement for users authenticating through their browsers.
The username, as typed into the browser, appears in the server logs for
all items accessed. This information is also available via asp and/or scripts.
RadIIS is implemented as an ISAPI filter, which is loaded by IIS. The only
other component required is a simple configuration file in the standard Windows
.ini format. A basic, fully operational configuration can be achieved by
the specification of as few as 7 items in this file. RadIIS was designed
to be simple to install and configure.
A variety of additional features and facilities are available to the user.
These include:
-
New with version 2.5: Support for cookie based session control. The
server will re-query for stale username/passwords and allow for instant logout.
-
Username/password (as typed into the browser) are accessible from ASP pages.
A section in the documentation illustrates both access and creation of cookies
containing this information.
-
Specification of a secondary RADIUS server, for use when the primary gets
congested or a failure occurs.
-
The ability to specify fields in the RADIUS authentication request packets.
-
Up to 10 separate directories (and their subdirectories) may be specified
for RADIUS authentication on a single web site.
-
An attribute/value pair, to qualify authentications, may be specified on
a per-directory basis.
-
Since RadIIS is built on top of IIS's Basic Authentication facilities,
the user may specify custom error pages (HTML) to be posted to the user upon
failure/rejection.
Please proceed to the licensing page for details of how to obtain a free
15-day demo. Also, we can provide a free SSL test certificate.
uudecode fix
The uudecode COM object has reportedly failed to work properly with certain
versions of .NET. The following links provide asp/vbscript alternatives for
decoding the uuencoded authorization header obtained via:
Request.ServerVariables("HTTP_AUTHORIZATION")
Note that the authorization header is sent in all subsequent http requests
to the server after Basic authorization is obtained. It is this header that
is decoded to provide AUTH_USER, and related server variables, in past versions
of asp/asp.net. An authorization header, as returned by Request.ServerVariables,
looks like:
Basic dGVzdF9icmFuY2g6cGFzc3dvcmQ.
The second string is the uuencoded username password with a ':' delimiter:
username:password.
ASP decode: An asp script to decode this can be obtained at the following:
http://www.motobit.com/tips/detpg_Base64/
Microsoft published method: Microsoft published a scripting solution
to decode this header to solve a related problem. Its Knowledge Base #835388:
http://support.microsoft.com/default.aspx?scid=kb;en-us;835388
Recent Revisions of RadIIS
2.50 Session support: High security cookie based sessions work in
a manner similar to, but completely independent from, ASP sessions. A new
encrypted cookie is generated every request. There is also a log-out mechanism.
2.51 Secure log: Sensitive information is no longer printed to the
logs at startup at low (production) log level. Also, passwords are optionally
not printed to the log on failed authentication requests. These facilities
were added in collaboration with Sandia National Laboratories.
2.52 Cache upgrade: The cache mechanism has been enhanced. Cache entry
timeout is now specified in minutes rather than hours. This makes RadIIS
useful in 'one time' password applications. This option was worked out with
our Canadian reseller (TH Consulting) and the staff a McGill University.
2.53 New uudecode and ini file encryption: This release contains the
uudecode fix discussed above. In addition, it supports file encryption of
the ini file. The ini file contains sensitive information (NT
username/password(s), Radius server location, Radius shared secret). This
greatly simplifies installation since no special precautions are now necessary
for directory access privileges.
2.54 Enhanced Sessions: The new implementation of sessions provides
far more security. This implementation also permits specification of both
logout and timeout pages. Ssl selection is no longer included in ini directory
specification. This option is no longer needed since modern versions of IIS
permit this specification in the directory security section of directory
property sheets. Also, a rarely appearing bug in the ini encryption has been
fixed.
2.60* 2-Factor Authentication Support: A new facility was added to
permit authentication via one-time-passwords generated by external devices.
This one-time-password is typed next to the username. Upon authentication
via Radius, the username and password are passed on to AD for normal
authentication. The result is a wrapper supporting external device generated
OTP's with subsequent authentication by Windows/AD.
2.61* Cache Upgrade: A new cache algorithm was added to support the
additional needs of the 2-factor option. The ini format has changed and is
simplified considerably. Also, a bug was fixed for the specification of secondary
Radius servers.
*2.60 and 2.61 were in limited release.
2.62 Generalized 2-factor/Radius/ODBC/AD: RadIIS now supports 3 methods
of authentications: Radius, ODBC, and Windows/AD. RadIIS can be optionally
configured to support external device generated OTP's, authenticated against
Radius, for any of these 3 methods. |
