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.


  • 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.


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


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


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 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!


The domain 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 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.


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.


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 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 I clicked this link and, after a few URL changes flicked across the address bar, I’m in!


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.


5 Replies to “Minimalist Office 365 with ADFS sandbox”

  1. What a timely post, Carol! I’ve just come back from an Office 365 briefing at Microsoft with OCG and this is exactly what my next step will be! With this and Steve Plank’s excellent video, I think I’m good to go.

    Keep up the good work on the blog. It is always a good read.

    Steve G

  2. Carol, interesting read as usual! I’m not 100% sure as I’ve not played with this, but I think the certificate is also use to sign/encrypt the tokens themselves. And these tokens go to the Office 365 apps obviously. I’m not sure if they check the validitity of the certificate… but they very well might do that 🙂

    As for regular HTTPS traffic you are absolutely right, the client contacts the AD FS server on 443 but the Office 365 server doens’t do that.


  3. A different cert is used for token signing and this is generated by the ADFS service itself. There is no need for it to be a public cert.

  4. Do you not enter your ADFS metadata URL into 365? I haven’t tried this yet so don’t know.

    I would expect that 365 would consume your metadata and use the token signing public cert from your metadata. If you update your token signing cert, the metadata also updates and 365 will get the update automatically.

Leave a Reply

Your email address will not be published. Required fields are marked *