|
Can be overcome.
I won't document specifics because I don't believe in
publishing publicly details on security issues that can't be blocked, but
anything you do that involves locking admins out of something can be overcome
except maybe for some file encryption stuff, maybe. I say file encryption simply
because I haven't dug into it, if I did, possibly I would know for sure that
could be overcome as well.
Restricted groups will raise the bar for entry though. Just
like many of the other compensating factors. The thing you are doing is slowing
down someone who doesn't know enough or slowing down someone who does know
enough to be caught up by auditing and monitoring but does anyone truly monitor
that closely? The better be if there is a question of trust with the
admins.
I agree with Gil that trust is granular and actually
started to put that into my last post but thought it was already too long. The
spirit in that is wrapped in the statement here
"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."
When it comes down to it in the end, you can't trust anyone
but yourself to do what is best for you. No one will do what is best for the
company unless that also works out for themselves. You have to make a judgement
call that the things that the person would do fall within an acceptable range
for you and if you are looking out for the company, for the company as well.
For instance, I was trusted to manage some pretty serious
systems and pretty much I wouldn't be questioned a whole lot on anything I
thought needed to be done and if I was questioned the chances are good I could
prove out technically why it must be done that way whether or not it really did
or not. However, I wasn't trusted very much to go talk on my
own to management outside of my chain or to users and very few developers.
When I did that, things tended to blow up because I have a habit of not coddling
people in terms of systems and security and architecture. Actually I think my
last firing had in great part to do with the fact that I sent an email to the
Director of IT pointing out deficiencies I saw in the corporate IT direction and
that we were headed for some trouble if some things weren't taken into account
and corrected.
A lot of people don't like that from analysts and get
whiney or upset or mad. They don't want to hear that something isn't safe or
perfect or great, they want to hear that they can sleep soundly every night and
never worry about a problem. That way when something goes pear shaped they can
come back and yell at the person who told them that and point them out for the
firing squad. If my systems can take a backwards turn at 2AM and I have to deal
with it, I want to get that out in the open the first day I take it on or find
out about it, not 6 months later after it happens. On the positive side, my
management and myself rarely got caught in something we couldn't fairly easily
handle or hadn't had some expectation of happening. My group was the only
support group not working during the great blackout a few years ago. We came in
and checked out what was happening and walked around for a bit and then I
jumped in my topless wrangler and drove home in a mad crazy rain shower
laughing and enjoying myself all the way.
joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CC/DNA) Sent: Wednesday, March 09, 2005 12:22 PM To: [email protected] Subject: RE: [ActiveDir] Problem: Limit Domain Admins and Administrators How about using a GPO’s restricted group feature and only granting Enterprise Administrators the ability to manage that GPO. You could set that on the Site Level (Although I am not a big fan of Site level GPO’s)
Todd Myrick MVP
From: Ruston,
Neil [mailto:[EMAIL PROTECTED]
These are all valid points but when put into practice can be troublesome.
Firstly, who monitors the admins? It certainly cannot be the admins themselves, so then who should it be? If the buck stops somewhere outside these admins, then where does it actually stop? Ideally, a forest (and each domain) is assigned an owner, who would be that person. Deciding who that should be is the tough part, however.
Secondly, where are these admin events sent? If sent to a console that the admins themselves manage, then again, we have a conflict of interest. So now we need a separate, secure, isolated application which monitors the admins and sends alters to this as yet undefined forest / domain Owner. How do we implement this such that the Admins cannot alter the data in that app etc etc?
Change Auditor is a great facilitator which may be used to help monitor the admins, but the 2 points above (and no doubt others) still need to be understand, addressed and overcome.
neil MVP - dir services
============================================================================== |
- RE: [ActiveDir] Problem: Limit D... joe
- RE: [ActiveDir] Problem: Li... joe
- RE: [ActiveDir] Problem: Li... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Li... Isenhour, Joseph
- RE: [ActiveDir] Problem: Li... deji
- RE: [ActiveDir] Problem: Li... Lee, Wook
- RE: [ActiveDir] Problem: Li... Perdue David J Contr InDyne/Enterprise IT
- RE: [ActiveDir] Problem: Li... Gil Kirkpatrick
- RE: [ActiveDir] Problem: Li... Isenhour, Joseph
