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.
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!