I use server admin console with the remote desktop snap-in from my workstation to connect and enter the domain admin credentials at that point, or I use the run-as whenever necessary. I never use my normal user account to log onto a server and rarely ever actually physically log into a servers console.
On Thu, Jul 16, 2009 at 11:10 AM, Miller Bonnie L. < [email protected]> wrote: > We also each have two accounts and separatation for Domain admins and > schema admins—I think the difference here is that we use the user one on > workstations and the admin one on servers. You’re saying you log onto both > as your user and then elevate where needed, right? > > > > *From:* Sherry Abercrombie [mailto:[email protected]] > *Sent:* Thursday, July 16, 2009 8:21 AM > > *To:* NT System Admin Issues > *Subject:* Re: UAC--argh... > > > > 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. < > [email protected]> 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:[email protected]] > *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 <[email protected]> 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:[email protected]] > *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:[email protected]] > *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:[email protected]] > *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:[email protected]] > *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:[email protected] <[email protected]>] > 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.<[email protected]> 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/> ~
