BPuhl’s Blog

A little bit of everything without actually being much of anything

Archive for August, 2008

For the engineering, physics types out there (with time to spare)

Posted by BPuhl on August 26, 2008



Posted in Randomness | Leave a Comment »

I have no idea what this is…

Posted by BPuhl on August 23, 2008

But the only way that I found that I was able to stop playing this…was to blog about it, so that everyone else can share in the timesuck…


Posted in Randomness | Leave a Comment »

Getting Single Label Name Resolution on MDM Enrolled Phones

Posted by BPuhl on August 21, 2008

If you’re using Mobile Device Manager, it’s likely that you’ll want to have your phones be able to resolve single label names.  If you do, then there are 2 basic options that you have, first you can make WINS servers accessible to the devices, or alternatively, you can configure the phones to append a DNS suffix to single label name queries.  In fact, as with the full OS’s, you can actually do both.

There is a Technet article located here which talks about some of this, and gives the following ADM template to be used to apply 2 registry settings to the phones – IMPORTANT DETAIL: AS OF 8/21/2008, ONE OF THE REG KEYS BELOW IS INCORRECT – SO KEEP READING!!!!

CATEGORY “Windows Mobile Settings”
       CATEGORY “Contoso DNS Settings”
            POLICY “Name Resolution Ordering”
                  KEYNAME “SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Comm\AFD”
                          VALUENAME “NameResolutionordering”
                          VALUEON NUMERIC 4
                          VALUEOFF NUMERIC 1
            END POLICY
            POLICY “DNS suffix”
                  KEYNAME “SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Comm\MSEC\IPSECVPNNIC1”
                  PART “Enter the dns suffix required” EDITTEXT REQUIRED
                         VALUENAME “Domain”
                        DEFAULT “dns.corp.contoso.com”
                         MAXLEN 32
                  END PART
            END POLICY

The net effect of setting these 2 registry keys is *supposed* to be, that they change the single label name resolution behavior to WINS first, and then to DNS with the suffix appended.

But in my MDM environment, I don’t actually have WINS servers available.  So this article doesn’t fully apply to me, and possibly you.  The MSIT MDM deployment exclusively uses DNS, so the first thing that was important was to find that the NameResolutionOrdering registry key has the following settings:

The search order for name queries when set is:
          Default (or 1) –  DNS then WINS
          Value 4 – WINS then DNS

The DNS queries will append any suffix as configured

So with this handy bit of information in hand, the first thing I did was chop out the section of the ADM template that set that registry key.  In my case, default was good enough for me.  Then I applied the GPO linked to the OU which our devices are in, recalculated the policy manually (I’m impatient) by using the update-MobilePolicyCalculation cmdlet on the Device Management server, and reconnected my device (using the Connect Now utility from the MDM resource kit client tools)

At this point, everything was working great – EXCEPT for that fact that it didn’t work.

When I would sniff the traffic on the DNS server, the queries all came in as single label names and did not have the suffix appended.  After much thrashing about checking registry keys and investigating the client, I finally dragged one of the Program Managers from the product team over to my office to help.  That was about the time that he let me in on the secret, that there is a “documentation bug” filed on that page, because the registry key for the setting the suffix is wrong.  Oh great.

Rinse repeat the whole thing with the correct registry key, and here is what the ADM template which actually worked finally looked like:

CATEGORY “Windows Mobile Settings”
      CATEGORY “MSIT DNS Settings”
           POLICY “DNS suffix”
                 KEYNAME “SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\Comm\MSEC\IPSECVPNVNIC1\Parms\TcpIp”
                 PART “Enter the dns suffix required” EDITTEXT REQUIRED
                        VALUENAME “Domain”
                        DEFAULT “mdm.microsoft.com”
                        MAXLEN 32
                 END PART           
            END POLICY

And that ladies and gentleman, is all that’s required to get single label name resolution on a mobile device, by appending a DNS suffix.

Posted in SCMDM | 7 Comments »

MSIT Schema Admin Whitepaper

Posted by BPuhl on August 20, 2008

The IT Showcase team just published our updated (actually, rewritten) white paper on how the MSIT identity team manages schema changes in AD.  There is also a webcast done by Joel Silver, talking about our schema change process.

Technical White Paper

IT Pro Webcast

Posted in Active Directory, Digital Identity, Identity and Access | Leave a Comment »

Tropic Thunder

Posted by BPuhl on August 16, 2008

Holy cow, that was just hilarious!  Not exactly the cinematic, theatrical debut of the century – but the perfect way to go sit in a cool theatre on a hot day laughing your a*s off.

I know who I am! I’m the dude playing the dude disguised as another dude! – Kirk Lazarus (RD Jr.)

“Les Grossman” really steals the show

Posted in Randomness | 1 Comment »


Posted by BPuhl on August 16, 2008

Walking up to work yesterday, there were a couple of kids – a brother and sister, maybe 8 or 9 years old – with a Coleman jug, stack of Dixie cups, and a pile of napkins – on the table hung a sign – LEMONADE 25 CENTS!

I remember growing up, and my dad who still spends his days driving around Huntington Beach, CA as a phone repair guy, would come home and talk about how he stopped at 4 or 5 or 6 lemonade stands.  One thing I learned from him – you never drive past a lemonade stand without stopping. 

Sunshine, warm weather, and cold lemonade.  Perfect start to what turned into a great day.

Posted in Randomness | Leave a Comment »

Application behavior with AD

Posted by BPuhl on August 8, 2008

Recently received an e-mail from a rock star co-worker who, for purposes of this blog, we’ll call “Randy” (largely because that’s his name).  His question was based on some questions that he was getting from a large, enterprise customer, and (slightly edited) went something like this:


Is the MSIT AD team burdened with expectations that the DC’s Name and IP address will remain the same, requiring that a new DC maintain the old Name and IP address when it is replaced?

<company’s> AD team is burdened by users that hardcode applications to a DC’s Name or IP address which makes the DC replacements with new hardware or the introduction of new 2008 DCs to replace old 2003 DCs with new HW much more difficult. 

I have said ideally the AD team should be free of such constraints.  (TCO increase, added time delays negatively impacts service availability, and they lose flexibility I want them to have.)

I have said an application that is hardcoded to the DCName or IP is “poorly written” and instead it should do a serverless bind, or understand SRV DNS records, etc.  (Windows can use the Locator, non Windows applications may account for the majority which I think we can address, partly with a registration system where application owners can be notified about Name and IP changes (if accepted by management.)

Their AD team does not have the executive sponsorship and they get blamed when users escalate issues and says the DC’s “broke” their application.

If Microsoft’s AD team does not have this burden or has executive support in other ways you could share?

I have now told the AD team that at a minimum they need to explain that these additional constraints add to the overall costs of AD.  Executives can approve the costs and need to understand they are not following best practices that AD is a service with published (DNS, Locator) location mechanisms.  Also similar constraints can further limit flexibility into the future.

Any comments on any of these statements is eagerly encouraged and appreciated.


Depending on where you work, politics, management support, etc… As you read this, you might think that this type of situation is absolutely ridiculous, or else it’s completely familiar and comforting to know that someone else lives in the same hell that you find yourself in each day at the office.

Here was my response (again, slightly edited):

There are only 7 infrastructure servers (which are not DC’s) which I’m aware of, that have a hard-coded IP address requirement – and those are the 7 stand-alone DNS servers which make up our internal root.

We are incredibly aggressive AGAINST anyone/anything hardcoding an application to either a domain controller name or an IP address.  We have a slight benefit, because with dogfooding, we often have DC’s offline.  So our SLA is that we will “always have capacity to provide services, but will never guarantee that any given DC will be online at any given time”  Which works because we typically have 2-3 DC’s offline for troubleshooting.

The closest thing that we’ve come to an “accommodation”, is the case of legacy NAS devices which had a dependency on the PDC.  After working with this team, we decided to implement a notification script, which will send that team an e-mail within 15 minutes of the PDC role being moved to a new server.  They are then responsible for updating their device configuration.  We do not give prior notice, or anything like that, it’s just a batch script in a schedule task that checks the PDC and send e-mail.

What I’ve said above is our “official” position.  The reality is that operationally, it’s much easier for us to keep the same IP addresses on servers because we have a dependency on them.  Our IPSec policies, and firewall (router ACL) config’s have the DC’s listed by IP address, and getting those updated is operationally a hassle.  In the past 7 years, we’ve renamed every DC at least 3 times that I’m aware of though, so anyone taking a name dependency would have a hard time.  Our network team has also re-IP’d the network at least twice that I know of, and an additional time recently where they re-IP’d a datacenter, so taking an IP dependency would be bad news as well.

I guess in short, is that we have avoided digging ourselves into that hole, so we haven’t really required executive level support to get out of it.  We have just established clear guidelines for consumption of our service, and told the application builders that they can build at their own risk.  It probably also helps that we are so dynamic, that any app which was hardcoded would be down more than it was up.

Hope this helps,


In typical IT organization fashion, we learned a long time ago that we can’t “say no” when the business comes around with a requirement.  But what we’ve found, is that by publishing and evangelizing clear (or at least murky) guidelines, we’ve been able to head off some of these types of problems.

And like I said in my reply, it probably also helps that we keep changing our names and IP’s all the time.  So if they don’t follow our guidance, they are surely going to break at some point.  🙂

Posted in Active Directory | 3 Comments »

Computers are people too

Posted by BPuhl on August 7, 2008

I remember hearing (and saying) that “computers are people too” quite a bit during Server 2008 dogfooding.  It was the way that we reminded ourselves that machine accounts are security principles, and in many ways, they are the most vulnerable security principles.  For example, a machine account is an “authorized user”, and can do the whole plethora of things which auth’d users can do, but it lacks the reliability of separate user names and passwords the way traditional users do.  Machine accounts manage their own passwords, but they’ll let any schmuck who can run something in machine context to “use” them.

This has a few implications.  From the AD perspective, when we’ve thought about machine accounts, it’s usually in the context of life cycle management of data in the directory.  You know, find all the machine which haven’t reset their passwords in 45 days – assume that this indicates that they aren’t on the network anymore, so delete the object.  Good housekeeping maneuver.

With Windows Server 2008, and specifically, with Read Only Domain Controllers – machine accounts became a little bit more important.  Do you let them have their passwords replicated into the RODC?  What happens if the users password is cached, but the machine isn’t?  No service ticket, no work-ey… 

In the federated identity world specifically, we branch this thought process out a little bit further – We want to treat the people like people, and the computers like people, but we also treat the applications like people too!  This actually isn’t specific to federated identity, because we all do this all the time anyway – we just use fancy words, like “service accounts”, “application pools”, and “delegation”.  But at the end of the day, what we’re doing is trying to force the application to “authenticate” to that which it is “authorized” to perform some function – huh…sounds just like machines and people…

So I’ll leave this for now, to let you munch on for a bit – just remember that your users aren’t the only users that you have – machines, and in some cases applications, are people too – and when you’re considering things like security policy, you shouldn’t forget it.

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

Posted by BPuhl on August 7, 2008

Hey!  See that…yeah, that thing wwwwaaaayyy over there?  Yeah, THAT was the point!  Guess you missed it…

(no, no reason why I’m posting this here or now…other than the fact that I said this to someone the other day, and I need to unstick it from my brain…)

Posted in Randomness | Leave a Comment »

Goldfinger Editions

Posted by BPuhl on August 6, 2008

I received an e-mail from Sanjay a little while ago, pointing me to some of his recently released “editions” of Goldfinger, his security analysis product.  I haven’t had the chance to download or test them yet, but plan to do so when I can finally come up for air at some point. 

If you want to take a look though, they are available here:  http://www.paramountdefenses.com/goldfinger_editions.php

Posted in Active Directory | Leave a Comment »