Office 365 provides various authentication options, such as cloud-IDs, Password Hash Synchronization or federated identities. Leaving out the specifics on how each of these options work, all of them are configured per domain. Whenever trying to access services in Office 365, the user is required to authenticate using its User Principal Name. For sake of simplicity, the general advise it to configure the UPN to match the email address which makes it less confusing for them.
The April 2015 Security Bulletin, Microsoft released an update for Active Directory Federation Service 3.0 which comes with Windows Server 2012 R2.
According to the documentation, the vulnerability would allow an attacker to gain access to an application – such as Office 365. Apparently the flaw is in the logoff process. As I understand it from the limited information available, although the user appears to have logged off, the logoff actually failed allowing an attacker to re-use the existing token to access the application as the user.
Although the bulletin mentions that Microsoft has no knowledge of any cases where this vulnerability was exploited, I personally wouldn’t wait for it to happen to me… 🙂
More information can be found here: https://technet.microsoft.com/library/security/MS15-040
As mentioned before, the purpose of this article series is to explore 3rd-party federation solutions that work with Office 365 and which can be an alternative to a Windows’ built-in ADFS server role. In this first article however, I will be discussing a solution which is somewhat different from the others that I will be looking into.
In fact, this solution is not really very different from a regular deployment. The company behind this solution is Celestix, whom have made their name with similar approaches for TMG, UAG and before that ISA servers. This time around, they [Celestix] have made an ADFS appliance out of a ‘regular’ Windows Server 2012 R2 machine. Through a custom web page, which is built into the appliance as a service in Windows, you have the ability to easily configure ADFS and DirSync by following a couple steps in the “Quick Setup Wizard”. Under the hood, the wizard will configure Microsoft’s implementation of ADFS and DirSync for you.
(the appliance’s web portal)
For this article series, Celestix was so kind to send me a (test)example of their A-Series (3400) appliance which is targeted at small to medium-sized organizations. The appliance is built on top of an Intel i5 CPU with a total of 8GB of RAM. Based on my experiences in the field, this ought to be more than enough for most (smaller) environments. There’s also a larger model which – by taking a look at the specs – is targeted more at the enterprise level. The CPU is upgraded to an Xeon E3 and comes with 16GB of RAM. More importantly though, the big brother (A-6400) comes with 2 redundant hot-swappable hard drives and powers supplies, whereas its little brother doesn’t have any of that.
It’s safe to assume that an appliance would cost anywhere between $ 4,000 and $ 5,000 (but don’t hold me to that!). For that kind of money – even though it includes the license for Windows too – it would be nice to have had at least a redundant hard drive; just for peace of mind. But then again, not many vendors offer that with their entry-level models.
(unboxing the appliance)
Celestix also has a solution for the ADFS Proxy role, which is built into their E-Series “Cloud Edge” appliance. I haven’t tested that appliance myself, but I can only assume it operates in a similar way as the A-Series. If you want a highly available setup, you will have to purchase at least 4 devices –just like you would do for a regular Windows-based ADFS setup; 2 Cloud Edge devices (to replace the ADFS proxy servers) and 2 A-Series appliances for the ADFS servers.
It is true that you could setup a (virtual) machine yourself and go through the configuration just as easy –that is if you know the steps to execute. But on the other hand, the configuration of ADFS in Windows Server 2012 R2 has become quite easy to do. On top of that, Microsoft is putting quite a bit effort into making it even more easy through e.g. Azure AD Connect; a solution which lets you configure DirSync and AD FS through a wizard. And that solutions comes for “free”… (although nothing is truly free; there’s always some overhead to take into account). Another thing I’m a little “worried” about is the device’s ability to upgrade specific software components. Right now, the appliance is equipped with ‘regular’ DirSync (not AAD Sync). If you are not looking to configure a multi-organization hybrid deployment or if you don’t have multiple forests, this should not be a problem at this very moment. But on the other hand, Microsoft has already mentioned that AAD Sync is the successor to DirSync which means the latter will disappear at some point.
It will be interesting to see how Celestix will deal with the upgrade to AADSync on the same appliance. As you might know, there is no in-place upgrade and switching from the one to the other is (sometimes) a little daunting. The current guidance for the upgrade is to uninstall DirSync and then install AADsync, at least – that’s the theory! And we all know how theories work in real life… When I spoke with the Celestix folks, they told me they were already working on figuring out a way to deal with this and they are also working on a version of their appliance that comes with AAD Sync out-of-the box.
A good thing about this appliance – unlike most other appliance – is that you have full control over the underlying operating system: you can RDP into it at any time and make changes where needed – of course, within the guidance of the vendor! But when it comes to ADFS or DirSync, this means that you could implement custom ADFS Claim Rules or configure some filtering rules. Unfortunately, there is no web interface for that.
One thing which I didn’t particularly like is how one would deal with high availability – but that might be a personal thing. When purchasing multiple devices, the web interface allows you to start the Windows Network Load Balancin management interface to setup an array and include multiple appliances. While NLB might work just fine, I’m not particularly fond of it. Also, the web interface launches the Windows NLB console; there’s no built-in wizard which guides you through the setup. I would have loved to see this feature be developed a little more – for instance including a wizard which sets up Windows Network Load Balancing, or which includes additional health checks over the built-in TCP connection-based health check. It is do-able, there are even some code samples that you can find on the internet: http://msdn.microsoft.com/en-us/library/cc307934(v=vs.85).aspx
I’m not saying it’s easy per se, but it would provide a lot of value for the audience which I think would benefit most from these kind of appliances.
Configuring AD FS & DirSync
Now that we’ve discussed the device a little, let’s take a look at home to start configuring it.
After having it connected to the network, I used the dial button on the device to do the basic networking configuration (assigning IP address etc). The configuration itself went fairly easy, but I was unable to connect to the device afterwards. It left me baffled for a moment, but after rebooting the appliance, I could connect to the web interface just right.
The first thing that I noticed is how clean the interface is. It’s particularly easy to navigate, and I had no problems finding what I needed. Through the Start menu-item, you can launch the Quick Setup Wizard where you immediately get the opportunity to join the machine to the domain.
Next up is a (mandatory) reboot, just like you would expect when joining a Windows machine to a domain:
After each reboot, the wizard will automatically continue where it left off. The next step is to start configuring ADFS. I chose to configure ADFS in the most simple way possible, using the built-in Windows Internal Database:
Oddly enough, the appliance does not allow you to generate a CSR. This means that you already have to have exported the certificate (with public key) before. It’s not a big deal, but it would have been nice if one could really work ‘from scratch’ here:
I chose the easy route: using Windows’ built-in database. The wizard also allows you to integrate with an existing SQL server – which is a requirement/recommendation for larger deployments:
Just like the wizard in Windows, you get a summary before firing of the wizard which will configure AD FS.
For those who have setup AD FS in Windows Server 2012 R2 before, you will notice that the wizard which Celestix uses is very similar: all the steps in this wizard are also the ones that you have to step through when configuring a Windows ADFS server.
It takes a few minutes to setup AD FS. Once this is done, you can go back to the wizard, which will then give you the option to configure “Office 365 Integration”. This means as much as: setup DirSync.
Next, you have to enter the Office 365 (Global Administrator) credentials, and you choose which domain you want to federate:
At this point, the appliance was giving me a hard time. It wouldn’t continue and displayed the following error message. As any administrator would do, I restarted it and was able to move on.
On the next page, I was able to specify some settings for DirSync. If you have setup DirSync manually before, I’m sure you will recognize them:
And that was it. After clicking “Next”, DirSync ran and I was able to successfully logon using ADFS:
The ADFS login-page. Just as you would expect:
What I particularly like about this solution is that it has some built-in reports. This can be very useful as the built-in AD FS roles does not come with that capability and looking for the right events in the Event Viewer can be time-consuming (unless you have already some reporting solution / PowerShell script that does that for you).
The first report is the ADFS Activity Report which gives you more information about the current authentication requests etc. I’ve simulated some failed logons and they showed up promptly (and correctly) in the interface:
The second report is more of a health statistics page. It will tell you if the required components are running and display some statistics about general usage.
The beauty of these reports are their simplicity. Unfortunately, I have not found a way to configure an alert when multiple failed logons occur. I was assured by Celestix that this is something they are working on for the future, and I welcome that. It would be really helpful if the right people in the organization would get a message when you might be under attack (or when just “more than usual” failed login attempts happen…).
In order not to go overboard with this article, there are some features (which are less important to the “ADFS Aspect” of the appliance) that I did not discuss. For instance, the web interface allows you to restrict access through the device’s Jog Dial (by configuring a password) and
I really liked the appliance, though I cannot speak to its performance and operations over time. Aside of some occasional hiccups (i.e. having to reboot the appliance through the wizard), I’ve had no problems configuring and getting it to work in a matter of a little more than one hour. Given that this is a v1-version, I trust these little wrinkles will sort themselves out shortly.
All things considered, some might find value in such an appliance, others might not. It all depends on what you are looking for. Personally, I don’t think there’s much value to be found if you are looking something to “replace” your AD FS servers with. However, if you take into account the (childishly) easy web interface and the built-in reports or if you have a small deployment and do not want the burden to manage additional servers, it might be a different story!
Stay tuned as in the next part of this article series, I will be discussing Okta for Office 365!
Recently, Microsoft released an update to Windows Server 2012 R2 which – next to a bunch of bug fixes – also includes new features to some of the Operating System’s components. Amongst these new features there’s one that I found particularly interesting, more specifically the update to the AD FS 3.0 component which enables customers to use a different attribute to identify federated uses in Windows Azure AD. The feature itself is better known as “Alternate Login ID”.
As the TechNet documentation on this topic describes, it would now be possible to use a different attributed from the User Principal Name to identify federated users in Office 365. This helps customers who aren’t able to change their UPNs from the current value (like e.g. domain.local or domain.corp) to an internet-routable domain (like domain.com). Even though that in many situations changing the UPN isn’t a big of a deal, some customers leverage the existing UPN in third party applications and therefore might not be able to make this change easily.
If you want to deploy this feature, you’ll have to figure some things out by yourself. The documentation that is currently available doesn’t explain all the steps. At least, that is if you want to implement it right away. I expect the documentation to become available shortly. Also mind that I haven’t seen any official statement that the use of “Alternate Login ID” is already supported by Office 365 today, but the documentation certainly hints to it and if I recall correctly, it was also announced at the Microsoft Exchange Conference, last week.
The configuration itself requires you to jump through a few hoops, including modifying DirSync to refer to the new attribute you’ve selected as being the Alternate Login ID instead of the UPN. Personally, I would still recommend changing the UPN – if possible. But there’s an alternative now and having alternative is always good thing, isn’t it?
I’ll definitely have a go at this later this week and will post my findings here.
[Update 04/14/2014] Here’s the KB article describing the update I reference in this article: http://support.microsoft.com/kb/2927690
There are multiple ways to setup a highly available ADFS server farm. One possibility is to install multiple federation servers using the default Windows Internal Database.
In that case, the first federation server is designated as being the ‘primary’ federation server. Every subsequent federation server that is added to the farm will be a ‘secondary’ federation server.
These secondary federation servers periodically poll the primary federation server for configuration changes and replicate these changes across. By default this is every 5 minutes.
This scenario is especially useful if you do not have a SQL server available or if you cannot make your SQL server highly available but still want to increase resiliency for your federation server farm.
Note when using the Windows Internal Database instead of SQL, you are limited to a maximum of 5 federation servers in a farm.
If you want more information, read my previous article on the implications of a database choice in ADFS:
When installing a secondary federation server, you might see the following error in the AD FS 2.0 Application Event Log when the server tries to contact the primary federation server to replicate the configuration database:
Source: AD FS 2.0s
There was an error doing synchronization. Synchronization of data from the primary federation server to a secondary federation server did not occur.
System.IO.InvalidDataException: ADMIN0023: Incorrect value for property LastPublishedPolicyCheckTime: 12/31/1899 11:00:00 PM.
at Microsoft.IdentityServer.PolicyModel.PropertyTypes.DateTimeProperty.Validate(Object context)
at Microsoft.IdentityServer.PolicyModel.PropertyTypes.PropertySet.ValidateProperties(Object context)
at Microsoft.IdentityServer.PolicyModel.Client.SearchResult..ctor(SearchResultData data, PropertyFactoryBase factory)
at Microsoft.IdentityServer.Service.Synchronization.SyncAdministrationManager.DoSyncForItems(List`1 itemsToSync)
at Microsoft.IdentityServer.Service.Synchronization.SyncAdministrationManager.Sync(Boolean syncAll)
at Microsoft.IdentityServer.Service.Synchronization.SyncBackgroundTask.Run(Object context)
Make sure the primary federation server is available or the service account identity of this machine matches the service account identity of the primary federation server.
In this specific case, the customer decided to geographically spread the different AD FS servers to increase the (site) resiliency of their federation server farm. However, this particular secondary federation server was located in a different time zone than the primary federation server. It seems that AD FS cannot handle the time zone difference by itself (unlike e.g. Active Directory that reduces time back to UTC).
After changing the time zone on the secondary AD FS server to match the time zone of the primary AD FS server, replication started working.
Earlier this year, Microsoft released an update to ADFS (RU1) which introduced some new features of which Client Access Policies were one. Client Access Policies allow you to restrict access to Office 365 services based on the location (IP) of your clients.
To find out more, have a look at the following TechNet article:
Unfortunately, configuring these policies is rather difficult and cumbersome, due to the regular expressions it uses. At least that was until recently, when I came across this interesting tool that helps building (complex) Client Access Policies.
The policy builder tool will allow you to graphically design and configure policies in an easy and straightforward manner:
To find out more about the tool and to download it, visit the following page: