BPuhl’s Blog

A little bit of everything without actually being much of anything

Archive for July, 2008

RODC’s and BitLocker

Posted by BPuhl on July 31, 2008

I’m not entirely sure why this keeps coming up, but I keep getting e-mails asking whether we are using BitLocker drive encryption on our regional domain controllers, specifically on our RODC’s.  The problem isn’t the frequency of the question (about once a week now), nor the answer (no, we aren’t)…no…My issue is that when people keep asking me, and I tell them no, then they want to argue the point.  I keep wondering to myself whether maybe I’m wrong, and we should be?  It happens often (me being wrong)…

So here’s the definitive answer of the moment:  Yes, MSIT is deploying Windows Server 2008 Read Only Domain Controllers to the vast majority of our regional locations.  We are working closely with some other teams, to ultimately host those RODC’s inside of Hyper-V as virtual machines, but for right now, they are dedicated servers.  Many of them are running server core, some of them are not.  And none of them are running BitLocker.

The reason that we’re not running BitLocker is the result of “Brian’s careful analysis”, which looks something like the following:  BitLocker has 4 TPM based modes of operation (not counting the non-TPM mode).  These are:

  1. TPM Only
  2. TPM + USB Key
  3. TPM + PIN
  4. TPM + PIN + USB Key

Operationally, there is some administrative overhead to configuring BitLocker on the server, so at minimum the value that we get out of having it needs to be greater than what we put into it.  Out of these 4 options, TPM by itself doesn’t really give us a whole lot of value, because if our RODC grows legs and walks down to the pub, it’s going to boot up just fine as soon as it get’s some juice.  Options 3 and 4 both require PIN’s, and the absolute last thing that we want to have happen, is for someone to have to remote into the management board to enter a PIN from a thousand miles away, while the users in the site are all going upstream.  That’s why we configure our regional DC’s to automagically reboot after a crash – we want them back online.  Imagine what this would do to all of us who remotely bounce a server using shutdown.exe, and then ping -t until it comes back up….blah…

I was part of a hilarious conversation with some folks on the BitLocker team and the MSIT hardware team (who were pushing for us to use it).  They proposed that for option #2, TPM + USB, that we could leverage the USB ports on the motherboard, so that the USB key was actually inside the case (when the bad guys stole it).

Of course, every time I tell THAT story, the conversation devolves into the type of pyrotechnic ejection sequence which could be initiated when the server is pulled from the rack.  Just imagine undoing the screws, sliding the server out, and POOF – the USB key launches out of the case at high speed, impacting the ceiling, and shattering into a thousand tiny bits.

Telling Laura about this one day recently, she did pose an optimization – after all, the key breaking up on impact with the ceiling isn’t completely reliable – so instead, she was opting for the small trap door container above the server.  The explosive still fires, the USB key still launches, but when it’s in the container in the ceiling, the door slides shut to “catch” the key, and keep it safe from the bad guys (who are walking away with the server).  Does it feel like we’re boarding on the ridiculous?

Like I said above..maybe I’m wrong here…but personally, I’d rather have my servers running after a reboot (without manual intervention), and I’d prefer it if they didn’t come armed with explosives.  Call me crazy.

 

Oh yeah – and before the marketing, BitLocker, or anyone else jumps down my throat – I’m ONLY talking about not wanting to run BitLocker on my RODC’s.  Both of my laptops have been BitLocker’d since pre-Vista-RTM, and are re-BitLocker’d after each flatten & rebuild.

Advertisements

Posted in Active Directory, Random Tecnical Stuff | 4 Comments »

Trust Attribute CROSS_ORGANIZATION and Selective Auth

Posted by BPuhl on July 30, 2008

Ever used Selective Authentication on a Windows trust?

Ever looked at the trustedDomain object via LDP (or your favorite tool), “just to check”?

Ever blown right past the trustAttributes values, because all it says is: FOREST_TRANSITIVE | CROSS_ORGANIZATION and you’re looking for something which is a little bit more intuitive than that?

Ever spent 30 minutes Live Searching, Googling, MSDN’ing, and everything else trying to figure out where the fark the bit is that gets flipped to make it selective authentication – or alternatively, just verify your sneaky suspicion that the CROSS_ORGANIZATION bit is the one?

Yeah – I hadn’t either until recently.  Turns out to be ridiculously difficult to find someplace that matches up the fact that when you see this:

Dn: CN=mslpa.corp.microsoft.com,CN=System,DC=corp,DC=microsoft,DC=com
cn: mslpa.corp.microsoft.com;
distinguishedName: CN=mslpa.corp.microsoft.com,CN=System,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0x0 = (  );
flatName: MSLPA;
instanceType: 0x4 = ( WRITE );
isCriticalSystemObject: TRUE;
msDS-TrustForestTrustInfo: <ldp: Binary blob 161 bytes>;
name: mslpa.corp.microsoft.com;
objectCategory: CN=Trusted-Domain,CN=Schema,CN=Configuration,DC=corp,DC=microsoft,DC=com;
objectClass (3): top; leaf; trustedDomain;
objectGUID: 211c8b93-b231-4a93-8bc5-e9bd865b1ecf;
securityIdentifier: <ldp: Binary blob 24 bytes>;
showInAdvancedViewOnly: TRUE;
trustAttributes: 0x18 = ( FOREST_TRANSITIVE | CROSS_ORGANIZATION );
trustDirection: 3 = ( BIDIRECTIONAL );
trustPartner: mslpa.corp.microsoft.com;
trustPosixOffset: 805306368;
trustType: 2 = ( UPLEVEL );

That the CROSS_ORGANIZATION flag (0x10) is the one which corresponds to Selective Authentication being in place for the trust.

Part of this whole exercise was born out of some confusion from people on the way that the UI mistakenly displays inbound and outbound trust information when there is a full trust in one direction, and selective authentication in the other, as detailed in http://support.microsoft.com/default.aspx?scid=kb;en-us;830572

And yes, I’m saying CROSS_ORGANIZATION and SELECTIVE AUTHENTICATION over and over again in my own petty attempt at convincing the search engines to return this post for the next person who comes along, looking to figure out what this CROSS_ORGANIZATION flag means.

Posted in Active Directory, Identity and Access | 3 Comments »

Politics, Pieces, and Parts…

Posted by BPuhl on July 29, 2008

I suppose I should have expected this, but I didn’t.  In my first post on MDM, when I said:

Wow, it’s been a remarkably long road to getting System Center Mobile Device Manager deployed here internally at Microsoft – and to be honest, we really don’t have it released to the general population yet  – but since we’ve got the infrastructure stabilized, and enough pilot users to be “close enough”, then it’s probably a good time to start a series on “How Microsoft IT designed and deployed System Center Mobile Device Manager.”

No – I didn’t actually mean that MDM as a system was hard to deploy.  Thanks to the commenters, pingbackers, other otherers, that decided to interpret this as “Wow, this system must be really hard to deploy”.  Come on guys, gimme a break – it’s just servers, we’re not talking rocket science here.

One thing which occurred to me though, is that I wonder how many of these people actually work in an IT department?  You know, limited budget, lots of politics, too many projects and not enough resources…yeah, the life that 98% of the IT guys in the world live in.

Just to be clear – No, quite frankly, MDM wasn’t all that hard to deploy.  Especially for those of us in MSIT, we actually had the opportunity to do something which we haven’t done in a long time – Rather than dogfooding the initial deployment of Yona (the codename that became SCMDM), politics, resources, and priorities intervened.  So we started our deployment just prior to MDM releasing to the public.  This is the rare case, where we actually had the documentation and whitepapers to use to deploy from.  That was actually refreshing!  So I’ll stop ranting here, and say that if you’re looking to deploy MDM, take a look at the Architecture, Deployment, and Operations guides – and you’ll be rock’n and rollin’.  Then you just need to deal with your own internal organizational issues 🙂

That was politics, so here are the pieces and parts of the MDM service:

Gateway Server – This is the one which everyone calls the “MDM Server”, though it’s really only one component of the system.  The MDM gateway server is the box which you deploy on the edge of your network.  Mobile devices connect to the Internet through their wireless service provider, and establish a VPN-like connection to this machine.  The idea is that this server would sit on the edge next to your VPN or other remote access infrastructure, and from here, devices can access your internal network.

Device Management Server – This is the box which does all of the work.  The MDM DM (sorry…had to…I love that acronym), runs WSUS and is used to manage the GW servers.  Devices connect to the the DM (via the gateway) to do things like software inventory, patching, application publishing, and policy application.  The DM server will also interpret the GPO’s which apply to a device from AD, and translate them into phone-speak for application.

SQL Server – The DM needs one of these.  We had multiple DM’s, which use the same SQL server that we set up on a SAN (not required).  We also have a separate server to use as the reporting server.

Enrollment Server – Web portal used for tethered enrollment of phones into MDM.  Think of this as “domain joining” the machine.  This server touches AD and the CA.

AD and CA – There is a domain prep and some certificate templates which need to be installed.  More on these later.

Posted in Random Tecnical Stuff, Rants, SCMDM | Leave a Comment »

Blast from the past

Posted by BPuhl on July 29, 2008

Listening to the radio this morning, there was a commercial which included the sound of a modem dialing up and connecting.  Wow, haven’t heard one of those in a while.  In fact, that commercial or the occasional rerun of Wargames are the only times that I can remember recently hearing the familar Beeeeeeppp bbeeeeepppp ssssshhhhhhhhhhh click – and these were just recordings of it.

Hmm…  when was that last time that you heard an “actual modem” dialing up?  Does anyone even use those things anymore?

Posted in Babbling and Blabbering, Random Tecnical Stuff, Randomness | 4 Comments »

Gigabit cross-over cable

Posted by BPuhl on July 27, 2008

Was talking with Dean this evening, and we wanted to swap a bunch of files around.  “Bunch” being multiple GB.  Started off all well and good over the wireless network, but we were still lacking something…ahh..that’s what it was:  “Throughput”

Since both his laptop and mine have gigabit ports, we decided to cable them together to get a little more “transfer” into the “file transfer” process. 

Fortunately I decided to think out loud when I said, “Sure, I think I have a cross-over cable”…because that gave him the opportunity to say, “Gigabit is smarter than that, you don’t need a cross-over cable anymore, it will automagically figure it out” – to which I appropriately responded: “Huh? What?”

So yeah – turns out that you don’t need cross-over cables anymore, gigabit network ports will automagically figure it out, and (according to Dean) they will even figure it out when you have gigabit on one side and 10/100 on the other side.  This obviously explains the long line of cross-over cables outside the unemployment office.

(for all of you who are thinking to yourselves, “yeah, duh! You mean you didn’t know that already?” – No, I didn’t)

I’m starting to enjoy this 21st century thing though

Posted in 21st Century, Random Tecnical Stuff | 3 Comments »

Posted by BPuhl on July 21, 2008

Compromise – That’s when everybody loses, but with the idea that everyone should lose equally

Posted in Quotes, Randomness | Leave a Comment »

Federation Agreements

Posted by BPuhl on July 20, 2008

For the past couple of years, I’ve been doing presentations at TechEd, ITForum, DEC (now TEC), and the European Identity Conference on how MSIT is using Active Directory Federation Services (ADFS).  Inevitably, somewhere in my talk, I’ll go back to our initial dogfooding deployment of ADFS in Windows Server 2003 R2, back in 2005, and discuss one of the biggest mistakes we made, and the “mind shift” which had to happen for us to succeed with ADFS.  That mistake, was applying “what we knew” to a new concept, rather than thinking about what we “needed” and the things which were really important to us.

I usually describe this experience, by explaining what happens when you first start to look at federation in an environment, when you’ve got nothing else to compare it to.  Typically the thought process for an ADFS deployment goes something like this:

– It’s single sign-on infrastructure, so Mr. Application Owner doesn’t want to support it for everyone, this is “Infrastructure”

– It’s SSO for users, and there is this “claims” thing which is ‘Identity’ data – so this is “Identity Infrastructure”

– We already have identity infrastructure – our directory – so let’s get the directory team engaged.  Oh yeah – and don’t forget, the technology has “Active Directory” in it’s name – and our directory is “Active Directory” – left hand, meet right hand.

What happens?  Your AD team gets tasked with figuring out how to host resources for partners to do single sign-on.  They’ve been hosting the directory that holds those partner accounts anyway, so this make sense.  Of course, at the same time, we’ve been beating this “directory centric” mindset into the security organization for years, and they are participating as well.  The result:

Both the team deploying ADFS, and the Security team making policies – have a directory centric slant on federation

This shouldn’t be bad right?  It’s Just another identity system.  Yes and no.  The problem with federation, is that if you’re hosting the applications (which is the specific scenario I’m talking about here), you need to “trust” the other organizations identity infrastructure.  Ok, well, trust may be a strong word – but it’s just so much easier than saying, “bind with complicated requirements wrapped up in legal framework” 

Ahh – but directory guys don’t trust anyone do they?  In general, we’re trusted, but that rarely (and usually only with a fight) goes in the other direction. 

Let’s assume that you get over this first cultural hurdle, and decide that it’s ok to trust your business partner for authentication, to get to those applications in your Extranet/DMZ – the ones which they already have accounts in your directory for.  What does the legal agreement look like when you let a bunch of directory brainstorm the requirements?  Well – it contains all of the things which are important to directory folks (makes sense).

Here’s the example which actually prompted this post.  2 weeks ago I received a request from a business partner to allow MS users to authenticate via ADFS to this partners Extranet environment.  This request was accompanied by a 9 page “Federation Agreement”.  The first 8 or so pages were boilerplate legaleze which isn’t really relevant.  The important part is copied below, with name changes to protect the innocent and minor formatting for readability:

Exhibit A Security Requirements

I. Password Policy Requirements:
User Account passwords MUST comply with all of the following requirements:
     Be at least 8 characters long;
     Contain upper and/or lower case letters, numbers and non-alphanumeric characters;
     Be changed at least once every 60 days; and,
     <COMPANY> provisioned accounts (Corporate, Partners domain, etc.) and vendor federated accounts for the same
     individual must have different passwords.

User Account passwords MUST NOT:
     Be cached or stored in cleartext human readable form;
     Be able to reuse their previous 10 passwords;
     Be shared with anyone; or,
     Be set such that the password never expires. Passwords must expire in accordance with 1.c above.

II. Password Best Practices:
User Account passwords SHOULD have at least one number, symbol and/or punctuation mark.
User Account passwords SHOULD NOT:
     Include words in any language or dictionary i.e. do not use a word from a dictionary;
     Be changed to words that have the letter(s) “o” changed to the number(s) zero “0” or the letter “i” changed to the pipe(s)
     symbol pipes “|” or the number one “1”, or vice versa;
     Be a family or pet name.

III. Account Policy:
     1. Access to <COMPANY>’s corporate resources MUST be through approved and valid individual account partner accounts.
         Sharing of user accounts is prohibited.

     2. Account partners MUST NOT impersonate anyone else or misrepresent themselves.

IV. Virus Protection
     1. The Company will ensure that all systems used to access the <COMPANY> Extranet have installed an adequate,
         daily updated, commercially available anti-virus scanner.

V. Screen Savers
     1. Any device used to access the <COMPANY> Extranet shall have enabled a screen saver which activates after 15 minutes
         of inactivity and is configured to lock the PC screen, requiring the User to re-enter their Account password in order to
         re-activate the device.

Note that this is the entire list of their security requirements.  The crazy ridiculous part, is that apparently this company had previously had conversations with some of the MSIT team, and based their agreement off of a very early draft of OUR OWN federation agreement!  What kind of monster did we create?!?!

Have you figured out what’s wrong with this yet?  I already said that this is one of the biggest mistakes that MSIT made when we were doing early drafts of our federation agreement.  So what’s the issue?

Like I said earlier – this is a very directory centric view.  When you manage a directory (remember, I’m also one of the directory engineers for MSIT), what kinds of things are important to you?  Password policies, complexity, etc…  Heck – as a community, how long did we fight to get Fine Grained Password Policy (now in Server 2008) into AD?  Passwords!  These are important things!  And they need to be strong! And they need to be unique!  And they need to be used often, like when the screen locks!  All of these are great and wonderful things that we believe in!

Yes, passwords are important, but let’s step back to the things which are more important.  Before we do though, let me share the response I sent to this federation request:

Thanks for sharing your requirements for federating Microsoft employees into your Extranet.  Unfortunately we are not able to complete the federation onboarding request at this time, as we are not able to meet the security requirements in Exhibit A.  Specifically the areas of concern are:

Password Policy:
– Our password policy requires users to change their password every 72 days, which is greater than your required 60
– We can only ensure that users do not synch multiple passwords within our directories.  Without admin access to your directory, we cannot verify that users are setting unique passwords
– There is a population of users whose accounts are set to never expire passwords

Virus Protection:
– We allow users to do federated authentication from any corpnet or Internet based machine.  Therefore we cannot guarantee that the machine the user authenticates from contains any type of virus protection.

Screen Savers:
– We allow users to do federated authentication of their identity from any corporate or Internet based machine.  Therefore we cannot guarantee the settings or integrity of the device from which the user is authenticated from

Let’s get back to the basics now – the things which are important.  What is the whole point of doing federated authentication between business partners?  DEPROVISIONING!  Yes, that’s the “one big thing”.  The major problem with the way that directories do Extranets and DMZ’s today, is that you’re relying on the partner to remember to deprovision one of his users, when that user is terminated.  With federated identities, you are tying access to your environment to the same identity that the partner company ties access to THEIR DATA to.  The one they issued.

From a federation agreement perspective, here are some of the things which I like to see:

  1. Figure out what the “minimum bar” for things like password policy is, not the settings which you would put in your own partner directory. 

    Ask yourself which is better, to have deprovisioning with a less secure password – or a more secure password on an account in your directory which may stick around for weeks after a user is terminated from their parent company?

  2. Determine what your acceptable bar is for deprovisioning user accounts.  Within MSIT, our SLA for deprovisioning a user is to have 90% of accounts disabled within 24 hours of termination, and 98% within 48 hours.
  3. Don’t try to tie things like machine state to identity.  Within the directory, we can say things like “domain joined machines” and “group policy application” and “patching and security requirements”.  Federation isn’t meant to get you a healthy machine.  Federation provides you with assurance of the most credible identity possible.  Our identity is more credible than yours, because we know when the user is still employed with us.

As always, security is about risk management.  Federation Agreements are the legal instantiation of a risk management policy.  Don’t set your risk management bar so high, that you actually end up reducing your security posture by preventing partners from federating.  You may “keep control” of the accounts in your directory – but those aren’t the most credible accounts that could be used to protect your data.

Posted in Active Directory, ADFS, Digital Identity, Identity and Access, Random Tecnical Stuff | 4 Comments »

When Good Glow-Sticks Go Bad

Posted by BPuhl on July 18, 2008

On the 4th of July, we all went out to Gasworks Park to sit with 10,000 or so of our closest friends.  This was the 2nd year that I’ve been out there, and that’s about the right interval for the deep-fried, sugar sprinkled, strawberry smothered yummy goodness. 

Heading home around midnight, just as we started across the 520 floating bridge back to “the Eastside” (I live in the city of Redmond), Anika, my 4-year old daughter let’s out this blood-curdling scream, starts holding her left eye, and alternating between screaming “it hurts!!” and “ouchey!!!”

Trying to figure out what the hell just happened – 5 minutes prior I had looked back and she was asleep in her booster seat – when we notice that one of those light-up light stick type glow necklaces had broken, and was all over her hands, shirt, etc…  she had rubbed her eyes in her sleep.

Divert to Overlake hospital ER. 

Into the emergency room – quick explanation and the ER doctor walks out to call poison control to find out what to do.  Record time, back into the room, holding a syringe, and a single-serve half&half capsule.  This is when we find out, that according to poison control:

  • The contents of glow-sticks, and that when you that stuff in your eyes, it feels very close to pepper spray (Yup, that was consistent with the reaction)
  • To neutralize and flush it – spray some half & half or whole milk, in the eye (WOW!  Was she serious?  Yeah)

At this point, the tears from crying had actually cleared much of it away, and we were down to a medium whimper.  So as she’s peeling back to the cover on the half & half capsule – she’s describing how this is the first time in 12 years that she had to go down to the cafeteria to get “the medicine” for an ER patient.  In fact, then 2 nurses came by, one holding a half-gallon jug, and the other with a pint-size whole milk container.  She had also sent them off “on a mission” to find something to spray in this kids eye!

Hurray! A little milk in the eye.  A few more tears.  Lots of snuggles.  And we’re loading back up into the truck to head home and try to get some sleep.

Fast forward…ummm…what, about 14 days or so? To this afternoon.  I’m checking the mail, and Overlake hospital has sent a copy of the charges which they are billing to my insurance company for our visit (thank goodness for medical insurance):

  • Emergency Room Visit – 491.73
  • Pharmacy (Other) – 9.66

WHOA! Wait a minute!  They are charging 9.66 in the ER for the half & half?  Ok sure, I bet the cost of the syringe to do said squirting was in there as well…but seriously!  This is the stuff that they were giving away for free down in the cafeteria!  WTF Mate!?!

Well – just further validation that this countries medical system is in complete disarray, and is likely beyond salvation. 

Posted in Anika, Randomness | 3 Comments »

Drink Master

Posted by BPuhl on July 17, 2008

There’s a bar in downtown Seattle called Vessel.  I’ve only been there a few times, but the bartender (who recently left) was Jamie Boudreau.

Well, it wasn’t until I started reading up on how he left Vessel, that I realized that this guy is in that category of “elite” bartenders.  You don’t run across them very often, but when you do – you get to stand in awe of what they are able to mix and pour.  He likes to refer to himself as a “molecular mixologist”.

Turns out that he has a blog, located at http://spiritsandcocktails.wordpress.com/

With his post on the Mai Tai 3000, all I could think was:  This guy is like a mad scientist, in an art class!

If you have any interest at all, it’s worth a link in the RSS reader.

Posted in Randomness | Leave a Comment »

Paging Mr. Deere, Mr. John Deere – please pick up the white courtesy phone

Posted by BPuhl on July 17, 2008

Everyone else can delete this…

 

Hey man!  I completely lost your contact info after Catalyst.  So hit me up in the comments with your e-mail addy.

~B

Posted in Randomness | Leave a Comment »