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) […]
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 […]
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 […]
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 […]
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 […]
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 […]
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 […]
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.