Running Windows as non-Administrator
From Docupedia
Contents |
Background
As a dyed-in-the-wool *nix administrator, one of the very first lessons you get taught (and often the hard way) is "DO NOT LOG IN AS ROOT!" Here, let me repeat that for the hard-of-hearing in the back:
DO NOT LOG IN AS ROOT!
So, now that we've established that, I'm going to take this core concept and modify it slightly for Windows users:
DO NOT LOG IN AS Administrator!
While this is not the magic bullet, it goes a LONG way toward preventing minor bugs/viruses/mistakes from taking out the entire operating system. Since I have recently been pressed into service at work as the Domain Administrator, I've decided to mandate this to all of my users.
Conventions
I decided to use a convention common to Kerberos: the "admin" principal. For those of you not as familiar with Kerberos, typically administrative users are set up with a "normal" Kerberos principal (a fancy name for "username" in the Kerberos world) and an "admin" principle. They take the form "bklang" and "bklang/admin" and have different passwords and different authorizations within the Kerberos scheme. Since Windows does not allow usernames to contain a '/', I used "bklang" and "bklang.admin"
The notes in this guide focus largely on the challenges of a domain administrator, but should apply largely to a local machine administrator. Some of the shortcuts and screens may be different, but the concepts should be the same. For my testing, my domain controllers were Windows Server 2003 SP2 and Windows SBS Server 2003 SP2 and R2. All client machines were Windows XP Professional SP2. The domain were installed in Windows 2000 functional mode, not 2003 enhanced.
Windows Permissions and Privileges
As an administrator there are two privileges you very likely take for granted: The ability to log on "locally" (ie. with a directly connected keyboard and monitor) and the ability to connect "remotely" (ie. with Remote Desktop). As an unprivileged user, you will not have either of these by default. The good news is that when you installed your Domain, it created two default groups which grant this privilege: "Server Operator" (local logins) and "Remote Desktop Users" (remote logins). Once you have created your two users ("user" and "user.admin") put your unpriviled user into one or both groups as appropriate. Your admin login ("user.admin") should already have this privilege by virtue of being an Administrator, or more accurately, in the "Administrators" group.
Note:
On at least one of my domain installations, I noticed that the appropriate privileges were not assigned by default to the necessary groups. To fix this problem, log in as an admin (ie. "username.admin") to your domain controller and navigate to the "Domain Controller Security Policy" under the "Administrative Tools" sub-menu. Yes, you can do this as a non-admin, but likely you won't even have the "Administrative Tools" submenu, so let's not put the cart before the horse. Expand the "Local Policies" tree and click on the "User RIghts Assignment" node. Look through the list of rights and find the one named "Allow log on locally". Open this and make sure at *least* the groups "Administrators" and "Server Operators" are listed. If they are not, add them as necessary. Next find "Allow log on through Terminal Services" and make sure at *least* "Administrators" and "Remote Desktop Users" are included. If they are not add them as necessary. Once this is done, assuming your unprivileged user has the appropriate groups, you should be able to log in locally or remotely as configured.
Installing Software
From a CDROM:
If you're lucky, the developers of the software you want to install were sharp and added a piece of code to their autorun that detects you are not an administrator and prompts you to either run it anyway or perform a "runas" (the windows equivalent to "sudo") for the installer. If you're really unlucky, the software will not catch your non-admin status at all and completely break in silent and hard-to-diagnose ways. In my experience most of the software from Microsoft do it right. For third-party stuff, your guess is as good as mine. The bottom line is: be aware when you install software that in most cases you want to do it as an admin. If in doubt, cancel the autorun or installer (if it is already running), navigate to the CD, and right-click on the "Setup" executable and select the "RunAs" option. This will allow you to enter a password to the credentials of your administrative user and proceed with the install.
From a downloaded installer file
This one is easy: Just always remember to right-click and "Run As" your administrative user to install the software. That is, of course, assuming you trust it. But then, if you don't trust it, why are you installing it anyway?!
