BPuhl’s Blog

A little bit of everything without actually being much of anything

Archive for February, 2009

AD Powershell Blog

Posted by BPuhl on February 26, 2009

There’s a new blog in town…



Posted in Active Directory, Random Tecnical Stuff | Leave a Comment »

3-D as an Afterthought

Posted by BPuhl on February 22, 2009

So it’s really tough to find something that can be moderately entertaining to a 16 year old, appropriate for the 4 year old, and not bore the snot out of the adults.  So far the options have pretty much limited themselves to bowling, or Pixar movies. 

Took a chance this afternoon, and we all loaded up to go see Coraline in 2-D.  This isn’t really a movie review, because seriously – Coraline?  But hey, it had a chance.

What is interesting though, is the current rash of 3-D movies that are coming out again.  In this case, we had the option of seeing “Coraline in 3D”, or just regular 2D.  Well, we thought we had the option but the 3D version started 10 minutes ago, and the 2D version started in half an hour, so 2D it was.

Sitting there though, it was obvious that this wasn’t a movie that was built around 3D.  Instead, it was a 2D movie with a couple of gratuitous scenes where they very obviously (even in 2D) drew in extra bits and pieces that would pop out of the screen in the 3D version.

I guess I’m just used to 3D in the “intentional” kind of way.  Usually when it’s been a trip to Disneyland, or someplace similar – starting way back when with Captain E-O, and more recently with the Bugs Life and similar movies that were actually made to be shown 3D.

Like I said, I didn’t really have huge expectations for the movie to begin with.  But it’s annoying when it’s so ridiculously obvious that they made the movie, and then after the fact, the marketing department told the artists to go back in and add some bugs popping out so they could market it in multiple dimensions.

Posted in Randomness, Rants | 2 Comments »

Security Evolution

Posted by BPuhl on February 21, 2009

My buddy Dan who used to work in Microsoft IT Security, and is now working over in the Information Protection product group (mostly known for RMS) wrote a doc back in 2005 on the evolution of security in the enterprise.  He had been asked for the doc so many times that he posted it to a blog about a year ago, but whenever I start thinking hard about federation, application authorization, claims based identity, and all of the other “fun” topics which make my days interesting, I occasionally need to go back and remember that being in IT is as much about where we are “at”, as where we are “going”.

This is the main graphic from the document:


From what I can tell, we are somewhere around the little tick mark that separate “near term” from “mid term”.  Things like IPSec, NAP, Windows Firewall, etc… have all done a pretty good job of moving the security from the network boundary to the host.  With Windows Server 2008 R2, Microsoft has finally productized Direct Access – which I can now admit that I have been happily been using for 2-3 years now, and probably couldn’t live without.

But when I think of the challenges in the identity space around federation, the separation between personal and business data, and how we’re going to protect the enterprise when everything is in the cloud – I can’t help but to think that maybe the arc on that “data” line is (unfortunately) a little too steep.  As hard as we try internally, the adoption around data protection is still far below what we need it to be.

Progress takes time, and I like working with the IPC team as they have a great things planned for the future.  Like everyone else though, it’s hard for me to “wait for the next release” to get the features I need.

Posted in Active Directory, ADFS, Digital Identity, Identity and Access, Random Tecnical Stuff | Leave a Comment »

Business Data and Personal Data (pot-A-to, pot-AH-to?)

Posted by BPuhl on February 21, 2009

How do you tell the difference between “business data” and “personal data”?  Since we’ve been diving head first into this whole federated identity thing, it’s turning out to be pretty darn important.

The best that I can come up with at this point, is the following guideline:

If you’re supposed to have access to a piece of information after you quit or are fired, then it’s personal

Man, I wish life were only that simple.  Here are a couple of examples of decisions from real life ADFS federations that we’ve set up between Microsoft and some of our business partners.

Microsoft employees in the US (and elsewhere) are provided medical and other types of insurance as part of their benefits package.  The HR team wants to leverage a vendor to manage most of the benefits, and provide SSO for employee’s.

Is this business or personal data?

By my definition above, this is pretty obviously business data.  Ah, however midway through the project, there was another requirement thrown out.  (I’m obviously stereotyping here, but for fun…)  It seems that a large number of Microsoft employees are married men, and some large percentage don’t want to manage anything remotely having to do with their family or finances, most likely because their wives won’t allow them to.  So during this project, we now need to allow an employee to provide access to the benefits portal for their spouse.

The solution?  Employee uses ADFS to sign into the portal, and then they can specify WLID’s that are allowed to log in and manage them as well.

Not bad, but the implementation went sideways.  What we’ve got now, is a case where users who are logging in from corpnet have to use ADFS, however ALL USERS that log in from the internet use WLID’s.

Operationally, this is really bad, because the only way you can tell from the internet, where a user is coming from, is by IP address – so if we add a new proxy server IP, we will have transient auth failures. 

From an IDM standpoint, the goal was that when a user was terminated, they lost access to the site.  They only have access because of their relationship with Microsoft (ie. it’s business data), and they lose access to it when they are terminated.  However instead of enforcing this with auth, we now have to rely on the HR, out-of-band, feed to notify the vendor of an employee termination.

Another example, occurred this past January:

In December, Microsoft and our payroll vendor federated an application such that MS employees in the US could gain access to their W-2’s (US tax documents) online, by signing into the application using ADFS.

It’s easy to interpret a W-2 as being business data, after all, it’s essentially a summary of your annual payroll, but it was this case that helped by boil me definition down to what I wrote above.

You see, in December we sent out this e-mail, we had a significant number of employees sign up for online W-2’s, which as part of the process they agreed not to need paper W-2’s to be mailed to them.  They would just print them out.

However in January of this year, Microsoft was one of several companies that unfortunately had to cut costs and lay people off.  Part of this process, was that the impacted users had their accounts disabled.

So to summarize the insult to injury:

-  A user signs up for online W-2’s
-  They are layed off
– And the account they need to use to access their W-2’s is disabled

This is a pretty clear case where we should have used some form of public auth provider like Windows Live ID or similar – essentially allowing users to get their W-2’s using their personal ID instead of tying the access to their business ID.

However you have to stop and ask yourself:  “If an employee accessing their W-2 is really a person accessing personal information, then what is an HR analyst that’s providing support, who has to access MY w-2 to give me the help I need?  Surely we could all agree, that this is a case of a business identity accessing business information!”

Posted in Active Directory, ADFS, Digital Identity, Identity and Access, Random Tecnical Stuff | Leave a Comment »

Ghetto Turtles

Posted by BPuhl on February 21, 2009

It’s the “turtles” candy snack thing-ey’s, but ghetto style. 

– Bag of pretzels
– Bag of Rolo’s candy
– Small bag of Pecan halves


Pre-heat the oven to 350
Line a cookie sheet with wax paper
Lay out individual pretzels with a little bit of space between them
Place one Rolo on top of each pretzel

Place the cookie sheet in the oven for 2-3 minutes, until the Rolo’s start to melt

Remove from the oven, and take one pecan halve, and press it firmly into the top of the Rolo, squishing it in with your finger

Serve warm

Last night when the cookie sheet came out, I had every intention of taking a picture to post alongside this blog…  but that would have required me stepping away from the turtles to get the camera, and there was no way that anyone else was going to wait on the chocolatey, caramely, salty, crunchy, nutty goodness that had appeared before them.  So maybe next time.  🙂

Posted in Babbling and Blabbering, Food, Randomness | 3 Comments »

Even with RODC’s, AD Is Still A Distributed System

Posted by BPuhl on February 21, 2009

Yes, it’s true, Active Directory is still a distributed system.  (this is the part where you say, “Well, yeah, duh!”)  But with Server 2008 and Read Only Domain Controllers, the distributed system changes some.  Sure, there’s that “unplanned feature” in ROGC’s that I blogged about last time, but this time it’s different. 

Remember back in the day, we had to train application developers that although all DC’s were essentially equal, they were only ‘loosely consistent’, so it wasn’t reasonable to think that you could make a write on one DC, and then immediately query another DC and expect the data to be there.  Made sense, but recently in MSIT we found that even our own developers were sort of taking some of this ‘loose consistency’ for granted.

A couple months ago, we had an escalation from one of our regional sites, that all BitLocker installations to laptops in the site (which of course, has an ROGC in it), were failing.  Not only were their failing, but they were failing with long and painful latency – in other words, just irk’ing everyone.

With a bit of digging and some investigation with the associated PG’s, we found that when BitLocker was configured on the machine in a site, it would write the recovery key into AD (like we wanted).  Of course, there was only an ROGC in the site, it needed a writeable, so the client went out of site and wrote the attribute.  Of course, BitLocker is one of those things that you always want to make sure you have the key for, right?  So in an attempt to be safe and secure (not to mention, recoverable), the BitLocker process then reads the key back from the DC to make sure that it was written.  Makes sense, but you can see what happens here – The attribute was written to a (full)DC in one site, and is read from the ROGC in the local site – which hasn’t replicated in the change.  Ooops.

So after batting this around a few times, here were some of the suggestions:

-  Before configuring BitLocker, run a script that sets the siteName registry key to a site that has a writeable DC
-  Rehome the subnets for the sites which are going to deploy BitLocker to a site which has a full DC for the domain, and then move them back
-  “Install this patched version” so that the BitLocker installation behaves better

It’s pretty obvious, the first and second are essentially hokey workarounds to a problem, aren’t anything that will scale to an enterprise deployment by any means, and/or solve the immediate need, but don’t take into consideration the ongoing effect of machines coming up in the site.

Instead we have been “testing” out a pre-release patch for this problem, and it’s working great.  Until it’s released, if you run into this problem, you’ll need to do one of the first 2 options above.  But it’s probably still worth a call to your local Microsoft guy to let him know that you want the patch.

Posted in Active Directory, Identity and Access, Random Tecnical Stuff | Leave a Comment »

Turning Heads on the Tarmac

Posted by BPuhl on February 12, 2009

Giant, bikini-clad woman lounges on Boeing 737 in-flight.  News at 11.

SWA Pilots Steve Christl and Mike Clemovitz Pose With "SI One"

Posted in Randomness | Leave a Comment »

More RODC Fun

Posted by BPuhl on February 5, 2009

During our deployment of Windows Server 2008, and then Server 2008 R2, we ran across an interesting case when we deployed in RODC out to one of our regional sites.  The problem was that when we put the RODC into the site in Fargo, ND, users started reporting that one of their serves which is part of a DFSR replica set was throwing errors and not replicating.

In true IT spirit, the first thing we did was deny all accountability and punt it to the DFSR team…after all…we didn’t touch anything :)  (not really, but that’s what usually happens)

Actually, what really happened was that the DFSR team came to us, because they were seeing errors that looked like this on their server:


After a little bit of research, the DFSR team came to the only logical conclusion:  AD was broken, and their object was corrupted on FAR-NA-DC-02.

Knowing of course, that AD doesn’t break, and object corruption most certainly couldn’t happen on OUR service, we started looking for alternative explanations.  To understand the environment, remember that we have a multi-domain forest.  In this case, the 2 relevant domains, REDMOND and NORTHAMERICA, are both part of the CORP forest.  The DFSR object is in the REDMOND domain, and Fargo is part of the NORTHAMERICA domain.

When we looked on a REDMOND DC for the object, we found:

Dn: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com
cn: Dynamics_Build202;
description: Contact: <snip>;
distinguishedName: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0x0 = (  );
instanceType: 0x4 = ( WRITE );
msDFSR-Options: 1;
msDFSR-ReplicationGroupType: 0;
msDFSR-Schedule: ��������…
msDFSR-TombstoneExpiryInMin: 86400;
msDFSR-Version: 1.0;
name: Dynamics_Build202;
objectCategory: CN=ms-DFSR-ReplicationGroup,CN=Schema,CN=Configuration,DC=corp,DC=microsoft,DC=com;
objectClass (2): top; msDFSR-ReplicationGroup;
objectGUID: c527a764-97da-4597-935d-dc96ad1fd889;
showInAdvancedViewOnly: TRUE;
uSNChanged: 452529472;
uSNCreated: 450899211;
whenChanged: 6/24/2008 12:50:51 PM Pacific Daylight Time;
whenCreated: 6/22/2008 11:18:13 PM Pacific Daylight Time;

So the REDMOND DC’s did have the attribute the service was looking for, in this case msDFSR-ReplicationGroupType

When we queried the NORTHAMERICA DC’s would find:

Dn: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com
cn: Dynamics_Build202;
description: Contact: <snip>;
distinguishedName: CN=Dynamics_Build202,CN=DFSR-GlobalSettings,CN=System,DC=redmond,DC=corp,DC=microsoft,DC=com;
dSCorePropagationData: 0x0 = (  );
instanceType: 0x0 = (  );
name: Dynamics_Build202;
objectCategory: CN=ms-DFSR-ReplicationGroup,CN=Schema,CN=Configuration,DC=corp,DC=microsoft,DC=com;
objectClass (2): top; msDFSR-ReplicationGroup;
objectGUID: c527a764-97da-4597-935d-dc96ad1fd889;
uSNChanged: 83626939;
uSNCreated: 82256556;
whenChanged: 6/24/2008 12:44:22 PM Pacific Daylight Time;
whenCreated: 6/22/2008 11:18:13 PM Pacific Daylight Time;

Ok, so at this point, we’re not talking rocket surgery or anything.  It was pretty apparent that the attributes that the DFSR service is looking for are not part of the partial attribute set, so they aren’t replicated to the GC. 

At this point, we’re feeling confident that the data for the REDMOND DFSR object wasn’t on the NORTHAMERICA RODC because it wasn’t supposed to be (not part of the PAS), so we started sniffing around to see what the actual problem could be. 

We started asking ourselves a question:  If you query a NORTHAMERICA GC on port 3268 for a REDMOND object, what do you get?  The answer of course is above, you get the object with the PAS.

But what if you query a NORTHAMERICA GC on port 389 for a REDMOND object?  The answer is, that since you’re querying the LDAP port, you should get a referral back to a REDMOND DC, and your client will chase the referral (unless told not to) and end up querying a REDMOND DC for the object.  In which case, they get the object with it’s full set of attributes.

At least that’s the normal, expected behavior.

What we found though was slightly different.  If you query full DC’s/GC’s, then you get the results you expect.  But when we deployed RODC’s, we found that if you queried an ROGC, on port 389, for an object in the REDMOND domain.  Instead of being returned a referral to the REDMOND DC, you were instead returned the object out of the servers GC partition, which only contains the PAS attributes.


A quick conversation with the product group came up with a few things:

1.  This isn’t the behavior we want, and it’s fixed in Server 2008 R2 (Win7 Server)
2.  The fix for this, is to add msDFSR-ReplicationGroupType to the PAS (Partial Attribute Set) so it replicas to all GC/ROGC’s.  Click here for how to do that.
3.  It’s generally considered a bad practice to rely on referrals to redirect you to where your data is

So now we’ve got this out of the way, and I think there will be a KB article coming sooner or later on this.  But for now, if you’ve got a multi-domain forest, where a DFSR replica set spans across the domains, and you’re using ROGC’s…well…hopefully you’ll find this post 🙂


Posted in Active Directory, Random Tecnical Stuff | 1 Comment »