![[HaBo]](/styles/default/logoklein.png){kind=small}
Mackz
Member of Honour
Windows Vista wird ja die UAP (User Account Protection) besitzen. (Allgemeine Infos: http://msdn.microsoft.com/windowsvi...ong/html/AccProtVista.asp#accprotvista_topic2)
Gerade gab es dazu neue Infos.
Q: what is the goal of user access protection?
A: in a nutshell "reduce the privs needed to do every day operations." You should have to Chat as an admin. are you right now? If I send you the wrong string right NOW, can I exploit this app and modify how your system boots? that's crazy!
Q: So why UAP how did it come about?
A: You can solve the security exploits in two high level buckets: let the apps run as admin but watch them carefully and try to keep them sandboxed, or you can do UAP and try to get the apps to sandbox themselves by only runnign with the privs they need. We chose the later.
Q: what are the advantages of UAP????
A: MASSIVE reduction in attack surface. fix the OS to feel like it was designed for the Standard User. auto-fix legacy apps to run as Standard User. MASSIVE reduction in enterprise cost because the users cannot easily break things anymore. Put the admin back in control of the machine
Q: How does it impact applications?
A: if the app runs well as Standard User, it wont affect them at all. If the app is an admin app, it will have a consent dialog in front of the user EVERY time the app is run
Q: What's the functional difference between confirming actions that require administrative rights versus requesting administrative credentials (i.e. username and password)?
A: First only the Protected Administrator (the user who has potential to elevate) can be presented with a "consent" prompt, because of new protection mechanisms in Vista we can "protect" this input. Now if a piece of malware invoked a "spoofed" consent dialog the at most they would get a mouse "OK" click and could not use this to run an elevated process. Now the Standar user who has no potential to elevate would be presented with a "credential prompt" and have to enter admin credentials. To secure this operation from physing attacks we have the Secure desktop credential mode.
Q: Will the option of turning off/disabling UAP be removed in later builds of Windows Vista?
A: The "toggle" to easily turn UAP off will be removed. However, you will still be able to turn it off via policy
Q: Why didn't UAP Team backport the UAP technology to older versions of Windows such as XP SP2 and Server 2003 SP1?
A: good question. The problem is that we have to change the way you start code so that NtCreateProcess would never give you the ability to run something as admin unless we know that it has been consented to by the user. We needed our MIC (mandatory integrity control) stuff ported to. There are simply too many changes to make it viable to port
Q: What will we see from UAP in beta2?
A: tons. UAP is pretty ugly in Beta 1. Beta2 has a much more robust view of "what is an installer" plus the Explorer will start looking much more UAP friendly. Printers will work. IE will elevate for installing an activeX control etc.
Q: Is there more to expect from UAP interface wise or are we seeing a near complete component in current builds?
A: We are continuing to change the UAP experience.. you will see big differences in Beta2. Note: we are constantly taking in customer feedback and incorperating it back into the product --Beta2 will be widely distributed and we expect to have great user feedback
Q: How will keep the average user from being instructed to bypass UAP by a piece of malware? For example malware might put up a window saying "just enter your password at the UAP prompt to continue install"
A: good question. Spoofing is definitely a problem that we are taking seriously. For the admin on the box, we remove the spoofing by only putting a consent dialog up in front of the user. in other words, just an OK dialog... so spoof away. However, we still have a problem for the Standard User asking for consent from an admin... we need the creds of the admin. Personally, I think that we can train people to use the UAP Consent Policy that says "you much press ctrl-alt-del to answer this elevation question"... what do you think?
Q: How does Internet Explorer 7 on Windows Vista take advantage of UAP?
A: As the Windows Vista desktop runs as Standard User by default so to does IE7 --getting better... The new restircted mode of IE7 will run with less privilege in the internet than IE running in the intranet. When IE7 needs to perform an admin taks like installing an ActiveX control it passes that request to the Admin broker who then requests administrative consent before continuing.
Q: What are five things you like about UAP?
A: Common User tasks work as Standard User; All users logon in Standard user mode irrespective of their potential privilege; All Administrative tasks require consent; A great in context elevation path for the Standard User via Over the Shoulder credentials (OTS) --user doesn't have to logoff and then logon as admin to perform admin tasks; Legacy application compatability as Standard user is great on Vista.
Q: Can the UAP be configured via the security database?
A: Yes. the settings are in SECPOL.MSC
Q: How will UAP and LUAFileVirtualization affect installation of ActiveX controls in IE for limited users? How does this interact with protected mode IE?
A: Given that almost all ActiveX controls are per machine they will require administrative consent to install, that said IE7 has what we are calling an Admin Broker, this broker will require consent from the admin to perform ActiveX installs.
Q: Is UAP is for just the users side of control or does it also limit the system account from doing tasks?
A: With UAP on, all admins, other than the build-in Administrator account, run as "protected admins" which means they will have to elevate applications as well.
Q: what options will installers get for queirying UAP settings
A: we dont want them to query. We have shifted the paradigm from "is this user an admin" to "assume that the user can type in the admin password and ask them anyway." For example, the control panel applets wont assume anymore that they Standard User should not have an "elevate to answer the question" setting. They should always be given the opportunity to elevate and type in the admin pw (NOTE that you control that via policy so that in the enterprise you can say that the Standard User has NO ability to elevate)
Q: will UAP affect the way MSI files are created?
A: not too much. It become more imporant to be aware that the user that installs the app may not be the user that RUNS the app. So dont do per-user settings during the admin setup
Q: if legacy applications try to write in a portion of the registry protected by UAP, will you get a question at the end whether to commit or rollback the changes? Will that pause the worker thread of the legacy application?
A: From the legacy application persepective it wil think the write was successful, we simply redirect "under the covers" without error.
Q: Will applications certified for Winodws XP be impacted by UAP?
A: At the end of the day if your application ran on XP as Standard User it will just work on Vista.
Q: Is there going to be a way to exclude known and trusted applications so that a prompt really means something and the user pays attention?
A: If you run an enterprise and deploy software with technologies like GPSI or SMS then you will not see prompts. If you try to manually install an All Users application and UAP is enabled you will get an elevation prompt.
Q: Does UAP affect application or system performance in anyway?
A: hmm... I answered this but it doesnt show as answered: There will be a perf hit for legacy apps. Virt-Redirection says "see if there is a virtualized version of this file before checking the real location in Program Files." that will slow the app down a tiny bit.
Q: Is it possible to configure these UAP features via Group Policy? Can they be suppressed or disabled compleately for end users?
A: Yes, via SECPOL.MSC. you have control over UAP and all the policies including whether or not your Standard Users have the ability to elevate.
Q: What will happens with UAP and automatic updates?
A: Automatic Update runs under a trusted service so UAP won't impact it. It even runs fine as a standard user on Windows XP for a comparison.
Q: How will UAP work with Legacy applications? Both 16 bit and DOS based?
A: We have a great Appcompat story for Windows Vista, if you application is working on XP it will most likely just work on Vista. Note: 16 bit applications will not be supported on 64 bit versions of Windows Vista.
Q: What locations will have LUA shims in Beta2? What are common app compat problems with UAP?
A: Program Files, HKLM\Software, SYSTEM32 etc. The big app compat problems are auto-updating code
Q: In its current incarnation, UAP plus file access security is causing a lot of pain for me, and will probably cause pain to end users. I encounter a lot of situations where I can no longer access the files I created under XP. .....
A: We are aware of these issues and are working to impliment the correct experience... as stated on earlier threads you will see signifigant improvments in Beta2 and via customer feedback the RTM version will be even better
Q: Specifically, what changes to installation tools must be made in Vista, in order to write files (like drivers) and to be able to affect the Registry?
A: This is definitely an area that requires more attention with the addition of UAP. First off, most installations will need to occur as an elevated operation. All of the placement of files in "machine-wide" locations such as \program files, etc. must occur during this elevated installation. User specific configuration should be run at first launch of the application and it shouldn't require elevation.
Q: Is there going to be any kind of system support, help or automatic popups where UAP detects what you are trying to do or app you are trying to install and uses your (MS's) experience to do the right thing?
A: good question. we are working on technology to help with scenarios such as this. I am not certain we will solve all of the issues though. For example, say we dont detect a setup... and the setup runs as Standard User... UAP will refuse to put the exe into Program Files. We _might_ be able to catch that and ask the user "was that a setup? can we help you elevate that?"
Q: I need to logon as Administrator, change file access rights, log back on as me and contonue doing my thing. How will the average user handle this. How will my mom handle this?
A: You will see great improvments in Beta2 and RTM --btw. my mother will be a Beta2 tester :>
Q: Is there, or will there be, an easy way to find (and possibly delete) all virtualized files? Is there an easy way in explorer to tell if a certain file is virtualized?
A: Currently no and no. In order to both see and delete the virtualized data you would have to manually traverse to the Vstore.
Q: What are the implications of UAP on users being able to patch their machines?
A: Users should be able to patch Vista without any issues. For ISV applications that ship patches we recommend using MSI 3.1 and the patching infrastructure it provides.
Q: How trusted will Microsoft Update be? Will users be allowed to just update as they please or will Administrators be allowed to prevent users from installing Microsoft patches? Meaning can Administrators perform their own QA against the Enterprise?
A: Yes WU will be a service and will be unaffected by UAP. Network Admins are in control of what updates happen in the enterprise if they want to be. (for example, via SUS)
Q: How will an application that starts a Kernel-Mode driver service (for low-level hardware access) be affected by UAP?
A: This depends on how the application starts the service. For example if you want to stop or start an installed service via services.msc then the mmc console must be running with administrative privilege
Q: ...... this will be a very bad user experience if people's backups fail.What is being done to prevent disasters like this?
A: We presented this technology to a bunch of backup vendor last week so they have seen what UAP entails for them. Fortunately, most of the backup software is run as a system service and therefore they will be unaffected.
Q: My current account is an "Administrator" of the system and everytime something goes to run, i am prompted for credentials. if i am the admin, why is this happening?
A: With UAP on, all admins, other than the build-in Administrator account, run as "protected admins" which means they will have to elevate applications as well.
Q: If a network drive has Vista installed, and a WinXP machine connects to the network drive with Vista and tries to run the installer there, will the WInXP machine be affected by UAP of any kind?
A: that depends on how far we get with "LUA on the Wire"... but in the specific scenario you described, there will be no affect. The setup code will run on the XP machine... with the creds of the logged on user of the XP machine.
Q: When you say"drivers aren't affected", does this also apply to display drivers (mirror drivers in particular)?
A: Vista has a ton of changes down driver control for enterprise admins. You can define exactly what drivers your users can install (without the need for the desktop user to be an admin on the box)
Q: What's the funcational difference between confirming an action that requires administrative permissions versus requesting administrative credentials?
A: The OS prompts for admin consent --this implies that the administrative application has already defined the requestedExecution level to be admin. What this means is Admin apps must be marked in order to request administrative privilege
Q: Can AppCompat database supplied with Windows Vista be modified?
A: Yes, both in the Home and Enterprise. In the home, you can rMouse click ont he exe and modify the security tab to say "this is an admin app". In the enterprise, you can use the enterprise version of that tool to set "admin-ness" and "no virt for this app"
Q: What is the commonest developer mistake in user priveleges?
A: quite simply: putting files right next to the exe in program files.
Q: I have notcied that when a worm comes in and destrosy data , it will also destroy windows components. How will UAP help me?
A: from a high level most worms require elevated privilege to destory the machine --UAP facilitates running the desktop as Standard User and thus blocks most per machines threats
Q: Will there be different default UAP settings for different Vista SKUs?
A: not yet. LUA is ON by default in all SKUs so far and the consent settings seem to be holding in all the SKUs too
Q: Will system restore at all interferre with UAP? If I roll my machine backwards does this effect it at all?
A: Sys Restore will be an admin app. If you roll back to a state that had a UAP policy difference, there will be an affect... other than those two items, no other affects
Q: Will users be able to safely install printers without being prompted for admin rights or requiring admin rights?
A: Yes, based on enterprise admin policy control. There will still be holes where the INF that the user installs puts on bad code though
Q: How will IPC be affected by UAP?
A: mostly unaffected. LUA apps need to be able to RPC to Services and Admin apps... we broke the ability to communicate via thread/data injection and via SendMessage... but not RPC. We may be limiting communication from "Low" to "Medium" or higher... which might affect Protected Mode IE
Q: What happens when I install dlss that would interfer with UAP protection?
A: Windows Resource Protection and Code Integrity prevent the replacing our Vista System binaries
Q: If you endow an account with Administrator priviledges, is that account (once logged in) also not subject to UAP checks?
A: we definitely app UAP to admins... ONLY the built-in admin is exempt. When you log in as admin, your explorer shell will run as Standard User... as will outlook, messenger etc. that is the CORE of what UAP gives you.
Q: Given a choice between running as Admin with UAP, and running as a genuine normal user, which would you recommend? Given that I'm used to the two accounts approach, will I be better off or worse of with UAP?
A: Big question -- because I'm a security person the answer is run as Standard User --always. Now in the home that might mean that you retain the Admin password on paper and enter it on demand....
Q: Does file virtualization allow one application to overwrite a file belonging to another application with a virtual copy, thus compromising that application or the system, if only for that user account?
A: Yes, as you point out though, only the user's account would be affected. Moreover, there are currently only a limited set of directories that are virtualized on a machine so this could only happen to applications installed there.
Q: What is being planned for developer support in regards to UAP? Will a program be able to request elevation? (requiring user acceptance of course)?
A: We will have a new Logo doc for UAP compliancy to help developers... As well we have a deployment whitepaper that walks you thru creating the necessary meta data to define the requested elevation level... see: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp
Q: some spyware were able to disable the windows firewall, how can you be sure they cannot disable UAP?
A: Good question. The Security Center backs up the policy setting in the home... and we are looking at ways to harden it. We could remove the policy (disallow anybody from turning it off)... but that would be a little draconian.
Q: How can developers ensure that their apps are in the AppCompat database if necessary?
A: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp
Q: Will UAP support third-party IFS?
A: IFS runs below the users context (we are talking about a file system, right?) .. therefore, UAP doesnt affect IFS
Q: How is UAP handled in a home network on MCE to access media files on another device?
A: Cheers... good docs: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp http://msdn.microsoft.com/windowsvista/security/
Q: What is "auto-fix", what are you really doing?
A: Here is the scenario. LoBapp1.exe drops a log file into Program Files\LoBApp1\log.txt. Under the covers, CreateFile is about to return an Access Denied. a Filter Driver catches that access denied, moves the filename to be "Users\<Username>\Virtual Store\Program Files\LobApp1\Log.txt" and tries again.
Q: Will UAP support more than just username/password credential input? (e.g. Smartcard, Fortezza, Biometrics)
A: Yes. Smartcard is already there. Since we use CredUI, any cred extender that plugs into the new Cred Provider model will work for answering the elevation prompt
Q: Does UAP affect Impersonation or other programmatic capabilities... and, if so, is there documentation out there on those changes?
A: Services that impersonate a logged on user will never see their virtualized view --note: we will be producing a whitepaper on the service interation with UAP in the Beta2 timeframe
Q: Will the dump files be unprotected in later builds, so users can send feedback without going into admin mode?
A: System dump files are protected in Windows Vista
Q: Will RunAs continue to work as it is today - i.e. you'll impersonate the user with the supplied credentials, with UAP enabled on that new user unless it is the built-in admin? Or is RunAs obsolete?
A: RunAs will give you a Standard User token ... even when you specify the right admin. In other words, if i am logged on as Standard User and say "Runas /user:adminuser cmd.exe" I will still get a "Standard User" cmd.exe. We have an active DCR to add a "runas /Elevate /user:adminuser cmd.exe"
Q: WIll UAP effect my programs performance?
A: not much if the app runs well as Standard User today. a LITTLE if it has to be virtualized. (we potentially have to check two places to see if there is a virtualized file before completing the open)
Q: Unfortunately, we still have some apps which do not function unless the user is an admin. How will UAP affect these if the circumstances with the apps don't improve)?
A: There are a number of technologies that support application compatibility for applications that don't run properly as normal user. In the case that the application truly needs full privileges you can mark it in a number of ways. See the following document for methods to mark an app. http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp>
Q: How can I change which accounts are setup with UAP on? In other words, the local admininistrator account is setup with UAP off - but we rename that account and scramble the PW. Can we select SOME domain accounts to not have UAP on?
A: Currently UAP affects all interactive users except the built-in admin. In Beta2 you can disable UAP permachine.
Q: How do you make a user a standard user?
A: dont add them to the local admin group. From the cmd line, a "Net User Joe /ad" will automatically be a standard User in Vista.
Q: Will UAP learn what program I accept to run? So it will no longer prompt me for password later?
A: There are currently no plans to support this scenario in Vista.
Q: Will the default account type created by the Vista OOB wizard (or something similar, assuming there will be something like that) be a "protected administrator" or a real limited account? (hoping for the latter here)
A: In Windows Vista the First account is always the built-in admin (installs the OS), the second user will be a member of the Administrators group and all other users will be Standard by default.
Q: Will UAP support more than just username/password credential input? (e.g. Smartcard, Fortezza, Biometrics)
A: Yes Vista natively support SmartCards, User type credentials (even via the secure desktop), and consent for the protected Vista Admin
Q: Does renaming the local or domain Administrator account have any effect on the UAP built in permissions?
A: No the account name is simply for display purposes
Q: Is there any difference between running as a regular user and running as an Administrator with UAP?
A: good question. Not much. That admin user has a "link" in their token that says "this person has the ability to elevate with their own creds".
Q: Will you improve the RUNAS command ? Sometimes it's very difficult to run as a non admin to perform administrative tasks. For example, it's difficult to run explorer under different user context.
A: Yes we have changed the Verb to be "Run Elevated..." Note: Explorer is a different question and yes it's currently hard to run two instances of Explorer in different security contexts
Q: How does UAP affect roaming profiles?
A: It doesn't
Gerade gab es dazu neue Infos.
Q: what is the goal of user access protection?
A: in a nutshell "reduce the privs needed to do every day operations." You should have to Chat as an admin. are you right now? If I send you the wrong string right NOW, can I exploit this app and modify how your system boots? that's crazy!
Q: So why UAP how did it come about?
A: You can solve the security exploits in two high level buckets: let the apps run as admin but watch them carefully and try to keep them sandboxed, or you can do UAP and try to get the apps to sandbox themselves by only runnign with the privs they need. We chose the later.
Q: what are the advantages of UAP????
A: MASSIVE reduction in attack surface. fix the OS to feel like it was designed for the Standard User. auto-fix legacy apps to run as Standard User. MASSIVE reduction in enterprise cost because the users cannot easily break things anymore. Put the admin back in control of the machine
Q: How does it impact applications?
A: if the app runs well as Standard User, it wont affect them at all. If the app is an admin app, it will have a consent dialog in front of the user EVERY time the app is run
Q: What's the functional difference between confirming actions that require administrative rights versus requesting administrative credentials (i.e. username and password)?
A: First only the Protected Administrator (the user who has potential to elevate) can be presented with a "consent" prompt, because of new protection mechanisms in Vista we can "protect" this input. Now if a piece of malware invoked a "spoofed" consent dialog the at most they would get a mouse "OK" click and could not use this to run an elevated process. Now the Standar user who has no potential to elevate would be presented with a "credential prompt" and have to enter admin credentials. To secure this operation from physing attacks we have the Secure desktop credential mode.
Q: Will the option of turning off/disabling UAP be removed in later builds of Windows Vista?
A: The "toggle" to easily turn UAP off will be removed. However, you will still be able to turn it off via policy
Q: Why didn't UAP Team backport the UAP technology to older versions of Windows such as XP SP2 and Server 2003 SP1?
A: good question. The problem is that we have to change the way you start code so that NtCreateProcess would never give you the ability to run something as admin unless we know that it has been consented to by the user. We needed our MIC (mandatory integrity control) stuff ported to. There are simply too many changes to make it viable to port
Q: What will we see from UAP in beta2?
A: tons. UAP is pretty ugly in Beta 1. Beta2 has a much more robust view of "what is an installer" plus the Explorer will start looking much more UAP friendly. Printers will work. IE will elevate for installing an activeX control etc.
Q: Is there more to expect from UAP interface wise or are we seeing a near complete component in current builds?
A: We are continuing to change the UAP experience.. you will see big differences in Beta2. Note: we are constantly taking in customer feedback and incorperating it back into the product --Beta2 will be widely distributed and we expect to have great user feedback
Q: How will keep the average user from being instructed to bypass UAP by a piece of malware? For example malware might put up a window saying "just enter your password at the UAP prompt to continue install"
A: good question. Spoofing is definitely a problem that we are taking seriously. For the admin on the box, we remove the spoofing by only putting a consent dialog up in front of the user. in other words, just an OK dialog... so spoof away. However, we still have a problem for the Standard User asking for consent from an admin... we need the creds of the admin. Personally, I think that we can train people to use the UAP Consent Policy that says "you much press ctrl-alt-del to answer this elevation question"... what do you think?
Q: How does Internet Explorer 7 on Windows Vista take advantage of UAP?
A: As the Windows Vista desktop runs as Standard User by default so to does IE7 --getting better... The new restircted mode of IE7 will run with less privilege in the internet than IE running in the intranet. When IE7 needs to perform an admin taks like installing an ActiveX control it passes that request to the Admin broker who then requests administrative consent before continuing.
Q: What are five things you like about UAP?
A: Common User tasks work as Standard User; All users logon in Standard user mode irrespective of their potential privilege; All Administrative tasks require consent; A great in context elevation path for the Standard User via Over the Shoulder credentials (OTS) --user doesn't have to logoff and then logon as admin to perform admin tasks; Legacy application compatability as Standard user is great on Vista.
Q: Can the UAP be configured via the security database?
A: Yes. the settings are in SECPOL.MSC
Q: How will UAP and LUAFileVirtualization affect installation of ActiveX controls in IE for limited users? How does this interact with protected mode IE?
A: Given that almost all ActiveX controls are per machine they will require administrative consent to install, that said IE7 has what we are calling an Admin Broker, this broker will require consent from the admin to perform ActiveX installs.
Q: Is UAP is for just the users side of control or does it also limit the system account from doing tasks?
A: With UAP on, all admins, other than the build-in Administrator account, run as "protected admins" which means they will have to elevate applications as well.
Q: what options will installers get for queirying UAP settings
A: we dont want them to query. We have shifted the paradigm from "is this user an admin" to "assume that the user can type in the admin password and ask them anyway." For example, the control panel applets wont assume anymore that they Standard User should not have an "elevate to answer the question" setting. They should always be given the opportunity to elevate and type in the admin pw (NOTE that you control that via policy so that in the enterprise you can say that the Standard User has NO ability to elevate)
Q: will UAP affect the way MSI files are created?
A: not too much. It become more imporant to be aware that the user that installs the app may not be the user that RUNS the app. So dont do per-user settings during the admin setup
Q: if legacy applications try to write in a portion of the registry protected by UAP, will you get a question at the end whether to commit or rollback the changes? Will that pause the worker thread of the legacy application?
A: From the legacy application persepective it wil think the write was successful, we simply redirect "under the covers" without error.
Q: Will applications certified for Winodws XP be impacted by UAP?
A: At the end of the day if your application ran on XP as Standard User it will just work on Vista.
Q: Is there going to be a way to exclude known and trusted applications so that a prompt really means something and the user pays attention?
A: If you run an enterprise and deploy software with technologies like GPSI or SMS then you will not see prompts. If you try to manually install an All Users application and UAP is enabled you will get an elevation prompt.
Q: Does UAP affect application or system performance in anyway?
A: hmm... I answered this but it doesnt show as answered: There will be a perf hit for legacy apps. Virt-Redirection says "see if there is a virtualized version of this file before checking the real location in Program Files." that will slow the app down a tiny bit.
Q: Is it possible to configure these UAP features via Group Policy? Can they be suppressed or disabled compleately for end users?
A: Yes, via SECPOL.MSC. you have control over UAP and all the policies including whether or not your Standard Users have the ability to elevate.
Q: What will happens with UAP and automatic updates?
A: Automatic Update runs under a trusted service so UAP won't impact it. It even runs fine as a standard user on Windows XP for a comparison.
Q: How will UAP work with Legacy applications? Both 16 bit and DOS based?
A: We have a great Appcompat story for Windows Vista, if you application is working on XP it will most likely just work on Vista. Note: 16 bit applications will not be supported on 64 bit versions of Windows Vista.
Q: What locations will have LUA shims in Beta2? What are common app compat problems with UAP?
A: Program Files, HKLM\Software, SYSTEM32 etc. The big app compat problems are auto-updating code
Q: In its current incarnation, UAP plus file access security is causing a lot of pain for me, and will probably cause pain to end users. I encounter a lot of situations where I can no longer access the files I created under XP. .....
A: We are aware of these issues and are working to impliment the correct experience... as stated on earlier threads you will see signifigant improvments in Beta2 and via customer feedback the RTM version will be even better
Q: Specifically, what changes to installation tools must be made in Vista, in order to write files (like drivers) and to be able to affect the Registry?
A: This is definitely an area that requires more attention with the addition of UAP. First off, most installations will need to occur as an elevated operation. All of the placement of files in "machine-wide" locations such as \program files, etc. must occur during this elevated installation. User specific configuration should be run at first launch of the application and it shouldn't require elevation.
Q: Is there going to be any kind of system support, help or automatic popups where UAP detects what you are trying to do or app you are trying to install and uses your (MS's) experience to do the right thing?
A: good question. we are working on technology to help with scenarios such as this. I am not certain we will solve all of the issues though. For example, say we dont detect a setup... and the setup runs as Standard User... UAP will refuse to put the exe into Program Files. We _might_ be able to catch that and ask the user "was that a setup? can we help you elevate that?"
Q: I need to logon as Administrator, change file access rights, log back on as me and contonue doing my thing. How will the average user handle this. How will my mom handle this?
A: You will see great improvments in Beta2 and RTM --btw. my mother will be a Beta2 tester :>
Q: Is there, or will there be, an easy way to find (and possibly delete) all virtualized files? Is there an easy way in explorer to tell if a certain file is virtualized?
A: Currently no and no. In order to both see and delete the virtualized data you would have to manually traverse to the Vstore.
Q: What are the implications of UAP on users being able to patch their machines?
A: Users should be able to patch Vista without any issues. For ISV applications that ship patches we recommend using MSI 3.1 and the patching infrastructure it provides.
Q: How trusted will Microsoft Update be? Will users be allowed to just update as they please or will Administrators be allowed to prevent users from installing Microsoft patches? Meaning can Administrators perform their own QA against the Enterprise?
A: Yes WU will be a service and will be unaffected by UAP. Network Admins are in control of what updates happen in the enterprise if they want to be. (for example, via SUS)
Q: How will an application that starts a Kernel-Mode driver service (for low-level hardware access) be affected by UAP?
A: This depends on how the application starts the service. For example if you want to stop or start an installed service via services.msc then the mmc console must be running with administrative privilege
Q: ...... this will be a very bad user experience if people's backups fail.What is being done to prevent disasters like this?
A: We presented this technology to a bunch of backup vendor last week so they have seen what UAP entails for them. Fortunately, most of the backup software is run as a system service and therefore they will be unaffected.
Q: My current account is an "Administrator" of the system and everytime something goes to run, i am prompted for credentials. if i am the admin, why is this happening?
A: With UAP on, all admins, other than the build-in Administrator account, run as "protected admins" which means they will have to elevate applications as well.
Q: If a network drive has Vista installed, and a WinXP machine connects to the network drive with Vista and tries to run the installer there, will the WInXP machine be affected by UAP of any kind?
A: that depends on how far we get with "LUA on the Wire"... but in the specific scenario you described, there will be no affect. The setup code will run on the XP machine... with the creds of the logged on user of the XP machine.
Q: When you say"drivers aren't affected", does this also apply to display drivers (mirror drivers in particular)?
A: Vista has a ton of changes down driver control for enterprise admins. You can define exactly what drivers your users can install (without the need for the desktop user to be an admin on the box)
Q: What's the funcational difference between confirming an action that requires administrative permissions versus requesting administrative credentials?
A: The OS prompts for admin consent --this implies that the administrative application has already defined the requestedExecution level to be admin. What this means is Admin apps must be marked in order to request administrative privilege
Q: Can AppCompat database supplied with Windows Vista be modified?
A: Yes, both in the Home and Enterprise. In the home, you can rMouse click ont he exe and modify the security tab to say "this is an admin app". In the enterprise, you can use the enterprise version of that tool to set "admin-ness" and "no virt for this app"
Q: What is the commonest developer mistake in user priveleges?
A: quite simply: putting files right next to the exe in program files.
Q: I have notcied that when a worm comes in and destrosy data , it will also destroy windows components. How will UAP help me?
A: from a high level most worms require elevated privilege to destory the machine --UAP facilitates running the desktop as Standard User and thus blocks most per machines threats
Q: Will there be different default UAP settings for different Vista SKUs?
A: not yet. LUA is ON by default in all SKUs so far and the consent settings seem to be holding in all the SKUs too
Q: Will system restore at all interferre with UAP? If I roll my machine backwards does this effect it at all?
A: Sys Restore will be an admin app. If you roll back to a state that had a UAP policy difference, there will be an affect... other than those two items, no other affects
Q: Will users be able to safely install printers without being prompted for admin rights or requiring admin rights?
A: Yes, based on enterprise admin policy control. There will still be holes where the INF that the user installs puts on bad code though
Q: How will IPC be affected by UAP?
A: mostly unaffected. LUA apps need to be able to RPC to Services and Admin apps... we broke the ability to communicate via thread/data injection and via SendMessage... but not RPC. We may be limiting communication from "Low" to "Medium" or higher... which might affect Protected Mode IE
Q: What happens when I install dlss that would interfer with UAP protection?
A: Windows Resource Protection and Code Integrity prevent the replacing our Vista System binaries
Q: If you endow an account with Administrator priviledges, is that account (once logged in) also not subject to UAP checks?
A: we definitely app UAP to admins... ONLY the built-in admin is exempt. When you log in as admin, your explorer shell will run as Standard User... as will outlook, messenger etc. that is the CORE of what UAP gives you.
Q: Given a choice between running as Admin with UAP, and running as a genuine normal user, which would you recommend? Given that I'm used to the two accounts approach, will I be better off or worse of with UAP?
A: Big question -- because I'm a security person the answer is run as Standard User --always. Now in the home that might mean that you retain the Admin password on paper and enter it on demand....
Q: Does file virtualization allow one application to overwrite a file belonging to another application with a virtual copy, thus compromising that application or the system, if only for that user account?
A: Yes, as you point out though, only the user's account would be affected. Moreover, there are currently only a limited set of directories that are virtualized on a machine so this could only happen to applications installed there.
Q: What is being planned for developer support in regards to UAP? Will a program be able to request elevation? (requiring user acceptance of course)?
A: We will have a new Logo doc for UAP compliancy to help developers... As well we have a deployment whitepaper that walks you thru creating the necessary meta data to define the requested elevation level... see: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp
Q: some spyware were able to disable the windows firewall, how can you be sure they cannot disable UAP?
A: Good question. The Security Center backs up the policy setting in the home... and we are looking at ways to harden it. We could remove the policy (disallow anybody from turning it off)... but that would be a little draconian.
Q: How can developers ensure that their apps are in the AppCompat database if necessary?
A: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp
Q: Will UAP support third-party IFS?
A: IFS runs below the users context (we are talking about a file system, right?) .. therefore, UAP doesnt affect IFS
Q: How is UAP handled in a home network on MCE to access media files on another device?
A: Cheers... good docs: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp http://msdn.microsoft.com/windowsvista/security/
Q: What is "auto-fix", what are you really doing?
A: Here is the scenario. LoBapp1.exe drops a log file into Program Files\LoBApp1\log.txt. Under the covers, CreateFile is about to return an Access Denied. a Filter Driver catches that access denied, moves the filename to be "Users\<Username>\Virtual Store\Program Files\LobApp1\Log.txt" and tries again.
Q: Will UAP support more than just username/password credential input? (e.g. Smartcard, Fortezza, Biometrics)
A: Yes. Smartcard is already there. Since we use CredUI, any cred extender that plugs into the new Cred Provider model will work for answering the elevation prompt
Q: Does UAP affect Impersonation or other programmatic capabilities... and, if so, is there documentation out there on those changes?
A: Services that impersonate a logged on user will never see their virtualized view --note: we will be producing a whitepaper on the service interation with UAP in the Beta2 timeframe
Q: Will the dump files be unprotected in later builds, so users can send feedback without going into admin mode?
A: System dump files are protected in Windows Vista
Q: Will RunAs continue to work as it is today - i.e. you'll impersonate the user with the supplied credentials, with UAP enabled on that new user unless it is the built-in admin? Or is RunAs obsolete?
A: RunAs will give you a Standard User token ... even when you specify the right admin. In other words, if i am logged on as Standard User and say "Runas /user:adminuser cmd.exe" I will still get a "Standard User" cmd.exe. We have an active DCR to add a "runas /Elevate /user:adminuser cmd.exe"
Q: WIll UAP effect my programs performance?
A: not much if the app runs well as Standard User today. a LITTLE if it has to be virtualized. (we potentially have to check two places to see if there is a virtualized file before completing the open)
Q: Unfortunately, we still have some apps which do not function unless the user is an admin. How will UAP affect these if the circumstances with the apps don't improve)?
A: There are a number of technologies that support application compatibility for applications that don't run properly as normal user. In the case that the application truly needs full privileges you can mark it in a number of ways. See the following document for methods to mark an app. http://msdn.microsoft.com/windowsvista/default.aspx?pull=/library/en-us/dnlong/html/AccProtVista.asp>
Q: How can I change which accounts are setup with UAP on? In other words, the local admininistrator account is setup with UAP off - but we rename that account and scramble the PW. Can we select SOME domain accounts to not have UAP on?
A: Currently UAP affects all interactive users except the built-in admin. In Beta2 you can disable UAP permachine.
Q: How do you make a user a standard user?
A: dont add them to the local admin group. From the cmd line, a "Net User Joe /ad" will automatically be a standard User in Vista.
Q: Will UAP learn what program I accept to run? So it will no longer prompt me for password later?
A: There are currently no plans to support this scenario in Vista.
Q: Will the default account type created by the Vista OOB wizard (or something similar, assuming there will be something like that) be a "protected administrator" or a real limited account? (hoping for the latter here)
A: In Windows Vista the First account is always the built-in admin (installs the OS), the second user will be a member of the Administrators group and all other users will be Standard by default.
Q: Will UAP support more than just username/password credential input? (e.g. Smartcard, Fortezza, Biometrics)
A: Yes Vista natively support SmartCards, User type credentials (even via the secure desktop), and consent for the protected Vista Admin
Q: Does renaming the local or domain Administrator account have any effect on the UAP built in permissions?
A: No the account name is simply for display purposes
Q: Is there any difference between running as a regular user and running as an Administrator with UAP?
A: good question. Not much. That admin user has a "link" in their token that says "this person has the ability to elevate with their own creds".
Q: Will you improve the RUNAS command ? Sometimes it's very difficult to run as a non admin to perform administrative tasks. For example, it's difficult to run explorer under different user context.
A: Yes we have changed the Verb to be "Run Elevated..." Note: Explorer is a different question and yes it's currently hard to run two instances of Explorer in different security contexts
Q: How does UAP affect roaming profiles?
A: It doesn't