One more bad thing in Windows 7 (installing under limited user accounts)

[baja_yu]

I've been testing an application and it's installer under various scenarios to make sure everything is running smoothly, regardless of user account type (standard/admin) or wether UAC is turned off or on.

The setup is this, Windows 7, two user accounts, let's say main (admin one) called TestA and a standard user account called TestS. Both accounts have no password set.

Installing on the admin account works ok regardless of UAC state (on/off), but... and this is a BIG but (which I like and I can't deny), this is how it goes on the standard account.

Case 1 - standard user account (TestS) - UAC on: started installer, got a modern looking Run As prompt, TestA account selected (showing it's picture even), asking for password. Since it's not set, clicked ok, process got elevated and the installer ran fine.

Case 2 - standard user account (TestS) - UAC off: started installer, got a classic, XP looking Run As screen. Instead of one field (to type password) there are now two (username and password) with "Administrator" pre-entered. Clicking OK, or entering TestA and clicking OK shows an error "...blank passwords are not allowd" but the account doesn't have one. So you can't install. Setting a password and entering it will work.

The conclusion is that when all security features (UAC and a password) are set, you can install, but when none are set, you can't. Seems logical, right?

[FireXtol]

I blame Balmer.

"It's just a phone. Not worth it." - Steve Jobs

[baja_yu]

I've submitted it to MSDN forums as well, hopefully some Apple (hater) Genius there will notice it and suggest (not to me but to MS developers) a fix.

[dilettante]

Haven't things been this way for some time?

Windows XP Baseline Security Checklists

User Account Passwords

To protect users who do not password-protect their accounts, Windows XP Professional accounts without passwords can be used only to log on at the physical computer console. By default, accounts with blank passwords can no longer be used to log on to the computer remotely over the network or for any other logon activity except at the main physical console logon screen. For example, you cannot use the secondary logon service (RunAs) to start a program as a local user with a blank password.

Assigning a password to a local account removes the restriction that prevents logging on over a network. It also permits that account to access any resources it is authorized to access, even over a network connection. As a result, it is better to leave a blank password assigned to an account rather than assigning a weak, easily guessed password. When assigning account passwords, make sure the password is at least nine characters long and that it includes at least one punctuation mark or non-printing ASCII character within the first seven characters.

[baja_yu]

Well it may have been, but now it seems there are two different overlaping methods. Like I pointed out, it acts differently if UAC is on. If it's on, you get one RunAs screen (new, modern one) that allows you to proceed without (with a blank) password. With UAC off it shows the old XP styled RunAs that doesn't.

[dilettante]

Well one is a UAC prompt for "over the shoulder elevation" while the other is a RunAs prompt. They probably come from two different pieces of software within Windows.

More than likely any future change would be to force a non-blank password for UAC prompts rather than the other way around.

[baja_yu]

Whatever their preferred policy is, I still think it's, at least an oversight on their part. UAC obviously provides you with a way around that limitation.

[dilettante]

I seriously doubt you'll see them change anything though. As the second paragraph I quoted states it can sometimes be better to leave a password blank. I doubt you'll find much sympathy for running with UAC turned off but you never know.

[baja_yu]

I've submitted my comments, plus your notes and link on the MSDN forums, maybe someone will read it, who knows.

http://social.msdn.microsoft.com/For...3-d3f89b50574c

It's not a very serious issue so I doubt it'll be high on their priority list. Thanks for your input.

[Nightwalker83]

Which version of Vista are you using?

[baja_yu]

Not Vista, W7.

[dilettante]

Well Win7 (Win 6.1) and Vista (6.0) do have some differences in the UAC area.

Testing on Vista would probably be smart. As of December 2009 Vista had around 18% of the desktop Windows market by one set of figures I saw. XP was already down to 2/3 of the installed and in-use market share.

That's 1/5 of the market and even if a ton of people installed Win7 over Vista there might be 1/6 of the machines running Vista yet. I seriously doubt the fraction has fallen that low. Most people won't see a reason to change until their next system purchase.

http://arstechnica.com/microsoft/new...kes-mac-os.ars

Before the end of 2010, we're expecting to see Windows 7 pass Windows Vista, Windows XP to drop below the 50 percent mark, and Mac OS X 10.6 to pass 10.5 and 10.4 combined.

Tune your crap-filter to eliminate Apple numbers. And as always Linux basically doesn't exist.

[baja_yu]

I don't have access to Vista at the moment but I'll try to whip one up in a VM these days and test too see what happens. Might be different since I think Vista's UAC is more strict than W7's.

[Nightwalker83]

Not Vista, W7.

Oops! Which, version of Win 7? Is this thread concerning installing applications you create on Win 7 or apps in general? I tried what you were talking about in the first post on my Win 7 laptop but on the normal user account whenever I tried to change settings, etc it would stop me saying I must be an administrator. Further more when I click "Change User Account Control settings" on the normal account nothing happens.

[baja_yu]

That's correct. A standard user can't change UAC settings, only an admin can, so you have to do it from the admin account first, and the setting is system wide, you can't set it differently for each user (I'm not sure if you can with two admin accounts, but with one admin one standard that's how it works).

It's W7 Ultimate. I was testing an installer for an application I made in VB6. Installer was done in NSIS. But the behavior (problem on standard account, UAC off) is true for any installer.

[Nightwalker83]

That's correct. A standard user can't change UAC settings, only an admin can, so you have to do it from the admin account first, and the setting is system wide, you can't set it differently for each user (I'm not sure if you can with two admin accounts, but with one admin one standard that's how it works).

Weird! I set the UAC to the lowest setting then switched to the standard account to try and install a program and received this message:

You don't have access to write to the installation directory.

Click Ok to select a different directory.

However, when I choose a different directory say "Desktop" it install fine. When I installed a program I created in VB6.0 under the standard account I was prompted to log-in to the administrator account. However, I was unable install the program without any problems.

It's W7 Ultimate. I was testing an installer for an application I made in VB6. Installer was done in NSIS. But the behavior (problem on standard account, UAC off) is true for any installer.

The version on my laptop is Win 7 Professional.

Edit:

Sometimes I receive this message when trying to install software under a normal account whereas other times a don't.

You must be logged in as an administrator or a member of the Power Users group when installing this program.

However no password dialog box appears so I can enter my admin username and password like I did above.

[baja_yu]

I get the dialog to enter admin username and password too. The problem is that when UAC is off, and the admin account does not have a password, it will not allow you to use it (reason explained in post #4), but when UAC is on (and you install under a standard account) you don't get the prompt to enter username and password (RunAs prompt) but you get an UAC prompt, which only asks for password, and allows the use of a blank password admin account, effectively getting around the security limitation explained in post #4/

[Nightwalker83]

I just tried it and it works!

Edit:

However, how many businesses would be lacks enough not to have passwords on their admin accounts?

[FireXtol]

I just tried it and it works!

Edit:

However, how many businesses would be lacks enough not to have passwords on their admin accounts?

Depends if the computer is connected to their network. Often you can simply unplug the Ethernet(disabling network login), reboot the machine(for the setting to take effect), and Administrator with a blank password gets you in!

@dilettante: I highly doubt XP will drop below 50% this year(depending on 'who' you ask). If past trends are any measure for future projections then XP will be relevant for several more years -minimally.

Vista will likely be irrelevant in a couple years(if not already). According to many sources(like Visual Studio magazine) Vista's market share has already fallen behind 7's(though their numbers are for businesses, and their methodology is probably better than a lot of 'web statistics').