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.
The portal is having issues getting authentication tokens for Microsoft_Azure_DataLakeStore a common error that happens under certain conditions and only if you did not read my previous post azure-data-lake-managing-data-access. In short, the error comes when the ADLS administrator has added your account to ADLS without adding the user to Azure AD (inviting you as a guest). […]
There are multiple options for authenticating users against Azure AD. But until now, full support for SSO based logins was only possible using two options. Azure AD joined devices, or a local ADFS service to your on-premises Active Directory. The latter being the most used option it also had its problems, first of all you […]
When you want to enable MultiFactorAuthentication (MFA) for Azure / Intune / Office 365 / Dynamics 365 and you are using federated logins and want to have the MFA provider to be on-premises (integrated with ADFS/PingFed/other) integrated.. you might run into an issue where the Azure MFA page keeps popping-up and asking you to register […]
When you want to change the user UPN, in certain conditions, this UPN change will not be synchronized to AAD (Office365/Intune/other).. why?
When you have federated domains for Office 365, or rather AAD in general and you want to switch your users from one domain to another, you will notice that that object will replicate anymore to AAD (and thus Office 365). I noticed this a long time ago, and it seems Microsoft now also posted this as a known KB a few weeks ago..
In my previous post, I talked about the possibility of using Kerberos Constraint Delegation to avoid having passwords in AAD. However, sometime you want to have a few passwords in AAD-Domain Services to ensure that administrators can still login to the VM’s interactively (RDP) or users are able to use certain services that are not published with Kerberos or aren’t web services.
In this post we will look at editing the configuration of AAD-Connect to synchronize the passwords* of users that have an attribute in AD present so that some users (like administrators) will be able to login to VM’s joined to AAD-DS using their on-premises passwords.
* see note below
New (and only available within Azure) are the Azure Active Directory Domain Services. This service is based on Azure Active Directory and the data replicated into it. It provides Domain Services as a service to subscription administrators and can be very useful for many scenario’s where domain services are required, but security or management of domain controllers in the cloud is a concern.
In many documents, you will see that you need to replicate user password [hashes] into AAD to make it fully work.. but this post is about how you can avoid that using Kerberos Constraint Delegation with Protocol Transition….
Read more
Azure Active Directory and thus any relying party on that service (such as Office 365) has two different modes for (your) custom domains that are added to it. Managed and Federated. Managed means that the authentication happens against the Azure Active Directory. The password (-hashes) of the user accounts are in Azure AD and no connection to any (on-premises) Active Directory Domain is made.
Managed domains have the advantage that you don’t require any additional infrastructure, and setting up the identities for logging on to Office 365 for example, is fairly easy. However, it does not support any Single-Sign-On which most companies do want. That is why AAD also supports Federated domains, in this case the authentication for a user happens against the corporate (on-premises) Active Directory through a service called ADFS (Active Directory Federation Services). More information on federated versus managed can be found on the Kloud blog (https://blog.kloud.com.au/2013/06/05/office-365-to-federate-or-not-to-federate-that-is-the-question/)
In this article we are going to take a look at how the federation service can be hosted in Azure (and possibly also on-premises) and what the architectures might look like.