One of the most looked at topics on this blogpost is the ImmutableID series for Azure AD Connect and AADSync. And I wanted to give an update to this, given the latest versions of Azure AD Connect seemed to have adopted the idea to use the ms-ds-ConsistencyGuid (or any other value) to replace the ImmutableID used for synchronization. Don’t worry, please keep reading the other posts, as they clearly explain the how behind the idea of using the alternative ImmutableID.. and this post is just to tell you.. Microsoft has made the implementation a lot easier!
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.
In Azure Active Directory you have the option to create dynamic groups. These are groups where members are added based on a formula that uses the attributes known on a user object in Azure AD. For example you can create a dynamic group of all users that have a specific job title: But what if […]