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 […]
In the initial post, we looked at PTA from a high-level perspective. This post goes into the actuals and internals of the PTA to ensure you can convince your security department on why PtA is a very good idea. Inside Azure AD there are multiple components that work together to ensure the safety of your […]
When you have your Azure Stack Development Kit, you might want to show it off to your customers or simply change the external IP address for some other reasons.. as we have seen earlier there is a dual NAT mode inside the Azure Stack Dev Kit box. The AzS-BGPNAT01 VM receives an external IP address […]
Now that we have our Azure Stack Development Kit in routing mode, we can also send the BGP information from within the Stack to the Juniper Firewalls (or any FW you have..). This will ensure that the new “external IP addresses” that are assigned to our workloads are accessible via our intranet route information and […]
Side Note: The experience of ASDK as described in this post are based on the late July bits of Azure Stack on a Dell T710. Future experience might (I certainly hope so..) be better and more integrated.. The T710 described in an earlier topic was purchased to run Azure Stack. And while I’m still waiting […]
You invested in Office 365 for you users, but you don’t want to annoy them with prompts where they have to put their usernames and passwords in, certainly as you have domain joined devices. For Office 365 ProPlus License Activation utilizing the SSO capabilities, you either had to put in an ADFS infrastructure or.. available […]
So, I got a question the other day on using ADFS in combination with some 3rd party applications in a very large AD environment. Basically the problem statement was: “ we don’t want to use UPN and we don’t want to use domain\username. Users should be able to login using either (only) their employeeID or […]
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.