|
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 -- -- -- |
- RE: [ActiveDir] Hiding in the Directory Noah Eiger
