Rob Sanders

IT Professional and TOGAF 9 certified architect with over 16 years experience, 14 in commercial software development and 8 years in IT consulting. Check out the "About Rob" page for more information.

Sep 082014
 

Hi All.

I’ve long moved all my kit reviews over to the Lego Republic but I felt that this one deserved some presence here at Sanders Technology.  Over the Father’s Day weekend, I assembled the following advanced Lego kit which is based on “The Tumbler” from the most recent Batman series of movies starring Christian Bale.

IMG_0759.JPG IMG_0770.JPG
Windscreen view / Rear tyres

Clocking in at 1869 parts, it’s not even close to being a lightweight set – this one if clearly for the adult fan or the very experienced teenaged builders.  It’s probably more attractive to those who have experience building Technic sets, but will appeal to anyone who is up for a building challenge.

IMG_0766.JPG IMG_0763.JPG
Interior view / Side profile

This set features two exclusive minifigures including Heath Ledger’s version of the Joker (which no doubt will be in high demand).  The assembled model is highly detailed and well designed and resembles the attention to detail often found in the Star Wars Ultimate Collector’s Series (UCS) models.

IMG_0762.JPG
Rear profile – massive wheels

The Tumbler, once complete, is just as intimidating as depicted in the films. 

IMG_0761.JPG
Side profile

More details on the five and a half hours it took me to build this Lego behemoth will be posted shortly on the Lego Republic.

IMG_0767.JPG
Driver’s seat

Aug 252014
 

IMG_0363_Medium

Well, I’ve finally managed to assemble the dream – a proper work space for working on servers, workstations, laptops and the like.  It’s been years since I’ve been in a position to put something together, but a few weeks ago I managed to finalize the installation.

IMG_0364_MediumIMG_0365_Medium

Aside from the home handyman capabilities this set up allows, the integrated LCD monitor, 5-port gigabit switch, waterproof keyboard and wireless mouse set under a twin pair of halogen lights gives me a place to bring equipment for full analysis and tinkering.

That is… assuming it‘s not freezing in the garage – the room isn’t insulated (yet) so there’s still that barrier to entry.  Have you got a similar work space?

Aug 212014
 

It’s been over two years since my last foray into the murky waters of Active Directory Federation Services (ADFS) 2.0 and it came past due for a return to claims-based authentication and federation.

My previous journeys were somewhat chronicled here and here.  This time around though, I’m going to be focusing on the latest and greatest – meaning Windows Server 2012 R2 (with update), which has been a far more pleasant journey thus far.

I literally started from scratch, because I rather like the environment to be clean before establishing a baseline configuration.  From my earlier article:

so if you’re going to do this properly, get your certificates sorted out up front.  My approach is to install and configure an Enterprise Certificate Authority and issue certificates from there.  Then, it’s just a matter of trusting the root CA (signing) certificate in your environment, and your cert chain should be valid

I’m excited to say I took my own advise and started with the basics first.  As you may recall from my earlier writing, my preferred scenario architecture is the segregation of external and internal entities by way of separate Active Directory forests.

As last time, I’m working predominantly with an initial set of four separate virtual servers, configured as follows:

image

Using an Enterprise CA, I trust the root CAs and then issue certificates as needed, and manage the DNS within each Active Directory forest.  This time around I fully configured the CAs in both domains for web enrolment and device enrolment as well as updating group policy to include the Enrolment Policy locations.

 

image

I also added the Root CAs of each domain to the Trusted Root Certificate store in the opposite domain’s DC (where AD FS is located) so that the federation Uris would be valid when the trusts were established.

Believe it or not, this doesn’t take very long to set up.  Configuring each domain at the same time (in parallel), I had most of the configuration working and tested in about an hour or so.  Having done it many times before, I knew the correct order to install and configure which makes a huge difference.

Installing IIS on the CA server also means you can avoid having to install IIS on the domain controller server, which is a nice win in terms of resource minimisation. 

Since we’re dealing with a few certificates here and there, it’s important to remember that clients/machines that do not trust the root CA signing certificate will experience warnings or other inconveniences – in other words, don’t do this in a Production environment unless it’s only used solely in-house, where you can deploy the CA signing certificate into the trusted root CA stores. 

External AD FS installations should always be signed using a certificate from an external (public) CA like https://www.startssl.com which offers free class-1 certificates.

image
Certificate Path

My Desired Outcome

What I want to be in a position to do is to offer users a choice of realms:

image

For the sake of keeping things clear, I’ve labelled the relying parties to indicate which domain they live in, but you probably would label the DMZ as ‘External Users’.

What should happen, once a user has authenticated, is that their subsequent requests to claims-aware applications shouldn’t require any further authentication, and their identity should be available across both environments.

Generating Valid Certificates – The Low Effort Way

Another tip – the AD FS installation expects a certificate (plus private key) with the common name of the ADFS service you’re going to configure to be in the .pfx format.

if you want a fast way of generating a web server certificate and you have an Enterprise CA installed and configured within the domain, you can switch to IIS Manager and request a Domain Certificate when viewing the server features (under Server Certificates):

image

Here you can add the common name and friendly names

imageimage

When you’ve entered the information, the wizard will go off and request a Web Server certificate based on the common name, and then will automatically store it in the Computer Account’s Certificate store.  You can fire up MMC and add the Certificates snap in (FIle –> Add/Remove Snap In) making sure you select ‘Computer account’ along the way:

imageimage

Once the certificate is located, you can simply export it including the private key.  Just move the exported .pfx file to the ADFS host, and you’re ready to install with a valid certificate.

A word about ADFS installation

I’m not going to go into detail about how to set up AD FS 3.0 itself, the existing documentation on the Internet is quite accurate, and honestly, if you’ve established the environment correctly, it’s really not tricky to do.  In Windows Server 2012 R2, ADFS 3.0 is a bona fide server role (in 2008/R2 the server role was ADFS 1.0/1.1, 2.0 was a separate download & install).

Sanity Checking the ADFS configuration

As mentioned in an earlier post, a quick browse to the following location: https://<your adfs location>/federationmetadata/2007-06/federationmetadata.xml should yield a metadata response:

image

Summary

This was just a brief intro to the environment I’ve configured, I’ll be going into more detail about how to live in a claims-aware environment in subsequent articles.