joeware - never stop exploring... :)

I recently received the September 2006 edition of TechNet magazine. Overall, good magazine, kind of boring, but relatively good info.

There is an article that seemed right up my alley… Lock Up Your Domain Controllers written by Steve Riley (aka  Sterile Y). Steve is an interesting person; when you initially meet him you don’t know if he is a surfer or a crazy artist type but you almost certainly don’t guess corporate enterprise computer security guy… He is a heck of a speaker and if you fall asleep in one of his presentations you most likely need to be checked out for narcolepsy.

Unfortunately, for this article he starts off with a good question and, IMO, a bad answer…

“What happens if someone steals one of my domain controllers?”

There is only one correct answer:

“You flatten and then rebuild the entire forest.”

I just can’t get behind that response unless you, for some insane reason, let that DC get back onto your network before doing anything about the theft or only found out about it AFTER it is back (shame on you here as well, you are monitoring your DCs right?[0]). This isn’t the first time I have disagreed with Steve on AD based security things but overall I think he says good things. I can’t speak authoritatively but I don’t expect many on the DS team would read that article and be thrilled with that initial statement as well.

After the explosion filled “blown out of proportion” grandiose “meant for the movie trailer” opening Steve goes on to list the possibilities that now occur for a DC that has been thus compromised… I like the list, while it isn’t comprehensive (which is a good thing, no reason to hand out secrets), he is absolutely 100% correct in that it is now a machine you cannot trust.

So if you don’t flatten the forest, what things do you do?

I have several items very high on the list of things to do. These are things that you and other DAs start doing ASAP, this is so so in order and expect you would try do as many concurrently as possible. The list includes:

1. Delete the stolen DC from your directory. Get out NTDSUTIL and follow the KB on removing data in AD after an unsuccessful domain controller which is KB216498 – http://support.microsoft.com/kb/216498/. This is the #1 you absolutely must do immediately with no hesitation item.
2. Reset every single ID with permissions to interactively log on (local logon rights) to any Domain Controller in the forest[1].
3. Reset every single ID that has permissions to modify the filesystem, registry, or services[2] of any DC in the forest[1].
4. Reset every single ID that has permission to manage any system/application that has hooks/agents into/on any Domain Controllers in the forest[1]. This includes but is not limited to anyone managing the software or servers implementing SMS, MOM, Tivoli, HPOV, AV or other management type software for the Domain Controllers.
5. If the above admins IDs have matching non-admin IDs and you don’t actively verify that admins aren’t syncing passwords between their admin and normal user accounts, reset all of the normal accounts of the people who had their admin accounts reset. I.E. Reset both $joe (his admin ID) and joe (his normal ID) because you can’t trust that those two passwords aren’t synced and who knows what things the admin has configured to be accessible to their normal user id.
6. Reset the password of every single domain controller (hint, psexec combined with netdom resetpwd is useful here…) in the domain.
7. Reset the krbtgt account for the domain TWICE.  This is required to invalidate all Ticket Granting Tickets (TGTs).
8. Reset every single ID that has permissions to modify AD outside of normal user access.

In my EXTREMELY honest and blunt opinion, the number of IDs encompassed in 2-4 inclusive should be comprised of the builtin Administrator IDs (which NO ONE uses) and the individual Admin/User IDs for about 5 people – which comprises all of the Enterprise and Domain Administrators for the entire forest. All of this shouldn’t take but a few seconds, you aren’t asking these people for permission to do it, you are just doing it. If you look at these tasks and think, my god I don’t know who they all are or my god, there are so many… You are already losing your battle for good security. Seriously, more than five people with those level of rights and you need to start figuring out what you are doing wrong.

If you don’t already have monitoring of critical items in your directory/DCs for changes (say like admin IDs, admin groups, GPOs, services, scripts, etc) then you need to start looking at them for changes and keep looking for a while just to make sure nothing slipped through that you missed.

Other items that you will want to do

1. Expire all normal user IDs. Let the help desk know this is coming…
2. Tell all service/proxy account owners[3] that they need to change their service/proxy account passwords immediately[4] and anyone who hasn’t changed their password in x hours (yes hours, not days) will be reset. The exceptions here are passwords that had enhanced rights in AD, those you already reset in 7 above possibly even prior to contacting the owners… Better to ask for forgiveness than be hacked. You must realize you aren’t asking their permission to do this stuff… You are the end all be all security administrator for the forest and you have to protect it and if that pisses people off, so be it.

This all may sound like a lot of work but it really isn’t all that much. If you prepare for it by scripting parts or all of it, it is even easier and less work. This shouldn’t be too much for a competent AD Admin to handle. If it is… Well maybe that person shouldn’t be an AD Admin. Active Directory is your Fort Knox of security for your Windows network, you don’t hire guards that couldn’t get a job protecting the local 7-11 from Slurpy bandits to protect Ford Knox from intelligent determined bad guys.

There is a word of warning though, it is likely you will break one or more applications or functions somewhere on the Windows network when you do this. You know what… so what! The idea is to protect the overall core security. If you knock some apps down for a little bit, it is better than the alternative of them being knocked down for a very long time while you are wiping your forest and rebuilding it because you were afraid to be aggressive with security in the first place.

This is the kind of thing you should have thought out ahead of time if not have a completely documented plan in place for.  You don’t want to be poking around trying to figure out what you should do when you should, in fact, be doing. There are few people who consistently think well when under pressure and it is kind of silly not to come up with at least the rough outline of a plan ahead of time so you can

A. Understand what your weaknesses are now so you can correct them.

B. Be able to block things others try to bring into your environment that will add more weaknesses later.

C. Have something you can follow when the fan and the excrement meet f2f.

The future

Oh how does this change going forward? With Longhorn we have a new Domain Controller type called the Read Only Domain Controller, RODC for short. It isn’t a BDC, I coughed that comment out several years ago at the Directory Experts Conference when Stuart Kwan (of the Ottawa Kwan Clan) first started talking about them so any jokes about it now are waaaaay old. The RODC truly truly isn’t a BDC. They are sort of similar in that BDCs were NOT strictly read only like many people assumed and the RODC is also not strictly read only however they are quite different in that a BDC didn’t always have to be a BDC whereas an RODC is always an RODC (at least for the first release)[5].

Also, it is publicly alleged that there will be no way to replicate[6] modifications made to an RODC back into the main directory. I am not saying that isn’t the case; I am saying what I always say, you can only prove things insecure, not secure…

RODCs should dramatically reduce the surface area of attack in WAN sites and the theft of a WAN site DC will not be anywhere near as exciting as it is now. It remains to be seen what happens in the real world but the RODC should be able to allow folks to deploy a few “full” DCs per geographic region and change the rest of their DCs to RODCs. Preferably RODCs on server core. That is a deployment which I would even allow to be on virtual machines in production without serious concern.

   joe

[0] And you don’t have to have a full blown monitoring environment to do this simple level of monitoring, a simple ping and LDAP query will tell you if a DC is on the network or not. Anytime a remote DC goes off the network, you should probably be trying to understand why…

[1] I say forest instead of domain because a lot of folks tend to maintain the same password and ID combination across domains.

[2] Which really is a combination of the first two but I am calling it out specifically because many people don’t make that connection.

[3] If you did things right, you can determine what accounts are proxy/service account from simple info from the accounts or their location in the hierarchy and you can who they are owned by in similar simple ways. If you have to sit back and thing… hmmm the ePortal ID is Bob’s… I think… You have lost that round. Just reset all of the passwords and wait for people to bitch.

[4] It is funny to tell these folks to change their password. It seems that regularly these people set up apps and have no mechanism for changing the service/proxy passwords at all just figuring they never need to. This is pure stupidity to allow this on your network. When I reviewed apps that were requesting service IDs one of the first questions I always asked right at the get go was how do you change your service password and is it smooth enough to do every 30,60,90 days? You often get the response back of, oh, I want a non-expiring ID… That is fine, non-expiring doesn’t mean you don’t change it. It means you change it in a slightly more controlled fashion. You still have to change it regularly and will be required to change it anything there is churn in your group of someone who knew it or anytime there is a perceived chance of compromise. Not having a mechanism to change that password easily means I won’t give out a service ID.

[5] There are many other things as well but I like knocking that one out of the way right up front.

[6] Though there is nothing stopping you from running a program with rights to read things off the RODC and then write them to a full DC.