I would be interesting in reading those as we would like to set that up here.. get a little worried with the CEO having Domain Admin rights.
_____________________________ Cameron Cooper IT Director - CompTIA A+ Certified Aurico Reports, Inc Phone: 847-890-4021 Fax: 847-255-1896 ccoo...@aurico.com From: Sherry Abercrombie [mailto:saber...@gmail.com] Sent: Thursday, July 16, 2009 9:18 AM To: NT System Admin Issues Subject: Re: UAC--argh... Ewwww, that has been a no-no for best security practices for years. I'm sure if you dig around long enough you could come up with documentation from MS to support that. I may have some references for you, but I'll have to dig around for them ;) On Thu, Jul 16, 2009 at 9:09 AM, David Lum <david....@nwea.org> wrote: I'm the wrong dude to ask, our admins here are domain admins on their day-to-day accounts (I am the only one who doesn't do that, but I have had no luck convincing anyone else to follow suit). I do log into some of my servers (DC's) with my domain admin account, other servers I use my daily use account. Dave From: Miller Bonnie L. [mailto:mille...@mukilteo.wednet.edu] Sent: Thursday, July 16, 2009 5:05 AM To: NT System Admin Issues Subject: RE: UAC--argh... Dave-do your people who log onto servers log on with limited accounts there as well? If so, how many people are we talking about? We are a pretty small group and we have limited accounts for workstation/daily activities usage, but when connecting to a server, an admin account is generally used. From: David Lum [mailto:david....@nwea.org] Sent: Wednesday, July 15, 2009 2:02 PM To: NT System Admin Issues Subject: RE: UAC--argh... I think the only time an admin account would be used would be specifically to install software - I'm thinking kind of like changing a Citrix server to install mode where you only invoke that mode to install stuff. And hopefully the thumb drive gets scanned before a file is opened or moved from it. Put another way, you don't use the machine logged in as a local admin, you use it as a regular user and make UAC ask for admin credentials to install something. David Lum // SYSTEMS ENGINEER NORTHWEST EVALUATION ASSOCIATION (Desk) 971.222.1025 // (Cell) 503.267.9764 From: Miller Bonnie L. [mailto:mille...@mukilteo.wednet.edu] Sent: Wednesday, July 15, 2009 1:40 PM To: NT System Admin Issues Subject: RE: UAC--argh... LOL-that happens a LOT in the school applications world with permissions in general-"it needs to be administrator". So question on disabling AAM-Wouldn't that defeat the "malware protection" component of UAC, assuming an admin account was somehow used run the malware without that admin user's knowledge? I'm going with logging onto a server as an admin. For example, admin user logs onto a server and sticks a thumb drive in to copy a file over. Somehow there is malware that got on the thumbdrive. Assuming nothing else catches it (AV, etc), would disabling AAM allow it to run without consent? From: David Lum [mailto:david....@nwea.org] Sent: Wednesday, July 15, 2009 1:21 PM To: NT System Admin Issues Subject: RE: UAC--argh... +1 on keeping UAC on. Disabling AAM is sufficient to remove the annoyances, UAC has real benefits. My opinion concurs with Ben's. Just last week I was working with a vendor who claimed their application required Vista's User Access Control (UAC) needed to be turned off for the application to work. This was a VENDOR telling me about their product! Yet amazingly I figured out how to make it work with UAC....needless to say, they have since updated their documentation. Dave -----Original Message----- From: Ben Scott [mailto:mailvor...@gmail.com] Sent: Wednesday, July 15, 2009 12:30 PM To: NT System Admin Issues Subject: Re: UAC--argh... On Wed, Jul 15, 2009 at 12:41 PM, Miller Bonnie L.<mille...@mukilteo.wednet.edu> wrote: > So, I've been trying REALLY hard to just get used to UAC with WS08 ... The following is my opinion and analysis. It differs significantly from the Microsoft party line. Disable admin approval mode (AAM) for all administrators. Keep UAC enabled. AAM is just a lot of smoke and mirrors. The right way to do things is to run as a "limited user" except when needed, and have a separate admin account for admin stuff. If you do that, you don't need AAM. Indeed, AAM makes things *worse*, because admins get so used to clicking dozens of prompts that they'll miss important prompts. However, Microsoft created a culture that expects to have admin rights. That includes many users, many programmers, many end-user customers, many of Microsoft's customers, and many ISVs. Simply saying "don't run as admin" wasn't working. I don't think it's likely that changing OOBE (out-of-box experience) to create separate accounts would help, either. People (or software) would just use the admin account for everything. So AAM was created. AAM is basically an attempt at letting a user have admin rights but not actually running with admin rights. The end result may or may not do anything to help lusers who insist on having admin rights all the time, but it just gets in the way of IT professionals who have been using separate admin accounts for years. I recommend keeping UAC enabled because it does have other benefits. Filesystem and registry virtualization needs UAC to work, and FS&R virtualization is (in my experience) the *only* actual improvement in Vista. UAC also lets Windows prompt for alternate credentials when an unprivileged user attempts a privileged operation. Thus an admin can provide privileged credentials when needed, without a full-blown separate logon. The above is my opinion and analysis. It differs significantly from the Microsoft party line. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ -- Sherry Abercrombie "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
