Windows Users Ignoring LUA Security

blankify writes "eWeek is running a story about the least-privilege, no-admin option available in Windows (2000/XP/2003) that has been mostly ignored by end users. From the article: '"To the average user, the notion of non-admin is abstract and obscure," said Michael Howard, a senior security program manager in Microsoft Corp.'s security business and technology unit. "Most users just don't know they can set up least-privilege accounts in Windows today, and that's just a sad reality."'"

It could be the default option during install

How about, embracing and extending good practice...

Re:It could be the default option during install

Try it yourself some time. Running windows without admin rights is a nightmare. About 2/3 of my programs won't operate (I'm a software developer) at all. I've fixed almost everyones computers that knows me (I hate being free tech support but anything for a friend) and stupid programs like a damn cat breeding program this one girl had wouldn't run without admin rights (after fixing her computer 3-4 times I tried the No Admin route to no avail).

Until programs run without being admin this whole arguement is pointless.

OS X does it perfectly.

Re:It could be the default option during install

Try something next time...

Change the shortcut to point to "runas /u Administator /p (the admin password) /e (the path to the exe) /a (whatever the arguments are)". That should let you run something as an Admin while still being an LU.

It certainly isn't easy

"Running windows without admin rights is a nightmare."

It certainly isn't easy, unless you're willing to invest significant technical time and effort into the project -- which is, I'm sure, a big part of the reason why most people don't do it.

That being said, I'm the admin for an organization with about 60 or so Windoze stations, and I can say that it can be done for most things. It most often involves figuring out what the defective program is trying to do, and then allowing it access to just where it needs.

The two most vital tools are FileMon and RegMon, both free from SysInternals (http://www.sysinternals.com/ [sysinternals.com]). They monitor file system or registry accesses. In the vast majority of programs can be made to work just by applying some ACLs on program-specific registry or filesystem branches.

There's no way in hell your "typical home user" could do this, though, which is, I expect, the problem and point.

Re:It could be the default option during install

Not to overdo the "sympathy for the devil" thing here, but I've been thinking about how screwed poor Microsoft is. Think about this; they've managed to paint themselves into a corner on security and stability issues, and they may not have any way to get out of it. Consider:

1. They carried the same codebase forward from Windows 3.1, never completely scrapping it, always just bolting new parts on. This has caused Windows to end up like a Rube Goldberg machine, so complicated on the inside that "they" say nobody at Microsoft really knows what everything in there actually DOES.

2. They really pounded the nails in the coffin when they deliberately bound IE into the O/S to frustrate the DOJ during the browser wars. By binding so many things right into the O/S, they glued themselves to their codebase. Can they even separate their GUI from the underlying O/S anymore?

3. Given that this monstrous, mammoth codebase is a hideous nightmare to try and "fix", obviously the smart thing is to pull a Steve Jobs: scrap the whole beast and glue a beaufitul, stable frontend onto a FreeBSD backend with a Mach Microkernel. This would turn Windows into a thing of beauty and stability, like the Mac O/S. But, CAN they? Is it even possible?

4. And, if they did that, they might face a revolt as virtually every software company, corporate IT department, and end user went completely ballistic. It could be suicide.

So, think this over: Microsoft is pretty much screwed, locked utterly into the codebase they've got. If they stick with it, eventually they'll be replaced by more secure, stable alternatives. If they try to save themselves the Apple way, the end could come sooner instead of later.

If YOU were Gates and Ballmer, what would YOU do?

Aside from spending the weekend on the yacht, I mean... ;)

I wonder why

"Most users just don't know they can set up least-privilege accounts in Windows today, and that's just a sad reality."

I wonder if this could have anything to do with the fact that the user interfaces, OS messages, and help files are not "user friendly" and written in mysterious GeekSpeak that the average user doesn't understand.

Re:I wonder why

Or the fact that 1/2 the programs only work with Admin rights.

Re:I wonder why

Even a lot of MICROSOFT games (Age of Mythology, for example) don't work unless you have admin rights...

Re:I wonder why

It isn't the unfriendliness of the UI or the help file.

By default, new accounts created during a windows install/first use interface are administrator accounts. As are new accounts created through the generic, task view Control Panel interface for account management.

It's one of the reasons that Windows is unsecure out of the box.

If MS merely made accounts user only be default, that would take care of it.

Of course, then you'd have to fix all of the crappy software out there that can only run as admin. And there's a lot of it. Major software packages like WordPerfect still don't handle user accounts and preferences correctly and it's a very simple thing to do.

Re:I wonder why

Lets not forget software just failing to work. Most third party applications simply will not run correctly in an LUA environment. Honestly, most MS software couldn't run this way before 2000. I run LUA and I have to use runas admin on far too many applications; how is that really LUA? And lets not forget that running IE with reduced rights will also cause many IE plugins and any IStream handoffs (like Media Player) to fail without explanation.

Of course, I totally agree that they claim of lack of user awareness when it is really a lack of MS support. Microsoft has also done nothing to simplify this issue for developers. There are no simple "test and prompt for elevation" routines. It's not a general Windows logo requirement; in fact it's buried in one paragraph in the enterprise logo. And to top it all off, aside from a few proactive devs making blog entries, there's been no attempt to educate users.

Way to go MS, blame user apathy for your own poor performance.

doh

most likely because this option breaks most applications

Re:doh

Too bad you posted as AC because that's exactly why I don't use it.

A limited account in linux still allows you to do most things without a hitch. Plus, when you need root access, you can do that within the logged on account without logging off.

I also tried setting up my SO's account as limited but she ran into problems all the time. It is hard to explain (excuse?) something as a feature when it is such a pain in the ass.

Hopefully, they will get this one thing right in Longhorn.

Re:doh

You can start a Administrator cmd prompt in windows without logging off:

runas /profile /user:Administrator cmd.exe

Or any other program can be launched.

Re:doh

Fast user switching doesn't work when your system is connected to a Windows domain.

Re:doh

most likely because this option breaks most applications

This is why most people don't know about it; developers and vendors barely understand Windows security, so it's ignored. The users instinctively know this and they play along, ignoring the existing capabilities.

The Microsoft platform is closed, poorly designed, obscure and ambiguous. Side effects are common and difficult to prevent or correct. Frobbing things that vendors aren't paying close attention to is a good way to invent new breakage.

Go ahead, be the first on your block to harden Windows with naive LUA. Spend the next two years chasing down truly arcane breakage. Teach Microsoft and third party vendors how to promulgate securable products. Meanwhile, I'll be using software on platforms that figured out most of this stuff a decade ago.

Cluelessness at Microsoft

There's a reason why most people don't use it. Microsoft's implementation is flawed to say the least. When a user sets themselves up this way and then installs programs as an Administrator, they find that they can't run the programs completely or correctly as the lower privilege user. Some of this is due to Windows application programmers doing boneheaded things. Much of it has to do with the programming practices Microsoft has fostered - like writing to global registry keys in the Windows 95 and 98 days. Contrast this will Apple which has gotten the APIs right, put out tutorials on how to do this and most importantly made the whole process of installing as Administrator but running as a User as painless as possible.

Tell that to the developers

If their software doesn't work in least priveleged mode doesn't it defeat the whole purpose of the system?

Re:Tell that to the developers

Hell, tell that to Microsoft [microsoft.com].

Certain Programs Do Not Work Correctly If You Log On Using a Limited User Account

Microsoft Flight Simulator 98
Microsoft Flight Simulator 2000
Microsoft Flight Simulator 2002 Professional
Microsoft Flight Simulator 2004 Century of Flight
Microsoft Train Simulator 1.x
Microsoft Money 2000
Microsoft Money 2001
Microsoft Money 2002
Microsoft Money 2003
MSN Messenger Service

Microsoft seems to have discovered the command-line, so maybe they'll discover the root account? Maybe they can fix their broken 'runas' soon thereafter.

It's also ignored by developers

Users ignore it, because it's a horrible pain to use XP using a normal user account.

There are numerous games that cannot be installed without admin rights, and plenty who cannot even be EXECUTED without admin rights. All because the devs are lazy morons.

Same goes with numerous applications.

Not to mention the fact that in many case applications break in random ways, without actually telling why they break.

So right now if you actually want to use XP, you pretty much are stuck with admin mode (or you have way more patience than I do in using 'run as..' or switching users)

Re:It's also ignored by developers

It's not just developers, unfortunately. Some important things just can't be done under normal account. For example: COM-server registration (and consequently ActiveX controls) requires admin access , because permission to access HKCR and HKLM is neccesary.

Re:It's also ignored by developers

There are numerous games that cannot be installed without admin rights

First off, this is true of *nix as well. Remember that lest step of installing new software, 'make install'? That one usually has to be done as a super-user, as it installs into common areas.

and plenty who cannot even be EXECUTED without admin rights. All because the devs are lazy morons.

Actually, this has nothing to do with the developers being lazy morons (which they're not). It has to do with MS' broken security model. The place where they chose to draw the line between user and admin restrictions in the API is so asinine that it's virtually impossible to write any sort of complex app that *doesn't* require some admin functionality to run.

But to be honest, why does it even matter? A lot of the vulnerabilities on Windows have nothing to do with installing software, or who has the permissions to run operations. They have to do with services' exploits and buffer overruns, which are already running as 'System' level (super-user) in the background.

Non-admin Wiki!

Everything you need to know http://nonadmin.editme.com/ [editme.com]

defaults

I'm sure the default setting of creating an admin level user with no password at install time, and then having it set to automatically log them in has nothing to do with it...

Windows' fault

Could it be "the sad reality" because Windows up until XP (ignoring 2000 and NT) there was no user-priviledges differences?

Maybe MS should start educating the population and force them to create passworded least-priviledged accounts and choose a password for the administrator account when installing or booting an OEM for the first time. Maybe also the administrator should be blocked out of surfing the web and playing games so that people just don't use the admin account for everything.

Too many apps won't run without Administrator Priv

One big obstacle is that too many applications I see require administrator privileges not just to install but also to run. Your end users figure that out, set themselves up as administrators, and leave it at that.

This is nothing new...

Sad state of affairs

Oh, I'm sorry for installing the system and using it as the default. Please continue to blame the users for paying you for a borderline operating system. It is not an education issue as much as it is a crappy software issue. You should not continue to turn a deaf ear, but I already know you will. Just send out an email that looks like a Phishing email but contains a system lockdown. That way, only the stupid people will click on it, and we can decrease the surplus population on the internet.

Lazy programmers

If so many Windows developers weren't so utterly lazy, and learned how to code an application that doesn't require administrator rights to run, things would be a lot easier. As it is, there are so many poorly-written apps out there that write to admin-only places in the registry, or dump files that need to be modified into system folders, that in a lot of large companies with a plethora of apps it's almost impossible to switch to a true LUA security model.

Of course, a lot of the blame goes to Microsoft for encouraging the idiotic "everyone's an admin!" mentality.

Longhorn should implement these

This is why during the set-up of Longhorn it'd be a really cool idea to create all the accounts for the welcome screen, or it's equivelent, as non-adminstrative users. In fact, it should go further than this, it shouldn't give you the option of creating an administrative account at all on this screen. The administrative user should be banned from internet access by default (with the exception of Windows Update) and if you decide to add another administrive account it should warn you profusely that this isn't a smart idea.

In .NET there are attributes that allow you to define permissions on methods. For example, if I know that my method only ever does algebra then I can ban it from network IO, File IO etc. It'd be a good idea to make these attributes required before the source will actually compile. You could have intellisense in Visual Studio autogenerate the most restrictive settings whenever you create a new method.

Some security counter-measures can be really a pain in the ass but these couple i've mentioned here would really help bring windows security under control. Windows security is not bad, per se, it just needs more configuration than we can expect from Joe Sixpack. We need to make security easier for them and that's in everyones best interest, Microsoft included.

Simon.

Reminds me of Red Hat...

... I'm a true blue Windows user, but I've tried linux. Red Hat 8, to be specific. I remember the FIRST thing it told when I logged in as root, was to create a new non-power account. It even showed me how to. Whenever I wanted to change/install something, a nice prompty would come up asking for my password to give it the proper priviliges.

M$ should learn from this, and their little article there, that instead of the stupid tour that appears when you first login after a fresh install, there should be a message alerting the user to create a new account.

Backwards compatibility

In my experience, lots of old Windows 95/98/Me software fails to run properly without administrator rights due to nasty habits like writing lots of stuff all over the system registry and/or Windows directory. XP Home also makes the problem worse by making it very hard to set file access privileges. All in all, the problem here is that running most Windows software with lower privileges doesn't work, so nobody sets up their system with limited privileges. Also, there is too much stuff you have to do manually to switch to the right privilege level for every task that you have to understand to actually gain anything for the added complexity.

In contexts where the system administrator and user are two different people (and the system administrator is on the job), things usually work smoothly. These contexts are also those for which software is properly written; how much office software needs administrator access to run? The problem comes when you have a clueless user who is also admin for a machine; you try explaining to people why they should have to type a password (administrator password) to install something and when they should enter this password without confusing them or discouraging them from using limited privilege accounts altogether. Unfortunately, this sort of protection is almost useless if the user with the admin password is clueless.

However, I see no reason why Internet-facing software shouldn't be written to drop privileges on startup, much like a lot of suid root binaries open the files they need and then drop to normal user privilege levels. For example, preventing IE from installing or modifying stuff all over the OS would help a lot.

An Example

On Windows 2000 fresh system installation, a game title Star Wars Galactic Battlegrounds (running on Age of Empires engine), published by Microsoft executes only in administrator account, not in user. Many other games of other publishers doing cd check or strange networking too.

It's Intentional

When a friend of mine got a new Windows XP (Pro, not Home) box, he asked me to help him get it set up. I told him that he should have two accounts: one admin (He has a strong password for his admin account and the username has been changed from default.) and one regular user. I explained the whole issue of how an exploited machine with the user running as admin could cause more problems than if he ran as a regular user. I cautioned him that he'd have to deal with the pain of switching between the accounts whenever he needed to do stuff that required admin rights. Since he's been trojaned before, he agreed. We also set up the Windows XP firewall for extra security since he was directonly connected to the net.

Within a month, I got a call where he said, "Dude! Can we get rid of this admin account and the goddamn firewall? Everytime I want to do anything useful, I have log into the admin account. And I'm always having to log into admin and turn the firewall off to play online games". So, I suggested that he spend the money to get an external hardware DSL/Cable router. He did, and we turned off the firewall. But he still wanted his regular user account to be admin because that's where all his data was. After arguing with him for a bit, I told him we could set it up as an admin user (he didn't want power user because we'd tried that and there were still a few programs he claimed he couldn't run even as power user. CDRWIN was one of them) but that if anything resembling the worm/trojan that hit him in Win98 happened, it would be a full reinstall. I wouldn't try to figure out what happened. He agreed. It's been a year and a half since then. He's really good about applying the latest critical updates and that hardware router has probably saved him numerous times. But I still think he's in a risky position.

Most people just don't want to have to deal with the hassle of switching between two user accounts or learning to use "runas". It will always be this way. End users need full privs on their boxes. The only way around this is to set OSes up so that each user's "desktop" is actually a full VM. Then if it gets hosed by them running as admin, the only thing that needs to be wiped is their profile and that VM's image. Much cleaner than having to do an OS reinstall or a postmortem.

Some reasons...

1) Windows XP has a crap default setup for user preferences; candy apple theme, "hide known file extensions", icons view, hide "my computer" etc.

Once the admin account is set, it is a PITA to do the same stuff for other accounts. XP needs a button that says "make ALL accounts use this as default" button on those settings.

2) No damn rhyme or reason behind what requires admin access and what doesn't. Sure, adding Office or Baldurs Gate should require admin, changing screen resolution? Hell no. Half the spyware normal users get uses privledge escalation holes anyway so it does not keep that crap down.

Make the stuff make sense.

Anyway, I have been told (but have not tried) that making the "temp" folder trees "Everyone" read/write explicitly, and adding each account explicitly fixes most of the "run as admin" problems. Most programs dont do much registry editing, but a lot need scratch space and if they use the temp folders, they need access to them.

Re:Some reasons...

Sure, adding Office or Baldurs Gate should require admin, changing screen resolution? Hell no.

Changing the screen resolution in Windows does not require admin privileges.

Half the spyware normal users get uses privledge escalation holes anyway so it does not keep that crap down.

Which ones ? Privilege escalation bugs aren't exactly common.

Anyway, I have been told (but have not tried) that making the "temp" folder trees "Everyone" read/write explicitly, and adding each account explicitly fixes most of the "run as admin" problems.

You've been told wrong. For starters, every user on the machine can create new files and modify existing files that belong to them in C:\Windows\Temp. Secondly, most all apps (even the badly written ones) use the per-user TMP variables that point to directories within the users profile (that they have "Full Control" over).

Most programs dont do much registry editing, but a lot need scratch space and if they use the temp folders, they need access to them.

No, in fact the most common problem is applications that try to store things that *should* go in HKEY_CURRENT_USER in HKEY_LOCAL_MACHINE. Bugs like this are actually a good indicator of the developer's lack of interest in updating their product, because per-user registry hives were introduced to Windows 9x back with Windows 98 (they've always been in NT AFAIK).

The second most common problem is stupid developers trying to write to files (often user or application preferences) in either their program's directory or the Windows directory (DOOM 3 has this problem).

Win XP Is An Ugly Kludge

While I was started on a TI 99/4 [oldcomputers.net] my parents got for me, sans monitor, and hooked up to an old 14 inch b&w TV, every machine following that was a wintel box up to being introduced to Mandrake (as it then was) 6.

DOS 3.3 was the first MS OS I understood, so much so that, when the first DOSSHELL came out, I asked why would someone need that? I jumped on the NT technology because, when it first came out, it was well documented, (vis a vis my experience) and it allowed a whole new playing field. When NT 4 came out MS moved Video and Printer drivers from User mode to kernel mode. This was, IIRC, about the time Bill Gates had his vision of the PC integrated multi media household. I believe the PC version of Windows has persued this vision of multimedia OS to the point of having become in WinXP an ugly, bloated kludge, but it does, as much as possible, deliver in an ugly way, as a backward compatible multimedia OS.

Win 2K was the last OS to maintain the promise that Win New Technology brought with it. Win XP saw the culimnation of MS' effort to integrate Win95/98/ME with some of the benefits of NT, but the end result is an all and everything everyman's stew meant to satisfy the cravings of the masses.

I run WinXP on a web box for multimedia but thanks to the lessons gleaned online (/.:) I'm moving on to a *BSD, or one of the upcoming microkernel OSes to do research.

This is not too hard to figure out

MS - Hello intrepid user. I know I've always allowed you to run as root before but check this out! You computing experience could be filled with and endless array of confusing dialogue boxes all basically telling you you're not root.

User - That sounds like it might suck.

MS - No no no, it's great! And it's pretty hard to implement. Oh and a whole shitload of legacy apps won't even install.

User - Why would I want that?

MS - It's safer.

User - Do you still let programs run as System?

MS - Well yes.

User - Why?

MS - Symantec asked us to support the Open Source Virus Community and we are!

I'll just repeat...

...exactly what I said in my previous post: least-priviledged admin-password-asking security systems are useless for home users. Make a user type his password n times a week and he'll type it in every single dialog window that asks for his password. Even the malicious ones.

So now you have your user enclosed inside an annoying stainless steel safe, except for the fact that it isn't safe at all, because he'll yell the door code at anyone standing outside.

Home users don't need annoying internal security. They need transparent outside access security. That's all. Give an annoying security tool to someone who is only interested in bein left alone to use his computer, and he'll break it in a minute.

Face it, people: users will always want to be in charge of their computer, to install the latest (card/3d/simulation/fishing) game, "multimedia" tutorial or whatever. So now you have two choices: 1. Give them a crippled (no admin access) computer and they'll give you the finger. 2. Give them the admin password and they'll render it useless.

And no, this is not a matter of education. Even the most experienced geek can get distracted and annoyed as hell with password prompts. Create a security system that gives you routinely security prompts and they're going to be... routine.

What we need to fix is the way computers execute applications. We need a secure list of routine applications and procedures and a secure code signing system. A system where funny-cat-game is really from a company that was previously-approved by -SOME SERVICE-. So that way we'll only have important security prompts at important situations.

No, this is not the solution for most security-related problems, but it's a rough notion of the direction we should be heading at: create a system, any system, that allows the computer to stop asking (the home user) passwords all the time.

Poor Apps Make Standard User Impossible

The sad reality of the situation is it is IMPOSSIBLE to run as a non-admin and actually get anything done.

As a savvy PC user I tried to setup my XP system following best practices. Only run as admin when necessary. However, the two applications I use everyday make this impossible. Quicken and NewsBin Pro. Both of these applicatons require write access to their respective program files directories which forces you to run the application with elevated priviliges.

Until either application developers create proper software that actually obeys the security model or Microsoft enforces this policy then Windows users will always be admins.

LUA hahaha..

I've had the enjoyment of learning all about LUA about two months ago. A very umm.. textbook example of a small network -- Win2k3 server, WinXP Pro clients.

Needless to say, this was not even CLOSE to what a UNIX user account is like.

Few thoughts..

1. App compatibility - very annoying. While some apps are kind enough to out-right say they suck and are not compatible, there are LOTS of apps that fail in *silent* ways. Mostly writing to folders and registry w/o checking for access rights. There are many apps that attempt to write temporary files outside of user folders (ie the Program Files folder) or even store user prefs in the system registry.

2. Along with #1 -- there are many things INSIDE WinXP that fail. One very annoying example is msconfig .. it throws up a dialog after an admin does some changes but for a user and does not acknowledge the user's response (silently fails when writing to a system registry key). I have no idea why a user is prompted when an admin does a modification. Same thing with user defaults -- the system, even though it prompts to set a browser as default, silently fails when setting registry keys (again, not a user registry key). Apparently there is no way to adjust registry key security from a GPO or script to grant users this access (w/o going to each system manually)..

3. runas .. hehe.. that is so not even close to su/sudo -- while there appears to be lots of little workarounds (ie logging into administrative network shares of drives) its cumbersome and adds so much extra time to troubleshooting.

4. Fonts .. I really don't understand why users don't have their own fonts folder. I had to manually go into each computer, modify the registry to give permission to add fonts, adjust the fonts folder permissions, yada yada.. PITA. A user font folder (that follows them if roaming profiles is enabled) would have been a piece-of-cake while leaving the system font folder small and fast.

Why LUA didn't work for me

When I first installed Windows on my new system, I tried creating a seperate non-admin account that I'd use for my day-to-day computing. Shortly thereafter, I added it to the Administrators group because I just couldn't take it anymore.

Installing applications was mostly a non-issue, with Windows prompting me for my Administrator password when I tried to install something that needed Administrator permissions.

However, almost everything else was a giant pain in the ass. If I wanted to use any of the control panels, I either had to log out/log back in as Administrator, use Terminal Services to connect to localhost and log in as Administrator, create yet another shortcut to run it as Administrator, or use the runas command. None of those options are nearly as slick as Windows Installer asking me for my Administrator password. Why they couldn't use the same model is beyond me.

It's not only the control panels that I had problems with. If I wanted to use Windows Update, I had to be Administrator, and it gave me no easy way to become Administrator. If I wanted to develop and debug something in Visual Studio, I either had to be Administrator or be in the debuggers group, which essentially gives you free access to poke at the system any way you like. And of course, numerous applications and games have copy protection systems that require system drivers and services to work.

Of course, LUA doesn't do a damn thing against network-based attacks.

In the end, it's much easier to run as Administrator and drop priviledges when running certain applications.

Re:Duh

Close,

It's ignored because Windows was never designed with security in mind and grew to be the mess it is because that's the only way you can properly run Windows, as admin.

To come along much later and fix this, then blame the users is very poor on Microsoft's part.

closer still...

It's partially driven by software that won't install as a regular user (i can kinda live with that) and/or won't run as a regular user (unacceptable except for system utilities).

I can't even count right now how many clients I have running users with admin membership because of crappy software.

And the kicker is, it's not that hard a programming task to make software run in the regular user context! argh!

eric

Re:closer still...

Yeah? That's because Unix type systems have had multiple users since, well, ever.

You have to accept the fact that certian people shouldn't do certian things on computers.

The fas is that it should be dead simple for a grandma so able to do so, to install a card game in her home directory, without bothering anyone else on a system--a unix system. It goes there, and, what? There's no issue. Quake 3 has the ability to install into a non-root privlidged user's account. If grandma rm -rf /'s, she's only going to take her stuff out, and maybe other people who share her group.

In Windows land, that card game may well have a fit if it dosen't get installed to c:\program files\bullshit cards. If it dosen't work that way on any system, the program is b0rked. Written by an idjet. It dosen't help that MS has programmed people and software writers to behave this way since, well, ever.

****EVERY**** MS home directory should by default have a My Programs folder, and software installed by that user should end up there--unless it really, really does need administrator access, or it needs to be shared by multiple users. Otherwise, who cares if grandma installs bonsai buddy, it's only going to affect her account and not spread to administrator--where everything can be gleefully cleaned.

bah, I just ran out of mod points. :(

Mod that man up.

Intuit is criminal number 1 in this area (this month anyway, I have my targets change from time to time...)

Get this: The "enterprise" version of QuickBooks that will allow you to run in terminal services (gotta spend that extra cash to run the same software remotely you know!), requires that you have Power Users or Administrator priveleges.

Here's the catch however: I have a client running Small Business Server 2003, and they just went through a company restructuring where the CFO is going to be 200 miles away for the next few months, and needs to be able to hit QuickBooks from a terminal server session (yes, I know, VNC, PC Anywhere, bitmap pusher x..., work with me here though).

So, on an SBS, you can't have any trusts, no member servers (I might be wrong on that last one, apparently there'a hack that allows this, but again...), so the only server on the domain is the DC. You DC does not have "local" accounts and groups, only the AD users and groups. So a local power user doesn't exist. The only rights I can give them to be able to work is Admin.

The whole point of remote users is to.....access things remotely. You're requiring that every one of my users that wishes to use QuickBooks have Admin rights, and if they want to run in term serv, I have to allow dial in rights to that Admin account.

So I got on the phone with them. I suggested the following workaround:

"What if I just create a domain account, say ""QuickBooks User"". Set it to an obscenely secure password that no one but the admins could possibly know. Make it long, make it random, make it not-so-easy to remember. Grant that account Admin rights. Set Quickbooks to "Run As..." that user. Now Quickbooks gets the Admin privs it needs, but not the user."

After going through a supervisor, I was explained that this wouldn't work, and in fact they misconstrued it as an attempt on my part to subvert their licensing (because now I only have a single Quickbooks user, and we're supposed to pay per-seat for the license), and "Run As..." is intentionally broken to prevent this, along with the ability to run in Terminal Server if you haven't purchased the enterprise version.

Wow.

Cash more important than security.

Hey guys? What is so important at the system level that the *user* needs to make modifications to the OS? Why not store the data in the user's profile? Or in a shared directory with rights granted to the users in the "QuickBooks Users" group?

I just don't get it. :\

Re:Duh

I think you're over-simplifying this. The Windows NT kernel and core services were designed with security in mind. The real issue is that the shell, UI, and API's do a really poor job of enforcing and providing convenient access to that model. MS made a tough choice when they created they Win32 API; they kept developer compatability and convenience but made security a whole lot harder. There are too many default behaviors in Windows that are just dangerous.

Look how CreateProcess will progressively search for an executable at each space delimited chunk in an unquoted path; that makes a great trojan attack. Consider the shatter vulnerability and associated dangers that result from simple window input; that's why services have to be run on a seperate ACL'd desktop to be safe. Consider how trivially a power user can escalate to admin; look at how many apps need at least that privelege. Look how much code you have to write to set a simple multi-user DACL on an object.

The fact is that security is very hard to do properly in an MS environment, and historically MS has done a very poor job of promoting and simplifying it. I audit security software now, but when I wrote software I had a ton of homegrown libraries to handle things shouldn't have been necessary. So while I agree the tools are there, you almost have to be a security expert to use them properly.