RE: [ActiveDir] Hiding in the Directory

[Sullivan Tim]

This is why I bought the book... Awesome post! From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, February 11, 2006 8:45 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Hiding in the Directory 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 Sent: Friday, February 10, 2006 11:54 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Hiding in the Directory 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 -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.15.5/256 - Release Date: 2/10/2006