In the fight against malicious code, security experts have long recommended that administrators have two accounts—one for everyday use and one for administrative tasks. Running as an administrator leaves you vulnerable to a malicious software (malware) attack. Moreover, administrator privileges grant a user sweeping powers such as setting passwords, file permissions, users and groups, and many others. Security administrators face the dilemma of limiting the use of administrator privileges while giving users adequate permissions to perform their routine tasks. One solution that accommodates both needs is to let some users run as administrators and configure those applications that are most vulnerable to a malware attack—email, IM, and Web browsing—to run as low-privilege Guest accounts. Let's look at when you might want to use a Guest account and how to set one up.
Why Use a Guest Account?
Because some users require privileged access for many of their daily functions, either forcing a restrictive permissions policy on users or granting all users full administrator rights could prove counterproductive. Take, for example, one company I visited several years ago that had a security-aware network administrator. He forced everyone in the company, even the developers, to run as nonadministrators on their own workstations for day-to-day tasks. Everyone felt this policy was overbearing and either complained about it or, if they had the know-how, broke in to their own systems to gain administrator access. . . .
)
)
)
Register
More importantly, much of the premise of this article is based on fiction. When a guest account logs out, everything in it's profile goes away, including all of HKEY_CURRENT_USER, and everything in the profile directory. You can login as a guest as many times as you want, and change every setting under the sun, but as soon as you log out, it's all gone.
Since the whole profile is vaporized on logout, suggesting that a guest account would be suitable for email or IM is just plain stupid. Guest accounts retain no settings, they are allowed zero storage that persists beyond the session. It has been that way since at least Windows 2000.
And another thing, on my system the user Deny Logon Locally is set for Guest (but not Guests,) so to make your suggestion even minimally work, I'd have to edit local policy.
I wish the "rate this article" less useful scale went into negative numbers, this little farce doesn't deserve a 1, but that was the lowest available choice.
Question: don't your writers check these things out before writing a bunch of hooey, and subsequently looking stupid? Might want to give it some thought. There's already a large volume of misinformation out there; why you choose to carelessly add to that I can't even imagine.
-Mark McGinty
mmcginty November 23, 2005 (Article Rating: