RUM is designed to provide a secure channel for user administration. RUM locks down its
registry keys and disk files, and configures IIS to require authentication. RUM uses
NTFS permissions and IIS authentication to restrict access to administrators and Helpers.
A Helper is an individual the administrator designates to use RUM.
Administrative Accounts (admins)
An Administrative account is defined as any account that is a member of the Administrators group
or the Domain Admins group. These groups may be named differently in nationalized versions of NT --
for example, in the French version of NT, the Domain Admins group is named Administrateurs Domaine
-- but RUM will find these groups no matter how they are named.
Helpers never have the ability to change administrative accounts. But for all other accounts, Helpers have the privileges you grant them. There are two main types of privileges you can grant:
User account settings:
Enable accounts, disable accounts, unlock accounts, change usernames,
or change full names and descriptions (each right is granted separately). These rights apply
to all non-administrative user accounts.
Add or remove existing user accounts from specific local or
global groups (each group the Helper controls must be specified). This right applies only to the
groups you specify.
The two types of privileges are not related. If you grant a Helper the right to change passwords, this
right applies to all non-administrative user accounts, not just the user accounts
listed in that Helper's groups. If you give a Helper rights to change group memberships for one group,
but no account settings rights, then the Helper will only be able to add or remove accounts from
that one group.
Additionally, Helpers can be granted permission to view RUM statistics, view excerpts from the Event Log
showing RUM entries, and synchronize the machine or domain. Synchronization will only be available if
RUM is running on a domain controller. Admins always have all rights.
A Helper has whatever permissions you grant specifically for that Helper, plus whatever rights
are granted to groups of which that Helper is a member. For example, if JANE is a member of
the group HELPERS, and you grant HELPERS the right to reset passwords, then JANE will
be able to reset passwords. If the group MANAGERS has permission to change usernames, and JANE
is a member of MANAGERS as well as being a member of HELPERS, then JANE will have both rights.
If you also add JANE herself as an individual Helper, and grant her the right to disable accounts,
then JANE will be able to disable accounts, reset passwords, and change usernames.
You must use an NTFS partition with RUM. (You should do this on any IIS machine anyway.) NTFS
is required in order to set correct permissions for the application. NTFS permissions are
what IIS uses to determine who can have access to what. If you're using a FAT volume, then
there are no restrictions at all.
You must choose the type of authentication to use. RUM works with either Basic (clear-text
passwords) or NT Challenge-Response, also known as NTLM, or a combination of both. NTLM does not send passwords
over the network, so with HTTP-style web access, NTLM is more secure than Basic. However, NTLM
will usually not work outside your Intranet. HTTPS-style web access uses SSL (Secure Sockets Layer),
and all data is encrypted, including the initial logon. With SSL, the authentication method is much
SSL (Secure Sockets Layer):
We recommend that you use SSL if possible. This requires that you have a server certificate, either from an
external agency such as Thawte or
Verisign, or an internal certificate, such as
can be generated with
Microsoft's Certificate Server. If you already have an SSL web site, simply add RUM to that
site during configuration, and RUM will inherit SSL capabilities. If you don't already have
an SSL web site, then we recommend that you create one before installing RUM. If, however,
you are putting RUM on a server that can only be accessed internally, and are not worried
about man-in-the-middle attacks or Ethernet snooping, then non-SSL is fine.
Default Web Site:
When you install IIS, it creates a default web site called "Default Web Site."
Best practices indicate you should disable (but not delete) the default web site immediately after
installing IIS. To disable it, right-click on the Default Web Site entry in MMC, then select Stop from
the pop-up menu. We recommend also renaming it to something like "Default -- do not start, do not delete"
to make sure other administrators don't accidentially delete or start the site.
The default web site includes sample applications, remote web administration, file
upload capability, and dozens of sample ASP and database access scripts. These samples and
tools are very useful for new administrators, but should never be enabled in a production
environment. They are not secure by default, and many of them cannot be made secure at all.
Do not delete the default web site, however; just stop the site from running. If you delete the
default web site without also changing several technical MTS settings, the samples can show up
as virtual directories in another web site on that machine without your knowledge or permission.
Already have content deployed using the Default Web Site? Not sure how to go about securing your
IIS site? See Microsoft's checklist
for lots of good information.
RUM Virtual Directory:
RUM can use any web site defined on your server. It does not need its own
site. It runs "in-process," so does not need WAM support. RUM is an ISAPI DLL that runs from
a virtual directory. You may create a separate site just for RUM if you want, or you can just
let RUM tag along on an existing site. (Not the Default Web Site!) You can change which web
site RUM uses after installation by clicking the IIS Settings button on the RUM Control Panel applet.
You should always let RUM create and manage the virtual directory for you, to make sure it is
secure. Advanced administrators may want to look at RUM's settings or tweak some parameters.
There is nothing to prevent you from creating and maintaining RUM's virtual directory yourself,
but the RUM configuration tools will overwrite your settings when you install, upgrade, or run
the IIS Settings tool.
RUM Security Context:
The ISAPI DLL portion of the program always runs in the security
context of the user operating the application, but the service portion runs in its own security
context. If you install RUM on a Primary Domain Controller (PDC),
member server, or stand-alone machine, RUM will not prompt you for a username during installation,
and will run the service portion of the program in the LocalSystem security context. Do not change
this setting. If, however, you install RUM on a Backup Domain Controller (BDC), RUM will need
to run the service portion of the program in the security context of an administrator. The user
account you choose should be a member of the domain's Administrators group, and a member of
Domain Admins. The account must also have the Log on as a Service right.