Category Archives: Azure

Posts, tutorials, and solutions covering the configuration of Microsoft Azure

Migrate to Microsoft Entra Connect

Posted on by
Reply

 Migrate to Microsoft Entra Connect KB ID 0001857

Problem

You want to migrate from Microsoft Azure AD Connect to Microsoft Entra ID connect.

Let me let you into a secret, (at time of writing) Entra ID connect and Azure AD connect ARE THE SAME THING, if you go to download Entra ID connect, the file you will download is called AzureADConnect.msi. So what you want to do is, upgrade Azure AD Connect.

If your existing Azure AD connect is running on Window Server 2016 (or newer) you can simply ‘in place upgrade‘ the existing Azure AD connect to version 2 and there’s no need to migrate anything.

If you MUST Migrate, because you are deploying on a new server for example, the process is straight forward.

  • Install on New Server and put into Staging Mode.
  • Put Old Server into Staging Mode.
  • Take New Server out of  Staging Mode, (ensure there are no errors/problems).
  • Uninstall from Old Server.

Solution: Migrate to Microsoft Entra Connect

So if you simply want to perform an in place upgrade because your OS is Windows Server 2016 (or newer), use the following article.

Upgrade Azure AD Connect

If you’ve made it this far then you are WANTING to Migrate to Microsoft Entra ID Connect, or as previously mentioned migrate to Azure AD connect on another server!

Migrate to Microsoft Entra Connect Step One: Export Settings

On the Old Server, launch the Azure AD connect shortcut > Configure.

Select  ‘View or export current configuration’ > Next.

Export Settings > Save them (by default in C:\ProgramData\AADConnect) > Save > Exit.

Migrate to Microsoft Entra Connect Step Two: Import Settings

Assuming you’ve done nothing other than download the install package on the new server  > Run the installer package > Agree to the EULA > Continue.

Customise.

Select ‘Import synchronisation settings > In the Location section enter \\old-server-name\c$\ProgramData\AADConnect\filename.json >  Install.

From this point forward I will assume you want everything set the same, so other than usernames and passwords accept the defaults > Next.

Enter the password to authenticate to M365/Azure AD.

This next screen can be confusing because you can’t click Next, and it’s not apparent why! Next to your domain there should be a green tick, if there’s a red cross you need to select ‘change password’ > Then enter the (local AD account) account you use for synchronisation > Next.

Next.

Both options should be ticked by default > Install.

Exit.

Migrate to Microsoft Entra Connect Step Three: Put Old Server Into Staging Mode

I find this much easier to do with PowerShell, but I’ll put the graphical procedure below if you prefer. Issue the following two commands.

[box]

$aadSyncSettings=Get-ADSyncGlobalSettings
$aadSyncSettings.parameters

[/box]

Locate the ‘Microsoft.synchronize.StagingMode‘ section and you will see its value is set to ‘False‘ i.e. staging mode is NOT enabled (or it’s in production mode).

To change the value to ‘True‘ i.e. enable staging mode use the following command.

[box]

($aadSyncSettings.parameters | ?{$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="True"
Set-ADSyncGlobalSettings $aadSyncSettings

[/box]

You can then  confirm that the staging mode value is set to ‘True’ with the following command.

[box]

$aadSyncSettings.parameters

[/box]

Migrate to Microsoft Entra Connect Step Four: Take the New Server Out of Staging Mode

On the New Server, use the following two commands.

[box]

$aadSyncSettings=Get-ADSyncGlobalSettings
($aadSyncSettings.parameters | ?{$_.name -eq "Microsoft.Synchronize.StagingMode"}).value="False"
Set-ADSyncGlobalSettings $aadSyncSettings

[/box]

You can then  confirm that the staging mode value is set to ‘False’ with the following command.

[box]

$aadSyncSettings.parameters

[/box]

Migrate to Microsoft Entra Connect Step Five: Check for Errors

On Premises: You can look in ‘Azure AD Connect Synchronisation Service.’

Microsoft 365: The main Admin console will tell you (in the user management pane).

Microsoft Entra Admin Panel: Look under identity > Provision from Active Directory.

Alternate Steps to Enable Staging Mode (From GUI)

On the Old Server, launch the Azure AD connect shortcut > Configure.

Configure Staging Mode > Next.

Enter your admin password > Next.

Tick to select ‘Enable Staging Mode‘ > Next.

Configure.

Exit

Alternate Steps to Disable Staging Mode (From GUI)

On the New Server, launch the Azure AD connect shortcut > Configure.

Configure Staging Mode > Next

Enter your admin password > Next.

Untick to deselect ‘Enable Staging Mode‘ > Next.

Configure.

Exit

Migrate to Microsoft Entra Connect Step Five: Uninstall Microsoft Azure AD Connect

On the Old Server, search for appwiz.cpl > run it > Select Microsoft Azure AD Connect > Uninstall > Yes > Remove.

Exit.

Related Articles, References, Credits, or External Links

Locate Your Azure AD Connect Server

Azure AD Connect: Correct Or Remove Duplicate Values

Cannot Recreate Azure AD ‘Local’ AD Connector

Forcing Azure AD Connect Sync

Insufficient access rights Error Code 8344

Posted on by
5

Error Code 8344 KB ID 0001636

Problem

With Azure AD Replication, you may notice that you have the following error when you take a look at your connector status;

Error: permission-issue
Connected data source error code: 8344
Connected data  source error: Insufficient access rights to perform this operation.

Solution: Error Code 8344

Firstly ensure that the user you are running AAD sync under, has the following permissions on the ‘root’ of your local AD domain.

  • Replicating Directory Changes: Allow
  • Replicating Directory Changes All: Allow

If the problem persists it’s usually because the account that is running the AAD sync does not have the appropriate rights to the mS-DS-ConsitencyGuid attribute for the affected users in the local Active Directory. The following commands will add the appropriate rights you ALL your local users;

[box]

$accountName = "Domain-Name\User-Name" 
$ForestDN = "DC=Domain-Name,DC=Domain-Extension"
$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd

[/box]

Lastly, if you have this problem on some ‘sporadic’ users, check to ensure that their individual user objects and inheritance enabled on their user object, before retrying.

 

If the problem persists use the AD Connect Troubleshooter.

Fix Error Code 8344 with AD Connect Troubleshooter

Open Azure AD Connect > Configure.

Troubleshoot > Next > Troubleshooting > Launch.

Option 4 > Note: At this point you may or may not be asked to install the RTSAT tools, if so enter Y {Enter} > Option 12 > Y {Enter} > E {Enter} > Type in the name of the connector (in the example below that’s pnl.com).

You will be prompted to authenticate with an administrative account > You will then have to accept each change, by typing A {Enter} You will need to do this SEVEN TIMES.

When complete force a full initial replication.

[box]

Start-ADSyncCycle -PolicyType Initial

[/box]

At this point go an have a cup of coffee, then come back and check Synchronisation Service Manager. You should now be error free.

Related Articles, References, Credits, or External Links

NA

Upgrade Azure AD Connect

Posted on by
Reply

Upgrade Azure AD Connect KB ID 0001813

Problem

On 15th March 2023 support for the following Azure AD Connect sync versions will be removed;

  • 2.0.91.0
  • 2.0.89.
  • 2.0.88.0
  • 2.0.28.0
  • 2.0.25.1
  • 2.0.10.0
  • 2.0.9.0
  • 2.0.8.0
  • 2.0.3.0

So plan in some maintenence and upgrade yours, at time of writing the current version is 2.1.20.0, so you can still upgrade if you running an older version.

Upgrade Azure AD Connect: Solution

Before you start it’s worth taking a few minutes to see how your current connector is configured, by simply running the shortcut it will stop replication and give you the option to look at how its currently configured.

Find Azure AD Connect Version

To check what version you are actually running;

[box]

Import-Module ADSync
(Get-ADSyncGlobalSettings).Parameters | select Name,Value

[/box]

Note: Above you can see I’m running 2.1.16.0 so I would still be OK, but let’s upgrade it anyway.

Test Azure AD Connector Health

Open the Syncronisation Service Manager, and have a look in your 365 portal, to make sure everything is running healthily.

Upgrade Azure AD Connect

This could not be simpler, download the new software, run it and supply an administrative account for your subscription, the upgrade will take about 10 – 15  minutes, go grab a coffee.

Once complete, rerun the same command you used above, to ensure the version number is now updated.

Then force a sync with the following command, and watch the service manager while it runs though each stage (it may take a few minutes, and look like it’s doing nothing, be patient!)

[box]

Start-ADSyncSyncCycle -PolicyType Delta

[/box]

Note: You can use PolicyType Initial that will take a LOT longer, (and sync everything). Usually a delta sync will be absolutely fine.

Related Articles, References, Credits, or External Links

NA

FortiClient Azure Authentication

Posted on by
9

FortiClient Azure KB ID 0001797

Problem

More and more people are using Azure as their primary identity provider, thanks in no small part to the massive success of Office/Windows 365. So if you want to provide a FortiGate/FortiClient SSL remote access VPN solution then securing it via Azure makes a lot of sense.

Multi Factor Authentication: If you have MFA on your Azure accounts then that’s a big box ticked for your accreditations and digital liability insurance also. This article does not cover enabling MFA in Azure, we are assuming you already have that enabled. I’ve covered that in other articles anyway, (use the search box above!)

Essentially your firewall will redirect authentication (via SAML) to Azure when you attempt to connect either via the web or tunnelled with the FortiClient.

Note: You can of course Use Azure MFA With Microsoft NPS (RADIUS) Server but this would require an additional server.

FortiClient Azure Authentication

FortiClient Azure Prerequisites

You will need an Azure subscription (a trial one is fine), obviously a FortiGate firewall, and a publicly signed certificate for the firewall (see below).

Note: Stop asking if you can use self signed certs – this one cost me six dollars! It needs to be publicly signed so Azure trusts it!

Add and Configure the FortiGate SSL VPN Application

From within your Azure tenancy, locate Enterprise applications and choose to add a new one.

Do a search for Forti and you should see the FortiGate SSL VPN application, select it.

In the setup single sign on  section, click ‘Get Started’.

Select SAML.

The ‘Vast Majority’ of the work that needs to be done will be done in here. In Section 1 (Basic SAML Configuration)  you will enter FOUR URLs (these URLs will reside on your FortiGate). 

Change the values in red to match your own publicly resolvable FQDN, (which will match the CN on your certificate).

Identifier (Entity-ID)

[box]

https://vpn.petenetlive.com/remote/saml/metadata

[/box]

Reply URL (Assertion Consumer Service URL)

[box]

https://vpn.petenetlive.com/remote/saml/login

[/box]

Sign on URL (Yes it’s the same as the one above!)

[box]

https://vpn.petenetlive.com/remote/saml/login

[/box]

Then scroll down.

Log out URL 

[box]

https://vpn.petenetlive.com/remote/saml/logout

[/box]

Then SAVE.

Section 2: Attributes and Claims, click edit.

Add a new claim.

Name = username, Source attribute = user.userprinciplename > Save.

Select the existing user.groups value > Change it to ‘All Groups’ > Tick ‘Customise the same of the group claim’ > Set the name to group > Save.

Note: It can take little while for the main page to refresh .

Section 3: SAML Signing Certificate. Download the Base64 version of the certificate.

Back on your FortiGate > System > Certificates > Import > Remote Certificate.

If you can’t see certificates click here.

Browse to and upload the certificate you just dowloaded.

Make a note of the certificate name, in this case it’s REMOTE_Cert_2 (You will need this later).

Section 4: Setup FortiGate SSL VPN. In this section there are three URLs that you need to take a copy of (they are used in the code block you will post into the FortiGate.

You now have all the elements you need to paste the following code block into your FortiGate, the following elements IN RED should be changed to match yours.

set-cert is the NAME that the FortiGate has given to its public cert, (mine’s the same as its common name, yours may be something else!)

entity-id, single-sign-on-url, and single-log-out-url are the URLs you pasted into section 1 (above).

idp-entity-id, idp-single-sign-on-url, and idp-single-log-out-url are the URLs you copied out of section 4 (above).

idp-cert is the NAME that the FortiGate has given to the cert you dowloaded from section 3 (above)

user-name and group-name are the attributes and claims you setup in section 2 (above).

[box]

config user saml
edit SSL-Azure-SAML
set cert vpn.petenetlive.com
set entity-id https://vpn.petenetlive.com/remote/saml/metadata
set single-sign-on-url https://vpn.petenetlive.com/remote/saml/login
set single-logout-url https://vpn.petenetlive.com/remote/saml/logout
set idp-entity-id https://sts.windows.net/de742342-edf0-49e7-8ca3-1402fddc17bc/
set idp-single-sign-on-url https://login.microsoftonline.com/de742342-edf0-49e7-8ca3-1402fddc17bc/saml2
set idp-single-logout-url https://login.microsoftonline.com/de742342-edf0-49e7-8ca3-1402fddc17bc/saml2
set idp-cert REMOTE_Cert_2
set user-name username
set group-name group
next
end

[/box]

Azure Groups

You will need a group in Azure created with the users that you wish to be able to authenicate into to the remote VPN. Take a copy of its Object ID (you will need that shortly).

With that object ID you can create a ‘Group’ on the FortiGate with the following code block

[box]

config user group
edit AAD-Remote-VPN
set member SSL-Azure-SAML
config match
edit 1
set server-name SSL-Azure-SAML
set group-name 02f047b1-8db2-4474-84df-21af6a16204c
next
end
next
end

[/box]

You will also need to add this group (In Azure) into the FortiGate SSL VPN application > users and groups > add user/group.

Click ‘None Selected” > Select your user group > Select.

Heed the warning! No nested groups, which is a little annoying, but you can’t say they didn’t warn you > Accept.

FortiGate SSL VPN

I’m going to use the basic settings to get this up and running, VPN > SSL VPN Settings > Listen on Interfaces (set to the outside facing interface (that the certificate name points to!) Server Certificate set to your publicly signed certificate > Scroll down.

Note: If you see a warning about not having configured SSL policy, dont worry we will fix that in a moment.

Create New.

Select the AAD user group (we created with the second code block) and set the Portal, (here I’m using full access so the remote client can use the web, or full tunnel options) > OK.

Policy & Objects > Firewall Policy > Create New.

Give the policy a sensible name > Incoming Interface will be SSL-VPN (Not outside!) > Outgoing interface is usually the inside (unless you have DMZs etc) > Source, add in All and your AAD-Group you created with the second code block above >  DISABLE NAT > Scroll down.

Change Logging to ‘All sessions’ (Note: once fully deployed, you can change this to security events) > OK.

Note: It may error at this point if the portal you have chosen, (in this case full-access) has split tunnelling enabled, you can either disable split tunnelling on the portal, or change All in the destination section to a particular subnet on the the LAN).

Testing Forti Web SSL With Azure

From an external client connect the web address of your FortiGate, all being well it should redirect you to Azure, (or your ADFS portal if you use ADFS).

Provision authentication is successful, you should see something like this.

Testing FortiClient Azure SSL VPN With Azure

Install the FortiClient, (here I’m using the VPN only version). Give the connect a sensible name > Set the gateway to your public FQDN, and tick ‘Enable Single Sign On (SSO) for VPN Tunnel > Save.

SAML Login

After your Microsoft authentication prompt appears, the client should connect successfully.

Related Articles, References, Credits, or External Links

Microsoft: Azure AD SSO with FortiGate

Fortinet: Configuring SAML SSO login for SSL VPN

Find The Azure AD Join Type

Posted on by
2

KB ID 0001597

Problem

I recently did a post about Joining Azure AD. while working on that I found out there were three different Azure AD ‘States’ (see below). But how do you pingd out your Azure AD Join Type?

  • Azure AD Joined: Aimed at Corporate owned machines joined to Azure AD, (or CYOD devices).
  • Azure AD Registered (Was called Workplace Joined, and still is if you work in PowerShell). Aimed at BYOD devices.
  • Azure Hybrid AD Joined: Where your machines are joined to both your local domain and Azure AD.

Of course your Windows clients can also still be Domain Joined, or Simply Workgroup Joined. But you can’t be Domain Joined and Azure AD Joined. Thought to be even more confusingly you can be Domain Joined and Azure AD Registered.

How To Find The Azure AD Join Type

Azure AD Join Type: Azure AD Joined

The command you need to use is;

[box]

dsregcmd /status

[/box]

Look for AzureADJoined : YES. Also take a note of the DeviceId. (Note: Is should NOT say domain joined also, if it does, your join type is Hybrid!)

To check with PowerShell, first you need to connect with Connect-MsolService, then. log into Azure AD. Then you can query a DEviceId’s status with the following command.

[box]

Get-MsolDevice -DevideID {Device-ID-From Above}

[/box]

Look for DeviceTrustType: Azure AD Joined.

From within Azure > Azure Active Directory > Devices > Locate the Device in question > Join Type: Azure AD Joined.

Azure AD Join Type: Azure AD Registered (Workplace Joined)

When a device is AD registered then it has been connected from a logged on account, that has been connected, via the Access Work or School wizard. You can see this only if you’re logged on as that user! Settings > Accounts > Access work or School > Look for an enter under ‘Connect’.

If you are not logged on as the user then run there same command we ran above;

[box]

dsregcmd /status

[/box]

And look for a WorkplaceDeviceId.

Then use the same PowerShell commands as above. 

First you need to connect with Connect-MsolService, log into Azure AD. Then you can query a DEviceId’s status with the following command.

[box]

Get-MsolDevice -DevideID {Device-ID-From Above}

[/box]

Look for DeviceTrustType: Workplace Joined. (Yeah very consistent, thanks Microsoft ‘half a job’ developers!)

Azure AD Join Type: Azure Hybrid AD Joined

You can use the same command to view Azure AD Hybrid Domain Joined status.

[box]

dsregcmd /status

[/box]

If you are Azure Hybrid AD joined. you will see that AzureAdJoined :YES, and so is DomainJoined.

You can also look in Azure yourself, and the properties of the device will tell you you are Hybrid AD joined for this device.

Domain Joined

You can use the same command to view Local (On-Prem) Domain Joined status.

[box]

dsregcmd /status

[/box]

And look for DomainJoined : YES, and DomainName : {Your-Domain-Name}.

Of course as always you can see the information on your computer’s ‘Properties’, like so;

Note: An Azure AD Joined Machine does not show details here, in fact it says it’s workgroup joined! (Again thanks Microsoft, we’ve only looked here since Windows NT4, would it have been that much more work to update this as well?)

Related Articles, References, Credits, or External Links

NA

Windows: Join Azure AD (AAD)

Posted on by
3

KB ID 0001596

Problem

With more people looking at Microsoft 365 (as opposed to Office 365), then the amount of people who want to Join Azure AD with their Windows machines is only going to go up. This is how to join your Windows and BYOD client devices to Azure AD.

There are essentially 3 WAYS to Join Azure AD.

  • Azure AD Join: Used for corporate assets. Windows Only! (Can be managed by Intune) Users log in with their Azure AD account only.
  • Azure AD Registration: Used for BYOD devices Windows/macOS/Android etc. (Can be managed by Intune). Users log in with their local credentials.
  • Hybrid Azure AD Join: Used for corporate assets you want to manage with GPO (or SCCM). Windows Only. These assets will be in a local (traditional on-premises domain).-WARNING: These devices require periodic sight of your on-premises AD, (or they become unusable). The Local domain needs to be connected to Azure AD with an Azure AD Connector.

Solution

 

Join Azure AD: Azure AD Join

Start > Settings > Accounts..

Access Work or School > Connect.

STOP! If you put your credentials in here you will Not join the machine to Azure AD you will perform an Azure Workplace Join (or be Azure Registered) that’s NOT WAHT WE WANT > Select “Join This Device to Azure Active Directory‘.

Enter your Azure AD/Office 365 Credentials > Next.

Join.

Done.

The machine will now show that it’s connected to.Azure AD

Note: The login screen now changes to ‘Sign in to: Your Work or School account‘.

Join Azure AD: Azure AD Register

Start > Settings > Accounts..

Access Work or School > Connect.

Enter your O365/M365/Azure credentials

Then after authenticating you ‘should’ see this.

How To Leave / Disconnect From Azure AD

Same place as above, select the connection and simply click ‘Disconnect‘.

Join Azure AD: How To Hybrid Join Azure AD

To Hybrid Azure AD join your machines to Azure AD, (this means they will already be in you local (traditional on-premises) domain, and then ‘additionally’ joined to Azure AD also. So your local domain needs to be syncing to Azure AD with Azure AD Connect. And you machines need to be Windows 10 (or Windows 8 with some additional requirements!)

You configure Hybrid Azure AD Join on the Azure AD Connector, like so;

Locate Your Azure AD Connect Server

Launching Azure AD from the Azure AD connect icon, will pause replication and allow you to make changes, locate ‘Configure Device Options’

 

Next >authenticate to Azure > Next.

Device Options > Configure Hybrid Azure AD Join > Next.

Next > Select Windows 10 (unless you have Windows 8 then theres some other hoops you have to jump though for that though) > Next

Tick you local domain > Edit  >Authenticate to AD (with an Enterprise Admin account) > Next.

Exit.

Now, be patient and wait it can take a while for your devices to start appearing in Azure, when they do that will look like this;

Related Articles, References, Credits, or External Links

Find The Azure AD Join Type

Azure Traffic Manager (DNS Failover)

Posted on by
Reply

KB ID 0001740

Problem

Why Azure Traffic Manager? I had to price up a hardware load balancer (ADC)  a couple of weeks ago for a client. I wont mention the vendor, (though I’m sure you can guess). Over 3 years it was going to cost (for a pair) about £100k, (so about 33k a year). That included the global DNS failover, this was so they, (the client) could fail over their services between multiple data centres.

OK there are other ADC vendors, and there’s even some budget vendors, I could use ARR, or even deploy NGINX. (Though supporting those deployments is another matter!) Whilst discussing this with my colleagues, the consensus was “We would be better deploying Azure Traffic Manager”. So I though I’d take a look to see just how difficult that was to deploy.

What is Azure Traffic Manager? Essentially a cloud based ADC that can provide availability and DNS failover, between Azure regions, and (more importantly in my case)  ‘External‘ endpoints, (so on premises, multiple data centres, other public clouds, etc.)

What Does Azure Traffic Manager Cost? Therein lies most people’s ‘bug-bear‘ with public cloud, that’s hard to quantify. So per million DNS lookups it’s £0.403p a month (up to a billion DNS queries,) THEN £0.28p per million DNS queries (over a billion) per month. I’m not sure how you would begin to calculate that? I can tell you how many people are on this website while you are reading this text, and how many hits we get a month, but DNS queries?

I no longer host my own DNS, I used to, but it was getting hammered by script kiddies 24/7 and my servers were just using processor cycles to do nothing productive. So I pay someone else to host my records now. I asked them..

Additionally you pay: £0.403p a month per (basic) monitored external endpoint or £1.41 a month per (rapid) monitored external endpoint.

I’m being a little disingenuous to Microsoft, in their defence this is a traffic management solution NOT a web load balancing/HA solution. If you look at it from that perspective then DNS queries is a better measurement than ‘web-hits‘ or ‘page-impressions’. But you will be billed on multiples of something that you have no control over and you have to just ‘Trust’ that when Microsoft tells you you’ve had 36 million DNS lookups then that’s correct.

Deploy Azure Traffic Manager

From the Azure portal > Create a Resource.

You will need to search for ‘Traffic Manager Profile” > Create.

Give it a sensible name > Set the routing meshing to Priority > Pick a Resource group (or create a new one) > Select your resource group location > Create.

Locate your traffic manager profile (look under all resources if you can’t find it) > Configuration.

Drop the DNS TTL to 30 seconds > I’m monitoring HTTPS on Port 80> Leave the probing interval on 30 seconds > Save.

Note: this will take 3 lots of 30 seconds before it will fail over (90 seconds). If you drop the poll interval to 10 seconds then you get billed the additional ‘fast interval charges‘ I mentioned above). You can set it to 0 lots of 10 seconds to make it fail over quicker, but that’s more expensive.

Endpoints > Add.

Add your primary site in with a priority of ‘1’, the repeat for your standby site(s), with lower priorities.

Before testing, make sure all the endpoints are ‘Online‘.

Overview > Copy the DNS name.

In your own DNS config, simply create a CNAME DNS record to point to the Azure one you copied above.

Testing Azure Traffic Manager

First let’s test Azure > Ping the domain name you coped from the Azure portal, you will notice it resolves to my primary site IP (that wont respond to pings, but that’s not important for testing. Power off the primary endpoint (or disconnect its NIC). And wait 90 seconds. Then ping it again, this time the IP address it responds to has changed to my secondary endpoint. That proves the Azure Traffic Manager works.

To illustrate I’ve got a slightly different web page on my primary and secondary external node, just to prove its working.

Related Articles, References, Credits, or External Links

NA

O365 with Duo MFA (Without a P1 License?)

Posted on by
4

KB ID 0001737

Problem

Working for a cloud service provider, (and a Duo partner). I get a lot of queries about Duo MFA for Office 365. Typically (I think) the best solution is to enable Azure Conditional Access and couple that with Trusted sites, so clients get challenged when out on the road, but not in the office. The drawback of this is Azure Conditional Access requires a P1 License, at time of writing that’s about $6 a month on top of you normal 365 licence. So it can work out expensive.

A couple of weeks ago, I was on a call with a client who wanted to use Duo Access Gateway to provide Duo MFA to their 365 tenancy. I’ve done the same thing for other clients with ADFS before, Basically you are just Federating a DAG into your Azure AD, rather than Federating an ADFS Server

This is what it looks like;

Duo MFA: DAG & Office 365 Pre-Requisites

  • Azure AD Sync needs to be setup, and a registered domain setup in your office 365 tenancy. (NOT the onmicrosoft domain!)
  • You need (at least) Duo MFA licensing to deploy. One level above free ($30 for a year).
  • DAG Server 2 x CPU, 4GB RAM, 60Gb HDD (Windows Server 2012 or newer (2019 supported) Note: You can also deploy DAG on Linux.
  • DAG Server should be in a DMZ, (not domain joined).
  • DAG Server needs IIS role installing.
  • DAG Server needs TCP Port 443 open (outbound) to Duo.
  • DAG Server needs TCP Port 443 open (Inbound) to Duo on the public IP address that your public DNS record is pointing to.
  • Download PHP (in Zip file format) Keep the Zip file handy.
  • Install a publicly signed SSL certificate (Common name or SAN must match the public DNS name). 

Note: Duo have great walkthroughs and videos on their site, this article is just to tie the various steps together.

Installing Duo MFA DAG

To setup IIS just use the following Powershell commands

[box]

import-module servermanager
add-windowsfeature Web-Server, Web-Mgmt-Tools, Web-CGI, NET-Framework-Core, Web-Asp-Net45, Web-Scripting-Tools

[/box]

Install and Bind a Publicly Signed Certificate: Let’s do this for free with Let’s Encrypt! See the following article.

Free Certificate for IIS with Let’s Encrypt

Download the newest version of PHP in zip format. and drop it on your desktop, then run the Duo Windows installer. You may be prompted to install the C++Runtime software (which may require a reboot). Post reboot the installer will launch.

Browse to and select the PHP Zip file > Next > Select the correct server hostname (if it’s not listed, then you need to enter it in the ‘hostname’ section of the https binding in IIS manager > Next > If you want to manage the DAG from any other IP addresses enter them > Next > Install.

When done  launch the ‘Configure’ page > Create an access password > Submit.

Configure Duo DAG Active Directory LDAPS Access

In the next step we need a copy of your CA Certificate (the CA that issued your domain controller(s) kerberos certificates). If you have just glazed over have a read of the following article;

Get Ready for LDAPS Channel Binding

From the DAG console > Authentication Source > Configure Sources > Select Active Directory* > Enter the FQDN of a domain controller, (the DMZ server needs to be able to resolve this I suggest putting it in the server hosts file).  > Port will be 636 (LDAPS) > Select LDAPS > Scroll down.

*You cant use Azure as a authentication source for Office365 MFA, (counter intuitively!)

Browse to and select the CA certificate you downloaded above > Set the attributes to “mail,sAMAccountName,userPrincipalName,objectGUID” > Search Base (I’m setting it to the top of my active directory e.g. ‘DC=pnl,DC=com’ > Search Attributes (I’ve set the same as the attributes above) > Search Username, set to a normal domain user account, (I’ve set-up a service account that’s just a member of ‘domain  users’ > Scroll down  > Type in the users password > Save Settings.

What should happen is, it should say LDAP Bind Successful, if it does not;

  • Make sure TCP Port 636 is open from the DMZ server to the Domain Controller(s)
  • Make sure you used the domain controller FQDN NOT its IP address, (the IP address is NOT on the Kerberos certificate).
  • Install the Remote Server Admin tools for ADDS – this will give you access to LDP exe which you can test LDAPS connectivity with (I’ve written about LDP before, use the search box above).

When happy, ensure Active Directory is set as the Active Source.

Federate Duo DAG With Azure Active Directory

Within the Duo DAG management console > Applications > Metadata > Download the Certificate  > Copy all the URLS to a notepad file.

 Copy the notepad file, and the certificate, to a domain joined server/PC that has the the Azure Active Directory Module for Powershell installed.

Execute the following commands, (change the values in RED to match your own);

[box]

Connect-MsolService
Log into your Tenancy, when prompted

get-msoldomain -domain your-domain-name.com

Make sure it says 'Managed' and NOT 'Federated'!
$dom = "your-domain-name.com"
$url = "https://portal.petenetlive.co.uk/dag/saml2/idp/SSOService.php"
$uri = "https://portal.petenetlive.co.uk/dag/saml2/idp/metadata.php"
$logoutUrl = "https://portal.petenetlive.co.uk/dag/saml2/idp/SingleLogoutService.php?ReturnTo=https://portal.petenetlive.co.uk/dag/module.php/duosecurity/logout.php"
$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\dag.crt")
$certData = [system.convert]::tobase64string($cert.rawdata)
Set-MsolDomainAuthentication –DomainName $dom -Authentication Federated -PassiveLogOnUri $url -ActiveLogOnUri $url -IssuerUri $uri -LogOffUri $logoutUrl -PreferredAuthenticationProtocol SAMLP -SigningCertificate $certData

get-msoldomain -domain your-domain-name.com
NOW it should say 'Federated'!

[/box]

Duo MFA Protect Office 365

Log into your Duo online admin console > Protect an application > Locate Office 365 (2FA with SSO self hosted) > Protect.

Unless ALL your mail clients* support modern authentication then tick “Allow legacy mail clients that only support basic auth to bypass 2FA” 

*Modern Authentication Supported on: Outlook 2013 (or newer), older Android mail clients don’t, though on modern versions of Android that you can install MS Outlook on does. Modern Apple IOS devices support modern authentication.

Click ‘Save Configuration‘.

Click “Download your Configuration File” this will download a JSON configuration file, put it somewhere your Duo DAG server can get to.

Add Office 365 MFS to Duo DAG

Back on the DAG server > Applications > Browse > Select the JSON file you downloaded above.

Open a web page, and try to log into office 365, after  you’ve entered your username, you should be forwarded to your DAG for 2FA

Related Articles, References, Credits, or External Links

NA

Azure: Point to Site VPN From mac OS?

Posted on by
13

KB ID 0001693

Problem

We mac users always get overlooked. If I had a pound for every time I’ve heard ‘Yeah we don’t support macs?” I would be a rich man. But thankfully this makes us work things out for ourselves usually!

So recently I did a article Azure: Point To Site VPN (Remote Access User VPN) but what if you want to use the same solution for a remote mac user?

Solution

Firstly you will want to download the VPN package (and have a valid client/user certificate, [see the link above]).

Obviously the installer is for Windows, but within the ZIP file you download, it has a copy of the XML file with the settings in it, and a copy of the Root CA certificate you used.

So your first job is to ‘import‘ the client certificate, it will be in PFX format, (if you followed my instructions), so you will need to supply the password you specified when creating the PFX file (not the mac password), when prompted to install it (double click on it).

The engineer in me isn’t quite sure why the client needs the Root CA certificate on it, (because that’s not how certificates work!) But Microsoft insist it’s necessary, so also double click and install the Root CA Certificate, (it’s inside the VPN Package).

You don’t need to install VPN software onto the mac, (it has its own built in). Click the Apple Logo > System Preferences > Network > Add > Interface = VPN > VPN Type = IKEv2 > Service Name = Azure-Client-VPN > Create.

Now open the XML file from within you VPN client software ZIP file, and locate the FQDN of the ‘Gateway’ address in Azure > Copy it to the clipboard.

Paste the server address into BOTH Server Address AND Remote ID > (Leave Local ID blank for now) > Authentication Settings

WARNING: I’m using mac OS Catalina, so I choose ‘None’ (NOT CERTIFICATE). But for mac OS Mojave (and older) CHOOSE CERTIFICATE). It’s a bug that causes an error (see below) if you don’t.

Select > Choose the CLIENT certificate you imported earlier, (Take note of the name in brackets, this is the common name on the certificate). You will need this in a minute!  > Continue > OK.

Put the Common Name from the certificate into the Local ID section > Apply > Connect.

All being well it should connect, (though it may prompt for you to enter your user password). BY DEFAULT the option ‘Show VPN Status in Menu Bar‘ should be ticked, if it isn’t then tick it.

With that option ticked, you can connect and disconnect the VPN quickly without needing to go back into System Preferences like so;

Error: VPN Connection, ‘An unexpected error occurred’

Remember above when I said choose ‘None‘ for Catalina, NOT certificate? Well this is what happens if you choose certificate!

Related Articles, References, Credits, or External Links

NA

Azure VPN: Point To Site VPN (Remote Access)

Posted on by
Reply

KB ID 0001692

Problem

Given my background I’m usually more comfortable connecting to Azure with a Route Based VPN from a hardware device, like a Cisco ASA. I got an email this afternoon, a client had a server in a private cloud and a server in Azure, they needed to transfer files from the Azure server to the server in the private cloud. Now on further investigation this client had a Cisco vASA so a VPN was the best option for them, (probably).

But what if they didn’t? Or what if they were ‘working from home’ and needed to access their Azure servers that were not otherwise publicly accessible?

Well the Microsoft solution for that is called an ‘Azure Point to Site VPN‘, even though in the current Azure UI they’ve called it ‘User VPN Configuration‘, because ‘Hey! Screw consistency and documentation that goes out of date every time a developer has a bright idea, and updates the UI’ Note: I have a thing about things being changed in GUIs!

So regardless whether you are on or off the corporate LAN, you can connect to your Azure Virtual Networks.

Azure VPN (Remote Access)

This is not a full Azure tutorial, I’m assuming, as you want to connect to existing Azure resources, you will already have most of this setup already. But, just to quickly run through. You will need a Resource Group, and in that Resource Group you will need a Virtual Network. (Note: I like to delete the ‘default‘ subnet and create one with a sensible name).

So far so good, within your virtual network you will need to create, (if you don’t already have one,) a ‘Gateway Subnet‘. To annoy the other network engineers, I’ve made it a /24, but to be honest a /29 is usually good enough).

Now to terminate a VPN, you need a ‘Virtual Network Gateway‘.

Make sure it’s set for VPN (Route Based) > Connected to your Virtual Network  > Either create (or assign) a public IP to it. I told you I’d be quick, however the Gateway will take a few minutes to deploy, (time for a coffee.)

Azure VPN Certificate Requirement

For the purpose of this tutorial I’ll just create some certificates with PowerShell, (a root CA cert, and a client cert signed by that root certificate). This wont scale very well in a production environment. I’d suggest setting up a decent PKI infrastructure, Then using auto-enrolment for your users to get client certificates. However for our run through, execute the following TWO commands;

[box]

$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject "CN=Azure-VPN-Root-Cert" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -KeyUsageProperty Sign -KeyUsage CertSign

New-SelfSignedCertificate -Type Custom -DnsName Azure-VPN-Client-Cert -KeySpec Signature -Subject "CN=Azure-VPN-Client-Cert" -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation "Cert:\CurrentUser\My" -Signer $cert -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2")

[/box]

Now launch ‘certmgr‘ and you will see the two certificates. Firstly, export the client certificate.

Yes you want to export the private key > You want to Save it as a .PFX file > Create a password for the certificate (MAKE NOTE OF IT!) > Save it somewhere you can get to, (you will need it in a minute).

Secondly, export the Root CA certificate.

 You DON’T export the private key > Save as Base-64 encoded > Again save it somewhere sensible, you will also need it in a minute.

Open the ROOT CA CERT with Notepad, and copy all the text BETWEEN —-BEGIN CERTIFICATE—- and —-END CERTIFICATE—- Note: This is unlike most scenarios, when working with PEM files, where you select everything, (it tripped me up!)

Back in Azure > Select your Virtual Network Gateway > Select ‘User VPN Connection’ (seriously, thanks Microsoft be consistent eh!) > ‘Configure now‘.

Pick an address pool for your remote clients to use, (make sure it does not overlap with any of your assets, and don’t use 192.168.1.0/24, or 192.168.0.0/24, Note: These will work, but most home networks use these ranges, and let’s not build in potential routing problems before we start!)

Choose IKEv2 and SSTP > Authentication Type = Azure Certificate > Enter your Root CA details, and paste in the PEM text, you copied above > Save > Time for another coffee!

When is stopped deploying, you can download the the VPN client software.

Azure Point to Site (User VPN) Client Configuration

So for your client(s) you will need the Client Certificate, (the one in PFX format,*) and the VPN Client software >  Double click the PFX file > Accept ‘Current User‘.

*Note: Unless you deployed user certificates already, and your corporate Root Cert was entered into Azure above.

Type in the certificate password you created above > Accept all the defaults.

Yes.

Now install the Client VPN software, you may get some security warnings, accept them and install.

Now you will have a configured VPN connection. I’m a keyboard warrior so I usually run ncpa.cpl to get to my network settings, (because it works on all versions of Windows back to NT4, and ‘developers’ haven’t changed the way it launches 1006 times!)

Launch the Connection > Connect > Tick the ‘Do not show…‘ option > Continue > If it works, everything will just disappear and you will be connected.

Related Articles, References, Credits, or External Links

NA