+9999 This is almost exactly what we do.
We use LogMeIn Rescue so we can support any computer as long as they have an internet connection. It doesn't sound any different than 'approving' a Viewfinity request minus the obvious manual installing. For a small amount of users we have separate local accounts they can elevate to as they constantly install dozens of types of small software and work with tools designed 20 years ago to connect to specialised hardware that's been around for just as long. We also have a local admin account on all computers with a randomised password (like LAPS) that is to be used in case a user desperately needs admin rights and has no internet connectivity - to be reset to a new random password next time machine is on network. Freddy From: [email protected] [mailto:[email protected]] On Behalf Of Nash Pherson Sent: Wednesday, 29 July 2015 8:31 AM To: [email protected] Subject: RE: [mssms] RE: Removing admin rights for users Joseph, You are hitting on some great common questions which all have solutions. "But I need to install software" Your organization should make standard software available for install or request through you enterprise management tools like ConfigMgr. For one-off installs, IT needs to provide a reasonable SLA with the business for opening a service request so the application is evaluated and tracked. Those service requests can almost always be completed remotely, so it shouldn't be hard to a quick response." "But I need this local printer, GPS thingy, etc" You can use Group Policy to allow the installation of drivers for certain classes of devices (like printers) without admin rights. For the exotic stuff, since you are going to end up having to support it, you want to have a hand in getting it set up. Devices need to be reviewed for security and supportability - don't let their 1 time purchase encumber the IT department with a significant long-term operational cost. Provide a reasonable SLA and give support remotely. "But I need this user-based ActiveX control" You can use Group Policy to white-list common user-based ActiveX controls so the user can install them without admin rights. For common system-based plugins, make them available in the App Catalog like other software. "But I'm a Dev and need to be able to play with stuff" That's great! Let's get you a virtual development environment that does not have access to our corporate network and data. Have fun in there, but the production environment is not for playing around. The organization needs to secure and ensure the operability of your device. "But this app doesn't work without admin rights" I have yet to see this actually be the case. You may need to open permissions to individual files/folders/registry keys. You may need to use compatibility mode. You may even need to use a compatibility shim that tricks the app into thinking the user is a member of the local admins group. You might even need to toss the app into an App-V container. But, since Windows 7 came out in 2009, I have yet to see a business app that couldn't be made to work without local Admin rights. While the things that require IT to be involved might seem like a lot or effort, you will see a significant reduction on break/fix tickets when you take away admin rights - more than enough to justify the change and free up resource to make reasonable SLAs work. And in the end your organization will get more secure and reliable systems. Long story short - any problems you run into are problems that have already been solved elsewhere. And if nobody has solved them at your org already, it's not going to happen unless you make it happen. I hope that helps, Nash Nash Pherson Microsoft MVP, Enterprise Client Management Senior Systems Consultant Now Micro [email protected]<mailto:[email protected]> Desk: 651-796-1168 Cell: 507-304-0946 [nowmicro]<http://www.nowmicro.com/> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Heaton, Joseph@Wildlife Sent: Tuesday, July 28, 2015 4:38 PM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: RE: [mssms] RE: Removing admin rights for users So, how would you address things like developers, who have MSDN licensing, from install/uninstalling as they need, or a regular user trying to add a local printer, or a user installing software for their GPS device that they just ordered through their program? Not being facetious, asking honestly. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Tuesday, July 28, 2015 11:49 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Removing admin rights for users It's not about blowing something up, it's about preventing malicious activity - intentional or not. If something malicious happens and all of your valuable data is stolen, does it really matter who did it anymore - you're most likely out of business? I dislike Viewfinity and other similar products as they poke holes and change default behaviors that should work. You should not have to resort to something like this IMO. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Heaton, Joseph@Wildlife Sent: Tuesday, July 28, 2015 12:38 PM To: '[email protected]' <[email protected]<mailto:[email protected]>> Subject: RE: [mssms] RE: Removing admin rights for users We have a policy in our Viewfinity, that allows developers to elevate whenever they need to, just by putting in their credentials. It pretty much gives them pseudo-local admin, but it logs everything they're doing, in Viewfinity, so if they do blow something up, we can go back and figure out what happened. From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andreas Hammarskjöld Sent: Tuesday, July 28, 2015 10:17 AM To: Jason Sandys; [email protected]<mailto:[email protected]> Subject: RE: [mssms] RE: Removing admin rights for users Writing server apps in Visual Studio is very cumbersome without admin rights. Things that require raw sockets, bcd files, backup etc are hard to do without it. Sure you can work and tweak local policies but then its almost better to have them dev:ing on a non prod environment as admin and RDP into it. UAC and VS works well in my experience though. Sent from Outlook Mail<http://go.microsoft.com/fwlink/?LinkId=550987> for Windows 10 From: Jason Sandys Sent: den 28 juli 2015 18:56 To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Removing admin rights for users As a side note, there is no such thing as "power users". They got rid of that in Vista because it was basically no different than a local admin. I concur with Daniel. If there are issues, it's the apps fault - you should not have to do anything special. Sometimes, special things are required though (which means doing some work investigation - it's not magic) but these mainly involve opening file or registry permissions on a limited basis if the app is doing something it shouldn't. ProcMon is the primary tool to discover these as necessary. You can also use LUA Buglight to help identify apps that are doing these bad things: http://blogs.msdn.com/b/aaron_margosis/archive/2015/07/01/lua-buglight-2-3-with-support-for-windows-8-1-and-windows-10.aspx. Also, if you leave UAC enabled (which you absolutely should), then through some virtualization/redirection magic (yes UAC actually is magic) you typically don't have to worry about these bad apps because UAC transparently redirects writes to files and registry values in privileged locations to the user's profile. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Daniel Ratliff Sent: Tuesday, July 28, 2015 11:44 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] RE: Removing admin rights for users It's generally one way or the other for us. Does the app install for all users? Deploy via SCCM and run as administrator. Does the app install per user/profile based? Deploy via SCCM and run as user. If the app needs to run as the user but requires admin, we sent it back to the vendor/developer to fix it. That's just bad development. Daniel Ratliff From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Beardsley, James Sent: Tuesday, July 28, 2015 12:40 PM To: [email protected]<mailto:[email protected]> Subject: [mssms] Removing admin rights for users I remember reading some of you saying your users do not have admin rights. We are about to start down that road and one of the concerns I have is for application deployment. Most apps can be installed as an administrator so those aren't of any concern but we have several small accounting apps that write to the user profile when installed and I'm wondering how others have handled apps like these. When something is installed as an administrator (which is the local system account, right?), does that still allow licensing info or other files to be written to the users' %appdata%, %localappdata%, or to HKCU? Have you run into any issues deploying software while users are not local admin? Its yet to be determined what rights we'll be giving them (power user vs standard user). I'd be interested in how you have your users set up and how that affects app deployment. Thanks, James Beardsley | Firm Technology Group Dixon Hughes Goodman LLP [cid:8644FC49-D5C9-45AE-B387-04FAFC0CC7A5]<http://www.dhgllp.com/> ________________________________ Confidentiality Notice: This e-mail is intended only for the addressee named above. It contains information that is privileged, confidential or otherwise protected from use and disclosure. If you are not the intended recipient, you are hereby notified that any review, disclosure, copying, or dissemination of this transmission, or taking of any action in reliance on its contents, or other use is strictly prohibited. If you have received this transmission in error, please reply to the sender listed above immediately and permanently delete this message from your inbox. Thank you for your cooperation. The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information.
