Re: Vista/7 permissions for script?

Tech-Archive recommends: Fix windows errors by optimizing your registry

I found this thread very interesting. I've had a Vista system since shortly
after it came out, but haven't used it much. I've been hoping someone would
do an analysis like you have done in this post because there were just too
many variables for me to handle. I'm thinking that the various versions of
Vista would also have to be taken into account. When I was thinking about
how to do the analysis, I thought that only Vista Ultimate shipped with all
the tools to allow playing with the parameters involved. My cheaper Vista
didn't have these tools, and Vista's terrible search tool made it too
frustrating to find out what was actually there.

I guess I'd like to see a table of your info, for all the classes of users,
with UAC on and off, and with no, one of some or all users needing to supply
a password to log on, etc, etc, etc. You haven't mentioned the "Installer"
user who has special right on my system. I don't know what 'built-in' users
are HP's creation and which are Microsoft's creation. Too bad I don't know
Installer's password. I Ghosted the hard drive of my Compaq Vista system
before its first boot, so I can truely get back to its as-shipped condition.
I'm amazed at the amount of scripting stuff in the system, most of it in
Python. I assume the first boot environment is Windows PE, and a person
could mess with that preboot system to make it more to his liking. I was
never able to successfully do that first boot when I restored the Ghost
image's boot partition to a larger partition in a larger hard drive -- it
always had to be the same size boot partition. Since my cheapo system came
with a 160GB hard drive, I'm limited by that primary partition size no
matter how large a drive I restore to. The rest of the drive is accessible
as additional partitions.

-Paul Randall

"mayayana" <mayaXXyana@xxxxxxxxx> wrote in message
news:eteToEd2JHA.1092@xxxxxxxxxxxxxxxxxxxxxxx
There doesn't seem to be much interest in this
topic. Maybe most people here are already using
Vista/7 and have come up with their own solutions.

TWIMC, I did some experimenting in order to work
out the details for myself. I found the following on
Win7, running a script that writes to HKLM and an
HTA that uses WMI to change services:

There seem to be 3 types of accounts:

- The real administrator.
- The fake administrator, which is the account
given to the person installing the system.
- "users"

The difference between a fake admin. and a "user"
seems to be that a fake admin. is given the chance
to elevate permissions *if a process has a manifest
that requests such elevation*, while a common user
is just blocked from actions that require permissions.
(And the fake admin. can also choose to elevate
permissions when starting some processes, though
HTAs are not in that category.)

As a "fake" Administrator, under normal
conditions, both the script and the HTA fail
without showing a UAC prompt, regardless of
UAC settings.

As the real Administrator both the script and
the HTA work without problem.

A fake Administrator can be converted to a
real Administrator by entering the following into
the Run box and clicking OK:

Net user administrator activate:yes

Note that this change seems to be permanent but does
not take effect until the next full reboot. A logoff won't
do it. The change can be reversed with:

Net user administrator activate:no

If your fake admin. account has a password you may need
to run this command from elevated cmd.exe so that you
can first enter your password:

Net user administrator [password]
Net user administrator activate:yes

As far as I can see, for anyone who wants to use scripts
freely, using HTAs, drag-drop scripts, etc. -- in other words,
for people who want to do more than only running scripts
from an elevated console window -- real admin. rights are
indispensible.

Using the above command to convert a fake
admin to a real admin also has another advantage:
The real admin account seems to be rigged so as
not to work without a password. Fake admin
accounts, on the other hand, are password-optional.
So converting a fake admin to real allows one to
log on as a real admin without necessarily needing
to use a logon password.


.