Re: Service accounts best practices
From: Joe Richards [MVP] (humorexpress_at_hotmail.com)
Date: 06/18/05
- Next message: ArizonaRay: "How do I prevent the use of tools like Hyena from gaining info"
- Previous message: Ferdie: "Re: Service accounts best practices"
- In reply to: Ferdie: "Re: Service accounts best practices"
- Next in thread: Ferdie: "Re: Service accounts best practices"
- Reply: Ferdie: "Re: Service accounts best practices"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 17 Jun 2005 19:46:29 -0400
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: ArizonaRay: "How do I prevent the use of tools like Hyena from gaining info"
- Previous message: Ferdie: "Re: Service accounts best practices"
- In reply to: Ferdie: "Re: Service accounts best practices"
- Next in thread: Ferdie: "Re: Service accounts best practices"
- Reply: Ferdie: "Re: Service accounts best practices"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]