Another comment, now would be a good time to implement something like this as you're changing server OS etc. We did this when we migrated to ActiveDirectory from NT4.0. Had a lot of whining and complaining at first, but once they got used to the new procedures, it wasn't a big deal.
On Thu, Jul 16, 2009 at 10:20 AM, Sherry Abercrombie <saber...@gmail.com>wrote: > I have two user accounts. One is my regular account that is associated > with my Exchange mailbox that only allows me access to my dept. share etc. > it's a limited access, typical user account. The other is a domain admin > that I use when I need to access (remote desktop, run as etc) something that > requires admin level privileges. It's very intentional to make us "think" > about what we are doing, allows for logging to be traced back to a specific > admin in the event that something needs to be looked at (rather than using a > "generic" domain admin account for all the domains admins in my group.) We > keep a separate enterprise domain admin account, and a schema admin account > that stays disabled until it is needed to make schema changes. > > We give our DBA's a specific DBA account that is only a local admin on > database servers, and we lock that account down to only being able to log on > the database servers so they can't log onto the Exchange server and muck > things up, and that DBA account is not a domain admin. > > Once you put something like this in place and enforce it, it's really not > difficult or hard to do, and doesn't impede productivity (no matter what > they might try to say to you about it, it doesn't impede productivity!) > > On Thu, Jul 16, 2009 at 9:54 AM, Miller Bonnie L. < > mille...@mukilteo.wednet.edu> wrote: > >> I realize that best practice will almost always dictate the most secure, >> but I’m talking about just the people that just need it here. I guess >> that’s what I mean—regular users don’t have any sort of access to even do a >> server logon, except for a few TS servers where permission are limited >> down. There are only a few people that do any sort of server management, >> and I’m talking about actual management stuff, like installing OS updates, >> firmware, software, etc, which requires higher privs. Or do you really log >> on as a user and then do a runas for pretty much everything? I’m mixing >> OSes here now, with mostly WS03 as opposed to the newer WS08 servers that we >> have. >> >> >> >> There are a few logons I would consider in a gray area where we could do >> it better, like a DBA that logs on as an admin on the server. But, when we >> tried to limit things down, it was tough enough to get it to the desktops. >> Even our admins get upset about having to elevate permissions to do things >> like connect to a share with another user name, etc. >> >> >> >> *From:* Sherry Abercrombie [mailto:saber...@gmail.com] >> *Sent:* Thursday, July 16, 2009 7: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 <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 >> >> >> >> >> >> >> >> >> >> > > > -- > Sherry Abercrombie > > "Any sufficiently advanced technology is indistinguishable from magic." > Arthur C. Clarke > > > > > > -- 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/> ~
