roger abell mvp

Yeah, a few more years swimming upstream and we might start
to see the water changing (but I do not hold my breath either).

ra

robert moir

then why ask ;-)

I'd say it was good practice to keep them seperate as administering the
domain and administering workstations (and even servers) are really two
seperate jobs. In big business these tasks would be taken care of by two
totally different groups of people.

As a practical matter, you have to decide how important following this best
practice is for you on a day to day basis depending on the size of the
business you're supporting and your cir***stances - I'd not rush to
implement business practices that were designed for the internal networks at
Ford or HP or something like that if your network is a small home business
with 3 computers to its name and actually includes your pet dog in the list
of corporate officers, or if you work in the sort of office where it doesn't
matter how many passwords are set because they're all written down on a
whiteboard by the secretary's desk "just in case someone else needs
them"....


--
--
Rob Moir, Microsoft MVP
Blog Site - http://www.robertmoir.com
Virtual PC 2004 FAQ - http://www.robertmoir.co.uk/win/VirtualPC2004FAQ.html
I'm always surprised at "professionals" who STILL have to be asked "Have you
checked (event viewer / syslog)".

joe richards mvp

All IDs should have different passwords. The builtin admin ID of a
domain in fact should be set to some nasty long (25+) character password
that is impossible to memorize that is then do***ented and placed in an
envelope and locked in the safe of a high ranking manager. There should
be no reason to use that ID in the domain.

As for Domain Admin IDs, every Domain Admin (all at most 5 of them)
should have their own Admin ID and it should be different from their
normal day to day user ID. So for instance if their normal ID is joe
their admin ID could be $joe. Those passwords of those two accounts
should not even be in sync.

There should be no generic native admin type IDs in use, at best generic
IDs should be limited to services and the permissions should all be
delegated as then you are only giving what you need versus giving them
what they need plus whatever happens to come with the builtin groups.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
http://www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

adam leinss

Yes.

First rule of security: physical access.

Think about where you will be using a LAP and a DAP.

More food for thought why is using a DAP outside a secured area bad?

Adam
--
Visit my PC Tech blog at http://www.leinss.com/blog

steven l umbach

I am not sure what you mean here by local administrator. There are local
administrators on domain computers and the local administrator account on
domain controllers stored in the SAM and is used for Active Directory
Restore or Recovery Console. Either way it is best to use different
passwords. Unless that password is very strong it may not be that hard to
crack the password in the local SAM. Also what a lot are lax on is to NEVER
logon to a non secured domain computer with any privileged account in the
domain. Keyboard loggers or malicious scripts can be used to capture those
credentials or to take over the domain, Use a non privileged domain account
to manage domain computers other than domain controllers and use different
local administrator passwords on sensitive servers than domain
orkstations. --- Steve

roger abell mvp

You caught me by surprise Joe - seems you have become a little
liberal ("no more than five domain admins") perhaps from seeing
client practices in the field.

So, devils advocate here, why five?

I recall when I had to pass adv compiler construction, the prof
observed, as soon as the proc has more than one register it really
does not matter how many there, the complexity of object gen
changes at the one/more-than-one boundary.

It seems to me something similar holds true here. Domain admin
accounts tightly held and used only when/if necessary, or accounts
individually issued to the domain admins (letting the pig out of the
barn).

I case you didn't notice, I miss your prior hard line viewpoint.
It was totally valid. It was also something no one was willing to
say much as it went counter to the mainstream usage. However,
in the long run (meeting today's and tomorrow's auditability,
personal protection, etc.) it will proable become the dominant
approach.

Roger

joe richards mvp

LOL. 3-5 DAs was my usual stance with 3 being the one I felt the best
about. I find people whine less when I say 5 versus 3 though.

And when you really really get down to it you don't even need 3 full
time DAs.

I don't agree that the register ****ogy works here though. I think what
applies with DAs is that the more DAs you have the less each feels
ownership for the environment. In other words, more cooks in the
kitchen, all of them pay less attention and if there is a hair in your
soup you really don't know where it came from. The smaller the DA group,
the more careful each DA would be I think or at least from what I have
experienced.

Consulting has been interesting though I must say... I have gone from
doing support of one of the world's larger deployments with 3 DAs to
seeing lots and lots of deployments and just hoping that these smaller
deployments with only 100k or so users would cut down to less than 100
Domain Admins... Those that listen start running more and more stable
but man is it a fight trying to explain to people they don't need those
rights for most everything they are doing. The usual answer is that
people need them for troubleshooting, and when I say give me specifics
they almost never can give me something that really does require DA.
They give me examples of how they want to change something to see if it
fixes a problem... that isn't troubleshooting.


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
http://www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

roger abell mvp

Nice Joe, I have to remember the anonymous hair in the soup approach.
For some reason 3 DA stuck in my mind, so 5 seemed a major move <g>
playing by percentages. In the limit of absurd (100+-) DAs, the register
****ogy probably does break down, but comparing 5 to 10 to 20 I think
it has some merit - assuming sane practices of monitoring use of, etc, is
there, it is no more effort to do so 4x. Of course that never happens ;-(
I would think that the view of how 5 cf 100 potential accounts,
workstations,
etc. that could, or if hijacked could, pretty much go anywhere, access
anything, would motivate orgs to rethink their "compliance auditability"
at least (since their ears are getting buzzed with that one lately).
The bottom line is probably that we are an instant gratification society,
wherein "simplicity" is understood as directness of access to immediate
results more than other aspects as simplification of risk factors, etc..
Cheers

roger abell mvp

Of course I am going to say yes.
That is not why I decided to finally respond, however.

Think of the situation this way. You have a fairly large amount of
infrastructure. Any one of the machines recognizes its uber-master,
based only on whether it is a member of the Administrators group
defined on itself (or is System).
So, what you are actually asking is along the lines of
"How should I segement up this infrastructure so that, if one of
these uber-masters gets compromised, I can live with having that
entire segment placed at high peril?"
In the extreme you might say, minimize the ability of fire to spread,
which would mean each account uber-master has unique creds.
In the extreme that means somewhat more uber-master creds to
track than machines, which itself becomes a problem.
So, your task is to determine your tolerance for exposure, where
the segmentation boundaries should be (draw the firebreaks), the
frequency of change of creds, etc. all in order to keep the risks
from your choices contained.
Now, a further observation. If member servers and/or client
machines are managed with machine local admin accounts, then
those are stored in the machine's SAM - which means these can
be fairly accessible to "rightful users" of those machines under
a number of scenios (most involving misconfiguration or unpatched
flaws). If on the other hand, the uber-masters of the members are
only domain accounts, this SAM risk is removed; but the machines
become serviceable (depending on existing caching) most reliably
only when network connected or when the (one?) local admin
account is used. However, if Domain Admins are used in the
environment, compromise of one of these is catastrophic - hence
I would say DA should be used ONLY when there are no real,
reasonable alternatives. For example, the client machines of one
segment should not be routinely managed with a DA account (!)
but with domain account(s) defined for that client segment.
Also, if the machine local account is not strongly secured, or if
a uniform password is used over a segment of machines, then
what has been accomplished ?? Crack one SAM and access
the whole segment (depending on config, this might have to be
at the physical console however, or even only in a safe mode
boot). So, what does one do? Make unique-per-machine
admin passwords and have a way to do a look-up of these if
and as they become needed due to network unavailabiltiy ?

There are many choices - and these trade off daily operational
"simplicity" with configuration to effect "greater simplicity" of
any potential future recovery needs (segmentation/containment).

joe richards mvp

Yeah I am hoping as companies and administrators become more capable and
knowledgeable they start locking down more and more. I wouldn't bet a
lot of money on it because there is a lot of silly people out there with
a lot of silly ideas, but any company I deal with will certainly get an
earful if they are running more than 3-5 admins or if their admins
report to different management.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
http://www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm