Tag: Azure AD

F5 BIG-IP & AAD & KCD – Cross Forest – Part 2

In the previous F5 posts we did, we always used a single forest, single domain setup. Obviously, this is not always the case, certainly when cross-forest migrations are being performed. Even in these situations we could leverage F5 and AAD’s federation capabilities to provide an SSO experience. Requirements: 2 Forests with a forest trust (two-way) […]

Read more

Forcing re-authentication on (some) applications

Sign-In Frequencies in Azure AD: You might have seen on Azure Active Directory a new feature called Sign-In Frequency. In this post we are taking a closer look at this feature. First, we need to understand how authentication works and which tokens we are receiving. When you sign-in to an application which is dependent on […]

Read more


In our previous post we looked at using Azure AD to perform the authentication for our F5 published web apps that used Kerberos. Now the strength of the F5 APM module is the SSO capabilities that allow it to authenticate users once and then they could reach any web app published by it, regardless of […]

Read more

F5 Big-IP & AAD & KCD

The title being full of acronyms, this topic is about publishing Kerberos based websites behind an F5 load balancer, while using Azure AD as the authenticating service. Or in more technical terms, F5 will rely on an external SAML based token to perform Kerberos Constraint Delegation towards a backend server. Get settled in, this is […]

Read more

ImmutableID – mS-DS-ConsistencyGuid – AADConnect – ADMT – part 3b

In part 3a, we explained how ADFS can be used in cross-forest migrations to ensure all users (migrated or not) can still authenticate. In part 3B we will be looking at Pass-Through authentication and how it affects migrated/non-migrated users. First of all, we need to make sure we have pass-through authentication agents deployed. In my […]

Read more

ImmutableID – mS-DS-ConsistencyGuid – AADConnect – ADMT – part 3a

To continue our coverage of ADMT and AAD, part three of the series. I know I promised 3 articles, but given the amount of data, I’ll split part 3 (authentication) in a few more posts.. We have 1 AAD and 2 AD’s; FORESTOOT.local as the source and TARGET.local is still the target AD forest. There […]

Read more

ImmutableID – mS-DS-ConsistencyGuid – AADConnect – ADMT – part 2

In our previous post we explored the backend of Azure AD Connect and what happens in multi-forest scenarios. In this post we will be looking into the ADMT migration and the effects on the cloud accounts. The FORESTROOT domain has a user (smith@azureinfra.com) which has been assigned a full E5 license to Office 365. The […]

Read more

ImmutableID – mS-DS-ConsistencyGuid – AADConnect – ADMT – new series

My posts on the ImmutableID seem to continue attraction from all over the world, and thus, let’s continue the fun. In a new series of posts we will be looking at the influence of the ImmutableID and Cross-Forest Anchor (name given by me, not sure if it is the actual name for it) in an […]

Read more

Even strong passwords are… stupid

While this blog is mostly focused around passwords and how to ensure people can login, the new direction within Microsoft is to get rid of passwords. I can already feel the shock from many security officers reading this post, but hear us (eeuh Microsoft) out on this one. Passwords are by default unsecure, they require […]

Read more

Azure AD Lockout configurations – avoiding AD account locks

On Monday morning, the office opened, and everyone tried to login to their computers, however no-one seemed to be able to login. The helpdesk was quickly flooded with calls and it seems everyone’s account was locked-out.

It could happen to almost every company that does not have a good policy on lockouts. Hackers try as many usernames and passwords as possible to get in or to deliberately lock everyone out. A Denial of Service attack in a different form.

When you are using Azure Active Directory with a password on-premises, this might become a reality. As many attempts are made on the ADFS server in a Federated architecture, the account in AD itself gets locked out.

But there is a way to avoid that. It is possible to have a pre-emptive lockout on ADFS while the internal AD account is still usable. This means users will not be able to login remotely to ADFS anymore for a period, but they will still be able to logon to their domain joined machines. When configuring this, make sure that the lockout is set to a lower standard than your internal AD policies. For example, if your AD policy states 5 attempts, 10 minute lockout, ensure that the ADFS policy is set to a maximum of 4 attempts.

Read more