Huh?!? It's already over. It was at 11:30am eastern time. Shookie has left the building...
________________________________ From: David Lum [mailto:david....@nwea.org] Sent: Thursday, July 16, 2009 12:22 PM To: NT System Admin Issues Subject: RE: UAC--argh... LOL - yeah "what kind of login do you mean?" It keeps us busy, to be sure. Few things are more ambiguous than "my computer doesn't work" though... Just over an hour until SHOOKIE PRESENTATION time! Dave From: Miller Bonnie L. [mailto:mille...@mukilteo.wednet.edu] Sent: Thursday, July 16, 2009 9:35 AM To: NT System Admin Issues Subject: RE: UAC--argh... Exactly-that is what we do and what I'm talking about, so I think we are doing the same things. RDP to the server and use an admin account when logging on at that point. Normal user logon when on workstations. I'm sorry if that was confusing-I probably should have clarified "logon to servers" as using RDP or at the console. I'm guessing you thought I meant for something like a shared folder connection from a workstation. There are so many different types of logons! From: Sherry Abercrombie [mailto:saber...@gmail.com] Sent: Thursday, July 16, 2009 9:23 AM To: NT System Admin Issues Subject: Re: UAC--argh... 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. <mille...@mukilteo.wednet.edu> 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:saber...@gmail.com] 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. <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] 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/> ~
