|
We use a couple of delayed replication sites
to help us fix screw ups more quickly. Don’t have to restore from backup
if you catch the problem soon enough. There are security implications though,
so it may not be for everyone. It’s helped on any number of occasions. Who watches the watchers is the eternal
dilemma of this untrustworthy world we live in. The best you can do is pick
good people and give folks enough access to do their jobs but no more. If you don’t
trust your admins, then either they stop being admins or you learn to trust
them. To do the latter, you have to invest some time, energy, patience and even
money to get them to where they need to be. In an industry where the Peter
Principle is all too applicable, you have to put people in a position to
succeed. Not easy, but you have to play with the cards you’re dealt,
right? Sometimes you have to take a chance and shoot for that inside straight.
Investing in the people may have greater return than any investment in
technology that we could recommend here. Wook From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Rick's comments are spot-on. Trust is a
gradient thing, not binary. You trust people *up to a point*. Where that point
is depends on you, your admins, and your environment. Unfortunately, delegation
of administrative rights isn't a gradient thing... you get rights in great
clumps. Once you put the domain admins I think a good approach
is "trust but verify". Grant the admins the rights they need,
and audit and review their administrative actions in detail and in real(ish)
time. You can catch and repair most screw ups before they have a significant
impact on the enterprise, and over time you develop a better (read: more accurate)
level of trust in your admins. Good service administration requires an up-front
approval process and a reliable auditing process. That's in fact why we built
Change Auditor for AD :) -gil From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Hey Rick, I didn't say how it should be
done below, specifically I didn't say fire anyone. I just indicated he couldn't
do what he wanted to do and other things that he has to avoid if he wants to
avoid that same issue. Actually I agree with what you recommended in your
previous post about spinning up role specific groups and delegated
permissions. The answer is really simple in all worlds,
mine, the perfect one, and the real one. Either you don't give people those
rights or if you can't go that route, you MUST realize and understand you
can't lock it down. No amount of doing anything will ever get you to the point
where you can block a determined and knowledgeable admin or someone who is in a
position to grant that to themselves. Period. One of the biggest security issues I see
anywhere is the assumption that things are safe due to people not understanding
the basic mechanics of Windows security. Because one person doesn't know how to
compromise a system or do something doesn't mean someone else doesn't,
that goes for you, me, Dean, or even your best MS Internal Security experts.
You can never prove a system safe, only unsafe. The straight up answer to any question of
how do I block a DA from doing x in the directory is always, YOU CAN'T. At that
point you make the decision of not granting the rights, granting the rights and
putting a bunch of procedures in place that make you think (or maybe you don't
but the infosec people do) it is safe to assuage yourself or a
clueless information security group[1], grant the rights and putting a
bunch of auditing around it, granting the rights and forcing yourself to trust
the person who you have given a gun. Once you understand you can't block DA's
from doing anything they want, EVER, you have to start to understand who can
get DA. The easiest is obviously anyone with admin rights on a DC. But anyone
who can manipulate services, drivers (even print drivers if the server executes
them) or any other system files, schedule AT jobs, can get local interactive
logon (this will depend on what vulns are currently available and not patched
on the DC or what files you can get placed where - lots of stupid admins you
can take advantage of), or anyone with physical access to the DC. The last thing we as a group should ever
say to anyone is that you can make an environment safe from Admins. We can't,
others can't. People need to understand that. Once people get over that
thought, then they are better prepared to come up with the solution that has
the consessions necessary to work. If a company doesn't have a very small
group of people that it can safely trust with its crown jewel of base security
(auth and authorization at least) then it has to concede that it has to give
permissions to people they can't trust and need the appropriate compensating
measures dependent on how much the company really cares whether or not the
person does something bad. joe [1] Being paranoid doesn't make you a good
security person, though it is a good start. Many security people I have met are
more paranoid than technical. Their technical knowledge is limited to
understanding how to use the the available security tools, not necessarily the
concepts and the guts behind them. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan joe – Great answer in a perfect world.
Great answer in the joe-run world. I’d like to do the same, but
it’s kind of funny that the guys I can’t really trust, the company
still employs because I can’t get evidence that is going to get them
fired to the degree in which HR is not going to spend the next 30 years in a
court room over false termination. If Rick Neuheisal can get $4.7 Million
for being fired as a coach because he violated NCAA rules, I’m sure that
the morons that I have to employ can make our life tough by being stupid on our
network. I can’t move them off to other
functions. Why? If I can’t fire them, I can’t replace
them. Management (upper) is kind of funny that way in the world that I
live in. The best that I can hope to do is to remove rights to the point
that if they piss themselves, it’s just their own mess – no one
elses. I suspect Mr. Lunsford is much more like
me. He’s in an environment where he has to employ people that
aren’t as good as we’d like them to be. Or, maybe even as
trustworthy as we’d like. So, that means that we:
Usually, the advice that “You
can’t do that” isn’t realistic. -rtk From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe You can't. Period. Solution: Don't give these people who are
untrustworthy administrator or any native group access and don't let them log
on interactively to your DCs or allow them to modify the file systems nor
registry nor services. Summary: You can't. Period. joe From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
|
- RE: [ActiveDir] Problem: Limit D... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Limit D... Ruston, Neil
- RE: [ActiveDir] Problem: Limit D... Myrick, Todd (NIH/CC/DNA)
- RE: [ActiveDir] Problem: Limit D... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Limit D... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Limit D... Isenhour, Joseph
- RE: [ActiveDir] Problem: Limit D... deji
- RE: [ActiveDir] Problem: Limit D... Lee, Wook
- RE: [ActiveDir] Problem: Limit D... Perdue David J Contr InDyne/Enterprise IT
- RE: [ActiveDir] Problem: Limit D... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Limit D... Isenhour, Joseph
- RE: [ActiveDir] Problem: Limit D... Grillenmeier, Guido
- RE: [ActiveDir] Problem: Limit D... Grillenmeier, Guido
- RE: [ActiveDir] Problem: Limit D... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Limit D... Isenhour, Joseph
- RE: [ActiveDir] Problem: Limit D... deji
