|
Posted by Roger Abell [MVP] on October 19, 2005, 12:33 am
If you were Registered and logged in, you could reply and use other advanced thread options
I have placed some comments inlined with your questions.
In general, there are some good papers on practices, but not
to my awareness ones that address you questions.
> I'm a little rusty with AD security...but was wondering if there are
> resources out there or can anyone break down what the best practices are
> regarding overall Domain security in terms of Administrators.
>
> 1. How many built in administrator accounts are there? Is there just one
> overall domain "Administrator" account who is part of the Domain
> Administrator group for an AD Forest? Should you rename the ID and then
> change the Administrator password and keep this in an encrypted DB or in
> an
> envelope just in case the Admins leave the company?
>
The is one built-in Administrator account per domain, and one per machine
(that
is not a DC) that is local to that machine only.
The practice of renaming the Administrator account was once a standard
practice. These days many people call the value of doing so into question.
The old, time honored approach was, it it is an install default and it is
changeable
then change it if its being at default could pose a risk. In fact, changing
it only
really serves as a bump in the road to the naive or those working in the
blind.
If your machine is exposed so that authentication attempts can come from
uncontrolled sources, then IMO renaming it is a gain. Whatever the truth,
renaming is simple and painless.
> 2. Should you rename all Administrator accounts, enable logging on the
> domain in case that password is changed and then make all the Sys Admin's
> use
> their own IDs as part of the Domain Admin group?
>
Rename issue already addressed.
Logging is only of value to the extent that someone is looking at the logs.
What is the problem with the password being changed ???
I would recommend that the built-in just be given a long, complex
passphrase,
and then set aside as an admin access account held in reserve but otherwise
not used day to day.
You SysAdms should IMO have two accounts: one is their plain user account
used for most all day to day office activities (email, etc.) , an account
not unlike
those of any other employee/manager/owner; the other account is empowered
to do what they need to do.
However, for most day-to-day administrative things one does not need to use
a Domain Admins account. It really depends on your abilities and your need
to be protective. One can delegate must of the common tasks to an account
that is not an admin - whether this is doable depends on familiarity with
doing so.
The Domain Admin accounts can do basically anything, see into pretty much
any file on any machine, etc. if one has an out-of-the-box setup. That is
way
too much capability for some people - for example if they only need to reset
passwords.
> 3. Are there many services on domain controllers that use "Administrator"
> for system access? Would you have to change that password as well or does
> it
> propagate automatically?
>
There are no services running as Administrator unless perhaps due to the
installation of some third-party application.
When a service is set to run as a particular account, and the password of
that account is changed, then the password also needs to be changed in
the services.msc for that service.
> Whats the best way to limit the abuse of a domain admin, make them
> accountable, log their actions but still allow them to do their day to day
> duties such as add/remove users, change persmissions, reset passwords,
> etc?
> I'm looking for overall best practices to eliminate the use of that shared
> Administrator ID (Or any domain Admin ID for that matter). We're looking
> to
> prevent abuse of power but not interfere with job duties. We want to
> rename
> this ID but then also at the same time we need to know the effects within
> the
> enterprise on doing so. How many different types of depedencies are there
> on
> this built in ID?
>
The best way to limit abuse is to use delegation so that individuals have
capabilities that match their tasks. Make a domain admin account available
for use when it is really needed, but that is not all that often for
changes.
With delegation used, domain admin can end up used more often for monitoring
etc. to see that all is or is not well.
Renaming any account is not an issue most of the time. It is usually the
SID
that is used by the system, not the display sting (like "administrator").
There
are some exceptions where an application or service has stored the name of
the account instead of its SID (for example, in IIS, or services that run
under
a specific account, etc.)
> Any help, assistance, comments or references to some good best practice
> security articles on AD would be great. Thanks!
>
--
Roger Abell
Microsoft MVP (Windows Server : Security)
MCDBA, MCSE W2k3+W2k+Nt4
| 
XML site map