May be time to look for a new rope on a different ship. Been there done that got the scars to prove it. Sometimes you just have to move on.
Jon On Fri, Nov 12, 2010 at 3:44 PM, Ziots, Edward <[email protected]> wrote: > Yep, the hole DCMA trick defintely is a eye-opener, but that has also > been dealt with accordingly, and folks understand that risk quite well. > That and the BSA stuff defintely will wake up folks accordingly. > > > > The part I get frustrated about is trying to do things by the best > practices and apply the correct security principles to my systems, and being > sniped at and second guessed every second of the way, does not make one > happy at all, even though implementing these foundations will seriously > raise the bar security wise, even though some people are going to lose > access they should have never had in the first place, but can’t seem to win > that argument accordingly. Like I said at the end of my rope. > > > > Z > > > > Edward E. Ziots > > CISSP, Network +, Security + > > Network Engineer > > Lifespan Organization > > Email:[email protected] <email%[email protected]> > > Cell:401-639-3505 > > > > *From:* Jon Harris [mailto:[email protected]] > *Sent:* Friday, November 12, 2010 3:19 PM > *To:* NT System Admin Issues > *Subject:* Re: Questions on the Application of Restricted Groups to Local > Groups on Servers, Workstations > > > > That is one diatribe that does not get old at least to me. Another thing > that would get the powers to be to see the light is an audit of software by > a vendor that cost the company big time for violation of > agreement/copywrite. You know like someone in the company getting caught > with unlicensed music, video, or software. That also seems to get them on > board with killing off advanced permissions. > > > > Jon > > On Fri, Nov 12, 2010 at 2:53 PM, Ziots, Edward <[email protected]> > wrote: > > Well that has already been dealt with ( common admin credentials, no more) > the real problem is permissions beyond ones job responsibilities, and the > risk that it entails, and the politics that goes with it. I think every > organization has that issue to some degree, but as we have seen in various > instances lately, failure to apply least privilege, and separation of duties > comes back to bite those organizations accordingly in a big way. ( Just > remember the incident in SF with the Rogue Network admin that basically held > the cities network at ransom) > > > > Nothing moves as fast or as well as I would like to see them or how they > need to do it correctly, so the frustration level goes up through the roof. > > > > Simple part, if you do the right things and stay diligent then the bad > stuff is less-likely to happen to you, but as Jim said, it takes a > catastrophe until someone “gets it”. > > > > Ok enough of my diatribe, > > > > Z > > > > Edward E. Ziots > > CISSP, Network +, Security + > > Network Engineer > > Lifespan Organization > > Email:[email protected] <email%[email protected]> > > Cell:401-639-3505 > > > > *From:* Kennedy, Jim [mailto:[email protected]] > *Sent:* Friday, November 12, 2010 2:45 PM > > > *To:* NT System Admin Issues > *Subject:* RE: Questions on the Application of Restricted Groups to Local > Groups on Servers, Workstations > > > > You need a virus outbreak that hits every box in a whole building across > the wire using the local admin credentials that are common between the > boxes. That was what it took here. > > > > *From:* Ziots, Edward [mailto:[email protected]] > *Sent:* Friday, November 12, 2010 2:37 PM > *To:* NT System Admin Issues > *Subject:* RE: Questions on the Application of Restricted Groups to Local > Groups on Servers, Workstations > > > > Actually, not when the cards are stacked against you… > > > > Z > > > > Edward E. Ziots > > CISSP, Network +, Security + > > Network Engineer > > Lifespan Organization > > Email:[email protected] <email%[email protected]> > > Cell:401-639-3505 > > > > *From:* Jon Harris [mailto:[email protected]] > *Sent:* Friday, November 12, 2010 1:57 PM > *To:* NT System Admin Issues > *Subject:* Re: Questions on the Application of Restricted Groups to Local > Groups on Servers, Workstations > > > > Keep trying and don't give up that fight it will be worth the effort in the > long run as you know. > > > > Jon > > On Fri, Nov 12, 2010 at 1:54 PM, Ziots, Edward <[email protected]> > wrote: > > Thanks guys, > > > > Reviewing it now and testing out the OU to start ripping and removing the > bloat in the local admins group, even though I lost my battle with further > restrictions of those groups, and following the least privilege best > practices. > > > > Z > > > > Edward E. Ziots > > CISSP, Network +, Security + > > Network Engineer > > Lifespan Organization > > Email:[email protected] <email%[email protected]> > > Cell:401-639-3505 > > > > *From:* KenM [mailto:[email protected]] > *Sent:* Friday, November 12, 2010 1:00 PM > *To:* NT System Admin Issues > *Subject:* Re: Questions on the Application of Restricted Groups to Local > Groups on Servers, Workstations > > > > There are a few ways you can do this. One would be in the restricted group > settings, create new group. The name would be the local group of the server > so Administartors and "Power Users". Add the local admin account and > whatever domain accounts in there. > > The other way would be to add a Domain Group in the GPO and set that as a > member of the local groups. The difference between the two is that the first > one will clear the group membership and the second one will just add to the > local group. Here are a few links. > > > > http://technet.microsoft.com/en-us/library/cc785631%28WS.10%29.aspx > > http://www.frickelsoft.net/blog/?p=13 > > > > > On Fri, Nov 12, 2010 at 12:48 PM, Ziots, Edward <[email protected]> > wrote: > > For those that have worked with the Restricted Group Functionality in > Windows 2003, Windows 2008 R2. I have the following questions. > > > > I am looking to create some group polices that will affect the local > administrators, power users groups on a set of computer objects (servers) in > particular OU’s. > > > > I am looking at using Restricted Groups to allow this to happen, so my > scenario would be the following. > > > > 1) How to designate the Local administrators group of the > Server/Servers within the GUI of the group policy Object, so I can say that > Group X in Domain X should be a member of the local administrators group > enforced by this group policy which is applied to the OU in which the > computer objects apply. ( Same would go for Power Users). > > > > Any white papers, or KB articles that have been of use in your application > of this feature would be greatfully appreciated, since the management here > needs this to happen in short order. > > > > Please advise, > > EZ > > > > Edward E. Ziots > > CISSP, Network +, Security + > > Network Engineer > > Lifespan Organization > > Email:[email protected] <email%[email protected]> > > Cell:401-639-3505 > > > > ~ 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 > > ~ 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 > > ~ 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 > > ~ 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 > > ~ 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
