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

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
>
>

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
>>
>>
>
>

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
>
>

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
>
>

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

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
>
>
>

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
>>
>>

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
>>>
>>>
>

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
> >
> >
> >

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
newsBUMNC5cFHA.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
> >>
> >>
>

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
>>>>
>>>>
>>