Minimalist Office 365 with ADFS sandbox

It’s kind of killing my laptop, but I have managed to get my virtual lab environment working with ADFS to an Office 365 trial. I think I’ve probably got the bare minimum config going on here, so for reference, here’s what I had to do.

Ingredients

• A host computer – in my case my Win7 laptop running Oracle VirtualBox,
• An Office 365 trial,
• A real live domain name that is resolvable on the internet and which you (or someone who likes you) has admin access to (this will be necessary for the verification process),
• A SSL certificate for said domain name,
• The following VMs:
• DC + ADFS: Win2008R2, 1024 MB of RAM (I couldn’t get ADFS to install with only 512MB), virtual network and internet access
• DirSync: Win2008x32, 512 MB of RAM, virtual network and internet access
• Workstation: Win7, 512 MB of RAM, virtual network and internet access

Note: there is now a 64 bit version of DirSync so it should be possible to install that on the DC as well.

AD

The name of my virtual AD domain did not match the external domain I had to use for ADFS. This does not matter – just add the external domain as a UPN suffix to AD.

You then also need to make sure any account you want to test with has a UPN of accountname@myrealdomain.com.

Certificate

I was under the impression that I’d need a public cert so Microsoft would trust my ADFS server, so I got a free one month cert from freessl. However I can see now that the cert is only used for internal communication between my ADFS server and my client, so I think now if I’d generated one in my own CA it would have been fine. The only provisio is the name of the cert must match myrealdomain.com.

ADFS

The instructions walk you through a proper setup with NLB and federation proxies. With a laptop lab I did none of this. I just have the one federation server running on my DC. Pretty much all I did was:

1. Installed ADFS – make sure you choose “first server in a farm”,
2. Installed the SSL certificate for myrealdomain.com onto the default IIS website,
3. Ran the ADFS wizard,
4. Ran the powershell cmdlets to add and federate the domain in Office 365 (documentation).

Internet Firewall

Another thing I was mistaken about was thinking the Microsoft Federation gateway would need to talk directly to my ADFS server but actually it doesn’t – the communication is between the client browser and ADFS. I’m not allowing external devices to access Office 365 via my lab, so I don’t need to grant access to my ADFS VM through the network firewall. Which is a relief!

DNS

The domain myrealdomain.com has a real, live ip address on the internet, however in my virtual network I want it to resolve to the internal ip address of my ADFS server. To do this I:

• Created a Primary Zone for myrealdomain.com in my domain’s DNS service,
• Created an A record in the zone pointing to the internal ip address of the ADFS server,
• Set a forwarder to the external DNS server, and
• Made sure all VMs in my virtual network used the virtual DC for DNS, rather than going straight to the external DNS.

DirSync

As I noted above, when I wrote this article there was only 32 bit DirSync. Now we finally have a 64 bit version. It should run on the DC but I haven’t tried it.

DirSync is damn easy to install. Just follow the instructions.

Activate an account

Once you have accounts DirSync’d up to Office 365, with the correct UPN matching the real domain that you federated, you can now activate one or two of them to use as tests.

Test

To test I logged in to my virtual workstation. This has a bridged internet connection in addition to the virtual network connection, and all DNS goes via the virtual DC.

I went to https://portal.microsoftonline.com and entered the user’s UPN. When I clicked the Password box it was greyed out and a link appeared telling me to authenticate against myrealdomain.com. I clicked this link and, after a few URL changes flicked across the address bar, I’m in!

Troubleshooting

The main mistake I made was to install the ADFS server in standalone mode the first time. Login actually worked, but it wasn’t SSO – the user had to re-enter their username and password. Checking the Security log on the DC showed NTLM auth being used.

So I re-ran the ADFS wizard (as the link had dissappeared from the Mnagement console I ran C:\Program Files\Active Directory Federation Services 2.0\FsConfigWizard.exe) and chose server farm. I then re-ran the powershell cmdlet Convert-MsolDomainToFederated.

Everything looked good, but wasn’t. I kept getting “Your organization could not sign you in to this service”. In the event logs I could actually see the user successfully logging in with Kerberos, but at the same time a KDC_ERR_BADOPTION error.

After much troubleshooting and hair-tearing I decided to run the powershell cmdlet Update-MsolFederatedDomain – and it fixed the problem!

As I’d had the foresight to run a Get-MsolFederationProperty both before and after the Update cmdlet I could actually compare and see what changed. The problem was the TokenSigningCertificate – it looks like the Convert cmdlet did not overwrite this so it still had the old thumbprint. After I ran Update the thumbprint changed to the new cert.