Getting your Bitlocker keys out of AD

I often talk about my perspective that AD is a great publishing engine, but that it should not be authoritative for anything.  Any mission critical data should be mastered outside of AD, and then sync’d into the directory to be published/consumed.

The problem with this, is when you have services which source their information in AD directly, but that data is still mission critical.  One example of this, would be BitLocker Drive Encryption recovery keys.  The BDE service on clients will write it’s recovery keys directly into AD.

Before MSIT broadly deployed Bitlocker, we worked with an internal team to build a solution for finding new BDE recovery keys, and copying them out of AD into an external store.  We even went a step further, and put some self-service recovery options in front of that store.

I’m happy to see that MSIT was able to publish this solution out to Codeplex, so we can share it with everyone.

If you’ve got Bitlocker deployed in your environment, but are ONLY storing the recovery keys in AD – you may want to take a look.

http://keyrecoverytool.codeplex.com/

AD Design Metrics

From http://www.shariqsheikh.com/blog/wp-content/uploads/2009/05/wtfm1.jpg

If you’re going to use the same password for everything…

At least let it be a good password:  http://www.cxo.eu.com/news/password-protected/

Passive Safety & Situational Awareness

I find that there are a lot of concepts which I bring to my job in MSIT, from my hobby as a private pilot.  In this case, I am “borrowing” the title for this post from an article by Bruce Landsberg in one of the magazines I subscribe to.  He starts:

… Compared to machines, the homo sapiens’ conceit of being masters of the universe shows us to be consistently unreliable when it comes to repetitive tasks.  We do excel, however, in thinking up ways to get out of mindless chores to refocus our short attention spans on really important stuff…

This hit me, because earlier today I was talking to some of our engineers about our “team server” – which is the box that we use to run all of our recurring scripts from, collect data to, store utilities/tools/scripts on, and generally dump stuff.  Appropriately named Dumpster (does that make us dumpster divers?  probably).  We run a lot of scripts to collect a lot of data for our own use.  Although we’ve got the full blown monitoring infrastructure in place and we own all the settings for alerting, etc…  SCOM is owned by one team, the alerts go to our 24×7 operations center (who resolves the bulk of them), etc…  So if the administrators are abstracted from most of the chaff, how do they maintain situational awareness?

Situational awareness, another one of those terms I picked up flying.  Basically, the understanding of what’s going on around you.  Easily demonstrated with the following question to your administrator:  “How’s AD doing today?” – by default, the answer will be, “AD’s running great” (that is their job after all…) – the follow-up question though, “How do you know?” is usually the zinger.  If the answer is, because nobody from Help Desk is screaming at us, then that’s probably not a good sign.  If the answer is, because there are no trouble tickets, that’s probably also not a good sign… 

Lack of bad doesn’t necessarily equal good.

When I have a chance to talk to the MS Directory Masters classes, I usually try to work in the following story:

In 2002, I was one of a small group of AD administrators for MSIT, we were knee-deep in dogfooding Whistler, which shipped as Windows Server 2003, when one day my GM walks by, sticks his head in the door (never a good sign), and asks “How’s AD doing today?”.  Default response at the time was something like, “Looks good, couple of DC’s being upgraded, so far so good… why do you ask?”  It’s at this point that he says, because I just got a call saying that our Extranet is offline, nobody can authenticate to any applications, our partners aren’t able to do business with us, and I was wondering what you were doing about it?  If I remember correctly, it was about that time that he looked a little worried about his hiring decision, turned and walked away…

Quickly (trying) to log onto the domain controllers, all 6 of the DC’s were running at 100% CPU utilization.  Perfmon, SPA traces, expensive/inefficient query logging – nada/zero/zip – we were in trouble.

Within a couple of hours, we’re all in a big room – techies around the table, managers looking over our shoulders, and we had the AD rock stars from the product group (the developers) sitting in the room, taking apart the DC’s in the debuggers.  They were all shaking their heads, when someone mumbled under their breath, “this almost looks like normal load…just a lot of it”

That’s when we decided to pull some perf data for the past 6 months, which looked something like this:

Sure enough, we had been growing load for the past year or so, all the DC’s were running at 100% CPU, we stole 4 servers which were racked & built for some other application, DCPromo’d them and perf dropped down to a reasonable level…

oops…

As you can see from my MSPAINT representation – WE ACTUALLY HAD THE PERF DATA!  The problem was, that we had lost situational awareness of what was going on in our other environments, because we were so focused on dogfooding.

The moral of the store then, being that it’s good to HAVE data, but it’s much better to LOOK AT the data occasionally…  

AD Admin Center

Anyone else started to play with the new Active Directory Administrative Center in the Windows 7 RSAT tools yet?  Here are my first impressions:

• Much easier to deal with multiple domains, especially when you’re looking to get to the FOO OU that’s buried 3 deep into each of 8 domains
• How can I make it load faster?
• I’ve been trained for so long, to type DSA.MSC to get to ADUC, that it never occurred to me that D, S, and A are a roll of the left hand fingers across the keyboard.  Now it’s DSAC.MSC, and I’m constantly entertained at how my fingers just refuse to get in that last “C”
• hVery annoyed that it’s actually NOT dsac.msc like I just said, but instead it’s DSAC.EXE – seriously? EXE? More training

Still need to play with it some more to figure it out, but I’m working on a project now where I needed to deal with a bunch of OU’s across multiple domains, so the ability to add starting nodes was uber-helpful – 2 thumbs up!

Adventures of Exchange 2010 and AdminSDHolder

For those of you who haven’t heard by now, there have been many threads over the past few days around the setup of Exchange 2010, and how one of the things which it does is to modify AdminSDHolder ACL’s, and the associated security implications.

Far as I can tell, this was kicked off by this blog post, which gives a good description of what’s going on and what the fuss is about:  http://dloder.blogspot.com/2009/08/exchange-2010-rc1-and-adminsdholder.html

It didn’t take long for threads to spawn on the public forums, such as http://www.activedir.org/ListArchives/tabid/55/Default.aspx as well as several internal distribution lists.

While I won’t claim that inside Microsoft, the left hand and the right hand always know what each other is doing.  We are very security conscious and in general the product groups do go out of their way to try to do things “right”

In the meantime, who does this affect?  Well, technically Exchange 2010 is only supported for production by a small number of TAP partners.  Of course, MSIT is on that list, so you might be wondering – what do we think about it?

While it’s not an official “policy”, in general, when it comes to managing Microsoft’s internal directory, we’ve got a fairly basic principle: 

                   If you create it, it’s yours, if you don’t – leave it alone.

In this case, AdminSDHolder isn’t something that Exchange created or even ‘owns’, it’s a base AD function.  Because we know that also by policy, none of the accounts which are impacted by AdminSDHolder are mailbox enabled (and thus within the scope of Exchange), we went through and removed the ACE’s from AdminSDHolder.  Does this mean that Exchange RBAC won’t be able to touch those objects?  Yup, but that’s by design of our security model.  We require separate (in our case, smartcard required) administrator accounts for all elevated permission users, and those accounts aren’t allowed to have mailboxes.

I won’t claim to know what’s going to happen in the future with Exchange 2010, but this is how we’re approaching it internally (and why).

Congratulations!

Congratulations to all of the MSIT and Product Group members who got us this far (and let’s not forget the users!)

SYSVOL Replication Migration Guide: FRS to DFS Replication

Web pages on Microsoft TechNet: http://go.microsoft.com/fwlink/?LinkId=139749

A Microsoft Word (.doc) document on the Microsoft Download Center: http://go.microsoft.com/fwlink/?LinkId=150375

AD in the Perimeter Network

A new whitepaper has been published providing the guidance you need to deploy Active Directory, and specifically RODC’s, in a “Perimeter Network” (the network segment formerly known as DMZ).

I know that a lot of folks have come to me, asking for help/guidance on putting RODC’s into the DMZ rather than putting full DC’s or having a separate forest.  This should provide the information you need to keep safe, secure, and most of all…functional.

Some of the topics include:
•         Security considerations and configurations for RODCs in the DMZ 
•         Network configurations for RODCs
•         Application compatibility with RODCs in the DMZ
•         Step by step instructions and a sample script to help perform domain join using RODCs

http://technet.microsoft.com/en-us/library/dd728034.aspx

 

Brandon pointed out to me, that the doc is nice, but having a downloadable version would be much nicer.  We fired off a quick mail, and there will be a downloadable version of the document in the download center in the near future.

Happy Birthday Redmond.Corp.Microsoft.Com

10 years ago, Microsoft’s largest internal domain was upgraded to Windows 2000 becoming the first production Active Directory, and it’s still going strong…

Dn: DC=redmond,DC=corp,DC=microsoft,DC=com
   whenCreated: 4/9/1999 7:49:12 PM Pacific Daylight Time;