Service accounts best practices

[Ferdie]

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

 

[Karl Levinson, mvp]

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]

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.

 

[Roger Abell]

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.

 

[Joe Richards [MVP]]

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

 

[Ferdie]

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

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.

 

[Ferdie]

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

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.

 

[Roger Abell]

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]

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.

 

[Ferdie]

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.

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

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.

 

[Roger Abell]

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

--
Roger

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.

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

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.


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.



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

 

[Joe Richards [MVP]]

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

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.

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

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.



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.




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

 

[Ferdie]

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 [MVP]]

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

 

[Ferdie]

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

Looks like a good read.

 

[Roger Abell]

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)

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

Looks like a good read.

 

[Ferdie]

The Security Monitoring and Attack Detection Planning Guide
http://www.microsoft.com/technet/se...andmonitoring/securitymonitoring/default.mspx

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