October 2004 - Posts
Update
It's a busy and very intersting time. This year has been a blast! I was pretty busy in the last couple weeks: Finished a migration project from NT to Windows Server 2003 at a insurance here, did a lot of classes recently (XP, WS2k3, included my talks about AD, DNS, XP SP2 Security Features, ..), couple interesting meetings, Telcos and WebCasts, organized with peers a MVP Get-Together in my area with very interesting guests, had a bad cold and recovered, and lots of other things I can't disclose right now. Additional I've renewed my MCT Certification - I'll still be MCT in 2005 and I'm really looking forward since I strongly believe 2005 will be a blast in the IT.
Later this week I'll drive to a former customer of mine whom I migrated as well, and extend their Active Directory rolebased administration to reflect the latest changes of the requirements since they just migrated to Exchange 2003 - I'm looking forward since it's just great to get back to a smooth AD with well designed roles and nice Administrators. Then I'll have a Schema Extension and Migration coming up - everything is already prepeared but I just love that stuff and look forward to it.
IT-Forum
I'll be at IT-Forum in Coppenhagen in November, and I'll be working some shifts in the Ask the Experts Area at the Windows Server (Directory Services) booth. If you are there and interesting in chatting about the technologies, come by.
Clarification of my last Weblog
I've had some very positive reactions of my last Weblog, however there are a few things I should clarify:
- You need to physically secure your Branch Office DC - I just posted the steps you should take if you are in the process or if you want additional security (keeping it in a locked room might not necessarilly prevent it from being stolen).
- If available encryption of the harddrive is another great step to secure it. I haven't done that yet and don't know if there are products out there which are certified for DCs - if anyone knows some product please comment to share that info.
- Attackers might just image the harddrive or steal data and keep it in place and online - try to figure out how you are able to protect yourself from that stuff and more important, how to recognize that data was stolen. If you are not alerted that something has left the building you won't react with the approbiate measures.
Guess that's it - if you have comments please comment on the weblog so others are able to participate in the discussion - I've received quite a lot via email on this but I'd prefer to keep the discussion public.
Ulf
Today there was a pretty interesting issue in the Windows Server Newsgroups: "What to do if a Branch Office DC is not physically secured?"
OK - the first thing ever should be not to put a DC anywhere where it's not physically secured from theft. But lets look what happens if someone gets your DC more closely.
If somebody gets physical access to a DC, first of all he gets all access to the local machine. That's not very difficult. So any readable local data on that DC is gone and known outside the company. To get further data out of the company, it would be necessary to hack the passwords which are stored on the DC and try to use those to hack into the company and retrieve more data of other machines, or place there a virus or trojan.
To get a domain administrator account is not very difficult after you got in as local administrator, but it will be either a new domain administrator or a old one with changed password. After getting access to the DC as domain administrator it's quite likely that the attacker starts to hack the existing service or administrator passwords - those are usefull for getting more information out of the remaining production environment.
Another option for the attacker would be to put that DC back into the Domain after he was able to add another administrative account. The DC will start to replicate again and the new administrative account resides on all DCs.
So here's my Opinion on things you are able to do to protect yourself if your DC is stolen until your physical security for the DC is in place:
- Prevent the storage of LM-Hashes of passwords, then change every password in the domain.
If you store the LM-Hash of a password it's calculated very fast by password cracking tools. If you configure your servers not to store it, you'll need to change your passwords to reflect that change.
- Use complex and long passwords, beyond 20 chars are good passwords.
Just use Phrases instead of words. The attacker will be able to get into the local system very fast, and they have access to all data on that DC. If he wants to attack the rest of the domain, he needs one of the existing domain administrative accounts or he needs to get the domain back into the domain. To prevent him to get the other passwords fast prevent LM-Hash and use long and complex passwords, this will give you some time to change the passwords on the domain after the DC is missing.
Passwords are not stored using reversible encryption (hopefully and by default) so the attacker needs to use a tool which tries to "guess" the right password. Hacking into the ntds.dit file won't help here, that would only help if the password is stored using reversible encryption.
If you have a plaintext passphrase which is not complex it might not help very long in the future. Make sure that it's complex and does not just use dictionary words in it. Main issue here is that we have to force password cracking tools to go into a brute force attack, that means to try every possible combination of the existing character set. If we have a password like that the time to crack it will go exponsially up with it's lenght.
- Use randomly generated very long passwords for service accounts.
As passwords for your service accounts you can use very long ones and completly randomly generated, you can create a script which changes the account password and the credentials for the service at the same time, no need to store the password anywhere else. If you need to use the password, change it again randomly.
- educate your users to use complex and long passphrases as well
- implement and test processes to change all passwords (including those of service accounts) in a short time
You need to be able to change the passwords in less than the time an attacker posseses the DC and tries to hack the passwords. Step 1. to 4. above will help you to increase that time from seconds to hopefully a few days.
- implement a process which defines what to do when a DC is stolen
e.g. delete the computer account of that DC immediatelly (to prevent him getting back on the network after it might have been hacked and a additional administrator created), change passwords of all accounts, perform a metadata cleanup of your domain.
- Never ever put back a missing DC into your domain without 100% reinstallation
If you are able to get your DC back you really need to reinstall it - you can't trust it anymore. There might be virusses, trojans, or accounts installed you most likely don't want into your domains.
If you follow those steps then if your DC is stolen they get all data on that DC, however if you prevent them to hack the domain accounts fast (done by step 1. to 4. above) you have some time (few days instead of seconds) to proceed with the other steps (5 and 6) to prevent them getting into the rest of the network.
And take care of point 7 - very important.
Another major misunderstanding: Automatic locking of accounts wouldn't help you here - the attacker is already in the possess of the DC and is able to change that before attacking the accounts.
That's just my opinion - I'm really curious what you think.
Ulf B. Simon-Weidner
Posting the last weblog reminded me on a situation which I like to share:
I was at a customer and we were in a workshop defining the roles in Active Directory needed for that enterprise. When we started there were a lot of people/departments which thought it's necessary to be either domain admins or account operators. We told them what they'd be able to break if they are domain admins. Then we went on how assigned GPOs would work if they created objects in the wrong spot, e.g. user accounts in computer ou's or vice versa. We told them that we are able to protect them from doing mistakes while keeping them happy on their assigned roles.
At the end of the workshop it was pretty funny - we were looking at a matrix of rights assigned per role, and they were not discussing anymore "I need those rights to perform my job", they were asking "Do I really need that right? I believe it's a different roles responsibility to take care of this".
Great experience for me, and spread the word out there - stick with the least rights necessary to perform any roles!
I'm one of the guys who prefers a AD-Implementation with the lowest rights possible - e.g. do not use build in groups if not necessary (the least one necessary in my eyes is Account Operators - usually you design OUs which are supposed to contain users, groups or computers, however AOs would be able to add users to the computers OU - necessary??).
Besides not assigning any members to those groups (if not necessary - again) I prefer not to have any unnecessary rights set on the objects in Active Directory. Every object you create in Active Directory has it's default rights, which are "inherited*" from the schema (*not 100% correct - but either you know what I mean or don't worry). It is possible to modify the default rights in the Active Directory Schema, but there's no guide out there which specifies the minimum rights needed on each object to keep Active Directory and all MS-Applications happy.
I was talking to a couple folks at MS and requesting a guide like that. Last night I was promised that they'll publish a X-Mas present for me. I'm very excited and looking forward to getting this guide - I've been waiting quite some time for it.