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.

Helper Rights

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:
1. 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.

2. Group memberships: 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.

Cumulative 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.

Admin Access:

NTFS:

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.

Authentication Method:

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 less important.

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.