Protecting your AD FS environment from password (spray) attacks (in an Office 365 context)

Recently, I attended the Thrive Conference in Ljubljana, Slovenia. During the IT Pro “Ask the Experts”-panel, an interesting question was raised: “How do I protect an on-premises AD FS environment from password spray attacks?”. Why is this such an interesting (and relevant) question, you may wonder? Well, over the past couple of months a lot of my customers have been targets of (organized) attacks, and I have been helping them overcome the effects of such attacks. Unfortunately, my customers are not the only ones! There is a disturbing trend, showing the number of attacks is steadily increasing, worldwide. These attacks aren’t only targeted towards large enterprises, it’s organizations of all sizes; seemingly random even.

The short answer to this question is: there isn’t ONE thing you can do solve the issue. Instead, there’s a bunch of things you could (and probably should) do. Spoiler: enabling MFA is one of them!

Before we dive into the technicalities, let’s first look at the dynamics of such attack(s). In a password spray attack, attackers use common passwords across various services (applications) to try and gain (unauthorized) access to password-protected services/content. The passwords they use are typically the so-called ‘usual suspects’ and include passwords such as “Summer2018!”, “Winter2018”, “Passw0rd” or the more ‘complex’ variant thereof “P@$$sw0rd”. I know you just chuckled, and you know why!

Unfortunately, attackers do not stop there. As more and more databases with user credentials are breached (more recently, Marriott ‘lost’ data from approx. 300 million accounts –including login data), attackers use the username/password combinations from those breaches in a similar way to try and gain unauthorized access to resources.

Because, nowadays, a lot of services are published onto the Internet, it’s almost a child’s game to target public services and be quite successful with these types of attacks. Even with a success ration of less than 1%, targeting several thousands of public applications yields enough success to make it worth their while. They are so successful because humans are creatures of habit and tend to use the same password for more than one service…

Once the attackers are in, they will use the breached account to (try) and exploit other vulnerabilities and increase privileges within the environment. Ultimately, their goal might be to steal data, encrypt contents and ask for ransom, etc.

So, now that we have that out of the way, let’s take a closer look at what you can do to harden your environment. Mind you that these recommendations are targeted primarily to Office 365, but the same principles (can) apply to other services behind AD FS as well! Note the recommendations below appear in no particular order. I did, however, add some thoughts here and there on what I believe is super useful and easy to implement. What you can (or cannot) do is up to you to determine, and in function of what applications you use, what your end user experience must look like and the buy-in from your management. The latter sometimes is the biggest challenge!

Use cloud authentication

Before diving into what you can do to enhance your AD FS infrastructure, you can also choose to replace AD FS with something else. For example, you could move to cloud-based authentication and use Azure AD accounts to authenticate to Office 365, federate with other applications, or use the Azure AD App Proxy to access on-premises applications.

Moving away from AD FS to cloud authentication moves the responsibility from dealing with these types of attacks from your own environment to Microsoft; they have the collective brain power, resources (like compute power) to intelligently detect and stop these types of attack. Although it solves the problem for you, it merely shifts the responsibility from having to deal with it yourself away.

When you move your authentication to the cloud, you can leverage additional components such as Azure AD Conditional Access. This, in turn, allows you to more intelligently perform authentication based on a set of (adaptive) rules. For example, Conditional Access can be used to not require MFA when you are using a known device from a known (trusted) location like your company network. When someone then tries to authenticate from outside the corporate network, or they aren’t using a registered device, they must perform MFA which then makes it a LOT harder for e.g. an attacker to gain access to an account –even when they have the right username/password combination…

Along the same lines, Microsoft offers Identity Protection in Azure AD. Instead of, or in addition to, defining a set of rules that will determine how authentication should be performed (Conditional Access), Identity Protection will leverage extensive AI-models to calculate a risk-score for an authentication attempt. Based on that score (low-medium-high), you can specific actions, such as denying access or requiring MFA (to prevent locking out valid users).

Telling people to replace AD FS with cloud authentication is easy. Doing so isn’t always possible, certainly not in the short term. So, let’s explore some other options.

Enable Multi-Factor Authentication

If there is one thing you should consider, it’s enabling MFA. Microsoft shared some startling numbers at their annual Ignite Conference: enabling MFA reduces the success rate of such attacks by an astonishing 99%. At the same time, they also revealed that too little organizations take advantage of MFA…

While it is an efficient way to stop password (spray) attacks from being successful, it doesn’t solve the problem caused by using passwords, or inherently the insecure way in which they are used and chosen by users. Nonetheless, MFA will render a valid username/password-combination virtually useless without the additional factor –something which is typically much harder to breach.

At the very least, you should use MFA for all your privileged accounts. These accounts can do most harm to your environment and should be well protected.

Off-topic: I know some will refer to the recent Azure MFA outage and point out that when MFA is not working, it really creates an operational problem. While this is completely true, there are few alternatives. Not turning on MFA could be far worse and will require you to keep a very close eye on the use of that account…!

Alternatively, consider keeping one or more break-glass accounts. These can be admin accounts that can be exempted from MFA using e.g. Conditional Access (e.g. require that the account can only be used from the internal network, on known devices). Having such an account will allow you to perform emergency-changes in your tenant, should such an MFA issues occur again in the future.

Turn on MFA as primary authentication

In addition to just using MFA, you can explore configuring MFA as the primary authentication method in AD FS 2016 and 2019. This doesn’t mean you can’t use passwords anymore: it can be used as the second factor after the initial MFA was successful. It means that attackers would first have to successfully perform MFA before they could attempt the username/password combination; very effective!

Use “advanced”, but built-in, AD FS capabilities

AD FS in Windows Server 2016/2019 have some features that are extremely useful. The first one is “(Extranet) Smart Lockout”. This capability will look at (un)successful authentication attempts and use the information gathered to proactively block authentication attempts from specific locations (IP addresses). The feature works in a very similar way than Azure AD’s smart lockout and is a good starting point to protect your environment.

Another feature is the “Banned IP”-list. This is a list of IPs that you can configure on your AD FS servers for which authentication attempts will be ignored. This is similar to the Smart Lockout capability, but you’ll have to configure it manually. If you leverage Azure AD Connect Health for AD FS, you can use the Risky IP report to block the IP addresses that consistently seem to be the source of unsuccessful authentication attempts and haven’t (yet) been caught by e.g. Smart Lockout.

Prevent bad passwords from being created

At the source of the problem (of password spray attacks) is the use of simple and predictable passwords. Educating users on what a good password is one thing, but do good passwords even exist? Even more so, users are notorious for not always playing by the rules…

So, better than just (blindly) trusting them, you can leverage Azure AD’s password protection in your on-premises environment. Without going into too much technical details, this feature will ensure that whenever a password change occurs in the on-premises environment, an agent will verify if the new password does not match a known bad (or banned) password and – if it does – prevent the password change, forcing the user to choose another password. Although this doesn’t solve the problem from known passwords to be used, it will – over time – ensure less simple and too obvious passwords exists in your environment. In turn, this decreases your attack surface a little bit.

Go for password-less, or just less passwords

Discussing the topic of whether getting rid of passwords is a good thing or not is worth an article by itself. Tldr; replacing passwords with something else is a good idea 😊

Today, you can already start by leveraging certificate-based authentication. This, too, is harder to compromise than passwords, but also notoriously difficult to implement (because of the management overhead for the deployment of client-side certificates etc). Because of the complexity, it’s not always a desired solution.

There are a few ways to go passwordless. One way I found to be super easy, is to use the Microsoft Authenticator app. Combining the requirement for MFA with password-less and Conditional Access is very powerful and super easy to deploy. Unfortunately, this will only work considering that 1) users must have a smart phone with the Microsoft Authenticator, and 2) they must access resources with their Azure AD account… Soon, you’ll also be able to use hardware (OAUTH) tokens instead of the authenticator app, adding (a bit) more flexibility in your options!

If you are up-to-date with your workstations (that is Windows 10, folks!) and you are using modern applications like Office 365 Pro Plus, you are in a good starting position to start adopting password-less authentication by implementing Hello for Business. Password-less is still very much something for the future, and passwords won’t disappear overnight. However, now is a great time to start planning and testing! If not, at the very least use it for a small subset of your (IT) users so you can get acquainted with it, both from a deployment and manageability perspective…


In Dutch, we have a saying: “meten is weten”. This roughly translates into “measuring is knowing”. Sounds horrible, doesn’t it? What it means though – in the context of this article – is that if you don’t measure/monitor your AD FS environment, you won’t know what’s happening or that you are under attack!

Azure AD Connect Health for AD FS is a good way to gain visibility into what’s happening in AD FS. However: what if you don’t have the licenses for it? Although there’s plenty of other (monitoring) solutions that can help you get the right information from AD FS, below I’ve included a (manual) way of using PowerShell to detect failed authentication attempts. It’s by no means a replacement for a decent monitoring solution –but it could be a starting point!

The script uses the AD FS event log information to lookup the IP information from the (failed) authentication attempts and compiles a list of countries that are generating these unsuccessful events. To retrieve the country to which an IP address belongs, the scripts uses the REST service. You will have to get your own API keys to perform the lookups! In the end, you can use the information from this report to proactively block specific IP addresses from the Internet. You can do this on your firewall or using the Banned IPs-feature in AD FS.

First, we’ll get the relevant events from the event logs:

#Define time frame for which to retreive events. Can be omitted.
$StartDate = "26/10/2018 19:00:00" | Get-Date
$EndDate = "27/10/2018 14:59:59" | Get-Date

#get events
$eventsFailed = Get-WinEvent -FilterHashtable @{logname='Security'; ID=1203; StartTime=$StartDate; EndTime=$EndDate} -ComputerName
$eventsSuccess = Get-WinEvent -FilterHashtable @{logname='Security'; ID=1202; StartTime=$StartDate; EndTime=$EndDate} -ComputerName

Next, we’re taking the events and extracting the required information from them. I am not a PowerShell-guru, so I am sure there are better ways to do this. However, below is what I could come up with in the short period I had to troubleshoot whilst an attack was going on. The customer I created this for then added a bunch of additional information (like coordinate and time stamps) afterwards.#reset variables

#reset variables
$result = @()

#Loop through results and compile the list

foreach($event in $eventsFailed){
    #workaround to get information.
    [xml]$eventXML = [xml]$Event.ToXml()
    $eventXML.Event.EventData.Data[1] | Out-File xml2.xml
    [xml]$xmlData = Get-Content .\xml2.xml
    $data = New-Object PSObject
    $ipAddress = $xmlData.AuditBase.ContextComponents.Component[3].IPAddress.Split(",")[0]

    #the clause below differentiates between internal and external IPs
    if ($ipAddress -eq "<internal IP addresses>")
        $data | Add-Member -MemberType NoteProperty -Name UserID -Value ($xmlData.AuditBase.ContextComponents.Component[0] | Select UserID).UserID
        $data | Add-Member -MemberType NoteProperty -Name IPAddress -Value $ipAddress
        $data | Add-Member -MemberType NoteProperty -Name Continent -Value "Europe"
        $data | Add-Member -MemberType NoteProperty -Name Country -Value "Belgium"
        $data | Add-Member -MemberType NoteProperty -Name City -Value "City"
        $data | Add-Member -MemberType NoteProperty -Name Region -Value "Region/Province"
        $data | Add-Member -MemberType NoteProperty -Name Lat -Value "50.9160" #latitue
        $data | Add-Member -MemberType NoteProperty -Name Long -Value "4.0402" #longitude
        $data | Add-Member -MemberType NoteProperty -Name Status -Value "Failure"
        $data | Add-Member -MemberType NoteProperty -Name TimeCreated -Value $event.TimeCreated
        $data | Add-Member -MemberType NoteProperty -Name Source -Value "Internal"
        $data | Add-Member -MemberType NoteProperty -Name Date -Value $event.TimeCreated.ToShortDateString()
        $data | Add-Member -MemberType NoteProperty -Name DateNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("yyyy-MM-dd HH:mm")
        $data | Add-Member -MemberType NoteProperty -Name TimeNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("HH:mm")
        #perform REST lookup to get IP information
        $ipLookup = Invoke-RestMethod -Method Get -Uri "$($ipAddress)?access_key=<accessKey>"

        $data | Add-Member -MemberType NoteProperty -Name UserID -Value ($xmlData.AuditBase.ContextComponents.Component[0] | Select UserID).UserID
        $data | Add-Member -MemberType NoteProperty -Name IPAddress -Value $ipAddress
        $data | Add-Member -MemberType NoteProperty -Name Continent -Value $ipLookup.continent_name
        $data | Add-Member -MemberType NoteProperty -Name Country -Value $ipLookup.country_name
        $data | Add-Member -MemberType NoteProperty -Name City -Value $
        $data | Add-Member -MemberType NoteProperty -Name Region -Value $ipLookup.region_name
        $data | Add-Member -MemberType NoteProperty -Name Lat -Value $ipLookup.latitude
        $data | Add-Member -MemberType NoteProperty -Name Long -Value $ipLookup.longitude
        $data | Add-Member -MemberType NoteProperty -Name Status -Value "Failure"
        $data | Add-Member -MemberType NoteProperty -Name TimeCreated -Value $event.TimeCreated
        $data | Add-Member -MemberType NoteProperty -Name Source -Value "External"
        $data | Add-Member -MemberType NoteProperty -Name Date -Value $event.TimeCreated.ToShortDateString()
        $data | Add-Member -MemberType NoteProperty -Name DateNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("yyyy-MM-dd HH:mm")
        $data | Add-Member -MemberType NoteProperty -Name TimeNearestHour -Value (($event.TimeCreated).AddMinutes(-(($event.TimeCreated).Minute % 60))).ToString("HH:mm")


    $result += $data

#get the results. This can be changed to output to CSV, XML or anything else, really.
Write-Output $result

Note: you’ll have to turn on AD FS Audit Logs for these events to start popping up in your Security Logs!

Help! I’m under attack…!

If your monitoring shows an unusual high number of failed authentication attempts, you might be under attack. But what to do next? First, keep calm and breathe! Now is not a good time to panic. Without you, the attackers have free reign! Pulling the plug might work but it is a bit drastic. So, let’s hold off on doing that for now.

Once you’ve overcome the initial shock, try to identify what the attack vector/angle of attack is. Perhaps the suspicious activity is coming from just a few IP addresses? Good. Block those. If things take a turn for the worse, you might have to (temporarily) block external access to resources. This doesn’t necessarily mean you have to lock out your users: if they have other means to access the (internal) network such as through a VPN-connection, they would still be able to authenticate directly to the internal AD FS servers.

The challenge with the VPN-approach is that it doesn’t work for basic authentication (e.g. ActiveSync with Exchange Online). This is because with basic authentication, the authentication request(s) are initiated by Exchange Online and blocking those IP addresses will cripple access for everyone who uses basic authentication.

As such, it’s important that you try to move away from Basic Authentication as a rule of thumb anyway. In a modern world, and with modern applications, there should be no need to basic authentication. For example, Outlook and Outlook Mobile can perfectly live without it. POP3 and IMAP on the other hand, not so much…

Basic Authentication is the root of all evil. A simple username/password combination is no longer from this era. It might have been a fitting solution in the early days of computing, but that’s long past. Even complex and long passwords provide little to no value if used incorrectly, which is how most of the users use them. It’s not just because of what passwords one use, passwords themselves are because of how they are used also subject to man-in-the-middle attacks, etc… But that’s besides the point of this article. What is the point, is that you should disable basic auth when you get the chance, and there’s plenty of ways you can do it in Office 365/Azure AD:

  • Use Conditional Access to block legacy Auth
  • Use Authentication Policies in Exchange Online to block basic auth
  • Block specific protocols (such as e.g. POP3/IMAP) for specific user accounts.
  • Use AD FS Claim Rules to (selectively) block basic auth from specific locations (or users, or groups, etc.)

If you can’t block basic auth completely, limiting what accounts can use it, is already a good first step! Remember, there is no single security strategy that you can implement in a single go. As with many things, it’s something that takes time to setup correctly and get users accustomed to. It’s like a good wine: it can get better with the age. But if you wait too long, it can become bad as well!

Wrapping up

There are many countermeasures, each addressing parts of the challenge. The more of the above features and capabilities you implement or configure, the more secure your environment becomes. However, it doesn’t mean that doing all of this will make you 100% secure, as there is no such thing…

Instead, make sure that you take a holistic approach. After all, your defense is only as good as the weakest link in the chain. Having a multi-layered approach is key. Secondly, make sure to monitor your authentication traffic. If not, you’ll be flying blind and it might take you a while to figure out something bad is happening.

Over the next couple of weeks, I’ll be diving more deeply into some of the topics mentioned in this article. Until then, all there is left for me is to wish you a great end of the year!


ADFS Blog How-To's Identity & Security Office 365

Azure AD Connect is now GA

Yesterday, Microsoft announced they released Azure AD Connect and Azure AD Connect Health to the public.
Azure AD Connect can be seen as the successor to DirSync/AADSync, with an added edge. It does not only allow you to configure directory synchronization, but the wizard also allows you to automatically setup and configure Active Directory Federation Services instead of having to go through the motions manually.

The GA of the tool has been long awaited and it’s great to finally see it become available for everyone. Make sure to check back in the weeks to come as I will more than likely be posting some articles on what’s new and how to deal with the tool.

You can read the original announcement here. If you want to skip the ‘boring’ stuff and get going straight away, you can get the tool from here.


ADFS Blog Hybrid Exchange News Office 365

Latest security bulletin addresses vulnerability in AD FS

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:

ADFS Blog News Office 365

3rd-party federation solutions for Office 365 (part 1): Celestix ADFS Bridge

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:

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!

ADFS Blog Hybrid Exchange Office 365 Reviews

Windows Server 2012 R2 ADFS ‘alternative login ID’, removes the need to have an internet-routable UPN

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


ADFS Blog Exchange Exchange 2013 Hybrid Exchange News Office 365

Error: You cannot synchronize the ADFS configuration database after adding a secondary federation server


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:

The issue

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:

EventID: 344
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.

Additional data

Exception details:
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.ClientObject.GetData()
   at Microsoft.IdentityServer.PolicyModel.Client.ClientObject.OnReadFromStore()
   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.SyncAdministrationManager.Sync()
   at Microsoft.IdentityServer.Service.Policy.PolicyServer.Service.SqlPolicyStoreService.DoSyncDirect()
   at Microsoft.IdentityServer.Service.Synchronization.SyncBackgroundTask.Run(Object context)

User Action
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.


The solution

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.

ADFS Blog Hybrid Exchange Office 365

Office 365 ADFS Client Access Policy Builder.

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:

Until later!

ADFS Hybrid Exchange Office 365