Service accounts best practices

Archived from groups: microsoft.public.win2000.security (More info?)

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
18 answers Last reply
More about service accounts practices
  1. Archived from groups: microsoft.public.win2000.security (More info?)

    They are mistaken. No service account requires local admin or domain admin
    privileges, unless possibly the account is intended to create, access or
    otherwise manage accounts. That's what domain admins are for. I would want
    to know exactly what it is the accounts or services need to do that requires
    domain admin privileges.

    Usually people, programmers or software companies claim that administrator
    privileges are required when all that is really needed is some file or
    registry permissions added to a normal user account.


    "Ferdie" <ferdie@sand.rr.com> wrote in message
    news:u1%23FADgcFHA.456@TK2MSFTNGP09.phx.gbl...
    > 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
    >
    >
  2. Archived from groups: microsoft.public.win2000.security (More info?)

    Agreed.

    I'm going to yank their DA privileges, and create a new account such as
    DA-username. But, I want to be fully ejumacated about giving them the needs
    that they want vs. best practices.

    "Karl Levinson, mvp" <levinson_k@despammed.com> wrote in message
    news:env5n$gcFHA.2124@TK2MSFTNGP14.phx.gbl...
    > They are mistaken. No service account requires local admin or domain
    > admin
    > privileges, unless possibly the account is intended to create, access or
    > otherwise manage accounts. That's what domain admins are for. I would
    > want
    > to know exactly what it is the accounts or services need to do that
    > requires
    > domain admin privileges.
    >
    > Usually people, programmers or software companies claim that administrator
    > privileges are required when all that is really needed is some file or
    > registry permissions added to a normal user account.
    >
    >
    > "Ferdie" <ferdie@sand.rr.com> wrote in message
    > news:u1%23FADgcFHA.456@TK2MSFTNGP09.phx.gbl...
    >> 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
    >>
    >>
    >
    >
  3. Archived from groups: microsoft.public.win2000.security (More info?)

    You need to look at each such service to see just what it is doing,
    and then provide for that. It is rare for DA to actually be needed,
    and should only be allowed after a case justifying it has been made
    (which would also provide you with a signature of expected behavior
    for the account - quite useful).

    So "want" this just because it is more simple to prescribe as a
    requirement instead of stating the specifics. Example, backup
    software (that is too often brain-dead about the existence of a
    Backup Operators group, or about simply using an account that
    has the backup user right granted) often states DA is needed as
    an assumption that one might want it to back up any possible
    machine in the domain, which is usually not a valid scenario.

    --
    Roger Abell
    Microsoft MVP (Windows Security)

    "Ferdie" <ferdie@sand.rr.com> wrote in message
    news:u1%23FADgcFHA.456@TK2MSFTNGP09.phx.gbl...
    > 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
    >
    >
  4. Archived from groups: microsoft.public.win2000.security (More info?)

    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
    >
    >
  5. Archived from groups: microsoft.public.win2000.security (More info?)

    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
  6. Archived from groups: microsoft.public.win2000.security (More info?)

    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
    >
    >
    >
  7. Archived from groups: microsoft.public.win2000.security (More info?)

    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
    >>
    >>
  8. Archived from groups: microsoft.public.win2000.security (More info?)

    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 butt 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
    >>>
    >>>
    >
  9. Archived from groups: microsoft.public.win2000.security (More info?)

    and . . .
    that very small group that do have access to a DA account
    should know not to use it when it is not needed, when what
    they are doing is accomplishable as say a server local admin.

    --
    Roger Abell
    Microsoft MVP (Windows Security)

    "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
    > >
    > >
    > >
  10. Archived from groups: microsoft.public.win2000.security (More info?)

    I have to fire up the laptop later, download and do some reading,
    but I just receive a listing of new guidance getting published on
    ms.com from the Patterns and Practices group, and one by its
    abstract sounds like just what you may be looking for, to effect
    guidance on granting admin accounts. I will post back after I
    review a little if it fits . . . but you are right, there are lots of
    mentions but not a great place to point an mgmt type nose.

    --
    Roger Abell
    Microsoft MVP (Windows Security)

    "Ferdie" <ferdie@sand.rr.com> wrote in message
    news:OBUMNC5cFHA.2696@TK2MSFTNGP09.phx.gbl...
    > 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
    > >>
    > >>
    >
  11. Archived from groups: microsoft.public.win2000.security (More info?)

    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 butt 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
    >>>>
    >>>>
    >>
  12. Archived from groups: microsoft.public.win2000.security (More info?)

    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 butt 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
    > >>>>
    > >>>>
    > >>
    >
    >
  13. Archived from groups: microsoft.public.win2000.security (More info?)

    Take your time.

    Some issues that I'll be looking for in the guide:

    Best way to give DB Admins access to Enterprise Admin.

    Best way to give Backup Operators access. We don't have the Backup Operators
    group. We're using W2K native mode.

    Best way to allow service accounts local access without access to log on
    locally.

    Best way to allow service accounts to copy files between multiple servers.

    Best way to allow Admins access to C$ shares.

    Best way to monitor access using a privileged account.


    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:OtQLxEadFHA.4040@TK2MSFTNGP14.phx.gbl...
    > I'll try to give it a quick review today and forward link along
    > (weekend :-)
    >
    > --
    > Roger
  14. Archived from groups: microsoft.public.win2000.security (More info?)

    Not only did it not cost anything, but it started saving tremendous amounts of
    money in support issues. Password issues started drying up, weird changes that
    would crop up that we couldn't determine where they came from but had caused
    various issues went away, etc. Basically, you get control of the environment. AD
    or even NT Domains that are not constantly being tweaked tend to run very well
    unless there are design issues with how it was put together.

    --
    Joe Richards Microsoft MVP Windows Server Directory Services
    www.joeware.net


    Ferdie wrote:
    > 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 butt 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
    >>>>>
    >>>>>
    >
    >
  15. Archived from groups: microsoft.public.win2000.security (More info?)

    Fredie,

    These are not going to cover that list, but may give some people
    some pause, if not food for thought.

    The Administrator Accounts Security Planning Guide
    http://www.microsoft.com/technet/security/topics/serversecurity/administratoraccounts/default.mspx

    The Services and Service Accounts Security Planning Guide
    http://www.microsoft.com/technet/security/topics/serversecurity/serviceaccount/default.mspx

    As I said, hot off the press, so I really have not had time to digest enough
    to be opinionated on these . . .

    --
    Roger Abell
    Microsoft MVP (Windows Server: Security)


    "Ferdie" <ferdie@sand.rr.com> wrote in message
    news:uvZOXebdFHA.584@TK2MSFTNGP15.phx.gbl...
    > Take your time.
    >
    > Some issues that I'll be looking for in the guide:
    >
    > Best way to give DB Admins access to Enterprise Admin.
    >
    > Best way to give Backup Operators access. We don't have the Backup
    > Operators group. We're using W2K native mode.
    >
    > Best way to allow service accounts local access without access to log on
    > locally.
    >
    > Best way to allow service accounts to copy files between multiple servers.
    >
    > Best way to allow Admins access to C$ shares.
    >
    > Best way to monitor access using a privileged account.
    >
    >
    >
    > "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > news:OtQLxEadFHA.4040@TK2MSFTNGP14.phx.gbl...
    >> I'll try to give it a quick review today and forward link along
    >> (weekend :-)
    >>
    >> --
    >> Roger
    >
    >
  16. Archived from groups: microsoft.public.win2000.security (More info?)

    Thanks for the links. FYI - I just saw these links on the GRC Security
    forums.

    Looks like a good read.

    "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
    news:OQA7ROhdFHA.2288@TK2MSFTNGP14.phx.gbl...
    > Fredie,
    >
    > These are not going to cover that list, but may give some people
    > some pause, if not food for thought.
    >
    > The Administrator Accounts Security Planning Guide
    > http://www.microsoft.com/technet/security/topics/serversecurity/administratoraccounts/default.mspx
    >
    > The Services and Service Accounts Security Planning Guide
    > http://www.microsoft.com/technet/security/topics/serversecurity/serviceaccount/default.mspx
    >
    > As I said, hot off the press, so I really have not had time to digest
    > enough
    > to be opinionated on these . . .
    >
    > --
    > Roger Abell
    > Microsoft MVP (Windows Server: Security)
    >
    >
    > "Ferdie" <ferdie@sand.rr.com> wrote in message
    > news:uvZOXebdFHA.584@TK2MSFTNGP15.phx.gbl...
    >> Take your time.
    >>
    >> Some issues that I'll be looking for in the guide:
    >>
    >> Best way to give DB Admins access to Enterprise Admin.
    >>
    >> Best way to give Backup Operators access. We don't have the Backup
    >> Operators group. We're using W2K native mode.
    >>
    >> Best way to allow service accounts local access without access to log on
    >> locally.
    >>
    >> Best way to allow service accounts to copy files between multiple
    >> servers.
    >>
    >> Best way to allow Admins access to C$ shares.
    >>
    >> Best way to monitor access using a privileged account.
    >>
    >>
    >>
    >> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    >> news:OtQLxEadFHA.4040@TK2MSFTNGP14.phx.gbl...
    >>> I'll try to give it a quick review today and forward link along
    >>> (weekend :-)
    >>>
    >>> --
    >>> Roger
    >>
    >>
    >
    >
  17. Archived from groups: microsoft.public.win2000.security (More info?)

    Yes, I believe the MS.com links went live Friday night.
    There is one more that may be of interest, dealing with making
    admin access to servers happen only with smart card login (even
    when that is the only use of smart cards in an infrastructure).

    --
    Roger Abell
    Microsoft MVP (Windows Security)

    "Ferdie" <ferdie@sand.rr.com> wrote in message
    news:eCsrZ4qdFHA.2664@TK2MSFTNGP15.phx.gbl...
    > Thanks for the links. FYI - I just saw these links on the GRC Security
    > forums.
    >
    > Looks like a good read.
    >
    > "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
    > news:OQA7ROhdFHA.2288@TK2MSFTNGP14.phx.gbl...
    > > Fredie,
    > >
    > > These are not going to cover that list, but may give some people
    > > some pause, if not food for thought.
    > >
    > > The Administrator Accounts Security Planning Guide
    > >
    http://www.microsoft.com/technet/security/topics/serversecurity/administratoraccounts/default.mspx
    > >
    > > The Services and Service Accounts Security Planning Guide
    > >
    http://www.microsoft.com/technet/security/topics/serversecurity/serviceaccount/default.mspx
    > >
    > > As I said, hot off the press, so I really have not had time to digest
    > > enough
    > > to be opinionated on these . . .
    > >
    > > --
    > > Roger Abell
    > > Microsoft MVP (Windows Server: Security)
    > >
    > >
    > > "Ferdie" <ferdie@sand.rr.com> wrote in message
    > > news:uvZOXebdFHA.584@TK2MSFTNGP15.phx.gbl...
    > >> Take your time.
    > >>
    > >> Some issues that I'll be looking for in the guide:
    > >>
    > >> Best way to give DB Admins access to Enterprise Admin.
    > >>
    > >> Best way to give Backup Operators access. We don't have the Backup
    > >> Operators group. We're using W2K native mode.
    > >>
    > >> Best way to allow service accounts local access without access to log
    on
    > >> locally.
    > >>
    > >> Best way to allow service accounts to copy files between multiple
    > >> servers.
    > >>
    > >> Best way to allow Admins access to C$ shares.
    > >>
    > >> Best way to monitor access using a privileged account.
    > >>
    > >>
    > >>
    > >> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    > >> news:OtQLxEadFHA.4040@TK2MSFTNGP14.phx.gbl...
    > >>> I'll try to give it a quick review today and forward link along
    > >>> (weekend :-)
    > >>>
    > >>> --
    > >>> Roger
    > >>
    > >>
    > >
    > >
    >
    >
  18. Archived from groups: microsoft.public.win2000.security (More info?)

    The Security Monitoring and Attack Detection Planning Guide
    http://www.microsoft.com/technet/security/topics/auditingandmonitoring/securitymonitoring/default.mspx

    I like this one too. It tells you what Event ID's to look for and what to
    skip.

    "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    news:uoBjatvdFHA.2212@TK2MSFTNGP14.phx.gbl...
    > Yes, I believe the MS.com links went live Friday night.
    > There is one more that may be of interest, dealing with making
    > admin access to servers happen only with smart card login (even
    > when that is the only use of smart cards in an infrastructure).
    >
    > --
    > Roger Abell
    > Microsoft MVP (Windows Security)
    >
    > "Ferdie" <ferdie@sand.rr.com> wrote in message
    > news:eCsrZ4qdFHA.2664@TK2MSFTNGP15.phx.gbl...
    >> Thanks for the links. FYI - I just saw these links on the GRC Security
    >> forums.
    >>
    >> Looks like a good read.
    >>
    >> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
    >> news:OQA7ROhdFHA.2288@TK2MSFTNGP14.phx.gbl...
    >> > Fredie,
    >> >
    >> > These are not going to cover that list, but may give some people
    >> > some pause, if not food for thought.
    >> >
    >> > The Administrator Accounts Security Planning Guide
    >> >
    > http://www.microsoft.com/technet/security/topics/serversecurity/administratoraccounts/default.mspx
    >> >
    >> > The Services and Service Accounts Security Planning Guide
    >> >
    > http://www.microsoft.com/technet/security/topics/serversecurity/serviceaccount/default.mspx
    >> >
    >> > As I said, hot off the press, so I really have not had time to digest
    >> > enough
    >> > to be opinionated on these . . .
    >> >
    >> > --
    >> > Roger Abell
    >> > Microsoft MVP (Windows Server: Security)
    >> >
    >> >
    >> > "Ferdie" <ferdie@sand.rr.com> wrote in message
    >> > news:uvZOXebdFHA.584@TK2MSFTNGP15.phx.gbl...
    >> >> Take your time.
    >> >>
    >> >> Some issues that I'll be looking for in the guide:
    >> >>
    >> >> Best way to give DB Admins access to Enterprise Admin.
    >> >>
    >> >> Best way to give Backup Operators access. We don't have the Backup
    >> >> Operators group. We're using W2K native mode.
    >> >>
    >> >> Best way to allow service accounts local access without access to log
    > on
    >> >> locally.
    >> >>
    >> >> Best way to allow service accounts to copy files between multiple
    >> >> servers.
    >> >>
    >> >> Best way to allow Admins access to C$ shares.
    >> >>
    >> >> Best way to monitor access using a privileged account.
    >> >>
    >> >>
    >> >>
    >> >> "Roger Abell" <mvpNOSpam@asu.edu> wrote in message
    >> >> news:OtQLxEadFHA.4040@TK2MSFTNGP14.phx.gbl...
    >> >>> I'll try to give it a quick review today and forward link along
    >> >>> (weekend :-)
    >> >>>
    >> >>> --
    >> >>> Roger
    >> >>
    >> >>
    >> >
    >> >
    >>
    >>
    >
    >
Ask a new question

Read More

Security Microsoft Windows