Re: Service accounts best practices

From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 06/20/05

  • Next message: Joe Richards [MVP]: "Re: Service accounts best practices" 
    Date: Mon, 20 Jun 2005 07:06:12 -0700

    I'll try to give it a quick review today and forward link along
    (weekend :-) 

    -- 
Roger
"Ferdie" <ferdie@sane.rr.com> wrote in message
news:OeCOCSJdFHA.1356@TK2MSFTNGP10.phx.gbl...
> Thanks for the war story Joe.  I like hearing about successful security
> implementations where the risk is high.  I just forwarded it to my boss.
> He'll be all for it, especially since it costs nothing.
>
> Now I can't wait for the article from Roger.
>
> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> news:eu0VJb5cFHA.3040@TK2MSFTNGP14.phx.gbl...
> > When I walked in the door there were on a multimaster NT4 domain setup
and
> > they had something like 75 domain admins across the world and about 6
> > generic Domain Admin IDs that were known to an unknown number of people
> > but guessed to be greater than 200 people. They had a terrific issue
with
> > change control and things were just broken that no one could figure out
> > why they were broken.
> >
> > Within 3 months I had removed all but one generic ID though the password
> > of that account was changed[1] so no one knew it but me. The 75 domain
> > admins were dropped to 12 and 15 others were changed to ServOps. As I
got
> > to learn more about what they all did, the servops were dropped
completely
> > and the domain admins got dropped to 5 which was the size of the
official
> > domain admin team at the time. That took about a year to accomplish but
> > mostly because I wasn't familiar with the environment and what things
> > people were supposed to be doing and the fact that it was NT4 which
can't
> > be delegated like AD can. You can guess I wasn't very popular and had
> > people known where I sat, what I looked like, and what vehicle I drove I
> > may not be here to type this. However, I was very devious and sneaky and
> > no one really knew who I was. Eventually people started noticing that
the
> > environment had gotten considerably more and more stable as it got
locked
> > down to the point where it simply just ran and had very very few issues.
> > At this point, people who said they couldn't do their jobs still could
and
> > things were just changing in the environment causing other things to
> > break.
> >
> > When we moved to 2K we started with 5 DAs, no serv ops. There was
limited
> > AD delegation to thousands of local site admins for creation/deletion of
> > workstation accounts (not server accounts) and the ability to update
> > membership and description on groups. All user admin was proxied through
a
> > provisioning system so the local site admins did not have native rights
in
> > the directory for users.
> >
> > I took a 6 month summer sabbatical from being the tech lead for the
> > company (I was fired by the consulting firm I was working for) and the
> > Fortune 5 company brought me back in through another company and had me
> > insource the support of the Active Directory and be the technical lead
> > again.  At that point, the DA list had grown to about 10 or so again. I
> > took over the directory and we went to 3 Engineer DA's and one manager
> > with DA rights. That occurred overnight when we took it over.
> >
> > It isn't necessarily easy but you have to make the decision to do it and
> > stick to it. I haven't heard many if any good reasons for people to have
> > domain admin rights. In fact my team didn't normally run with domain
> > admins rights. They did most troubleshooting with normal user ids and
only
> > used domain admin when they knew they were going to go in and change
> > something or if there was something that absolutely couldn't be viewed
as
> > a non-DA which was very few items. So few I can't even remember them.
> >
> > A lot of it though comes down to actually understanding how security and
> > Windows works so you can push back when someone says they need some
level
> > of access rights. There was more than one occasion where I wrote some
> > software to prove to a vendor they didn't know what they were talking
> > about.
> >
> > Make sure every person who says they need that access explains exactly
why
> > they need it. What does the program do that requires that access and how
> > come it isn't done in a better way? The biggest pain in the *** issues
> > were around monitoring, software delivery, and AV. In the end, I said if
> > our team didn't run those components for the domain controllers, they
> > wouldn't be run on the domain controllers and they weren't. AV isn't
> > needed if the people with write access to the DCs are intelligent about
> > how they use their IDs. Software delivery and monitoring can be handled
in
> > different ways, you don't need agents on the domain controllers running
in
> > DA or localsystem. If you do, anyone controlling those tools are also
> > domain admins so you might as well give them that access up front and be
> > honest about it.
> >
> > As you run into issues. Feel free to post them here and get ideas or
> > possible join the activedir.org list and post them there.
> >
> >
> >    joe
> >
> >
> > [1] It was changed every time I had to give it out which was for new DC
> > installs because there was a very interesting DC install process that
was
> > followed. The DCs came from Dell as DCs that were built from a copy of
the
> > domain we had in production.
> >
> >
> >
> > --
> > Joe Richards Microsoft MVP Windows Server Directory Services
> > www.joeware.net
> >
> >
> > Ferdie wrote:
> >> Don't get me wrong, I'd like to get there.  But how long did it take
you?
> >> I guess it would help to start off that way.
> >> I think I need a guide specifically targeting all of the resistance
that
> >> I'm about to hit.  I can't seem to find the right one.
> >>
> >> "Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> >> news:ucqcGe4cFHA.4064@TK2MSFTNGP10.phx.gbl...
> >>
> >>>It really doesn't do anything for you. They can simply give themselves
> >>>the rights back.
> >>>
> >>>The only people who should have domain admin rights are the exact
people
> >>>doing domain admin work and it should be a very small group. I had
three
> >>>people as domain admins of a fortune 5 forest consisting of 250k users
> >>>and about 400 domain controllers globally distributed. No services had
> >>>those rights, they were all delegated.
> >>>
> >>>--
> >>>Joe Richards Microsoft MVP Windows Server Directory Services
> >>>www.joeware.net
> >>>
> >>>
> >>>Ferdie wrote:
> >>>
> >>>>I need to be careful though.  The DB group teaches me nice things like
> >>>>SQL queries.  I think if I just remove the right to log on locally to
> >>>>any box, then that would reduce the vulnerability a little.  Its a
small
> >>>>step for now, but a huge step in breaking the comfort level.
> >>>>
> >>>>"Joe Richards [MVP]" <humorexpress@hotmail.com> wrote in message
> >>>>news:%23ECPTKtcFHA.456@TK2MSFTNGP09.phx.gbl...
> >>>>
> >>>>
> >>>>>Make them document exactly why they need domain admin. I have done
this
> >>>>>dance with several vendors. Generally they say that because they have
> >>>>>no idea what their app needs nor why.
> >>>>>
> >>>>>  joe
> >>>>>
> >>>>>--
> >>>>>Joe Richards Microsoft MVP Windows Server Directory Services
> >>>>>www.joeware.net
> >>>>>
> >>>>>
> >>>>>Ferdie wrote:
> >>>>>
> >>>>>
> >>>>>>Can someone point me to a guide to securing service accounts?  I
have
> >>>>>>some accounts that require Domain Admin rights (or so they say), but
> >>>>>>don't need to log on locally.  I'd like to remove that right, so
that
> >>>>>>they don't use it to bypass the logical access control.  There might
> >>>>>>be some other issues that come up, so I might need a guide.
> >>>>>>
> >>>>>>Thanks,
> >>>>>>Ferdie
> >>>>
> >>>>
> >>
>
>
  • Next message: Joe Richards [MVP]: "Re: Service accounts best practices"