Microsoft Windows Vista Community Forums - Vistaheads
Recommended Download



Welcome to the Microsoft Windows Vista Community Forums - Vistaheads, YOUR Largest Resource for Windows Vista related information.

You are currently viewing our boards as a guest which gives you limited access to view most discussions and access our other features. By joining our free community you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is fast, simple and absolutely free so , join our community today!

If you have any problems with the registration process or your account login, please contact us.

Driver Scanner

Re: Built-in admin account

microsoft.public.windows.vista.security






Speedup My PC
Reply
  #1 (permalink)  
Old 12-29-2006
David W. Fenton
 

Posts: n/a
Re: Built-in admin account
"Richard G. Harper" <rgharper@email.com> wrote in
news:es7YLQ9DHHA.3228@TK2MSFTNGP03.phx.gbl:

> As developers, programmers and corporations get their stuff in a
> bag, there will be less need for elevation than before. But for
> now, it's nearly essential.


I'm afraid I simply don't believe this. There are still programs
(like QuickBooks) that require admin permissions on Win2K and WinXP,
and Intuit has had since 1999 to fix that. They just refuse to do
it. And that's far from the only such application.

If you really think that software developers will adapt to UAC, then
I wonder how you explain the fact that so many of them never adapted
to *not* running as admin on older versions of Windows? This has
been the bane of my existence as a system admin for small
businesses.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Reply With Quote
Sponsored Links
  #2 (permalink)  
Old 12-30-2006
Jimmy Brush
 

Posts: n/a
Re: Built-in admin account
Hello,

<snip>
> If you really think that software developers will adapt to UAC, then
> I wonder how you explain the fact that so many of them never adapted
> to *not* running as admin on older versions of Windows?


Reason's simple ... before, developers could assume the user had admin
privileges with limited consequences - a few users (proportionally speaking,
of course) who were in the minority would have problems, but most users out
there would have no problems.

Now, most users are running inside of a UAC enviornment - they are now the
majority. Developers tend to program for the majority. Microsoft has
essentially turned the tables, and is using this fact to force them to
update their applications. Unless developers want to inconvienence their
customers by forcing them to click on a prompt every time their applications
starts (and they won't do this unless absolutely necessary), they will
change their program.

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/

Reply With Quote
  #3 (permalink)  
Old 12-31-2006
David W. Fenton
 

Posts: n/a
Re: Built-in admin account
"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in
news:14BEC911-DD02-4B0E-B6EE-9736188B73FC@microsoft.com:

><snip>
>> If you really think that software developers will adapt to UAC,
>> then I wonder how you explain the fact that so many of them never
>> adapted to *not* running as admin on older versions of Windows?

>
> Reason's simple ... before, developers could assume the user had
> admin privileges with limited consequences


Why in the world would developers have assumed that? The only reason
I know that anyone sets up users as admins is because of the fact
that developers assume that users are set up as admins. If the
software developers did their job properly, nobody would have to run
as admins.

- a few users (proportionally speaking,
> of course) who were in the minority would have problems, but most
> users out there would have no problems.


Depends on what software you're running.

> Now, most users are running inside of a UAC enviornment - they are
> now the majority.


Huh? How in the world can most people be running in a UAC
environment when Vista has just been released?

> Developers tend to program for the majority.


Then they should design their programs to *run* LUA. Installation is
a different matter, of course.

> Microsoft has
> essentially turned the tables, and is using this fact to force
> them to update their applications. Unless developers want to
> inconvienence their customers by forcing them to click on a prompt
> every time their applications starts (and they won't do this
> unless absolutely necessary), they will change their program.


Well, sure, but the locked down C: drive of Win2K didn't change
their habits, so why will UAC change them now? To me, it seems like
UAC just makes it *safe* to run as admin, rather than making it more
attractive to engineer your apps to run LUA.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Reply With Quote
  #4 (permalink)  
Old 12-31-2006
David J. Craig
 

Posts: n/a
Re: Built-in admin account
It is about time that developers finally created applications that do not
require admin access. If the free software folks can do it and have been
doing it for years, why does it take so long? Many Microsoft programs
require admin access, though newer versions may be better. I do know that
most of their developer tools needed it far too frequently. CD/DVD burning
software is another application category that needs it. There used to be a
fairly standard interface called ASPI but it hasn't been shipped with
Windows for a long time. That allowed any application to obtain access to a
device handle to CD & DVD drives while running in normal user mode. There
were some bugs where access to hard drives could be had and that was a
problem, but fixing it and publishing it would make it easier. Now almost
all burning software has to have a driver that can provide access to the
optical drives. Each one is unique and the API is not standard.

Let us hope that the new push towards UAC and everyone running in user mode
takes hold. I see far too many posts from those who just disable UAC and
think that is a good thing. My only question for them is why not keep using
XP. That would make sense. You can create a manifest for an existing
program that will identify its admin requirements and just use UAC.
Somewhat of a pain, but just like Linux when you run Yast it always requires
the root password.

"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in message
news:14BEC911-DD02-4B0E-B6EE-9736188B73FC@microsoft.com...
> Hello,
>
> <snip>
>> If you really think that software developers will adapt to UAC, then
>> I wonder how you explain the fact that so many of them never adapted
>> to *not* running as admin on older versions of Windows?

>
> Reason's simple ... before, developers could assume the user had admin
> privileges with limited consequences - a few users (proportionally
> speaking, of course) who were in the minority would have problems, but
> most users out there would have no problems.
>
> Now, most users are running inside of a UAC enviornment - they are now the
> majority. Developers tend to program for the majority. Microsoft has
> essentially turned the tables, and is using this fact to force them to
> update their applications. Unless developers want to inconvienence their
> customers by forcing them to click on a prompt every time their
> applications starts (and they won't do this unless absolutely necessary),
> they will change their program.
>
> --
> - JB
>
> Windows Vista Support Faq
> http://www.jimmah.com/vista/



Reply With Quote
  #5 (permalink)  
Old 12-31-2006
Jimmy Brush
 

Posts: n/a
Re: Built-in admin account
>> Reason's simple ... before, developers could assume the user had
>> admin privileges with limited consequences

>
> Why in the world would developers have assumed that?


Because that was the truth - the majority of windows users operated their
computer within an administrator account. I'm definately not saying that's
the right way for the developer to look at things, but that was the cold,
hard reality.

> The only reason
> I know that anyone sets up users as admins is because of the fact
> that developers assume that users are set up as admins.


Perhaps in a locked-down business world this is the case. However, things
are different in the consumer world. From the point of view of a software
developer, if they weren't specifically targeting customers using a
least-privileged enviornment, I can easily see why they wouldn't care if
their app didn't work 100% in a least-privilege environment [although I
don't agree with this behavior].

> If the
> software developers did their job properly, nobody would have to run
> as admins.


Agreed.

This is kind of a chicken-and-the-egg problem. Developers won't program
software for non-admins until most people run as non-admins. People won't
run as non-admins until developers program for non-admins. Deadlock!

UAC solves this problem by making the majority of users run as both admin
and non-admin, with non-admin being default, and the transition into admin
mode undesirable from the viewpoint of the software developer.

>> - a few users (proportionally speaking,
>> of course) who were in the minority would have problems, but most
>> users out there would have no problems.

>
> Depends on what software you're running.


Well, actually the statement I made here depends on the market for a
software applicaton. My point here was that if a developer knows that their
user is running as an administrator [majority of cases for most markets
pre-Vista] then they have less motivation for making sure their app works
right in the minority case where their user is in a least-privileged
environment.

>> Now, most users are running inside of a UAC enviornment - they are
>> now the majority.

>
> Huh? How in the world can most people be running in a UAC
> environment when Vista has just been released?


I was speaking in abstract terms here. If a developer is writing an
application for Vista, then they must assume that the user will be in a
UAC-protected environment, since that is the default case.

>> Developers tend to program for the majority.

>
> Then they should design their programs to *run* LUA. Installation is
> a different matter, of course.


That's my point - thanks to UAC, they have a very strong motivation to do
this .

>> Microsoft has
>> essentially turned the tables, and is using this fact to force
>> them to update their applications. Unless developers want to
>> inconvienence their customers by forcing them to click on a prompt
>> every time their applications starts (and they won't do this
>> unless absolutely necessary), they will change their program.

>
> Well, sure, but the locked down C: drive of Win2K didn't change
> their habits, so why will UAC change them now? To me, it seems like
> UAC just makes it *safe* to run as admin, rather than making it more
> attractive to engineer your apps to run LUA.


In Vista, developers must either re-engineer the app to be LUA, or require
the user to click a prompt every time the app is run. Before, there was no
"down-side" to not engineering for a LUA environment for the general case
[where the user is an admin]; now, there is.

> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/



--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/

Reply With Quote
  #6 (permalink)  
Old 12-31-2006
David W. Fenton
 

Posts: n/a
Re: Built-in admin account
"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in
news:527387BD-7E31-4B59-98DE-C6A308081850@microsoft.com:

>>> Reason's simple ... before, developers could assume the user had
>>> admin privileges with limited consequences

>>
>> Why in the world would developers have assumed that?

>
> Because that was the truth - the majority of windows users
> operated their computer within an administrator account. I'm
> definately not saying that's the right way for the developer to
> look at things, but that was the cold, hard reality.


That's a chicken and egg problem, seems to me. Yes, Microsoft's
setup routines encouraged setting up as an admin user, but that was
because it was the only practical way for MS to accomodate
developers that weren't adjusting their installers to run properly.
In the beginning, I guess it was a matter of accomodating legacy
software, but frankly, most legacy software runs pretty well under a
user-level logon.

>> The only reason
>> I know that anyone sets up users as admins is because of the fact
>> that developers assume that users are set up as admins.

>
> Perhaps in a locked-down business world this is the case. However,
> things are different in the consumer world.


Oh, puh-leaze. I am a computer consultant who works for
microbusinesses and individuals, and none of them have any problems
running as user-level logons. Of course, they wouldn't do that if I
hadn't set up their PCs properly.

> From the point of view of a software
> developer, if they weren't specifically targeting customers using
> a least-privileged enviornment, I can easily see why they wouldn't
> care if their app didn't work 100% in a least-privilege
> environment [although I don't agree with this behavior].


That's a ridiculous attitude on the part of any software maker. By
not handling it, they are buying themselves customer support
problems the come with the incompatibilities. "Run as an admin" is
not a proper answer, but for some reason, the industry has let them
get away with it.

>> If the
>> software developers did their job properly, nobody would have to
>> run as admins.

>
> Agreed.
>
> This is kind of a chicken-and-the-egg problem. Developers won't
> program software for non-admins until most people run as
> non-admins.


That's a STUPID attitude. The whole point of the MSI was to handle
the locked-down system drive and system folders. That was the point
at which all developers should have redesigned their apps to run in
LUA environments.

> People won't
> run as non-admins until developers program for non-admins.
> Deadlock!


My clients are running LUA in domain-free environments. There are
only a small number of apps that have required one-time registry
permission tweaks to get them to run.

> UAC solves this problem by making the majority of users run as
> both admin and non-admin, with non-admin being default, and the
> transition into admin mode undesirable from the viewpoint of the
> software developer.


No, admin is the default for the user logon, but the applications
launch by default without full admin permissions. It's a backwards
way of doing it, seems to me -- run as admin all the time, but don't
actually give administrative permissions to the processes launched.

>>> - a few users (proportionally speaking,
>>> of course) who were in the minority would have problems, but
>>> most users out there would have no problems.

>>
>> Depends on what software you're running.

>
> Well, actually the statement I made here depends on the market for
> a software applicaton.


What's the justification for Quickbooks needing admin permission?
Ever tried to run it on a Terminal Server?

> My point here was that if a developer knows that their
> user is running as an administrator [majority of cases for most
> markets pre-Vista]


And, of course, the reason why there are millions of zombie PCs out
their pumping out spam...

> then they have less motivation for making sure their app works
> right in the minority case where their user is in a
> least-privileged environment.


Seems to me that "less motivation" = too lazy to bother.

>>> Now, most users are running inside of a UAC enviornment - they
>>> are now the majority.

>>
>> Huh? How in the world can most people be running in a UAC
>> environment when Vista has just been released?

>
> I was speaking in abstract terms here. If a developer is writing
> an application for Vista, then they must assume that the user will
> be in a UAC-protected environment, since that is the default case.


But they don't have to do *anything* -- UAC handles it for them
(though in a way that may annoy the user).

>>> Developers tend to program for the majority.

>>
>> Then they should design their programs to *run* LUA. Installation
>> is a different matter, of course.

>
> That's my point - thanks to UAC, they have a very strong
> motivation to do this .


To me it seems that UAC will relieve them of any responsibility to
bother one way or the other.

>>> Microsoft has
>>> essentially turned the tables, and is using this fact to force
>>> them to update their applications. Unless developers want to
>>> inconvienence their customers by forcing them to click on a
>>> prompt every time their applications starts (and they won't do
>>> this unless absolutely necessary), they will change their
>>> program.

>>
>> Well, sure, but the locked down C: drive of Win2K didn't change
>> their habits, so why will UAC change them now? To me, it seems
>> like UAC just makes it *safe* to run as admin, rather than making
>> it more attractive to engineer your apps to run LUA.

>
> In Vista, developers must either re-engineer the app to be LUA, or
> require the user to click a prompt every time the app is run.
> Before, there was no "down-side" to not engineering for a LUA
> environment for the general case [where the user is an admin];
> now, there is.


Is it really *every single time*? That's one I didn't quite grasp, I
guess.

It has annoyed me for years and years and years (since the
introduction of Win2K) that apps supposedly developed to run on the
latest NT-based version of Windows were not LUA-compatible. And I've
never understood why any number of sysadmins I know of run their
desktops in a domain environment with local admin logons. How can
people in this day and age be so completely ignorant of the security
problems this creates? And, last of all, I blame MS for having made
machine setup default to an admin logon (with no password, and no
logon prompt). If MS had defaulted to LUA, then this problem would
have been solved a long, long time ago.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Reply With Quote
  #7 (permalink)  
Old 12-31-2006
David W. Fenton
 

Posts: n/a
Re: Built-in admin account
"David J. Craig" <Dave@yoshimuni.com> wrote in
news:O0S0m1HLHHA.3268@TK2MSFTNGP04.phx.gbl:

> Let us hope that the new push towards UAC and everyone running in
> user mode takes hold.


Perhaps I've misunderstood UAC, but I think what it does is allow
people to run as admin more safely, by only handing out the admin
credentials when the user has explicitly authorized it.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Reply With Quote
  #8 (permalink)  
Old 12-31-2006
Jimmy Brush
 

Posts: n/a
Re: Built-in admin account
<snip>
>> Perhaps in a locked-down business world this is the case. However,
>> things are different in the consumer world.

>
> Oh, puh-leaze. I am a computer consultant who works for
> microbusinesses and individuals, and none of them have any problems
> running as user-level logons.


I wasn't commenting here on whether one would have problems running as a
standard user.

> Of course, they wouldn't do that if I
> hadn't set up their PCs properly.


Aha! My point!

>> From the point of view of a software
>> developer, if they weren't specifically targeting customers using
>> a least-privileged enviornment, I can easily see why they wouldn't
>> care if their app didn't work 100% in a least-privilege
>> environment [although I don't agree with this behavior].

>
> That's a ridiculous attitude on the part of any software maker. By
> not handling it, they are buying themselves customer support
> problems the come with the incompatibilities. "Run as an admin" is
> not a proper answer, but for some reason, the industry has let them
> get away with it.
>


Agreed.

<snip>
>> This is kind of a chicken-and-the-egg problem. Developers won't
>> program software for non-admins until most people run as
>> non-admins.

>
> That's a STUPID attitude.


Agreed.

>> People won't
>> run as non-admins until developers program for non-admins.
>> Deadlock!

>
> My clients are running LUA in domain-free environments. There are
> only a small number of apps that have required one-time registry
> permission tweaks to get them to run.


By "people" I am referring to the majority of windows users, not you or your
clients .

>> UAC solves this problem by making the majority of users run as
>> both admin and non-admin, with non-admin being default, and the
>> transition into admin mode undesirable from the viewpoint of the
>> software developer.

>
> No, admin is the default for the user logon, but the applications
> launch by default without full admin permissions. It's a backwards
> way of doing it, seems to me -- run as admin all the time, but don't
> actually give administrative permissions to the processes launched.


Yeah, it seemed backwards to me at first as well... but the more I thought
about it, the more it made sense to me. If I am really an administrator, why
should I have to have a seperate limited user account for security reasons?
Why shouldn't I be able to control the privileges of applications I run from
a single account?

>>>> - a few users (proportionally speaking,
>>>> of course) who were in the minority would have problems, but
>>>> most users out there would have no problems.
>>>
>>> Depends on what software you're running.

>>
>> Well, actually the statement I made here depends on the market for
>> a software applicaton.

>
> What's the justification for Quickbooks needing admin permission?
> Ever tried to run it on a Terminal Server?


Right ... this is the "minority" of users with problems that I was talking
about. I imagine the justification would go something like "why should we
spend resources making these 'niche' scenarios work correctly when we could
be fixing bugs/refining/adding features that many more people will see and
use?"

>> My point here was that if a developer knows that their
>> user is running as an administrator [majority of cases for most
>> markets pre-Vista]

>
> And, of course, the reason why there are millions of zombie PCs out
> their pumping out spam...


True.

>> then they have less motivation for making sure their app works
>> right in the minority case where their user is in a
>> least-privileged environment.

>
> Seems to me that "less motivation" = too lazy to bother.


LOL.

>>>> Now, most users are running inside of a UAC enviornment - they
>>>> are now the majority.
>>>
>>> Huh? How in the world can most people be running in a UAC
>>> environment when Vista has just been released?

>>
>> I was speaking in abstract terms here. If a developer is writing
>> an application for Vista, then they must assume that the user will
>> be in a UAC-protected environment, since that is the default case.

>
> But they don't have to do *anything* -- UAC handles it for them
> (though in a way that may annoy the user).


No, UAC does not handle anything for them [unless they decide to live with
forcing the user to approve their application to run whenever it starts, and
I just don't see any developer wanting that unless they are developing an
administrative program where this would be normal and acceptable].

UAC is just the means by which the system prompts the user if they want to
run a program with admin privileges. It is NOT automatic - an application
has to request this dialog to be shown WHEN IT STARTS. A process (or com
component) either receives admin privileges or it doesn't. If an app/com
component w/out admin privileges attempts to do an admin operation and it
has not been elevated via UAC, the operation will fail.

If a developer wants their program to run correctly without displaying a UAC
prompt, it will have to be programmed to work correctly as a standard user -
just like if they wanted it to work correctly in XP as a standard user.

There are a few "hacks" that UAC does for legacy XP apps in order to get
them to work, but they are not desirable as they can silently fail in some
pretty nasty ways.

>> That's my point - thanks to UAC, they have a very strong
>> motivation to do this .

>
> To me it seems that UAC will relieve them of any responsibility to
> bother one way or the other.


No ... if an app wants to use admin power, they will have to get the user's
permission when the program starts. If an app doesn't want to throw a
permission prompt, it must be designed to work under a standard user
account, otherwise it will fail.

UAC is forcing them to make their apps work under a standard user account to
avoid prompting the user every time their application starts.

This will force developers to only use admin power when absolutely
necessary, because they will not want their application prompting the user.

<snip>
> It has annoyed me for years and years and years (since the
> introduction of Win2K) that apps supposedly developed to run on the
> latest NT-based version of Windows were not LUA-compatible. And I've
> never understood why any number of sysadmins I know of run their
> desktops in a domain environment with local admin logons. How can
> people in this day and age be so completely ignorant of the security
> problems this creates? And, last of all, I blame MS for having made
> machine setup default to an admin logon (with no password, and no
> logon prompt). If MS had defaulted to LUA, then this problem would
> have been solved a long, long time ago.


I agree with you, but I see UAC as something better than the traditional
"this is my standard user account and this is my admin account" approach.

I see UAC as fleshing out answers to some more fundamental questions: Why do
programs that don't need X privileges receive X privileges? My user account
grants me X privileges ... why can't I (or my administrator) set policy
describing which applications I can use my privileges with? Why must I have
more than one user account in order to have a secure system, when I am
really only a single user? Does that really make sense?

> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/


Happy New Year!
*throws confetti*

--
- JB

Windows Vista Support Faq
http://www.jimmah.com/vista/

Reply With Quote
  #9 (permalink)  
Old 01-02-2007
David W. Fenton
 

Posts: n/a
Re: Built-in admin account
"Jimmy Brush" <JimmyBrush@discussions.microsoft.com> wrote in
news:CA1D6324-2587-4484-AA64-A5A8ED6BF25D@microsoft.com: [me:]
>> It has annoyed me for years and years and years (since the
>> introduction of Win2K) that apps supposedly developed to run on
>> the latest NT-based version of Windows were not LUA-compatible.
>> And I've never understood why any number of sysadmins I know of
>> run their desktops in a domain environment with local admin
>> logons. How can people in this day and age be so completely
>> ignorant of the security problems this creates? And, last of all,
>> I blame MS for having made machine setup default to an admin
>> logon (with no password, and no logon prompt). If MS had
>> defaulted to LUA, then this problem would have been solved a
>> long, long time ago.

>
> I agree with you, but I see UAC as something better than the
> traditional "this is my standard user account and this is my admin
> account" approach.


I agree that UAC is good, but it's good points have virtually
nothing to do with the problem of apps that are written to require
full admin permissions.

> I see UAC as fleshing out answers to some more fundamental
> questions: Why do programs that don't need X privileges receive X
> privileges? My user account grants me X privileges ... why can't I
> (or my administrator) set policy describing which applications I
> can use my privileges with? Why must I have more than one user
> account in order to have a secure system, when I am really only a
> single user? Does that really make sense?


Absolutely. UAC allows those who really need to run as admin to be
able to do it safely. For users who have no need for that (which
ought to be MOST USERS), it really shouldn't be adding anything new.

I have worked at a number of companies with domain controllers and
all the users logged on with user-level permissions (with the
exception of QuickBooks users!). I really think it's only home users
and small businesses without proper system administration who are
running as admins.

If UAC forces software makers to fix what they've been doing wrong
since 1999, then that's great. But I see that as only a side effect
of the design of UAC, not its chief purpose.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
Reply With Quote
  #10 (permalink)  
Old 01-11-2007
Jimmy Brush
 

Posts: n/a
Re: Built-in admin account
<snip>
> I agree that UAC is good, but it's good points have virtually
> nothing to do with the problem of apps that are written to require
> full admin permissions.


In the context of apps that *should not* need admin permission but require
it anyway, I disagree - UAC is designed to deal with these apps, by both
working around legacy apps that do this (virtualization) and making it much
more painful for developers to create such programs.

Granted, UAC does, in fact, allow programs to be written to require full
admin permission, and so one can say that it doesn't "concretely" solve this
problem; however, I think the reality of how an application runs with full
admin under UAC cannot be ignored, and will indeed be a major motivation for
devs to write software with least privilege.

However, in the case of actual admin apps requiring "an administrator" to
run them, you make an excellent point [and I have said this before]. UAC as
it's currently implemented makes it too easy for developers who have a need
to allow their program to have extra privileges to just mark their
applications as "requiring an administrator", instead of doing it the
correct way and testing to see if the user has the needed privileges and
prompting for elevation only if necessary.

This kind of sweeps the entire rich privilege model of Windows under the
rug, replacing it with "administrator" or "not an administrator". If I have
a certain privilege but am not an administrator, I should be able to run a
program that needs the privilege I hold without having to be a part of the
administrators group.

As an example, take the system clock. Users must hold the change system time
privilege in order to change the time. Windows does it at least
semi-correctly - if the user has this privilege, they can change the system
time, regardless of whether they are an administrator or not. However, if
the user doesn't hold this privilege, the clock requests an administrator to
log in. I'm sure this took a non-trivial amount of code to implement, when
UAC should do this automatically for the application.

As it stands, it is much easier for the developer to simply mark their app
as 'require admin' than to implement the logic necessary to check for
privileges and request elevation only if necessary. And this require admin
behavior is now kind of "supported" by Microsoft, whereas before testing for
admin and failing if not was considered hackish. This is going to set a
dangerous precedent IMHO.

If the system clock was implemented the way I see most developers
implementing it, it would be marked 'require administrator' to run,
resulting in all non-admins having to provide admin credentials to change
the system time, even if they held the appropriate privilege.

> Absolutely. UAC allows those who really need to run as admin to be
> able to do it safely. For users who have no need for that (which
> ought to be MOST USERS), it really shouldn't be adding anything new.


Well, I would add here that UAC implements virtualization and integrity
concepts to the compatability and security architectures, which provide
benefits to standard user accounts. Virtualization allows many legacy apps
that wouldn't run in Windows XP as a standard user to run in Vista as a
standard user. Integrity control provides privilege seperation between
well-defined integrity levels (system vs. admin vs. non-admin vs.
restricted), helping to prevent shatter attacks between levels as well as
allowing each level to define a "sandbox" that controls which securable
objects that level can write to, that takes precedence over the permission
list on objects.

The infrastructure required to support different privileged apps inside of a
single user account can be useful for non-admin accounts as well .

> I have worked at a number of companies with domain controllers and
> all the users logged on with user-level permissions (with the
> exception of QuickBooks users!). I really think it's only home users
> and small businesses without proper system administration who are
> running as admins.
>
> If UAC forces software makers to fix what they've been doing wrong
> since 1999, then that's great. But I see that as only a side effect
> of the design of UAC, not its chief purpose.


You say tomato, I say tomato. Regardless of how we chose to classify it,
I certainly hope (and expect) to see significant change in this area in the
next few years, thanks primarily to UAC.

> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/




--
- JB
Microsoft MVP - Windows Shell/User

Windows Vista Support Faq
http://www.jimmah.com/vista/

Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
How to access an AOL Email account with WINDOWS MAIl =?Utf-8?B?RW1tYW51ZWw=?= microsoft.public.windows.vista.mail 10 11-23-2009 03:15
can't receive or send email =?Utf-8?B?RGFuIFY=?= microsoft.public.windows.vista.mail 7 06-08-2007 13:30
Delete Administrator Account? =?Utf-8?B?TWNHdXl3ZXI=?= microsoft.public.windows.vista.administration accounts passwords 7 03-11-2007 15:10
Can't Download From POP Account When Logged Into Domain ejoseph@ipowerllc.com microsoft.public.windows.vista.mail 0 03-02-2007 01:26
Pseudo-Admin vs Run as Administrator? Gerry Hickman microsoft.public.windows.vista.security 8 01-13-2007 01:53




All times are GMT +1. The time now is 14:06.




Driver Scanner - Free Scan Now

Vistaheads.com is part of the Heads Network. See also XPHeads.com , Win7Heads.com and Win8Heads.com.


Design by Vjacheslav Trushkin for phpBBStyles.com.
Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.6.0 RC 2

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120