Using Azure MFA Server as an SSL LDAP Proxy

This post outlines the steps required to initiate your on-premises Azure MFA Server deployment as an SSL LDAP proxy for Active Directory. This allows MFA to be put 'in-line' for anything authenticating to Active Directory via LDAP - a useful solution for legacy on-premises applications that cannot support MFA through an update or migration to an Azure MFA supported solution such as an Azure Enterprise Application.

This post assumes your Azure MFA solution is deployment and working on-premises. From this base working profile, we perform the following steps to enable it as an SSL LDAP Proxy.


In the Multi-Factor Authentication Server console select 'LDAP Authentication'. From here we need to select 'Enable LDAP Authentication. Standard LDAP port of 389 and SSL LDAP of 636 should be entered.

If using SSL LDAP, we must enter a trusted third party certificate or one that is provided from a valid internal PKI infrastructure, such as Active Directory certificate services. If it is a self signed certificate, please note the service will not start and you will cause issue for your LDAP proxy and it will not listen on either 389 or 636 (or alternative ports if you have configured them). Please also note that you must restart the server at this stage to have the LDAP Proxy service start.

We then need to also 'authorise' clients that can connect to the LDAP Proxy service. Simply select 'Add' under the clients section and add the IP address and specify an application name to provide a basis of understanding for the client that is connecting.

One thing to remember here is if you want the LDAP Proxy to only support users that have enrolled for MFA, you should select 'Require Multi-Factor Authentication user match'. If you leave this unchecked it will allow users that haven't been enrolled for MFA to also be able to use the LDAP Proxy, and of course be allowed to authenticate with only their username and password. This is a good setting if you want to front the LDAP Proxy immediately and slowly enroll users into MFA.

We now need to change 'Directory Integration' from 'Use Active Directory', to 'Use specific LDAP configuration'. You will need to specify a server, Base DN of your Directory and use a sufficient account to perform a BIND with on behalf of the Azure MFA Server Proxy service. You can then use 'Test' to test a succesful connection and bind operation to your Active Directory.

And that's it, the LDAP Proxy service is configured. So how can we test it before pointing applications that use LDAP authentication to it? Well we could use test applications of course, but you can always use LDP.exe to perform a simple LDAP authentication test.

Open LDP.exe and select 'Connect', enter the IP address of the LDAP Proxy and specify the port and whether you have implemented SSL or not.

Once connected perform a BIND using the credentials of a user you want to test. If you have configured the LDAP Proxy to allow authentication for users not registered for MFA then you will authenticate as normal - just as if you had pointed LDP.exe at a Domain Controller.

If however the user has been enrolled for MFA, prior to getting authenticated to the directory you will be prompted on your multi factor authentication device! Either phone, text of the Microsoft Authenticator App. I of course use the App as it provides the best experience, so after selecting 'Approve', I am authenticated.

If you are using phone or text as a second factor mechanism - consider upping the timeout settings to 30-60 seconds to not receive a timeout before the user has a chance to respond.


Finally I wanted to talk about enabling the LDAP Proxy service when you have Azure MFA Server and you are using ADFS. If Azure MFA Server is installed on your ADFS server farm, combining Azure MFA Server and ADFS is a supported topology. However if you plan to deploy a non-SSL LDAP Proxy service and plan to use port 389 this will conflict with ADFS and break it.

It is best to seperate Azure MFA Server when using LDAP Proxy rather than have it installed on an ADFS server. You will most likely have to split Azure MFA Server to dedicated servers as using non-specific ports may make use of the service less than ideal with your applications that require LDAP authentication.

Have fun!

@OliverMoazzezi

Mitigating Azure MFA issues during outages for Azure MFA, Azure Conditional Access and Azure MFA Server

Microsoft suffered a very unfortunate Azure Multi Factor Authentication issue on November 19th which affected thousands of their customers for many hours. In a world where MFA is a must, even if most tenants still don't use this fantastic feature, and the service breaks, how do we mitigate the service issue that we experienced?

Well the first thing to understand is what version of Azure MFA are you using? There's effectively 3 versions in Office 365 which provide additional features and functionality via licensing: Azure MFA, Azure MFA Premium - although this cannot be purchased anymore as of October 2018, and Azure Conditional Access which allows MFA in it's workflows. On top of this there's also Azure MFA Server, an on-premises product to contend with as well - which was also affected by the outage.

So in a future scenario where we could have another Azure MFA outage, what steps as an Administrator can we take to gain access to our tenancy as well as mitigate user sign-in issues?

Let's take a look..

So from a user perspective, and we're just using the standard Azure MFA solution here, they won't be able to sign-in as MFA will be enforced. If you have legacy Azure MFA Premium licenses in play still or have Azure AD Premium licensing you'll find you can add trusted locations under 'service settings'.

So we now have two options, providing the service is still honouring trusted locations, which on the November 18th outage it was, we can setup some additional locations like the IP address of the user that's working from home. Or we can temporarily disable the user. Once the outage has recovered we can then go back and enable them once more. Remember to select 'restore multi-factor authentication on all remembered devices' so they won't have to re-register their device which can cause employee confusion.

If the users are logging into Office 365 and we have utilised Azure Conditional Access to create an MFA workflow, then the legacy Azure MFA page as shown above will show the users as disabled for MFA - but they will very much be enabled. To get this information on who is enabled you will have to dig through Azure AD Powershell.

In regards to getting the users access to their services again will require you to relax the MFA workflow in the Azure Conditional Access rule set, or disabling the rule altogether until the outage is over.

To relax the MFA requirement search under | Access Controls | Require multi-factor authentication

To disable the conditional access rule simply toggle it to OFF under | Enable policy

So your users sign-in issues are now resolved, what about your administrators? The answer here will lie somewhere above depending if you simply use the standard Azure MFA management page or if you manage an MFA workflow through Azure Conditional Access - however I would expect you to have a seperate conditional access rule for your Administrators, VIPs, Finance Teams etc.

If you are in the position where you cannot actually login to your tenant at all to make the above changes then you should have an account that allows Global Administrator access to your tenancy where it's details are unknown and locked into your BCS process. I recommend the standard *.onmicrosoft.com account here. If you are utilising Azure Conditional Access ensure you have setup an exclusion policy - which is actually Microsoft best practice for this very reason.

This is especially important if you have Customer Lockbox enabled - as Microsoft won't be easily able to help you gain access to your tenancy!

So finally that leaves Azure MFA Server. In the scenario encountered on November 19th how can we mitigate sign-in issues when Azure MFA Server is in use and users are enabled through it?

Simply open the Multi-Factor Authentication Server console, select Users | User and we can disable MFA altogether if we so wish until we want it enabled once more.

We also can utilise Trusted IPs and skip MFA requirements for them - just like in the Azure MFA service. We must however configure the IP addresses in the Multi-Factor Authentication Server console. Select | User Portal | Trusted IPs | and enter them here.

However there are other ways still. We could simply enable 'one time bypass' so MFA is still enabled but the user when they try and login to Office 365 during the outage will not get prompted for MFA.

Ensure you have an account that is a Portal Administrator

Once the admin is logged into the User Portal they can simply find the user and initiate 'one time bypass' and a time in seconds it will stay active before turning off the bypass. 300 seconds is the default. The next time the user logs in, MFA is not required, and then subsequently enforced once more.

So is there any other ways? Yes - and one from the outage that it is worth ensuring you keep enabled. Ensure under | User Portal | Settings | Use security questions for fallback | is checked. This will allow a standard security question response in the event of Azure MFA failure.

Take care,
@OliverMoazzezi

The importance of Multi-Factor authentication with the prominence of phishing scams

Phishing scams are one of the largest threats to Office 365 user credentials out there. Why? Well it's one of the easist and yet most effective efforts hackers can do to obtain user credentials to provide access to corporate data. There have been a number of prominent phishing attacks targeted specifically for Office 365 in the last two years, most likely due to the huge success Microsoft has had with the platform.

I was alerted to a rather sneaky new phish yesterday, where a phishing emails were made to look as if they were coming from the Microsoft.

Message tracing immediately proved otherwise, but it took the user, should the user click on the link, to a sophisicated phishing site hosted on Azure asking the user to login.

You could alter the url to provide any username in the login box that you wanted

If a user fell to the phishing attempt it would fail login with a simple 'loading' screen

All together a clever attack, and one no doubt harvesting lots of Office 365 credentials. But what can they do with the credentials if there is no second factor authentication in-place? Well the answer to that ultimately lies in what security you have configured for your Office 365 tenancy - for example no second factor authentication but conditional access policies only allowing login from known locations or compliant devices would help - but an unlikely scenario! The most likely scenario is the attacker gains access to your Office 365 tenant through the compromised credentials.

The single biggest improvement you can make is enabling multi-factor authentication, whilst you can't fully control the behaviours of your users - one can only hope they listen and comply when potentially falling foul of phishing attempts - you can strengthen their login to Office 365 by enabling Azure MFA. This service comes in three flavours, the standard free service included with certain Office 365 SKUs, Azure Multi Factor Premium and then the MFA functionality in Azure Conditional Access. It's a no-brainer, implement MFA to protect your data and user identities - this stops phishing scams in their tracks.

User education is still a requirement however, users shouldn't be complicit in security just because they believe they are protected with MFA - they need to be versed in understanding attack types that could be launched against them. As should Administrators take advantage of reporting capabilities in Azure Active Directory to identify risky sign-ins and check sign-in locations, as part of daily or weekly tasks. Microsoft give you all of these features to help you protect your tenant - use them.

So what other improvements can we make to enhance security for Office 365? Well Secure Score is a great start, this will provide a variety of suggestions on improving the security of your tenant. From simple things such as disabling auto-forwarding on mailboxes, or setting OneDrive for Business and SharePoint Online sharing links with expiry limits as-well-as removing anonymous access to them; to suggestions that require greater planning such as just in time access and implementing granular access with RBAC.

Other improvements you can make is enabling ATP (Advanced Threat Protection), whilst this havesting website was still online I ran it through an ATP enabled tenant and ATP correctly flagged the site as malicious - note that if you are interested in ATP, this actual feature is called 'Safe Links', and needs to be manually enabled and applied.

Don't forget to enable the enhanced protection it provides to OneDrive for Business and SharePoint Online documents, and Office click-to-run.

Finally, with your user education initiatives in the fight against scammers, train your users to submit malicious sites or phishing scams and spam to Microsoft as well as alerting adiministrators so internal communication and technical checking processes can be completed.

Report for Office 365 here

Report for Windows Defender Security Intelligence here

Stay safe out there,
@OliverMoazzezi

Changing phones when using the Microsoft Authenticator app for Azure MFA in Office 365

Hi all,

I've had a busy beginning start of 2018 moving customers to Office 365 and have had a few blog posts and blog post ideas queueing up on me for a while now. So, here's the first post for March.

How does one change their Azure MFA settings once you an administrator has forced you to enroll and you're now a year in and you're changing your mobile phone?

Good question! It's not discussed on any kb article or Microsoft blog post. So if you need to change your device or even your 2nd factor type, for example from text or phone to the App, then follow this process.

1. Login to Office 365 and go to 'My Account'

2. Go to 'Security and Privacy'

3. Select 'Update your phone numbers used for account security'. Now it will ask you to go through multi factor authentication at this stage. So if you have lost your device then contact IT support to help resolve your issue (their solution will be that they will make you re-enroll).

4. Select 'Configure' and setup the Microsoft Authenticator app on your new phone by either using the QR code or the manual url.

5. You can of course change your 2nd factor type by changing your preferred option. Note that you will only be able to select what your IT Administration team has made available to you.

And that's it. If you don't want the cumbersome process of going all the way through to the 'My Accounts' page you can also use this link: https://aka.ms/MFASetup

Take care,


@OliverMoazzezi

New Office 365 sign in experience and Microsoft Authenticator app with code sign-in for 2nd factor issues

This has just happened on my Office 365 account with the new sign in experience - I can  no longer change verification option and enter a code rather than approve or deny based on notification.


This was enforced on Windows Phone/Mobile it appears as notifications no longer work - however users using the code over notification on iOS or Android will most likely be getting the same lockout as they cannot provide 2factor anymore to successfully login.


New experience:





What I have had to fall back to:







It appears the new sign in experience multi factor request needs to add the verification code to the new experience.


When I signed up to the new sign in experience it provided the new sign in but reverted to the old screen for 2factor authentication. Now they have updated it so both parts are the 'new sign in' experience it appears they have forgotten about users that log in with a verification code.

So if you're testing the new sign in experience, ensure you aren't using code verification.

Take care,

Oliver Moazzezi
@OliverMoazzezi