Microsoft recently released the Azure AD Single Sign On preview feature, which is a way to support Kerberos authentication in to Azure AD. The neat thing about this is that you don’t need ADFS to have an SSO experience if you’ve already got AD infrastructure in place. It works the same way as in-domain authentication, via a Kerberos ticket granting scheme.

This is a somewhat confounding feature for anyone who has experience with Kerberos in Windows because every party needs to be domain-joined for Kerberos to work. This doesn’t seem possible in the cloud considering its a) not your box, and b) it’s over the public internet. Now, you could create one gigantic AD environment in Azure and create a million trusts to each local domain, but that doesn’t scale and managing the security of it would… suck. So how does Azure AD do it?

It’s deceptively simple, actually. Kerberos is a federated authentication protocol. An authority (Active Directory — AD) issues a ticket to a user targeting the service in use which is then handed off to the service by the user. The service validates that the ticket came from a trusted source (the authority — AD) and converts it into a usable identity for the user. The validation is actually pretty simple.

  1. Both the service and authority know a secret
  2. The authority encrypts the ticket against the secret
  3. The service decrypts the ticket using the secret
  4. The ticket is validated if decryption succeeds

It’s a little more complicated than that, but that’s the gist.

Nothing about this process inherently requires being domain-joined — the only reason (well… not the only reason) you join a machine to a domain is so this secret relationship can be kept in sync.

With this bit of knowledge in hand, it’s not that big a leap to think you can remove some of the infrastructure requirements and have AD issue a ticket to the cloud. In fact, if you’ve had experience with configuring SSO into apps running on non-Windows boxes you know it’s possible because those boxes aren’t domain joined.

So enough background… how does this work?

During installation and configuration:

  1. A Computer object is created in AD representing Azure AD called AZUREADSSOACC
  2. Two Service Principal Names (SPNs) are added to the account
    • HOST/
    • HOST/
  3. A password is created for this account (the secret)
  4. The secret is sent to Azure AD
  5. Both domains of the SPNs are added as intranet zones to any machine doing SSO

Authentication works as follows:

  1. When a user hits and enters their username, an iframe opens up and hits the autologon domain
  2. The autologon domain returns a 401 with WWW-Authenticate header, which tells the browser it should try and authenticate
  3. The browser complies since the domain is marked as being in the intranet zone
  4. The browser requests a Kerberos ticket from AD using the current user’s identity
  5. AD looks up the requesting autologon domain and finds it’s an SPN for the AZUREADSSOACC computer
  6. AD creates a ticket for the user and targets it for the AZUREADSSOACC by encrypting it using the account’s secret
  7. The browser sends the ticket to the autologon domain
  8. The autologon domain validates the ticket by decrypting it using the secret that was synced
  9. If the ticket can be decrypted and it meets the usual validation requires (time, replay, realm, etc.) then a session key is pushed up to the parent window
  10. The parent window observes the session key and auto logs in

The only sort of synchronization that occurs is that initial object creation and secret generation. AD doesn’t actually care that the service isn’t domain joined.

Technically as far a AD knows the service is domain joined by virtue of it having a computer account and secret, but that’s just semantics. AD can’t actually manage the service.

That’s all there is to it.

Kate and I bought our first house a few months ago. This likely comes as a shock to us more than anyone else. The house was built in 2002, which means it has the benefit of being built to a more rigorous set of standards and codes than say a house built in 1972 and as such is theoretically safer and more energy efficient. The downside of a house built in 2002 is that it’s on the wrong side of the great technology upgrade divide.

Most houses these days are wired with data in mind. The current standard is somewhere between CAT-5e and CAT-6a as they can be used for any number of evils throughout the house like internet, home theater, or even analog telephones, and are somewhat future-proof because they can handle gigabit to theoretical 10-gigabit speeds. In addition, coax is still often run to many rooms for cable boxes or internet connections. If you go back in time a few years you might see a few networking runs, but you’ll see more coax runs, and possibly a few analog telephone runs using CAT-3. If you go even further back, you’ll find just coax and CAT-3, and if you keep going back you’ll see even less. The farther you go back, the less useful wiring you’ll find.

original-wiringThere was a time when builders didn’t really add any extra wiring capacity to homes, but consumers had a demand for technologies requiring it, so the home owners got the service providers like the cable or phone companies to do the wiring installs. The unfortunate problem is that the installed wiring is often not future-proof and therefore has a limited utility, and, of course, needed updating whenever technology matured past a certain point.

What this long winded history lesson leads to is the fact that this house was built with very little useful wiring for my home network.

One of the first things I did when we moved in here was to do an inventory of all the wiring. The previous owners liked to watch TV, and they liked to talk on the phone, but the house wasn’t pre-wired for this sort of thing so at some point they got the-cable-provider-that-shall-not-be-named to run a ton of coax and CAT-3 everywhere.

One nice thing about outdated wiring is that you can use it as the pull string for the new wiring. In this case the wiring all originated from the ugly lovely beige service points on the front of the house, and ran into the basement where it developed into a rats nest of wiring. Thankfully coax requires special termination when branching because of signal degradation, but CAT-3 telephone wiring does not. Well, it does, but not for idiot installers. Each telephone drop was haphazardly run through whatever seam was available, or run through pre-existing holes used for mains wiring (balanced connection or not, there’s going to be interference), and the installers just used electrical tape and wire nuts whenever they needed to be spliced into another line.

The wiring running upstairs exited the basement through a hole in the wall used by the power and refrigeration lines of the AC condenser, hidden away inside the little lip on the siding used to move water away from the house, run up the side of the wall, back into the wall, and sealed off with some water-resistant sealant.

So I had that going for me.

I decided none of it was salvageable, and more importantly none of it was running the right way, so I ripped it all out.

By this point, my ISP, EPB Fiber, had already been in and ran a new CAT-5E cable to a spot near a shelf in my garage (see what I mean above?). We owned the house all of a day and half when the installer showed up so I hadn’t given a lot of thought to where it should go. The only option I had at this point to was to plug in a wireless router. The router worked fairly well for a while, but there were two critical flaws in it’s location: 1) it gets hot in the summer because the basement is not insulated, and 2) it was about as far away from my office upstairs as it could be, so the signal sucked.

The next step was to figure out how this place should be wired. I’ve learned a few things over the years having been part of many office cabling jobs. There are a few simple rules worth keeping in mind when trying to lay out a wiring design:

  • All wiring should come to a head in a single place
  • That place should be central to everything, if possible
  • Keep the runs as short as possible
  • Run more cables than you think you’ll need

I’m sure the pros can list a dozen more rules, but these are what I know.

I had a pretty good idea where I wanted network drops, but I didn’t have a great idea where they should all start. I consulted my mostly-to-scale drawing of the house I created in Visio (every home owner makes one of these, right? No? Just me? Weird.) and found that the trunk line for the second floor AC runs up a column right in the middle of the house.

The red circle is approximately where the column runs to the attic.

The red circle is approximately where the column runs to the attic.

That column runs from the basement all the way to the attic. Handy. A few feet away from that is the back of the basement stairs where the previous owners stored a bunch of leftover materials from the renovation they did. It wasn’t useful for very much besides storage, so I decided it was the best place to run all the wires.

Under the stairs turned out to be a good spot to house the wiring.

Under the stairs turned out to be a good spot to house the wiring.

As luck would have it, the new internet drop was actually installed just on the other side of that wall, so it didn’t have far to go to get to under the stairs. Unfortunately the installer did something that I found to be stupid:

Can you guess which one they installed?

Can you guess which one they installed?

In reality it probably had no impact on performance. The cable was crossing perpendicular to the mains, never really ran parallel with any of it, and it was a good distance from everything. Still… it looked bad, and it bugged me. Since I was already running wire, it wouldn’t hurt to plan to include another 50ft or so to the fiber demarc out front.

So now that we’ve got a nice central spot for everything to run, I needed to figure out what to run. EPB runs CAT-5e as a matter of course because it’ll support gigabit, but it’s hitting it’s upper limits of performance these days. I decided to go with CAT-6 because  my base internet connection is gigabit fiber with the potential to upgrade to 10-gigabit (seriously), and it’s still got a lot of room for upgrade in the future. I also couldn’t justify spending twice the cost for CAT-7 on the whim that I might upgrade to 10gb in the future. Frankly at that point I’d just run fiber — it’s more fragile, but not susceptible to interference.

Equal parts useful and frustrating.

Equal parts useful and frustrating.

Anyway, getting back to realistic future-proofing, I decided to run at least two cables per room, more for rooms I know would need it — like my office. I measured the runs from under the stairs, up the column to the attic, across the ceilings, and down the walls to the various spots they needed to go. I added 20% to each run for safety and figured I needed a little more than 600 ft of cable.

I bought a roll of 1000ft and cut it into segments long enough for each run. I could have bought less, but its cheap in bulk, and I was going to make mistakes. I collected all the wire destined to run all the way to the attic (most of the wiring as it turns out) and taped them all together every 5 ft or so. I ended up with a massive and heavy snake of a cable.

Now the fun part. If you’ve ever run cable you know it’s a pain in the ass, especially through multiple floors. I had to get the heavy cable from the basement all the way to attic. I decided to use a metal fish tape run through the column from the attic to the basement (hitting every possible thing imaginable along the way). My working theory was this: pull as much cable into the attic as possible, leaving just enough in the basement long enough to be neatly run to the spot under stairs. It worked well enough, but gravity didn’t have any of it, so I had to tie some off in the attic and route it through the access hole to keep it from falling.

Why yes, that is the mains and smoke detector signal wire running across the access hole.

Why yes, that is the mains and smoke detector signal wire running across the access hole. It’ll have to get fixed… later.

Cut the three sides at a steep angle leaving the top uncut.

Cut the three sides at a steep angle leaving the top uncut.

The next phase was to get the wires to the necessary walls, which were, of course, at opposite ends of each other. I bought a bunch of cheap hooks to hang in the attic so the wires weren’t just sitting on the insulation. In addition to keeping things neat and tidy, they also provided spots to loop the wires so they don’t get pulled taught.


Once the wires were in the general vicinity of the wall I had to drill holes so they can run down the wall to their final spot. I cut a hole in the wall where I wanted to network drop to go, and used a 48″ drill bit to drill up the wall into the attic space. I was expecting to hit a fire stop in the wall (a horizontal 2×4 fit between the wall studs) and was not surprised when I hit one with the bit. It was too cumbersome to drill through it with the 48″ bit, so I cut a hole just below the fire stop and used a shorter bit to drill through it.

Use a punchdown tool for the wires.

I had learned a neat trick when cutting holes: cut out the left, right, and bottom sides at a steep angle, but leave the top side uncut. Break the top drywall, but leave the paper intact. Now you wont lose the chunk, and it’s easier to repair. 

Once I was past the fire stop I was able to use the 48″ bit to drill through into the attic. I ran the fish tape up the wall, using the upper cutout to guide it into the attic, taped the bundle of wire destined for that wall to the end, and yanked it down. Rinse and repeat for each wall. Once I was certain I was done in the attic, I cleaned up the insulation that got moved around (don’t compress insulation — it reduces it’s effectiveness), closed up the access hole and proceeded to drink a gallon of water — word of advice: only do work in the attic early in the morning, or in the winter, or hire someone else to do it. The wires were terminated with CAT-6 keystone jacks.

Now I needed to finish the other ends back down in the basement. I didn’t want to just terminate the wires with RJ-45 connectors, so I opted to wire them into a patch panel.

Measure your lengths carefully. You don't want to rip out the wires and start all over again because they don't sit right in the channel.

Measure your lengths carefully. You don’t want to rip out the wires and start all over again because they don’t sit right in the channel.

The patch panel wasn’t going to mount directly to the wall, and all the networking components needed a place to live, so I mounted everything into a rack. This had the added benefit that it has a small fan at the top pulling air over all the components keeping them just a little cooler than they would normally be.

The glass is nice because you can see the blinky lights when all is done.

The glass is nice because you can see the blinky lights when all is done.

However, the area beneath the stairs was open stud, so I needed a place to mount the rack. I bought a sheet of 3/4″ plywood and attached it with a dozen screws across 3 studs. The rack itself was mounted to the plywood, into the studs with four 5/8″ x 3″ lag screws. I don’t think it’s going anywhere.

Before wiring in the patch panel, I routed the wires through a hole in the top of the rack and neatly wrapped them together using Velcro ties — don’t use zip ties, they’ll dig into the jackets.

Those hooks came in handy. They keep everything neat and tidy.

Those hooks came in handy. They keep everything neat and tidy.

Once the patch panel was wired in I used a simple continuity-based cable tester to verify I didn’t mix up any pins. Of the two-dozen or so jacks, I only switched one wire pair in one jack — not bad!

I installed the patch panel at the top of the rack to allow for proper cable management. Below the patch panel is a Ubiquiti EdgeRouter, and below that is a Linksys switch. At the bottom is a small UPS mostly just used to keep everything alive long enough to prevent any damage during power outages. On top of that should be a small shelf, but I couldn’t be bothered to install it. Where the shelf should be is all the gear that isn’t mountable, like the NAS, Cisco SMB PoE switch, and the power injector for my network-connected Geiger counter.

Velcro ties are amazing.

Velcro ties are amazing.

I decided to color code all the patch cables. Red is inter-network, and yellow is intra-network.

A speed test was in order once everything was all wired in.

Not bad.

Not bad.

Not bad at all.


There is a growing trend where authentication is occurring within browser controls in applications instead of through native UI. In general, this is good because it makes things like federation simpler, and lets you use different forms of authentication without requiring changes to native components.

This means any application you build can rely on a single authentication service and support a multitude of credential types without having to do anything in your own native app. Microsoft is all in with this through Azure AD, and through the ADAL (Azure Active Directory Authentication Libraries).

This is just rendered HTML.

This is just rendered HTML.

Of course, there are problems with that. Paramount is that on Windows you’re more or less stuck with using the Internet Explorer WebBrowser Control. Now, IE has come a long way over the last few years to be standards compliant and overall it works really well. The story, however, is a little different when you’re using the WebBrowser control. That’s because the control defaults to IE 7 compatibility mode, meaning any HTML rendered through the control is interpreted by a — in the literal sense — retarded rendering engine. It really doesn’t function well and has no support whatsoever for any newer technologies.

Alternate title: Debugging JavaScript in Embedded Browsers on Windows.

There are ways you can fix this by using the X-UA-Compatible header or meta tag, or through the FEATURE_BROWSER_EMULATION registry key, but sometimes they both just fall short and you’re stuck troubleshooting just what the heck is going on in the page — and you don’t get the fancy F12 tools since it’s hosted in a process separate from a browser.

So how do you debug this thing? Thankfully Microsoft has a lot of debuggers, and most of them are available through Visual Studio. The process is pretty simple.

First, you need to enable script debugging in Internet Explorer (or disable-disabling script debugging) by unchecking both “Disable script debugging” options.

Enable Script Debugging

Enable Script Debugging

A word of advice — check these again when you’re done otherwise you’re going to see a lot of annoying pop ups asking to debug things.

Next, open Visual Studio and open the debugger Attach to Process window. Open the code Type Selection and switch to Script debugging.

Script Debugging

Script Debugging

Now attach the debugger to the offending process.

You are offensive, sir.

You are offensive, sir.

And cause something to explode.

Let's go offend someone!

Let’s go offend someone!

And it explodes.

There goes the neighborhood.

There goes the neighborhood.

Now you can break into the code and figure out what’s going on. The nice thing is that it’s a full debugger, so you have access to all the usual tools like the console.

Consoling You as you debug.

Consoling You as you debug.

Have fun.