Friday, 15 February 2019

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!






Friday, 8 February 2019

Using the Win32 Application Packaging Tool for Intune deployment

First of all Happy 2019!

Hopefully by now you are using Microsoft Intune to manage some of your device estate - even if the concentration is purely for mobile and tablet MDM purposes. Intune is a great way to manage Windows 10 devices - especially with Autopilot and AAD joins. But how do you push Win32 apps to your devices?

In comes the Win32 Application packaging tool. You can get the build from Github here.

It's fairly easy to use to convert your msi and exe files to the .intunewin standard for uploading into the Intune console.

In this example I am packaging Notepad++, in the root of the folder that houses the IntuneWinAppUtil.exe create a folder that houses the application you want to convert, ensuring any ancillary files are included, and also create another folder to push the converted file format out to.


From here open PowerShell or the command prompt and run:

"IntuneWinAppUtil.exe -c "Source Folder containing the application files" -s The name of the .exe -o "The output folder to put the .intunewin package to"

The switches are explained below, and -h is for help.

Sample commands to use for the Microsoft Win32 Content Prep Tool:
IntuneWinAppUtil -h
This will show usage information for the tool.
IntuneWinAppUtil -c -s -o <-q>
This will generate the .intunewin file from the specified source folder and setup file.
For MSI setup file, this tool will retrieve required information for Intune.
If -q is specified, it will be in quiet mode. If the output file already exists, it will be overwritten.
Also if the output folder does not exist, it will be created automatically.
IntuneWinAppUtil
If no parameter is specified, this tool will guide you to input the required parameters step by step.
Command-line parameters available
-h Help
-c Setup folder for all setup files. All files in this folder will be compressed into .intunewin file.
Only the setup files for this app should be in this folder.
-s Setup file (e.g. setup.exe or setup.msi).
-o Output folder for the generated .intunewin file.

It will then package your file.




And you'll have your .intunewin packcage to upload to Intune.

You'll now be able to upload the package to the Intune console.



Have fun!


Wednesday, 19 December 2018

Why does AzureAD advanced reporting and Azure Identity Protection give me conflicting alerts?


This is for any Office 365 Administrator that is using the advanced reporting features of Azure AD Premium P1 and also Azure Identity Protection as part of Azure AD Premium P2.

If you are using this reporting functionality from AADP1 and AADP2 you will no doubt be getting reporting conflicts where Azure Identity Protection is reporting suspicious activity even though you have ring fenced your networks and locations in the Azure Portal. This is a confusing and annoying anomaly that will frustrate you, but here's the answer to the issue. Azure Identity Protection, also known as the Cloud App Security Portal, doesn't honour any of the name locations or trusted locations you have setup in Azure Conditional Access | Named Locations.


Let's take a look!

Here you can see I am in the Azure AD Admin Center. Utilising the advanced reporting features of Azure Ad Premium P1 allows me to get more granular reporting capability from Azure on what is happening in my tenant and how users are authenticating and access Azure and Office 365 services. One of the great features here is adding 'known IP address ranges'. As shown below.



Selecting this takes me to Azure Conditional Access, where I can configure named locations. You can see I have configured my locations below as any good administrator should as this information is used to filter alerts and give information to the system to provide fine tuned alerting to you. When you add a named location in you also have the option of making it trusted - for example to bypass MFA requirements for 'trusted locations' rather than having to specify individual locations that come from this list.


So once I have populated all of this information my advanced reporting features of Azure AD Premium P1 will start to use them - and my alerts will take into account the configuration I have placed here. But what about Azure Identity Protection which is a feature of Azure AD Premium P2?

Well the truth is it doesn't use this configuration data at all - which is a crying shame. You have to configure it all over again. Let's log in and take a look.


You can see I am getting alerts for my Washington Office here, even though it's configured and trusted in the named location section of Azure Conditional Access in the Azure Portal.

So how do I remedy this so I have a unified advanced alerting capability and identity protection platform?

Well you need to add the locations into the Cloud App Security Portal. Specify the cog in the upper right area of the Cloud App Security Portal and select 'IP address ranges'


From here you will have to enter your locations once more.


Once entered, Azure Identity Protection will be able to use these locations in any of the pre-canned policies, or indeed any custom ones you create, to provide the same insight data that you are getting from the advanced reporting feature of Azure AD Premium P1.


And that's it. No more alert conflicts between the two systems where advanced reportings understands that a network is trusted and you get conflicted information from Azure Identity Protection.

The only downside is you will need to remember to update both until Microsoft ingest Azure Identity Protection fully into the Azure Portal (which I hope they will do!) and they share the same metrics and configuration data. Until that time, administer both.

Have fun!

Thursday, 22 November 2018

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

Friday, 28 September 2018

Controlling access to the Outlook on the Web Beta Experience


Exchange Online customers are now having users being asked to trial the new Beta experience for the service once more. But what happens if this causes confusion in the work-place and introduces higher help desk calls? What happens if you are the IT Administrative function and you want to control when this experience is rolled out to your users?

Well the good news is we can control it with Outlook Web App policies and some Powershell..


Users are now getting asked to trial the new experience in the upper right area of their Outlook on the Web experience as Microsoft has pretty much rolled this out to all tenants in Office 365. Users will have been accustomed to the below experience for quite some time


The new 'beta' experience, introduces a look and feel that is almost exactly what consumer users of Outlook.com have been experiencing for the last 6 months.


We can control this by removing the option to users by utilising Powershell and editing the default Outlook Web App mailbox policy or creating a new one and assigning it to users. You may even have multiple policies already in place and need to make multiple changes. Here's what a user logged into Outlook on the Web looks like with the option removed.


So why do we need to use Powershell to modify this feature? This is because you cannot control the Outlook Beta Experience in the Exchange Administrative Center - the feature control isn't there.


So open a Powershell connection to your Exchange Online tenant and let's use Get-OwaMailboxPolicy to check the policies you have in-place. You will most likely just have the default policy, unless you have created additional ones in the past.


We're specifically looking for 'OutlookBetaToggleEnabled'


If you want to make the change against the default policy simply utilise this command

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-default -OutlookBetaToggleEnabled $false

And that's it we're done. If you have multiple policies in play then make sure you do it for each, or if you want to control roll out you can create a new policy with the feature disabled, then set it to specific users using the Set-CasMailbox cmdlet. For example:
Set-CASmailbox -Identity user@domain.com -OwaMailboxPolicy "Policy Here"


Don't forget though, this change is coming and will wholly affect Kiosk and F1 plan users - so don't remove the feature and forget about it. Utilise this to control the experience whilst you inform users of the change.

Until next time,

@OliverMoazzezi




Thursday, 20 September 2018

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

Wednesday, 12 September 2018

Creating App Protection policies in Microsoft Intune


Microsoft Intune provides a great service in managing devices, whether they are iOS, Android, MacOS or Windows (and yes, including Windows Mobile to an extent for the time being..), but what happens if you want a lighter way or providing security governance to corporate data without having to manage the whole device? Well.. that would be Microsoft Intune App Protection.

You can have app protection policies in-place even if you have fully managed devices by Intune - however the service supports an unmanaged device having managed apps with protection wrapped around the apps to provide corporate governance - so how exactly do we set this up?

Let's take a look.

In the Azure Portal, open Microsoft Intune. From here, let's drill down into 'Client Apps'






From here we have a variety of options from app configuration policies to pushing apps out to devices. What we are looking for in this instance however is 'App protection policies'


Select this and then select 'Add Policy'


We now need to name our policy, select what OS it is for (this example is for Android), provide a description if necessary (always a good idea!) and select the required Apps. In this instance I am creating a policy for Outlook, but in this example I have shown you can multi-select Apps into a single protection policy if you so wish. Be warned they'll all share the same protection policy configuration. If you need Apps with different configurations, create seperate policies.


There are a variety of options available to configure. In this example I am specifying that a device backup cannot back up any of the App data. I also have options to disable data transfer to other apps, as well as specifying user data transfer - I am specifying here 'Policy managed apps with paste in' here. The options available and what they mean are detailed below

Blocked: Do not allow cut, copy, and paste operations between this app and other apps.

Policy managed apps: Only allow cut, copy, and paste operations between this app and other restricted apps.

Policy managed apps with paste in: Allow data cut or copied from this app only to be pasted into other restricted apps. Allow data cut or copied from any app to be pasted into this app.

Any app: No restrictions to cut, copy, and paste operations to or from this app.


In 'Access Actions' I specify whether access requires a password or pin, you can see I can protect the app with a variety of security options, even enforcing full credential requirements if warranted. There is however a level or security versus productiy, so in this example I am specifying a 4 digit pin.


We can also set sign-in security requirements, we have the option at leaving them at the defaults or changing their values and actions. Actions are defined, and we select them from pre-defined capabilities. We can also delete each one if we believe they are not a requirement for our protection policy.

 Once you have saved the policy you'll see the policy under 'Client Apps | App protection policies


I will now assign this to a select Azure AD group I have created. I drill into the policy and select 'Assignments'


I specify my Azure AD Group and save it.


So my App protection policy is all set! Assuming my user has an Intune license assigned how does an App within the protection policy behave? Let's take a look.

I'm using Outlook as the example. I'll download it from the store and open it.


 Once I sign-in with my Office 365 credentials I am prompted I need to activate a device administrator

I select 'Activate' to continue the process





It will give me information on what device adminstrator will do - a collection of policies from my App protection policy.


It will then take me through setting up the requirements for access to the App.


For both Android and iOS there is a requirement to have the Company Portal app installed. The app doesn't have to be signed into or the device to become managed, but at this time it's needed. Select 'Keep Account' and we'll then download the App.

So that's it. So what happens when I open Outlook? The answer is I am asked to enter a 4 digit pin - just what I configured in the policy. On top of this my data transfer settings and app paste in options are also configured and honoured.



That's it - take care :)

Have fun!
@OliverMoazzezi