How do I bring up the Administrator Command Prompt?

[Guest]

I tried to adapt my XP defrag script to Vista x64 RC1, but I ran into a snag.

When I execute the defrag command I get a nice message (below) that I need
to elevate my privs to run the defrag.exe cmd.
______________________________________________________________
C:\Windows\System32>defrag c:

This program needs to run with administrative permissions. Use an
administrator
command prompt and then run the program again.
______________________________________________________________

So, I searched help and no reference to the Admin Cmd Prompt.

My account has admin level privs, but this is apparently not enough, so how
does one elevate the command line privileges to Administrator? Are we talking
a runas cmd.exe?

I've only had Vista on the system for 2 days, so please don't crucify me for
posting a n00b question.


--
Good Sites to know:
http://www.sysinternals.com
http://www.eventid.net
http://www.microsoft.com/technet
http://www.isaserver.org
http://www.nu2.nu/pebuilder

 

[Jimmy Brush]

Hello,

In Windows Vista, even though you have administrator privileges, the
programs you run only receive "standard user" permissions, unless they
automatically ask you for permission ("Windows needs your permission to
continue") or you explicitly give them such permision (right-click on them
and click Run As Administrator).

This is technically different that the runas command when logged into an
administrative account - when you right-click and click Run As
Administrator, the program runs inside of your user profile with your admin
powers. However, using runas, the program will run under a different user
profile.

I do not believe there is a command-prompt equivalent to right-click and
click run as administrator.

A shortcut you can use:

- click start
- type: cmd
- press the right-ctrl, right-shift, and enter at the same time

This will do the same thing as right-click cmd.exe and clicking run as
administrator. It will work for any exe that you type into the start search
bar.

 

[Frank Saunders, MS-MVP OE/WM]

I tried to adapt my XP defrag script to Vista x64 RC1, but I ran into a
snag.

When I execute the defrag command I get a nice message (below) that I need
to elevate my privs to run the defrag.exe cmd.
______________________________________________________________
C:\Windows\System32>defrag c:

This program needs to run with administrative permissions. Use an
administrator
command prompt and then run the program again.
______________________________________________________________

So, I searched help and no reference to the Admin Cmd Prompt.

My account has admin level privs, but this is apparently not enough, so
how
does one elevate the command line privileges to Administrator? Are we
talking
a runas cmd.exe?

I've only had Vista on the system for 2 days, so please don't crucify me
for
posting a n00b question.

Start | All Programs | Accessories
Right click the Command Prompt and choose Run as Administrator.

 

[Guest]

All good information and very appreciated, but I'm still unclear on one
point. If I schedule this cmd file using Task Scheduler - will the task
scheduler automatically run the program with administrator privs, or will I
just see a runas prompt when the task executes? Can I schedule this task
using my own Account, or do I now have to schedule it using the local admin
acct?

I will try it when I'm home from work tonight, and post my results.

Thanks,

--
Good Sites to know:
http://www.sysinternals.com
http://www.eventid.net
http://www.microsoft.com/technet
http://www.isaserver.org
http://www.nu2.nu/pebuilder

 

[Jimmy Brush]

The task will be run just as if you had ran it inside your user account -
i.e. it will run with restricted privileges. You will need to set the task
to run in the context of one of the system accounts in order for it to work
properly. When this is the case, you will not be able to "see" the command
executing - it will not be associated with the visible desktop.

I am unsure of the behavior if you set the task to run in the context of the
built-in administrator or any other administrator for that matter.

 

[Gerry Hickman]

Start | All Programs | Accessories
Right click the Command Prompt and choose Run as Administrator.

If he does that, which user profile will the task run within?

 

[Jimmy Brush]

If you are logged in as a user that is a member of the administrators group,
the command prompt will be running from the currently logged in user's
profile.

However, if you are logged in as a "normal user", the command prompt will
run from the user profile of whomever authenticated into the UAC dialog box.

 

[Ben Miller]

If you are looking to add this to a script this might help:

runas /user:administrator cmd

You can replace the cmd with the batch file or vbs script or whatever app
you intend to run with administrative credentials.

Hope this helps!

-Ben

______________
Ben Miller
CISSP
GSEC
Security+

 

[Jimmy Brush]

Unfortunately, this would not work out-of-the-box as the administrator
account is disabled by default.

Also, this does not exactly reproduce the behavior of the UAC "elevation"
sequence - this would always run the program from the user profile of the
"administrator" account, whereas UAC elevation runs the program from the
currently logged-in administrator account (assuming the logged-in user is an
administrator).

However, if the administrator account has been manually enabled and one
doesn't mind the application running from the profile of the administrator
account, this is a good alternative

 

[Gerry Hickman]

Hi Jimmy,

You make a good explanation below and you are right to point out the
issues, but some of us need to run unattended scripts overnight and we
don't allow our users to have Admin rights. In this context, the only
sensible option (I can see) is to enable the real Administrator (or a
clone) and disable UAC.

I can only understand UAC in the context of the home user. I don't see
how it's supposed to help with overnight unattended installations and
change and configuration management?

In the context of the home user it seems a terrible idea to me; it's
effectively letting them still run as Administrator but they have to
keep clicking "OK"? They'll just get used to saying "OK" then when they
get a job in a corporation, they'll still keep saying "OK"? What does it
achieve?

 

[Jimmy Brush]

You make a good explanation below and you are right to point out the

issues, but some of us need to run unattended scripts overnight and we
don't allow our users to have Admin rights. In this context, the only
sensible option (I can see) is to enable the real Administrator (or a
clone) and disable UAC.

You can use scheduled tasks to allow processes (such as your script) to
automatically run in the context of another user or the system, with admin
rights, and without prompting the currently logged-on user for permission.

I can only understand UAC in the context of the home user. I don't see how
it's supposed to help with overnight unattended installations and change
and configuration management?

You may have to do some things differently than before . There are
mechanisms that allow an administrator to "bless" MSI files that will allow
them to install without prompting the local user for permission; also, you
can use scheduled tasks to run admin procedures on boxes that are invisible
to the user and do not prompt the user for permission.

In the context of the home user it seems a terrible idea to me; it's
effectively letting them still run as Administrator but they have to keep
clicking "OK"? They'll just get used to saying "OK" then when they get a
job in a corporation, they'll still keep saying "OK"? What does it
achieve?

For the home user:

With UAC enabled, even though they are an "administrator", all the programs
that run on their computer are running as if they were a limited user,
including the windows shell. Only programs that the user explicitly
authorizes get admin privileges.

This achieves many things:

* The UI and the majority of programs are running with restricted
privileges. If these programs have a security vulnerability, the potential
damage they can do is severely limited. The attack surface for the default
installation of Windows just went down considerably.

* Programs that DO require admin privileges must prompt the user for
permission. Developers don't want their program to do this. Thus, they will
try to develop their programs as to not requrie admin privileges, unless
they really need it, and if they do need it, they will try to limit its use.
This will finally force software developers to adhere to Microsoft's
programming guidelines, making for more secure (and hopefully less buggy)
software. Gone are the days where programs always assume they have admin
privileges.

* UAC allows other features to work, such as Internet Explorer Protected
Mode and the "hard" separation between programs running as admin and
programs not running as admin. This privilege seperation reduces the attack
surface by making it much more difficult for a lower-privilged program to
escalate its privileges.

The user gets these benefits even if they click CONTINUE on every screen
that asks them for permission. This, by itself, is LIGHT YEARS ahead of XP
security-wise.

* The user can discriminate as to what programs receive admin permissions.
Granted, it is still up in the air as to how many users will proactively
take advantage of this power; personally, I think this will be more
effective than everyone seems to think; time will tell, though.