Users as local admins can be gotten around with enough resources and/or management backing. No-one should have to bear that cross.
---Blackberried -----Original Message----- From: David Lum <[email protected]> Date: Fri, 8 Jun 2012 16:29:00 To: NT System Admin Issues<[email protected]> Reply-To: "NT System Admin Issues" <[email protected]>Subject: RE: Reality check “separation of privileges or separation of duties which should be firmly entrenched in most workplaces” HAHAHAHAHHAHAHHAHAHAA! Oh wait, you said “should” Dude, our users are still local admins and I’m the only one who seems to care, not one of the 5 Service Desk guys are inclined to move us in that direction, they only see it as extra work. Only one other SE has a separate DA account for Domain Admin access, the rest of ‘em they’re normal accounts are DA accounts. Hmm…that might be a vent… From: Ziots, Edward [mailto:[email protected]] Sent: Friday, June 08, 2012 6:57 AM To: NT System Admin Issues Subject: RE: Reality check Seems strange that business users would have admin access to a server, which wouldn’t obey separation of privileges or separation of duties which should be firmly entrenched in most workplaces ( again YMMV as stated before). Z Edward Ziots CISSP, Security +, Network + Security Engineer Lifespan Organization [email protected]<mailto:[email protected]> From: Christopher Bodnar [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Friday, June 08, 2012 9:28 AM To: NT System Admin Issues Subject: Re: Reality check It depends on your environment. That's almost identical to the procedure we have here. When provisioning a new server here, part of the process is to create a new AD group with this naming convention: ACME_ADMINS_SERVERNAME This group is then placed in the local administrators group of the server. All business users that need admin access to servers have a separate account for that purpose. They submit a privileged access request, and when approved our "user admin" group adds them to the appropriate AD group that was created for the server. In a small environment this might be overkill. YMMV Christopher Bodnar Enterprise Achitect I, Corporate Office of Technology:Enterprise Architecture and Engineering Services Tel 610-807-6459 3900 Burgess Place, Bethlehem, PA 18017 [email protected]<mailto:> [cid:[email protected]] The Guardian Life Insurance Company of America www.guardianlife.com<http://www.guardianlife.com/> From: David Lum <[email protected]<mailto:[email protected]>> To: "NT System Admin Issues" <[email protected]<mailto:[email protected]>> Date: 06-08-12 09:14 AM Subject: Reality check ________________________________ A fellow team member (not an SE, but more of an application owner type of tech person) needs Local Admin access to a server to install and configure a new application on it. I understand the need and agree with it. Instead of just throwing his account into the local admin group on that server I did the following: Created a LA-<servername> account (LA= Local Admin) Created a security group called LA-<servername>_LocalAdmin, added the above to it Created a GPO to put said security group into local admins on that server My thinking is 1. This keeps him from using his daily account to be local admin on the box 2. I don’t have an individual assignment on that server In general, I view putting a user specifically into a server’s local group as the same as putting a user (instead of a group) into the ACL of an NTFS folder. If said employee leaves, it’s difficult/tedious to see where they had access TO so we have no idea where their replacement might need to be added. However, was that really too much work to give the guy the ability to log in as local admin? David Lum Systems Engineer // NWEATM Office 503.548.5229 // Cell (voice/text) 503.267.9764 ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ----------------------------------------- This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
<<inline: image001.jpg>>
