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 <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/> ~