I agree with the restricted groups approach, basically best of both world, but I also agree with the filemone/regmon/procmon minimalistic approach with file permissions in a GPO to assist with the situation, which hopefully gets ride of most of the LUA bugs, that these silly developers put us in as IT admins.
Z Edward E. Ziots Network Engineer Lifespan Organization MCSE,MCSA,MCP,Security+,Network+,CCA Phone: 401-639-3505 -----Original Message----- From: Kennedy, Jim [mailto:[EMAIL PROTECTED] Sent: Thursday, August 28, 2008 12:51 PM To: NT System Admin Issues Subject: RE: Local admins? We skin that cat this way..... Use the Restricted groups the same way. A support person hits the desktop and adds the user to the local admin's group. Can be done remote via computer management. That gives them enough time for the user add their software before the GPO blows them back out of the group again. Requires a relog by the user but if support forgets to take them back out right away GPO fixes it in short order. Your way works of course, just tossing out another way if it can be of any help. > -----Original Message----- > From: Stephen Wimberly [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 28, 2008 12:48 PM > To: NT System Admin Issues > Subject: RE: Local admins? > > There are going to be times when custom software will require the > installing > user to be the one using it later. Right now Blackberry desktop is a > pain > for me. For those we've done this: > > 1. Create a GPO to modify the BUILTIN\Administrators group on the local > workstations such that the local admins include, Administrator, > domain\Domain Admins, domain\LocalAdminGroup (Computer Policy: Windows > Settings: Security Settings: Restricted Groups > > 2. Create a security group within the domain called > domain\LocalAdminGroup > > 3. Whenever you feel like it you can move users in and out of the > LocalAdminGroup and their rights will elevate or decline, after a > restart of > course :) > > ======================== > > Here is how we've handled the three objections you listed: > > Windows update via WSUS > > Java updates via GPO (it's a pain to keep updated, but it's worth it) > > Antivirus updates via AntiVirus server > > > > -----Original Message----- > From: Anthony [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 28, 2008 11:52 AM > To: NT System Admin Issues > Subject: Re: Local admins? > > This getting rid of local admin track sounds great from all the > feedback. > > Doesn't updates need local admin, like: > > Windows Updates? > > Java Updates? > > Antivirus Updates (say stand alone version of AVG or Norton)? > > Those seem to be the main 3 I can think of offhand. Do most of you > figure > out ways around these with permissions and such, or just periodically > do > these updates with an admin account? > > Anthony > ----- Original Message ----- > From: "Phil Brutsche" <[EMAIL PROTECTED]> > Sent: Wednesday, August 27, 2008 4:56 PM > Subject: Re: Local admins? > > > In my environments NO ONE EVER gets local admin, politics be damned - a > common saying is "I don't care who you are, how much you make or who > you > know. You're NOT getting local admin." > > Sure there's some nuclear fallout once in a while, but everything runs > much > much smoother in the long run. By myself I'm ultimately responsible for > 300+ > machines and that many stations is *not* a big deal. It helps that the > most > complicated program 80% of those stations run is MS Office. > > Based on what I've seen, if you don't have local admin you're bordering > on > not needing AV & AS packages. Yes, it's a bold statement, but true in > some > of my environments - I've validated it over the years with a laptop > running > a commercial AV package (currently Kaspersky). The only things it > catches > are cookies and malware installers in home folders. > > Salvador Manzo wrote: > > Local Admin is the exception, and generally only occurs for political > > reasons. Apps which "require" local admin get run through FileMon > and > > RegMon to tear down minimum rights, and GPOs set any required > > permissions based on group membership. > > -- > > Phil Brutsche > [EMAIL PROTECTED] > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ > <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
