|
> - Joe, are there
legitimate cases where an explicit ACE has been assigned in the directory?
Sure
in a normal delegated environment you will find all sorts of explicit ACEs. The
reason I say to look for explicit ACEs is because there is no reason to go
looking at all of the inherited ACEs since they all derive from an explicit
ACE somewhere above, it will just overwhelm. Looking at the explicit ACEs
narrows down how many you have to look at. If you later need to chase where they
can get inherited to you can still do that but getting a good idea of what is
out there initially is most important in my mind.
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noah Eiger Sent: Tuesday, February 14, 2006 11:01 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Hiding in the Directory Wow! Thank you. I had a
feeling that posting a question like that would generate some interesting
traffic. I am fortunate in this
case to be able to guide much of the policy (though there will be some battles)
as well as rebuild all of the DCs (they are all getting traded out for new
boxes). I also got them to sign off on forbidding anonymous IDs (which I have
stamped out except for those weird service accounts for Backup Exec or
Exchange). I believe that policies will backup the tighter security.
One thing I keep
running into is the fact that this company is geographically dispersed. Folks
feel they are “out there” alone and just as they want to be able to fix their
truck when it stalls, they want to tinker with their computers. For sure, this
shows up with the local-admin-demands-on-the-workstation fights but also on the
network. I need to be able to assure them that they are reasonably supported
“out there”. While there is lots to
ask about these responses, a few pop to mind: - Al, how has the
securing the Builtin administrator account password gone badly? I have done this
at several places and just want to know what to watch out
for. - Joe, are there
legitimate cases where an explicit ACE has been assigned in the directory?
- In a way, I am seeing
some folks with three accounts: standard users, administrator, and DA / EA. The
administrator account would be the one that gets some delegated
permissions. - Practical question: I
know how to prevent folks for logging on interactively but how can I restrict
admins from accessing the Internet on the machines where they can log in. (And
is that a good idea?) Thanks
again. --
nme From: Al
Mulnick [mailto:[EMAIL PROTECTED] Interesting joe. Builtin administrator
account should have a very long nasty painful password which is in an envelope
and in the safe or other locked location of a high level company official that
can not be retrieved easily. There should be no reason that ID needs to be used
unless things have gone very badly. If you have apps that require it for some
reason, you need to speak to the vendor. If they don't want to help, publish the
issue widely, loudly, and publicly; yes even if it is MS - maybe even especially
so, if anyone should be doing it right.... I have seen this go badly. Can I just say that you
need to include a policy AND a process that maintains this? I won't go into
detail, but it leads to the next one which is along with securing these rights,
secure the physical access as well. This is not always possible, but for
those times when it's not you should hope and pray that your monitoring catches
the reboots :) It just makes sense to review and reduce the people that
have physical access to the domain controllers at this time as well as to the
backup media.
joe [1] The last company I
did ops for, we had a rather long winded testing process for people before they
could get a Domain Admin ID. On average a new Enterprise Admins team employee
wouldn't get any admin rights for several months and before they did would get
to explain pretty much the whole environment to the current team and answer any
questions the team had until the team felt strongly about granting access. In
the meanwhile, the trainee gets to try and figure out issues with their normal
user id. Since a considerable amount of troubleshooting can be and should be
done with a regular ID, this means they can still be fairly productive and
learn. It doesn't mean they are fully knowledgable and can handle things on
their own, it simply means that the team is fairly confident the person isn't an
immediate danger to the environment. Absolutely! Almost all of the troubleshooting can
and most often should be done via a non-admin account. There's a lot of
information available without the EA or DA being needed.
-ajm On 2/11/06, joe <[EMAIL PROTECTED]>
wrote: My first thought is you
can't solve policy issues with technology. This is *clearly* a policy issue.
The first thing, IMO,
that needs to be done is for someone who has the power to come up with a policy
(or dig out an existing policy) of what will be done by anyone caught with admin
rights that shouldn't have them who got them after knowingly having them
removed. This policy needs to be strict, I would treat the person like someone
who has hacked the company. Putting in backdoors for yourself is something I
have seen people walked to the curb before and that is how you treat those
people. This isn't a game, it is corporate security policy. This should be made
clear in an official memo that is discussed with the individuals whose access
will be removed and have them sign it separately. If you have tons of folks or
if they are geographically disperse then just broadcast it to them, getting it
signed off by everyone will probably be too much. Allow the individuals to
report any and all mechanisms that they are aware of that they can gain admin
level rights. This won't solve much of anything if someone is the type that is
going to come in through a backdoor because you missed it but that gives a
handle to be used if you catch them at it. The next thing I think
is that I am lax to document in a detailed technically specific way all of the
different things to look for that I can think of because if someone is looking
to plant little backdoors this is a great way to get a list of places to do it.
Let me say that there have been a lot of good ideas put out already, any script
kiddie will be proud. ;o) I will try to give technically non-specific
generic things to look at for any insecure situation. I am sure some folks
will be like, "holy crap that is way overboard" and some other folks who
have seen bad things will be like "is that all?". When I think about security
around Domains and DCs I err on the side of secure and painfully tight. I don't
think of this from the standpoint of "so-so" security for small companies
where the compromise of a DC would be a "oh darn I need to reload" event but
from the standpoint of large companies where compromise of a DC could mean
serious dire consequences and billions of dollars. Rebuild every
single DC from scratch. Consider the situation to be a compromised
environment. You do not know where you stand, rebuilding is a valid thought. If
you can't rebuild a DC, you need to do a complete audit on it. All services, all
registry entries that can be used to launch apps, binaries, services, shares,
file/folder ACLs, scheduler, etc. It is easier and faster to rebuild the
machines from scratch though if you audit them properly. Plus rebuilds steps
around root kits. Remove all IDs from any
native admin groups of personnel who are not vetted or authorized (your bad if
you authorized individuals without a vetting process, don't give admin rights to
people you don't have a strong knowledge of and who don't have a strong
understanding of the environment they are getting rights over[1], i.e. don't
trust blindly). If you have any more than 3-4 people in Enterprise/Domain Admins
group, you need to understand completely why and there shouldn't be any IDs that
aren't assigned directly to a SINGLE human being. Anything else that requires a
generic or application type Domain Admin ID is either being handled in a lazy
way or is an app you should consider not using. Do not give acc ops, srv ops,
etc to any ID. Do not use native right groups in the domain. They have too much
power. DAs and EAs should be populated, nothing else.
Scan all DefaultSDs on
schema classes and look for anything out of the ordinary. I would focus on user,
computer objects, container (OU, Container, DomainDNS, etc) classes but review
all of them. You could do a quick scan of metadata and look for anything changed
since these folks got access. Scan for all explicit
ACEs on all objects in the directory. Write the script to toss out anything that
doesn't offer some level of Write or Control Access as that is the key part
initially, I would make the script so that it also tossed out the common
"normal" write accesses like anything everyone change password, etc. Also filter
out all DA, EA, System, and Domain Controller ACEs. I would be extremely picky
about looking at the adminsdholder object. Investigate everything
under sysvol. Remember that global scripts and gpo's can be nice friends
they can also be horrendous enemies. This includes reviewing every single
setting in every policy that can apply to DCs. Rebuild the
workstations used by the domain admins from scratch, use vetted media.
Physically secure them from access by anyone who isn't a domain admin. Laptops
are the best solution and require the admin to not leave the machine unattended.
Consider syskey or disk encryption that requires something from the actual admin
to get in. I do not allow any software to autoupdate on Admin workstations, this
includes software delivery, windows update, AV autoupdate, etc. Obvious the
corollary is that DAs don't use any machine not their own.
DAs must use different
password for their normal ID and admin ID. They need to understand why. If they
cannot quickly comprehend why, they are no longer domain admins. IMO,
domain admins should be security experts. They are the caretakers of your
security bastion. Put a logon script into
place that prevents domain level admin IDs from logging into workstation class
machines (this is something you should always do anyway). I would also seriously
considering putting the same mechanism into place for any servers that
haven't been vetted. Of course if someone is really good, by the time the logon
script runs it is too late anyway, but most people trying to compromise
environments aren't that good. This is where policy statements come into play as
well, tell your domain admins that they DO NOT LOG interactively into machines
they do not trust implicitly. Better yet, have a list of machines that
DAs are allowed to log on interactively, if they log into a machine not on that
list, they lose domain admin rights, they have proven themselves
untrustable. Obviously, DAs do not
have mailboxes. Builtin administrator
account should have a very long nasty painful password which is in an envelope
and in the safe or other locked location of a high level company official that
can not be retrieved easily. There should be no reason that ID needs to be used
unless things have gone very badly. If you have apps that require it for some
reason, you need to speak to the vendor. If they don't want to help, publish the
issue widely, loudly, and publicly; yes even if it is MS - maybe even especially
so, if anyone should be doing it right....
joe [1] The last company I
did ops for, we had a rather long winded testing process for people before they
could get a Domain Admin ID. On average a new Enterprise Admins team employee
wouldn't get any admin rights for several months and before they did would get
to explain pretty much the whole environment to the current team and answer any
questions the team had until the team felt strongly about granting access. In
the meanwhile, the trainee gets to try and figure out issues with their normal
user id. Since a considerable amount of troubleshooting can be and should be
done with a regular ID, this means they can still be fairly productive and
learn. It doesn't mean they are fully knowledgable and can handle things on
their own, it simply means that the team is fairly confident the person isn't an
immediate danger to the environment. -- O'Reilly Active
Directory Third Edition - http://www.joeware.net/win/ad3e.htm From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On
Behalf Of Noah Eiger I
have been asked by a company to help them tighten what is currently a very loose
security model. Now, several non-IT-but-computer-adept employees have accounts
with full Domain Admin privileges. Many of these folks are programmer types and
pretty savvy (which leads them to think they know what they are doing – that's
another story). They are also aware that we are going to tighten things down.
For political reasons, we could not just yank their admin access.
So
the question is: if you were one of these folks and were inclined to mischief
(or simply ensuring your continued access), how might you hide yourself in the
Directory? More to the point: where should I look beyond the obvious group
memberships? Thanks. --
nme -- -- -- |
