SSL Inspection and Office 365

Posted on Leave a commentPosted in Azure, Azure Information Protection, cloud, firewall, Office 365, proxy, SSL

Lots of cloud endpoint URL’s break service flow if you enable SSL Inspection on the network devices between your client and the service. My most recent example of this Enterprise State Routing in Windows 10.

Microsoft have a list of URLs for the endpoints to their service, where they are categorised as Default, Allow or Optimize. The URLs that are Allow or Optimize should avoid SSL inspection.

The endpoint list is found at https://support.office.com/en-us/article/managing-office-365-endpoints-99cab9d4-ef59-4207-9f2b-3728eb46bf9a#webservice and the JSON for this can be downloaded, as well as a PowerShell script to return the IPs and URLs.

Within this JSON file you can look for the category and if the category is Allow or Optimize then ensure the matching URLs are not SSL inspected.

Azure MFA 503 Error When Authenticating

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

If you have installed version 7 of Azure MFA Server on-premises (7.0.0.9 or 7.0.2.1 at the time of writing) and have enabled IIS authentication with Forms Based authentication and the Native App, but when you need to authenticate you are presented with a 503 DLL error. The reason for this is that version 7 removed support for 32 bit Windows, but if the application pool in IIS for the website you are running is a 32 bit pool then the 64 bit DLL provided by MFA for authentication will not run. If you change the pool to 64 bit then the MFA authentication DLL will work, and your phone call/text or mobile app verification should occur. Of course, if you change the application pool to 64bit make sure that other DLLs used by the application are not 32 bit and so the application itself, rather than MFA, would not fail.

If the application is 32 bit and therefore the application pool needs to be using 32bit MFA DLL’s then you either need to upgrade your application to 64 bit or downgrade MFA Server to version 6.3. To obtain version 6.3 you need to raise a support call with Microsoft.

Upgrading Azure Multi-Factor Authentication Server

Posted on Leave a commentPosted in Azure, Azure Active Directory, MFA, Multi-Factor Authentication, Office 365

A new version of Azure MFA Server was released at the end of March 2016, version 7.0.0.9. This provides an in place upgrade to the previous version 6.3.1.1. This version is based on .NET 4.5 and not .NET 2.0, which is the big change in the product, along with new end user functionality in the ADFS Adapter. Note the upgrading the ADFS Adapter piece is prone to issues, which I have documented here.

This blog post just outlines the standard upgrade process. It takes about 10 minutes and the service is uninstalled and reinstalled, but leaves the database and settings in place – so it requires downtime or a load balancer. If you have more than one MFA server in a cluster then the older versions still running 6.3.1.1 will still work for users but the administration screens are read only once at least one server is upgraded. All servers should therefore be upgraded in a short interval.

Before upgrading, take a copy of the “Program Files\Multi-Factor Authentication Server” folder as a backup is useful, especially if you have the ADFS Adapter installed as the service name has changed and that breaks ADFS Server.

Then, the following are just the sequence of screenshots from the installation (upgrade) so you know what to expect:

The old version has a 2013 splashscreen:

image

The MFA admin page points out that a new version is available:

image

Ensure you have the May 2014 Cumulative Update on your Windows Server 2012 R2 boxes (you ought to regardless of this prompt):

image

Visual C++ (x86 and x64) versions will be installed:

image

image

image

image

image

image

Then there follows a long pause of a good few minutes. Hang in there, the old software is still in place and running. The new installer will start shortly:

image

image

And complete in less time than you waited for the installation to start:

image

The service restarts and this machine is now running the 7.0… version

If you start the admin console you will see that it is copyright 2016:

image

You will also get prompts about upgrading any of the installed components. If you look in Programs and Features at this time you will see that there might be some components still on version 6.3.1:

image

 

You will also see that the admin portal is running mixed versions:

image

If you open the admin console on another node, you will be warned about the mixed versions:

image

As long as you upgrade all the components one after the other you should get no issues, so I don’t recommend an order for these components to be installed in, but I do not recommend leaving them not upgraded:

image

image

I also recommend installing the required components in advance, as that is quicker. For an upgrade you need to install ASP.NET45 under IIS Application Development in Server Manager. You will return here at the end to uninstall .NET 2/3.5 if appropriate.

image

When it comes to upgrading though, I do recommend you upgrade on component and then the next. Don’t start them all at once – though you will be prompted all at once to do this. So pick one, click Yes and wait for that to complete. It will take a few minutes for each installer to start, so be patient:

image

Note that the installer does not suggest the correct Application Pool for each component. So make sure you select the correct one each time.

image

image

image

Then move onto the next installer. If you closed the Yes/No prompt for each installer you can reach it via that area of the admin console:

image

Remember to set the Application Pool correctly as well:

image

Like the User Portal installer, there is not much to see so close the installer when finished. Ensure you are running the latest .NET updates as well though:

image

I have documented the ADFS Adapter upgrade on this post, as there are specific issues with it.

If once you have upgraded all the previously installed components, you visit Programs and Features you can see that the Mobile App is not upgraded. The mobile app is not installed via the admin console, so the console will not prompt about the install. To install the Mobile App run MultiFactorAuthenticationMobileAppWebServiceSetup64.msi from C:\Program Files\Multi-Factor Authentication Server. You will need to start this installer from an administrative cmd prompt:

image

Again, change the Application Pool to the correct value for the application. It will show the Virtual Directory as well here, and unlike this example, this is recommended to be something easy to type on a mobile device. Upgrading the app does not recall the previous virtual directory name, and so you should ensure that you enter that here as well. If you upgrade it and do not change the Virtual Directory name then you need to uninstall it and reinstall it, but remember to copy the upgraded web.config from the virtual directory first. It contains the username and password of the SDK user account.

image

Upon completion of all nodes in the MFA cluster, the admin portal shows all versions the same:

image

Finally, note that though you may pick the Application Pools during the various installers, new pools with new names (starting ASP.NET v4.0) are created but not used. The old app pools are upgraded to .NET 4.0 and I recommend removing the unused pools at your convenience as both the unused and used pools are the same apart from in name:

image image

image

Installing Azure Multi-Factor Authentication and ADFS

Posted on 14 CommentsPosted in Azure, MFA, multi-factor auth, Multi-Factor Authentication, Office 365

I have a requirement to ensure that Office 365 users external to the network of one of my clients need a second factor of authentication when accessing Office 365 resources from outside the corporate network. The free Multi-Factor Authentication (MFA) feature of Office 365 will not distinguish between network location so we need to enable MFA on ADFS (or Federated) authentication for external connections. External connections are those that come through a WAP server to the ADFS server and not those that come to ADFS directly.

To set this up, first install ADFS on Windows Server 2012 R2 and install additional ADFS servers and load balancers as required. Install the WAP servers in your DMZ and connect them to the on-premises ADFS server(s). Once this is all up and running enable MFA in Azure. You will need to create an MFA instance for billing purposes. Once this is created you can download the MFA software to the ADFS Server. For this blog we are using MFA Server version 7, released April 2016. This version does not need .NET 2.0 installed and works with .NET 4.0

On the ADFS Server run the MFA installer and follow the prompts. Make sure you have the Dec 2014 Cumulative Update or later (preferable the latest) installed. Accept the prompts for the two Visual C++ Runtime installations and complete the installation.

Following installation the wizard runs to configure MFA and MFA replication. I suggest making a group (called ADFS) and not using the default and setting up replication. The email address and password is obtainable from the MFA download page and is valid for 10 minutes.

Once installed start the MFA software and go to the AD FS page. Install the AD FS connector by pressing the button. On the primary ADFS server you then need to enable ADFS/MFA integration by running in PowerShell .\Register-MultiFactorAuthenticationAdfsAdapter.ps1. You can find this in Program Files\Multi-Factor Authentication Server. This is not needed on secondary servers.

Repeat the MFA install on all ADFS servers and install the MFA connector.

To allow users to set their own phone number and MFA settings install the SDK, User Portal and Mobile App features. These are detailed below:

User Portal

This requires that you install IIS/Web Server role on the server. In the role services for IIS include the HTTP Redirection feature, the ASP.NET 4.5 feature (under Application Development) and IIS 6 Metabase Compatibility (under IIS 6 Management Compatibility). Other role services are added because of these options.

Accept the prompts to create the users. You will be taken to a page about virtual directories. I tend to select the defaults here, apart from the app pool, which I set the the one that matches the name of the feature I am installing. I use HTTP Redirect feature to redirect the user from the root directory to HTTPS://fqdn/MultiFactorAuth.

image

Once the User Portal is installed I set the relevant options in the MFA admin program such as the User Portal URL and the auth methods allowed. If you are going to install the Mobile App feature then allow users to use this option.

If you are configuring HTTP Redirection then set this on the root directory of the default website now. Redirect only the root directory to HTTPS://fqdn/MultiFactorAuth

image

Make sure you turn HTTP Redirect off on all subdirectories and virtual directories of the application will not be reachable. Also check that HTTPS is bound to a certificate in IIS and to the website.

SDK

To install the SDK go to the Web Service SDK node in MFA on each ADFS server and click the Install Web Service SDK button. This requires Basic Authentication enabled in IIS. This is not a default role service, so you will need to add it to the server at this time.

Install the SDK and select the defaults:

image

If you have HTTP Redirection enabled, check it is disabled for the virtual directory as it won’t be by default.

Mobile App

To use the Azure Authenticator app to sign in to ADFS (as a second factor of authentication) you need to enable the Mobile App and have the URL reachable from the internet. The URL can be published through the WAP servers as these are available to you. To publish the MFA mobile app through WAP you can use the following cmdlet (changing the URL and certificate thumbprint as required):

Add-WebApplicationProxyApplication -BackendServerUrl ‘https://auth.domain.co.uk/mfaApp/’ -ExternalCertificateThumbprint ‘xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx’ -ExternalUrl ‘https://auth.domain.co.uk/mfaApp/’ -Name ‘Multi-Factor Authentication’ -ExternalPreAuthentication PassThrough -ClientCertificateAuthenticationBindingMode None -BackendServerCertificateValidation None -InactiveTransactionsTimeoutSec 300 -ClientCertificatePreauthenticationThumbprint ”

The mobile app needs to be installed on each ADFS server. Do this by opening a command prompt as admin and browse to the installation folder of the MFA server (C:\Program Files\Multi-Factor Authentication Server). Then run MultiFactorAuthenticationMobileAppWebServiceSetup64.msi

image

Change the Virtual Directory to something short, as users might need to enter this on their phone. I use mfaApp for this. Install and when finished If you have HTTP Redirection enabled, check it is disabled for the virtual directory as it won’t be by default.

Open this folder in admin cmd prompt (C:\inetpub\wwwroot\mfaApp in my case) and edit web.config. Modify the following two keys as follows:

<add key=”WEB_SERVICE_SDK_AUTHENTICATION_USERNAME” value=”” />
<add key=”WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD” value=”” />

The username and password here needs to be a member of the PhoneFactor Admins group in Active Directory.

Then locate <setting name=”pfpaws_pfwssdk_PfWsSdk” serializeAs=”String”> and change the Value string that follows from http://localhost:4898/PfWsSdk.asmx to https://fqdn/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx.

Finally enter the MFA App URL in the Mobile App section of the MFA admin program – this setting needs to be done once, as it will replicate to the other servers.

Restart the servers and you are ready to go.

Configuring ExpressRoute With NRP Errors

Posted on Leave a commentPosted in Azure, ExpressRoute, VNet

I had a scenario where when I ran Get-AzureRmExpressRouteServiceProvider in a new Azure tenant I would get the following error in PowerShell.

Get-AzureRmExpressRouteServiceProvider : Subscription a4ca03ea-42e4-4a18-a50f-79bcc53907e4 is not registered with NRP.
At line:1 char:1
+ Get-AzureRmExpressRouteServiceProvider
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureRmExpressRouteServiceProvider], CloudException
    + FullyQualifiedErrorId : Microsoft.Azure.Commands.Network.GetAzureExpressRouteServiceProviderCommand

This is one of the required cmdlets in configuring ExpressRoute. The fix is to use the following cmdlets to create the required objects that are not mentioned in the ExpressRoute setup article at https://azure.microsoft.com/en-us/documentation/articles/expressroute-howto-circuit-arm/ and then return to this article and complete the rest of the setup.

  1. First, ensure you are logged into Azure PowerShell using the Resource Manager cmdlets (see https://azure.microsoft.com/en-us/blog/azps-1-0/ for steps to install these) and Login-AzureRMAccount to login to the correct tenant
  2. Second, select your subscription with Get-AzureRMSubscription followed by Select-AzureRMSubscription –SubscriptionName “Free Trial”. Replace “Free Trial” with the name of your subscription.
  3. Run Get-AzureRmExpressRouteServiceProvider – you should get the above error. If not then this blog post is not relevant to you
  4. Create a resource group and then create a virtual network inside this resource group. These settings will need to be set to something suitable for your network. Suitable means not overlapping with any subnet on-premises. The AzureRM PowerShell to do this looks like the following:
  5. # Create a VNet with two (or more subnets). First subnet must be named GatewaySubnet and min /28

    $Location = “West Europe”
    New-AzureRmResourceGroup -Name “InternalNetworkResourceGroup” -Location $Location
    $GatewaySubnet = New-AzureRmVirtualNetworkSubnetConfig -Name ‘GatewaySubnet’ -AddressPrefix 192.168.192.0/28
    $LANSubnet1 = New-AzureRmVirtualNetworkSubnetConfig -Name ‘AzureLAN1’ -AddressPrefix ‘192.168.192.16/28’
    New-AzureRmVirtualNetwork -Name AzureInternal -ResourceGroupName “InternalNetworkResourceGroup” -Location $Location -AddressPrefix 192.168.192.0/24 -Subnet $LANSubnet1,$GatewaySubnet

  6. You can now run Get-AzureRmExpressRouteServiceProvider  without error and continue creating your ExpressRoute request and obtain your service key

Password Writeback Errors

Posted on 9 CommentsPosted in Azure, Azure Active Directory, Group Policy, IAmMEC, Office 365, password

I had been struggling with password writeback testing and was coming across the following set of errors, and found that searching for them uncovered nothing online. So I wrote this blog to remind me and help you solve these issues. These errors are all visible in the Application log of the Event Viewer.

User Restrictions

The following error is because the user has “user cannot change password” option set in Active Directory:

EventID 33004: TrackingId: 7344da2c-ab9d-42ef-adea-4a17d07fdeb9, Reason: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contoso.co.uk, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230626, message=The password could not be updated because the management agent credentials were denied access.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)

And also, as the second error generated:

Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5716): ..\server.cpp(11139): 0x80230626 (The password could not be updated because the management agent credentials were denied access.)
Azure AD Sync 1.0.8641.0″

image

Group Policy Restrictions

Its possible that the errors you see for password writeback in the application log are due to restrictions on the user’s password that they have chosen. If the password is not complex enough then you get a warning in the password reset page the user is visiting in Azure, but you can also get this is a Group Policy restriction is in place even if you have set a strong password. The text in the error message in the Azure password change portal reads “This password does not meet your corporate password policy. Please make sure to use a mix of upper and lowercase letters, numbers, symbols, and to update your password to one that you haven’t used previously.”. Therefore though Azure accepted the passwords (original and new) the on-premises server rejected them with the following:

Event ID 33008: TrackingId: 3c8c78dc-9167-4286-9384-e2f0e777af87, Reason: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified., Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contoso.co.uk, Details: Microsoft.CredentialManagement.OnPremisesPasswordReset.Shared.PasswordResetException: Synchronization Engine returned an error hr=80230619, message=A restriction prevents the password from being changed to the current one specified.
   at AADPasswordReset.SynchronizationEngineManagedHandle.ThrowSyncEngineError(Int32 hr)
   at AADPasswordReset.SynchronizationEngineManagedHandle.ChangePassword(String cloudAnchor, String sourceAnchor, String oldPassword, String newPassword)
   at Microsoft.CredentialManagement.OnPremisesPasswordReset.PasswordResetCredentialManager.ChangePassword(String encryptedChangePasswordRequestString, String publicKeyEncryptedSymmetricKey, String publicKeyEncryptedSymmetricIV)

and

Event ID 6329: An unexpected error has occurred during a password set operation.
“BAIL: MMS(5236): ..\server.cpp(11139): 0x80230619 (A restriction prevents the password from being changed to the current one specified.)
Azure AD Sync 1.0.8641.0″

This of course seems self explanatory – your password is not complex enough for your rules on-premises but complex enough to get past the Azure initial checks that it imposes.

image

This error though is especially annoying in test scenarios where you have turned off all the complexity checks. To test why you are getting this error, first check its a password change error and not something else, and try and change the users password on-premises. You should get the same restriction. Then use the cmd prompt to check the password settings for the user.

</p> <p>net user username /domain</p> <p>

This will report the following:

User name                    user1
Full Name                    First Last
Comment
User’s comment
Country/region code          000 (System Default)
Account active               Yes
Account expires              Never

Password last set            7/7/2015 3:19:00 PM
Password expires             Never
Password changeable          7/8/2015 3:19:00 PM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   7/8/2015 10:31:05 AM

Logon hours allowed          All

Local Group Memberships
Global Group memberships     *Domain Users
The command completed successfully.

image

In this example, notice the highlighted. Here there password minimum age requirement in Group Policy has been removed:

image

But the domain controller (after running gpupdate to force the change to the domain controller) still enforces a single day to allow the change to occur.

For test scenarios, modify group policy to 0 days (rather than not defined) and probably increase the max age from the suggested default of 30 days:

image

After running gpupdate, you get the following for the net user command:

Password last set            7/8/2015 10:42:05 AM
Password expires             Never
Password changeable          7/8/2015 10:42:05 AM

Now you should be able to change your password in Azure against an on-premises user.

Strong Password Required

In the password change portal, the user is required to enter a strong password regardless of any restrictions that you have on-premises. So even if you are testing and have removed all history and complex and renewal requirements for the password, Azure will ensure that a strong password of 7 or more characters is entered regardless of your on-premises policy. In fact, Azure does not know your on-premises policy for password restrictions and enforces its own in addition to the one you have.

You get errors in the portal that read “Strong password required. Combine at least three of the following: uppercase letters, lowercase letters, numbers, and symbols.”. You also cannot reset the password to the same and the errors you get look like the following options:

image image image image 

Success

For completion of the blog, here is what you should see in the event log when it is working:

Event ID 31006: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordRequestStart, Details: ethan@contosochemists.co.uk

Event ID 31007: TrackingId: f430189d-984c-41d5-a4a6-333c66ffae1f, ChangePasswordSuccess, Details: Context: cloudAnchor: User_9b83f544-ba22-4ffb-bff5-c1c2374d654c, SourceAnchorValue: F39SWQrM2EidaboN8UC8Ww==, UserPrincipalName: ethan@contosochemists.co.uk

Configuring Sync and Writeback Permissions in Active Directory for Azure Active Directory Sync

Posted on 47 CommentsPosted in 2008, 2008 R2, 2012, 2012 R2, active directory, ADFS 3.0, Azure, Azure Active Directory, cloud, exchange, exchange online, groups, hybrid, IAmMEC, Office 365, WAP, Web Application Proxy, windows

[This blog post was last updated 5th October 2017 – added support to Exchange Hybrid for msExchDelegateLinkList attribute which was announced at Microsoft Ignite 2017 for the support of keeping auto-mapping working cross on-premises and the cloud]

[Updated 18th June 2017 in advance of the release of AADConnect version 1.1.553.0. This post contains updates to the below scripts to include the latest attributes synced back to on-premises including publicDelegates, which is used for supporting bi-directional sync for “Send on Behalf” of permissions in Exchange Online/Exchange Server hybrid writeback scenarios]

[Update March 2017 – added another blog post on using the below to fix permission-issue errors on admin and other protected accounts at http://c7solutions.com/2017/03/administrators-aadconnect-and-adminsdholder-issues]

Azure Active Directory has been long the read-only cousin of Active Directory for those Office 365 and Azure users who sync their directory from Active Directory to Azure Active Directory apart from eight attributes for Exchange Server hybrid mode. Not any more. Azure Active Directory writeback is now available. This enables objects to be mastered or changed in Azure Active Directory and written back to on-premises Active Directory.

This writeback includes:

  • Devices that can be enrolled with Office 365 MDM or Intune, which will allow login to AD FS controlled resources based on user and the device they are on
  • “Modern Groups” in Office 365 can be written back to on-premises Exchange Server 2013 CU8 or later hybrid mode and appear as mail enabled distribution lists on premises. Does not require AAD Premium licences
  • Users can change their passwords via the login page or user settings in Office 365 and have that password written back online.
  • Exchange Server hybrid writeback is the classic writeback from Azure AD and is the apart from Group Writeback is the only one of these writebacks that does not require Azure AD Premium licences.
  • User writeback from Azure AD (i.e. users made in Office 365 in the cloud for example) to on-premises Active Directory
  • Password Hash Sync (this is not really writeback, but its the only permission needed by default for forward sync, so added here)
  • Windows 10 devices for “Azure AD Domain Join” functionality

All of these features require AADConnect and not and of the earlier verions. You can add all these writeback functions from the AADConect setup wizard, and if you have used Custom mode, then you will need to implement the following permissions.

In all the below sections you need to grant permission to the connector account. You can find the connector account for your Active Directory forest from the Synchronization Service program > Connectors > double-click your domain > select Connect to Active Directory Forest. The account listed here is the connector account you need to grant permissions to.

SourceAnchor Writeback

For users with (typically) multi-forest deployments or plans or a forest migration, the objectGuid value in Active Directory, which is used as the source for the attribute that keys your on-premises object to your synced cloud object – in AAD sync parlance, this is known as the SourceAnchor. If you set up AADConnect version 1.1.553.0 or later you can opt to change from objectGuid to a new source anchor attribute known as ms-ds-consistencyGuid. To be able to use this new feature you need the ability for AADConnect connector account to be able to read ObjectGUID and then write it back to ms-ds-consistencyGuid. The read permissions are typically available to the connector account without doing anything special, and if AADConnect is installed in Express Mode it will get the write permissions it needs, but as with the rest of this blog, if you are not using Express Mode you need to grant the permissions manually and so write permissions are needed to the ms-ds-consistencyGuid attribute. This can be done with this script.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$ForestDN = "DC=contoso,DC=com"

$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":WP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd | Out-Null

Note that if you use ms-ds-consistencyGuid then there are changes required on your ADFS deployment as well. The Issuance Transform Rules for the Office 365 Relying Party Trust contains a rule that specifies the ImmutableID (aka AADConnect SourceAnchor) that the user will be identified as for login. By default this is set to ObjectGUID, and if you use AADConnect to set up ADFS for you then the application will update the rule. But if you set up ADFS yourself then you need to update the rule.

Issuance Transform Rules

When Office 365 is configured to federate a domain (use ADFS for authentication of that domain and not Azure AD) then the following are the claims rules that exist out of the box need to be adjusted. This is to support the use of ms-ds-consistencyguid as the immutable ID.

ADFS Management UI > Trust Relationships > Relying Party Trusts

Select Microsoft Office 365 Identity Platform > click Edit Claim Rules

You get two or three rules listed here. You get three rules if you use -SupportMultipleDomain switch in Convert-MSOLDomainToFederated.
Rule 1:
Change objectGUID to ms-DS-ConsistencyGUID
Rule Was:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,objectGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);
New Value:
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/claims/UPN”, “http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID”), query = “samAccountName={0};userPrincipalName,ms-DS-ConsistencyGUID;{1}”, param = regexreplace(c.Value, “(?<domain>[^\\]+)\\(?<user>.+)”, “${user}”), param = c.Value);

Preparing for Device Writeback

If you do not have a 2012 R2 or later domain controller then you need to update the schema of your forest. Do this by getting a Windows Server 2012 R2 ISO image and mounting it as a drive. Copy the support/adprep folder from this image or DVD to a 64 bit domain member in the same site as the Schema Master. Then run adprep /forestprep from an admin cmd prompt when logged in as a Schema Admin. The domain member needs to be a 64 bit domain joined machine for adprep.exe to run.

Wait for the schema changes to replicate around the network.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Azure AD Global Admin and Enterprise Admin permissions for Azure and local AD forest respectively. The cmdlets for this are obtained by running the Azure AD Connect tool.


$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
Initialize-ADSyncDeviceWriteBack -AdConnectorAccount $accountName -DomainName contoso.com #[domain where devices will be created].

This will create the “Device Registration Services” node in the Configuration partition of your forest as shown:

image

To see this, open Active Directory Sites and Services and from the View menu select Show Services Node. Also in the domain partition you should now see an OU called RegisteredDevices. The AADSync account now has permissions to write objects to this container as well.

In Azure AD Connect, if you get the error “This feature is disabled because there is no eligible forest with appropriate permissions for device writeback” then you need to complete the steps in this section and click Previous in the AADConnect wizard to go back to the “Connect your directories” page and then you can click Next to return to the “Optional features” page. This time the Device Writeback option will not be greyed out.

Device Writeback needs a 2012 R2 or later AD FS server and WAP to make use of the device info in the Active Directory (for example, conditional access to resources based on the user and the device they are using). Once Device Writeback is prepared for with these cmdlets and the AADConnect Synchronization Options page is enabled for Device Writeback then the following will appear in Active Directory:

image

Not shown in the above, but adding the Display Name column in Active Directory Users and Computers tells you the device name. The registered owner and registered users of the device are available to view, but as they are SID values, they are not really readable.

If you have multiple forests, then you need add the SCP record for the tenant name in each separate forest. The above will do it for the forest AADConnect is installed in and the below script can be used to add the SCP to other forests:

$verifiedDomain = "contoso.com"  # Replace this with any of your verified domain names in Azure AD
$tenantID = "27f998bf-86f2-41bf-91ab-2d7ab011df35"  # Replace this with you tenant ID
$configNC = "CN=Configuration,DC=corp,DC=contoso,DC=com"  # Replace this with your AD configuration naming context
$de = New-Object System.DirectoryServices.DirectoryEntry
$de.Path = "LDAP://CN=Services," + $configNC
$deDRC = $de.Children.Add("CN=Device Registration Configuration", "container")
$deDRC.CommitChanges()
$deSCP = $deDRC.Children.Add("CN=62a0ff2e-97b9-4513-943f-0d221bd30080", "serviceConnectionPoint")
$deSCP.Properties["keywords"].Add("azureADName:" + $verifiedDomain)
$deSCP.Properties["keywords"].Add("azureADId:" + $tenantID)
$deSCP.CommitChanges()

Preparing for Group Writeback

Writing Office 365 “Modern Groups” back to Active Directory on-premises requires Exchange Server 2013 CU8 or later schema updates and servers installed. To create the OU and permissions required for Group Writeback you need to do the following.

Import the cmdlets needed to configure your Active Directory for writeback by running Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session. You need Domain Admin permissions for the domain in the local AD forest that you will write back groups to. The cmdlets for this are obtained by running the Azure AD Connect tool.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$cloudGroupOU = "OU=CloudGroups,DC=contoso,DC=com"
Initialize-ADSyncGroupWriteBack -AdConnectorAccount $accountName -GroupWriteBackContainerDN $cloudGroupOU

Once these cmdlets are run the AADSync account will have permissions to write objects to this OU. You can view the permissions in Active Directory Users and Computers for this OU if you enable Advanced mode in that program. There should be a permission entry for this account that is not inherited from the parent OU’s.

At the time of writing, the distribution list that is created on writeback from Azure AD will not appear in the Global Address List in Outlook etc. or allow on-premises mailboxes to send to these internal only cloud based groups. To add it to the address book you need to create a new subdomain, update public DNS and add send connectors to hybrid Exchange Server. This is all outlined in https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspx. This ensure’s that on-premises mailboxes can deliver to groups as internal senders and not require external senders enabled on the group. To add the group to the Global Address List you need to run Update-AddressList in Exchange Server. Once group writeback is prepared for using these cmdlets here and AADConnect has had it enabled during the Synchronization Options page, you should see the groups appearing in the selected OU as shown:

image

And you should find that on-premises users can send email to these groups as well.

Preparing for Password Writeback

The option for users to change their passwords in the cloud and have then written back to on-premises (with multifactor authentication and proof of right to change the password) is also available in Office 365 / Azure AD with the Premium Azure Active Directory or Enterprise Mobility Pack licence.

To enable password writeback for AADConnect you need to enable the Password Writeback option in AADConnect synchronization settings and then run the following three PowerShell cmdlets on the AADSync server:


Get-ADSyncConnector | fl name,AADPasswordResetConfiguration
Get-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD"
Set-ADSyncAADPasswordResetConfiguration -Connector "contoso.onmicrosoft.com - AAD" -Enable $true

The first of these cmdlets lists the ADSync connectors and the name and password reset state of the connector. You need the name of the AAD connector. The middle cmdlet tells you the state of password writeback on that connector and the last cmdlet enables it if needed. The name of the connector is required in these last two cmdlets.

To set the permissions on-premises for the passwords to be written back the following script is needed:

$passwordOU = "DC=contoso,DC=com" #[you can scope this down to a specific OU]
$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Reset Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":CA;`"Change Password`";user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;lockoutTime;user'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$passwordOU' /I:S /G '`"$accountName`":WP;pwdLastSet;user'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for Exchange Server Hybrid Writeback

Hybrid mode in Exchange Server requires the writing back on eight attributes from Azure AD to Active Directory. The list of attributes written back is found here. The following script will set these permissions for you in the OU you select (or as shown at the root of the domain). The DirSync tool used to do all this permissioning for you, but the AADSync tool does not. Therefore scripts such as this are required. This script sets lots of permissions on these eight attributes, but for clarify on running the script the output of the script is sent to Null. Remove the “| Out-Null” from the script to see the changes as they occur (the script also takes a lot longer to run).

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$HybridOU = "DC=contoso,DC=com"

#Object type: user
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;user'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchDelegateLinkList;user'"
Invoke-Expression $cmd | Out-Null

#Object type: iNetOrgPerson
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUCVoiceMailSettings;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchUserHoldPolicies;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchArchiveStatus;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchBlockedSendersHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchSafeRecipientsHash;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msDS-ExternalDirectoryObjectID;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;publicDelegates;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;msExchDelegateLinkList;iNetOrgPerson'"
Invoke-Expression $cmd | Out-Null

#Object type: group
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;group'"
Invoke-Expression $cmd | Out-Null

#Object type: contact
$cmd = "dsacls '$HybridOU' /I:S /G '`"$accountName`":WP;proxyAddresses;contact'"
Invoke-Expression $cmd | Out-Null

Finally you need to run the above once per domain.

Preparing for User Writeback

[This functionality is not in the current builds of AADConnect]

Currently in preview at the time of writing, you are able to make users in Azure Active Directory (cloud users as Office 365 would call them) and write them back to on-premises Active Directory. The users password is not written back and so needs changing before the user can login on-premises.

To prepare the on-premises Active Directory to writeback user objects you need to run this script. This is contained in AdSyncPrep.psm1 and that is installed as part of Azure AD Connect. Azure AD Connect will install Azure AD Sync, which is needed to do the writeback. To load the AdSyncPrep.psm1 module into PowerShell run Import-Module ‘C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1’ from an administrative PowerShell session.

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account usually in the form of AAD_number].
$cloudUserOU = "OU=CloudUsers,DC=contoso,DC=com"
Initialize-ADSyncUserWriteBack -AdConnectorAccount $accountName -UserWriteBackContainerDN $cloudUserOU

Once the next AADSync occurs you should see users in the OU used above that match the cloud users in Office 365 as shown:

image

Prepare for Password Hash Sync

This set of PowerShell ensures that the AADConnect account has the correct permissions to read password hashes from the Active Directory when they are changed, so that the service can sync them to the cloud. You need this permission whenever you enable Password Hash Sync (which could be in conjunction with another authentication method as well)

$DomainDN = "DC=contoso,DC=com" 
$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].

$cmd = "dsacls.exe '$DomainDN' /G '`"$accountName`":CA;`"Replicating Directory Changes`";'"
Invoke-Expression $cmd | Out-Null

$cmd = "dsacls.exe '$DomainDN' /G '`"$accountName`":CA;`"Replicating Directory Changes All`";'"
Invoke-Expression $cmd | Out-Null

Prepare for Windows 10 Registered Device Writeback Sync

Windows 10 devices that are joined to your domain can be written to Azure Active Directory as a registered device, and so conditional access rules on device ownership can be enforced. To do this you need to import the AdSyncPrep.psm1 module. This module supports the following two additional cmdlets to prepare your Active Directory for Windows 10 device sync:

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync
Initialize-ADSyncNGCKeysWriteBack

These cmdlets are run as follows:

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is often an account in the form of MSOL_number or AAD_number].
$azureAdCreds = Get-Credential #[Azure Active Directory administrator account]

CD "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep"
Import-Module .\AdSyncPrep.psm1
Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount $accountName -AzureADCredentials $azureAdCreds 
Initialize-ADSyncNGCKeysWriteBack -AdConnectorAccount $accountName 

To successfully run these cmdlets you need to have the latest version of the Microsoft Online PowerShell modules installed (the V1.1 versions, not the V2.0 preview). You can get these from https://www.powershellgallery.com/packages/MSOnline (which in turn needs MSOL Signin Assistant from https://www.microsoft.com/en-us/download/details.aspx?id=41950 and the Windows Management Framework v5 from https://www.microsoft.com/en-us/download/details.aspx?id=50395). If you get errors in the above, make sure you have the correct version, download from above and try the scripts again.

Once complete, open Active Directory Sites and Services and from the View menu Show Services Node. Then you should see the GUID of your domain under the Device Registration Configuration container.

image

Managing Office 365 Groups With Remote PowerShell

Posted on 2 CommentsPosted in Azure, cloud, exchange, exchange online, groups, IAmMEC, mcm, mcsm, MVP, Office 365, owa, powershell

Announced during Microsoft Ignite 2015, there are now PowerShell administration cmdlets available for the administration of the Groups feature in Office 365.

The cmdlets are all based around “UnifedGroups”, for example Get-UnifiedGroups.

Create a Group

Use New-UnifiedGroup to do this. An example would be New-UnifiedGroup -DisplayName “Sales” -Alias sales –EmailAddress sales@contoso.com

The use of the EmailAddress parameter is useful as it allows you to set a group that is not given an email address based on your default domain, but from one of the other domains in your Office 365 tenant.

Modify a Groups Settings

Use Set-UnifiedGroup to change settings such as the ability to receive emails from outside the tenant (RequireSenderAuthenticationEnabled would be $false), limit email from a whitelist (AcceptMessagesOnlyFromSendersOrMembers) and other Exchange distribution list settings such as hidden from address lists, mail tips and the like. AutoSubscribeNewMembers can be used to tell the group to email all new messages to all new members, PrimarySmtpAddress to change the email address that the group sends from.

Remove a Group

This is the new Remove-UnifiedGroup cmdlet.

Add Members to a Group

This cmdlet is Add-UnifiedGroupLinks. For example Add-UnifiedGroupLinks sales -LinkType members -Links brian,nicolas will add the two names members to the group. The LinkType value can be members as shown, but also “owners” and “subscribers” to add group administrators (owners) or just those who receive email sent to the group but not access to the groups content. To change members to owners you do not need to remove the members, just run something like Add-UnifiedGroupLinks sales –LinkType owners -Links brian,nicolas

You can also pipe in a user list from, for example a CSV file, to populate a group. This would read: Add-UnifiedGroupLinks sales -LinkType members -Links $users where $users = Get-Content username.csv would be run before it to populate the $users variable. The source of the variable can be anything done in PowerShell.

Remove Members from a Group

For this use Remove-UnifiedGroupLinks and mention the group name, the LinkType (member, owner or subscriber) and the user or users to remove.

To Disable Group Creation in OWA

Set-OWAMailboxPolicy is used to create a policy that is not allowed to create Groups and then users have that policy applied to them. For example Set-OWAMailboxPolicy “Students” –GroupCreationEnabled $false followed by Set-CASMailbox mary –OWAMailboxPolicy Students to stop the user “mary” creating groups. After the policy is assigned and propagates around the Office 365 service, the user can join and leave groups, but not create them.

Control Group Naming

This feature allows you to control the group name or block words from being used. This is easier to set in the Distribution Groups settings in Exchange Control Panel rather than via PowerShell. To do this EAC use Recipients > Groups and click the ellipses icon (…) and select Configure Group Naming Policy. This is the same policy for distribution groups. You can add static text to the start or end of name, as well as dynamic text such as region.

Admins creating groups are not subject to this policy, but unlike DL’s if they create groups in PowerShell the policy is also not applied and so the -IgnoreNamingPolicy switch is not required.

How To Change Your Office 365 App Password

Posted on 11 CommentsPosted in ADFS, app password, Azure, IAmMEC, MFA, multi-factor auth, Multi-Factor Authentication, Office 365

If you are enabled for Multi-Factor Authentication (MFA) in Office 365 then you will need an App Password for some applications that do not support MFA. The user interface for creating a new App Password is well hidden in Office 365 (its not on the Password page for example).

Post updated in 2016 to take account of the changes in the Office 365 portal.

Post updated in 2017 to show that Microsoft have added a short URL to reach this page. You can skip the below and go to http://aka.ms/CreateAppPassword

Post updated in Aug 2018 to take consideration of the new SSPR and MFA converged UI. If you have this turned on then App Password changes are as described at https://docs.microsoft.com/en-gb/azure/active-directory/user-help/security-info-app-passwords. If you have not enabled this yet (late 2018 it will probably become the default regardless) then the above link will work for you.

Here is how to find it now:

  1. The user logs into Office 365 portal (http://portal.office.com) and clicks their photo to the top-right of the page
  2. Click My Account
  3. Click Security and Privacy menu to the left or the Manage Security and Privacy link on the main area of the page
  4. Click Additional Security Verification
  5. Click Create and manage app passwords
  6. This takes you to https://account.activedirectory.windowsazure.com/AppPasswords.aspx. You can (and therefore should) bookmark this page now so you don’t need these instructions again!
  7. Create yourself an additional app password and give it a description.
  8. Use the new app password in the program that you need to login to.

Here is how to find it (in the old Office 365 portal)

  1. The user logs into Office 365 portal (http://portal.office.com) and clicks the cog icon to the top-right of the page
  2. Click Office 365 Settings
  3. Scroll down past Password and choose Additional Security Verification
  4. Click Update my phone numbers used for account security
  5. Answer your phone to approve your request to go to this page (you might not be asked for this)
  6. Click “app passwords” on the top menu. This takes you to https://account.activedirectory.windowsazure.com/AppPasswords.aspx. You can (and therefore should) bookmark this page now so you don’t need these instructions again!
  7. Create yourself an additional app password and give it a description.
  8. Use the new app password in the program that you need to login to.

Exchange OWA and Multi-Factor Authentication

Posted on 21 CommentsPosted in 2010, 2013, Azure, exchange, IAmMEC, MFA, MVP, owa, smartphone

Multi-factor authentication (MFA), that is the need to have a username, password and something else to pass authentication is possible with on-premises servers using a service from Windows Azure and the Multi-Factor Authentication Server (an on-premises piece of software).

The Multi-Factor Authentication Server intercepts login request to OWA, if the request is valid (that is the username and password work) then the mobile phone of the user is called or texted (or an app starts automatically on the phone) and the user validates their login. This is typically done by pressing # (if a phone call) or clicking Verify in the app, but can require the entry of a PIN as well. Note that when the MFA server intercepts the login request in OWA, there is no user interface in OWA to tell you what is happening. This can result in user disconnect and stops the use of two-way MFA (receive number by text, type number into web application type scenario). Therefore to that end, MFA directly on the OWA application is not supported by the Microsoft Exchange team. Steps for setting up ADFS for Exchange Server 2013 SP1 or later are at https://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx. Once this is in place, you need to enable MFA for ADFS rather than MFA for OWA. I have covered this in a separate post at http://c7solutions.com/2016/04/installing-azure-multi-factor-authentication-and-adfs.

To configure Multi-Factor Authentication Server for OWA (unsupported) you need to complete the following steps:

Some of these steps are the same regardless of which service you are adding MFA to and some slightly different. I wrote a blog on MFA and VPN at http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication and this contains the general setup steps and so these are not repeated here. Just what you need to do differently

Step 1

See http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication

Step 2: Install MFA Server on-premises

This is covered in http://c7solutions.com/2015/01/windows-rras-vpn-and-multi-factor-authentication, but the difference with OWA is that it needs to be installed on the Exchange CAS server where the authentication takes place.

Ensure you have .NET 3.5 installed via Server Manager > Features. This will install the .NET 2.0 feature that is required by MFA server. If the installation of the download fails, this is the most likely reason for the failure, so install .NET 3.5 and then try the MFA Server install again.

The install of the MFA server does not take very long. After a few minutes the install will complete and then you need to run the Multi-Factor Authentication Server admin tools. These are on the Start Screen in More Apps or the Start Menu. Note that it will start the software itself if given time:

image

image

Do not skip the wizard, but click Next. You will be asked to activate the server. Activating the server is linking it to your Azure MFA instance. The email address and password you need are obtained from the Azure multi-factor auth provider that was configured in Step 1. Click the Generate Activation Credentials on the Downloads page of the Azure MFA provider auth management page.

image

The credentials are valid for ten minutes, so your will differ from mine. Enter them into the MFA Server configuration wizard and click Next.

MFA Server will attempt to reach Azure over TCP 443.

Select the group of servers that the configuration should replicate around. For example, if you where installing this software on each Exchange CAS server, then you might enter “Exchange Servers” as the group name in the first install and then select it during the install on the remaining servers. This config will be shared amongst all servers with the same group name. If you already have a config set up with users in it and set up a new group here, then it will be different settings for the users. For example you might have a phone call to authenticate a VPN connection but use the app for OWA logins. This would require two configs and different groups of servers. If you want the same settings for all users in the entire company, then one group (the default group) should be configured.

image

Next choose if you want to replicate your settings. If you have more than one MFA Server instance in the same group select yes.

Then choose what you want to authenticate. Here I have chosen OWA:

image

Then I need to choose the type of authentication I have in place. In my OWA installation I am using the default of Forms Based Authentication, but if you select Forms-based authentication here, the example URL for forms based authentication shown on the next page is from Exchange Server 2003 (not 2007 or later). Therefore I select HTTP authentication

Next I need to provide the URL to OWA. I can get this by browsing the OWA site over https. The MFA install will also use HTTPS, so you will need a certificate and have this trusted by a third party if you want to support user managed devices. Users managing their own MFA settings (such as telephone numbers and form of authentication) reduces the support requirement. That needs the User Portal, the SDK and the Mobile App webservice installed as well. These are outside the scope of this blog. For here I am going to use https://servername/owa.

image

Finish the installation at this time and wait for the admin application to appear.

Step 3: Configure Users for MFA

Here we need to import the users who will be authenticated with MFA. Select the Users area and click Import from Active Directory. Browse the settings to imports group members, or OUs or a search to add your user account. Once you have it working for yourself, add others. Users not listed here will not see any change in their authentication method.

Ensure that your test user has a mobile number imported from the Active Directory. If not add one, choosing the correct country code as well. The default authentication for the user is that they will get a phone call to this number and need to press # before they can be logged in. Ensure that the user is set to Enabled as well in the users area of the management program.

Step 4: Configure OWA for MFA (additional steps)

On the IIS Authentication node you can adjust the default configuration for HTTP. Here you need to set Require Multi-Factor Authentication user match. This ensures that each auth attempt is matched to a user in the users list. If the user exists and is enabled, then do MFA for them. If disabled, then the setting for Succeed Authentication on the advanced tab comes into play. If the user is not listed, authentication passes through without MFA.

image

Change to the Native Module tab and select OWA under Default Web Site only. Do not set authentication on the Backend Web Site. Also enable the native module on ECP on the Default Web Site as well:

image

Then I can attempt a login to OWA or ECP. Once I successfully authenticate my phone rings and I am prompted to press #. Once I press # I am allowed into Exchange!

Windows RRAS VPN and Multi Factor Authentication

Posted on 6 CommentsPosted in Azure, MFA, multi-factor auth, password, phone factor, policy, pptp, remote desktop, rras, sdk, vpn

This blog post covers the steps to add Multi Factor Authentication (MFA) to Windows RRAS server. Once this is enabled, and you sign in with a user enabled for MFA in Azure Multi-Factor Authentication Server (an on-premises server) you are required to answer your phone before you can connect over the VPN. That is, you connect to the VPN endpoint, enter your username and password and if they are correct, then confirm that you want to authenticate by answering your phone. If you are not connecting over VPN and someone else is and using your credentials, unless they also have your phone they are not going to succeed! And all this for less than a £1 per user per month!

This configuration requires the following components set up:

  • Multi Factor Authentication set up in Azure
  • Azure Multi-Factor Authentication Server installed on-premises
  • Some users configured in Azure Multi-Factor Authentication Server
  • RRAS VPN server configured to use RADIUS for authentication, with the MFA server being the RADIUS endpoint

Step 1: MFA setup in Microsoft Azure

To do this you need an Azure subscription and DirSync configured to populate the Azure Active Directory with users. If you already have Office 365 with DirSync then you have this configuration already and you can login to Azure using the Azure AD link from the Office 365 management portal.

Once in Azure select “Active Directory” from the portal and click “Multi-Factor Auth Providers” from the menu at the top. You will probably not have any providers listed here, but if you do already (for example you are already using MFA for Office 365 or AD FS) then you can use the existing provider. To add a provider click Add, select “Multi-Factor Auth Provider” and “Quick Create” as shown:

image

Provide a name and then choose a usage model. Usage models are per user or per authentication. Per User works when a single user will authenticate more than 10 times a month. When users would only use MFA occasionally you can buy the service by the authentication request. For example if you had 200 VPN users who connected each day, you would choose Per User. But if you had 200 VPN users, who only dialled in once a month (i.e. a total of 200 authentications) then you would be better off buying the Per Authentication model as you would pay for 20 batches of authentications (each batch allows 10 authentications regardless of the user). You cannot change the authentication model without removing the auth provider and making a new one.

Finally, link the provider to your directory.

Select your auth provider once it is created and click Manage at the bottom of the portal:

image

This opens a new tab in the browser and takes you to the Azure Multi-Factor Authentication management pages.

Whilst here, as there is actually not a lot to do here, take a look at Configure to see what settings you can change. Maybe enter your email address for the fraud alert notifications, but leave everything else as is for now.

Back on the home page of the Azure Multi-Factor Authentication web site, click Downloads.

Step 2: Installing Multi-Factor Authentication Server

From the Downloads page find the small download link (above the Generate Activation Credentials button) and download the software to a Windows Server that is joined to your domain.

On the said server install .NET 2.0 and IIS with the default settings. Ensure that you have a digital certificate installed, as the web site the the users will go to for provisioning and managing their device is available over SSL. Mobile phones can use the app to validate connections as well, and that will be the subject of a different blog post, but you need a trusted cert that is valid and has a subject name such as mfa.domain.com (where domain.com is your domain) and so a 3rd party cert is required. In this blog I have used my wildcard cert from DigiCert.

Run the Multi-Factor Authentication Server installer and proceed through the steps. Use the wizard to configure the server and select VPN. During the installation you will also need to authenticate the Multi-Factor Authentication Server to Azure. This requires a set of credentials that are valid for ten minutes at a time, and generated from the Generate Activation Credentials button in the management web page at Azure. So don’t click this button until the Multi-Factor Authentication Server requires this info.

For this blog I am going to protect my VPN with Azure MFA. Therefore during the configuration wizard I select just the VPN option:

image

As you proceed through the wizard you will be asked about the RADIUS client configuration needed for your VPN provider. In here enter the IP address of your RRAS box and a password that you have made up for the occasion. You will need this password, or shared secret, when configuring the RRAS server later.

image

Finish the installation of Multi-Factor Authentication Server.

Once complete, open the Multi-Factor Authentication Server management program and select RADIUS Authentication. Ensure Enable RADIUS authentication is selected as this will allow this server to provide authentication on behalf of the RADIUS client and therefore insert requests for MFA via the users phone into the authentication flow.

image

Double click the IP address of your VPN server and select “Require User Match”

Step 3: Configure Users for MFA

Click the Users icon in Multi-Factor Authentication Server and click Import from Active Directory. Set the filtering to add just the users you want to enable MFA for. A user who dials in who is not listed here will not be blocked from authentication to the VPN.

image

A user will have a yellow warning icon next to it if it is disabled. For disabled users you can either allow authentication to pass through the MFA server without requiring the user to have the second factor of authentication working. This can be set on the users properties, and the Advanced tab by selecting Succeed Authentication for “When user is disabled”. The enabled check box is on the general tab.

If a user is enabled here then they will need to either complete the MFA authentication process. The exact process the user needs to do to pass the authentication process always starts with getting their username and password correct. After that they can do one of the following:

  • Press # when the call comes through to their phone
  • Reply to a text message – texts go to a US number, so this might cost the user international rates!
  • Press the Verify button on the MFA app on their phone
  • Optionally add a PIN number to any of the above – for example, when the MFA call comes through to enter your PIN and then press # rather than just #.

Each user can have different settings. When you import users from the Active Directory it reads (by default) their mobile number from the Active Directory as the primary number to authenticate against. You can set backup numbers if required. If a user has a mobile number they are enabled by default. When importing you can set which MFA method the user will use, and you can install the MFA portal so the user can change their own settings if you want (outside the scope of this blog).

By now you have Azure MFA configured, the MFA server installed on-premises (it will need port 443 access to Azure to complete the authentication) and users set up in the MFA server. The MFA server is also configured to act as a RADIUS endpoint for your VPN service. If you install more than one MFA server for load balancing and HA, ensure that each MFA server is selected on the Multi-Factor Auth Servers tab on the RADIUS settings – this starts the MFA RADIUS service on each selected machine.

Before you configure VPN, final step here is to test the user. From the Users area on the MFA server select a user and click Test. Authenticate as the user, username and password required for this test, and then press # after answering the phone. Try out the SMS or text message form factor for authentication as well. To support the mobile app you need to install the users portal, the SDK and the mobile app web service – so thats for a different blog post.

Step 4: Configure RRAS VPN to Use Multi-Factor Authentication

Finally, change to your RRAS server. Before going any further, ensure that RRAS is working before MFA is enabled – you don’t want to troubleshoot MFA only to find it was RRAS not working in the first place! The RRAS server’s IP address must match the IP address listed under the RADIUS configuration in the MFA server.

Right-click the RRAS server name in the Routing and Remote Access console. If you are setting up MFA for another type of VPN server then any that supports RADIUS will do. In the server properties, select the Security tab and change the Authentication provider to RADIUS Authentication (it was probably Windows Authentication).

image

Click Configure to the right of this drop-down and click Add:

image

Enter the IP address of your MFA server, repeating the Add process if you have more than one MFA server configured. Enter the shared secret that you used when setting up the MFA server and ensure that the timeout is set to 60 seconds. This is an important setting. When the user connects to the VPN server, the timeout needs to exceed the time it will take for the users phone to ring, listen the the greeting, enter the PIN (optionally) and press #. One minute should be enough to do this. After one minute the RRAS VPN server will automatically fail authentication, so the user has one minute to complete the second factor authentication on their phone.

You should now be able to dial into your VPN and authenticate with your username and password. Once you succeed with this, the MFA authentication starts and the call will arrive on your phone:

image

You can get the graphic as a vCard from http://1drv.ms/1xXCA01. Download this vCard, save it to your contacts and when you sync your contacts to your phone, your phone will tell you the Microsoft Phone Auth service is calling. You could change the name and graphic to suit, just make sure the number matches the CallerID setting in Azure MFA.

Whilst you are waiting for the call the arrive, and before you accept the auth request, the VPN client appears to pause:

image

Once you complete the auth, the VPN session starts up. If the call and time to answer exceeds 60 seconds, then consider increasing the RADIUS timeout on the VPN server.

Finally, and this will be a different blog post, you might want to offer the user a portal they can go to to change their settings such as updating phone number and changing mode of authentication etc. But this is off topic for this post. Later posts will cover using this MFA server integrated with AD FS and OWA as well.

Creating Mailboxes in Office 365 When Using DirSync

Posted on 18 CommentsPosted in 2008 R2, 2012, 2012 R2, 2013, Azure, cloud, dirsync, exchange, exchange online, Office 365

This blog post describes the process to create a new user in Active Directory on-premises when email is held in Office 365 and DirSync is in use. With DirSync in use the editable copy of the user object is on-premises and most attributes cannot be modified in the cloud.

Creating the User

  1. Open Active Directory Users and Computers on a Windows 2008 R2 or later server. Ensure that Advanced Features is enabled (View > Advanced Features)
    • Note that if you do not have 2008 R2 or later then use ADSI Edit to make the changes mentioned below that are made on the Attribute Editor tab in Active Directory Users and Computers 2008 R2 or later.
  2. Create an Active Directory user as you normally would. Do not complete any Exchange server properties if you are requested to do so. Completing Exchange on-premises will make a mailbox on premises that will then need to be migrated to Exchange Online. This document describes creating the mailbox online.
  3. Ensure that the user’s email address on the General tab of the AD properties is correct.
  4. Ensure that the users login name on the Account tab is as follows:
    1. User Logon Name: The first part of their email address
    2. The Domain name drop-down: The second part of their email address (not the AD domain name if they are different)
    3. User Logon Name (Pre Windows 2000): DOMAIN as provided and use the first part of the email address (i.e. first.last etc). If first part of email is too long enter as much as you can and ensure it is unique within domain)

Setting the Email Address Properties

  1. On the Attribute Editor tab ensure that Filter > Show only attributes that have values is not selected. Then find and enter the following information:
    1. proxyAddresses: SMTP:primary.email@domain for this user – SMTP needs to be in capitals. Then add additional email addresses as required, but these start with smtp: in lower case.
    2. targetAddress: SMTP:first_part_of_email@tennantname.onmicrosoft.com
    3. Note that both these addresses need to be unique within your directory – Attribute Editor will not check them for uniqueness but they will fail to replicate to Azure with DirSync if they are not unique.
  2. Click OK and close the account creation dialog.
  3. Within three hours this object will sync to Windows Azure Active Directory.
    1. This can be speeded up by logging into the DirSync server and starting PowerShell
    2. Type “Import-Module DirSync” in PowerShell
    3. Type “Start-OnlineCoexistenceSync” in PowerShell – DirSync will replicate now rather than waiting up to three hours.
  4. Check that the DirSync process was successful – if you have entered values that are not unique then DirSync will fail to replicate them and you will need to fix them on-premises and replicate them again.
  5. Licence the user in Office 365 by logging into https://portal.office.com and granting a licence to this user that contains an Exchange Online licence. The mailbox will be created automatically shortly after this.

Additional Attributes

The following are a list of attributes to change in ADSI Edit or the Attribute Editor tab to modify other attributes as required:

Important Point

The above attributes are not the full and exclusive list of attributes and values that you need to set. For example, in Jan 2018 Microsoft published support for delegate access permissions across forest in a hybrid deployment – this uses values that are mentioned in the full list link in the paragraph above but are not set here.

This document should only be used as a reference and not to create or maintain mailboxes for AD accounts that are synced to the cloud – for that you need to have an Exchange Server as that is the only supported way to maintain your Exchange Online attributes. At Microsoft Ignite in 2017, it was announced that cloud management for synced accounts is coming – until that time you are best advised to have the Exchange Server for its admin tools only installed on-premises as well.

An “Inexpensive” Exchange Lab In Azure

Posted on Leave a commentPosted in 2010, 2013, Azure, cloud, DNS, exchange, exchange online, hyper-v, IAmMEC, Office 365, vhd, vm, vpn

This blog post centres around two scripts that can be used to quickly provision an Exchange Server lab in Azure and then to remove it again. The reason why the blog post is titled “inexpensive” is that Azure charges compute hours even if the virtual machines are shut down. Therefore to make my Exchange lab cheaper to operate and to not charge me when the lab is not being used, I took my already provisioned VHD files and created a few scripts to create the virtual machines and cloud service and then to remove it again if needed.

Before you start using these scripts, you need to have already uploaded or created your own VHD’s in Azure and designed your lab as you need. These scripts will then take a CSV file with the relevant values in them and create a VM for each VHD in the correct subnet (that you have also created in Azure) and always in the correct order – thus ensuring they always get the same IP address from your virtual network (UPDATE: 14 March 2014 – Thanks to Bhargav, this script now reserves the IPs as well as this is a newish feature in Azure). Without reserving an IP, when you boot your domain controller first in each subnet it will always get the fourth available IP address. This IP is the DNS IP address in Azure and then each of the other machines are created and booted in the order of your choosing and so get the subsequent IP’s. Azure never used to guarantee the IP but updates in Feb 2014 now allow this with the latest Azure PowerShell cmdlets. This way we can ensure the private IP is always the same and machine dependancies such as domain controllers running first are adhered to.

These scripts are created in PowerShell and call the Windows Azure PowerShell cmdlets. You need to install the Azure cmdlets on your computer and these scripts rely on features found in version 0.7.3.1 or later. You can install the cmdlets from http://www.windowsazure.com/en-us/documentation/articles/install-configure-powershell/

Build-AzureExchangeLab.ps1

# Retrieve with Get-AzureSubscription 
$subscriptionName = "Visual Studio Premium with MSDN"

Import-AzurePublishSettingsFile 'downloaded.publishsettings.file.got.with.Get-AzurePublishSettingsFile'

# Select the subscription to work on if you have more than one subscription
Select-AzureSubscription -SubscriptionName $subscriptionName

# Name of Virtual Network to add VM's to
$VMNetName = "MCMHybrid"

# CSV File with following columns (BringOnline,VMName,StorageAccount,VMOSDiskName,VMInstanceSize,SubnetName,IPAddress,Location,AffinityGroup,WaitForBoot,PublicRDPPort)
)
$CSVFile = Import-CSV 'path\filename.csv'

# Loop to build lab here. Ultimately get values from CSV file
foreach ($VMItem in $CSVFile) {

    # Retrieve with Get-AzureStorageAccount  
    $StorageAccount = $VMItem.StorageAccount

    # Specify the storage account location containing the VHDs 
    Set-AzureSubscription -SubscriptionName $subscriptionName  -CurrentStorageAccount $StorageAccount
  
    # Not Used $location = $VMItem.Location     # Retrieve with Get-AzureLocation

    # Specify the subnet to use. Retreive with Get-AzureVNetSite | FL Subnets
    $subnetName = $VMItem.SubnetName

    $AffinityGroup = $VMItem.AffinityGroup      # From Get-AzureAffinityGroup (for association with a private network you have already created). 

    $VMName = $VMItem.VMName
    $VMOSDiskName = $VMItem.VMOSDiskName        # From Get-AzureDisk
    $VMInstanceSize = $VMItem.VMInstanceSize    # ExtraSmall, Small, Medium, Large, ExtraLarge 
    $CloudServiceName = $VMName
    $IPAddress = $VMItem.IPAddress              # Reserves a specific IP for the VM
    if ($VMItem.BringOnline -eq "Yes") {
        Write-Host "Creating VM: " $VMName
        $NewVM = New-AzureVMConfig -Name $VMName -DiskName $VMOSDiskName -InstanceSize $VMInstanceSize | Add-AzureEndpoint -Name 'Remote Desktop' -LocalPort 3389 -PublicPort $VMItem.PublicRDPPort -Protocol tcp | Add-AzureEndpoint -Protocol tcp -LocalPort 25 -PublicPort 25 -Name 'SMTP' | Add-AzureEndpoint -Protocol tcp -LocalPort 443 -PublicPort 443 -Name 'SSL' | Add-AzureEndpoint -Protocol tcp -LocalPort 80 -PublicPort 80 -Name 'HTTP' | Set-AzureSubnet –SubnetNames $subnetName | Set-AzureStaticVNetIP –IPAddress $IPAddress        
        # Creates new VM and waits for it to boot if required
        if ($VMItem.WaitForBoot -eq "Yes") {New-AzureVM -ServiceName $CloudServiceName -AffinityGroup $AffinityGroup -VMs $NewVM -VNetName $VMNetName -WaitForBoot}
            else {New-AzureVM -ServiceName $CloudServiceName -AffinityGroup $AffinityGroup -VMs $NewVM -VNetName $VMNetName }
    }
}

Remove-AzureExchangeLab.ps1

# Retrieve with Get-AzureSubscription 
$subscriptionName = "Visual Studio Premium with MSDN"

Import-AzurePublishSettingsFile 'downloaded.publishsettings.file.got.with.Get-AzurePublishSettingsFile'

# Select the subscription to work on if you have more than one subscription
Select-AzureSubscription -SubscriptionName $subscriptionName

# CSV File with following columns (BringOnline,VMName,StorageAccount,VMOSDiskName,VMInstanceSize,SubnetName,IPAddress,Location,AffinityGroup,WaitForBoot,PublicRDPPort)
$CSVFile = Import-CSV 'path\filename.csv'

# Loop to build lab here. Ultimately get values from CSV file
foreach ($VMItem in $CSVFile) {

    # Stop VM
    Stop-AzureVM -Name $VMItem.VMName -ServiceName $VMItem.VMName -Force

    # Remove VM but leave VHDs behind
    Remove-AzureVM -ServiceName $VMItem.VMName -Name $VMItem.VMName 

    # Remove Cloud Service
    Remove-AzureService $VMItem.VMName -Force
}

CSV File Format

The CSV file has a row per virtual machine, listed in order that the machine is booted:

BringOnline,VMName,StorageAccount,VMOSDiskName,VMInstanceSize,SubnetName,IPAddress,Location,AffinityGroup,WaitForBoot,PublicRDPPort
Yes,mh-oxf-dc1,portalvhdsjv47jtq9qdrmb,mh-oxf-mbx2-mh-oxf-mbx2-0-201312301745030496,Small,Oxford,10.0.0.4,West Europe,C7Solutions-AG,Yes,3389
etc,…

The columns are as follows:

  • BringOnline: Yes or No
  • VMName: This name is used for the VM and the Cloud Service. It must be unique within Azure. An example might be EX-LAB-01 (if that is unique that is)
  • StorageAccount: The name of the storage account that the VHD is stored in. This might be one you created yourself or one made by Azure with a name containing random letters. For example portalvhdshr4djwe9dwcb5 would be what this value might look like. Use Get-AzureStorageAccount to find this value.
  • VMOSDiskName: This is the disk name (not the file name) and is retrieved with Get-AzureDisk
  • VMInstanceSize: ExtraSmall, Small, Medium, Large or ExtraLarge
  • SubnetName: Get with Get-AzureVNetSite | FL Subnets
  • IPAddress: Sets a specific IP address for the VM. VM will always get this IP when it boots and other VM’s will not take it if the happen to boot before it
  • Location: Retrieve with Get-AzureLocation. This value is not used in the script as I use Affinity Groups and subnets instead.
  • AffinityGroup: From Get-AzureAffinityGroup (for association with a private network you have already created).
  • WaitForBoot: Yes or No. This will wait for the VM to come online (and thus get an IP correctly provisioned in order) or ensure things like the domain controller is running first.
  • PublicRDPPort: Set to 3389 unless you want to use a different port. For simplicity, the script sets ports 443, 80 and 25 as open on the IP addresses of the VM

Creating an Azure VPN with a Draytek Router

Posted on 10 CommentsPosted in Azure, cloud, draytek, exchange, firewall, ipsec, vpn

The Microsoft Azure cloud operating system can be connected to your network by way of a virtual private network or VPN. Azure lists some supported devices and provides configuration scripts for them, but does not include the Draytek range of devices. Draytek devices are common in the small business market and for techy home users. This blog post will show how to configure a site to site VPN between your network and your Azure tenant using a Draytek 2920 router. Other Draytek routers will work as well, just the screenshots and instructions here are from that model of router.

Collecting required information

Before you start you need the following information to hand:

  • The IP subnets of your network. For the purposes of this blog these are 192.168.5.0/24 and 192.168.6.0/24
  • The IP subnet that you wish to use in Azure. This needs to be different from the subnet(s) on your LAN. For the purpose of this blog this will be 192.168.4.0/24.

Configuring Azure Networks

To configure your VPN login to your Azure tenant at https://manage.windowsazure.com/ and from the services area on the left click Networks near the bottom. Add a new network by clicking Create a virtual network or from the bottom toolbar clicking + New and from the options select Custom Create. Note that Quick Create will not create a valid solution as it will note create a VPN gateway.

Enter the name of the VPN network and enter a name for the affinity group that you need to create. You will place virtual machines into this affinity group so that they get an IP address valid for this network. I’m based in the UK, so I choose West Europe (i.e. Dublin) as the datacentre to use.

VPN001

Click the right-hand arrow at the bottom of the screen and check Site to site VPN. You only need to add a DNS name and IP address (to an existing DNS server) on your LAN if your virtual machines need to use this DNS server to resolve on-premises resources. I will use Azure to do my name resolution, so will not enter them here.

VPN002

Click the right-hand arrow at the bottom of the screen and enter a name for your LAN and your external IP address (not shown here). This needs to be a static IP address that is not NAT’ed, so in my case this will be the external IP address of the Draytek router. Also enter the address space(s) for your LAN.

VPN003

Click the right-hand arrow at the bottom of the screen to go to page 4 of the wizard and select an address space that does not conflict with your LAN address spaces entered on the previous screen. In the picture below I have configured 192.168.4.0 as the subnet with a /24 CIDR range. You can edit the values provided if they do not suit. For the subnets within this network, you need one or more subnets for the address space. My final aim for the Azure tenant is to host a multisite Exchange Server lab, so I will create four subnets within the 192.168.4.0/24 address space. The first address space is going to be reserved for routing purposes back to my LAN. The routing subnet is configured by clicking the add gateway subnet button.

VPN004

Click the tick mark and wait for the network to be created. Once created click the network name and then Dashboard.

VPN005

You will see that the gateway is not created. To start the VPN gateway at Azure click the Create Gateway button on the lower black toolbar. Choose Static Routing and confirm the choice. In about 15 minutes time the status of the gateway will go blue and the VPN grey.

VPN006

We can now move onto configuring the router on your LAN as Azure is now waiting for the connection to take place.

Configuring a Draytek Router to Connect to Azure

On the VPN page in Azure you will see the status of the connection showing the amount of data that has crossed the connection to date and the IP address that you need to connect your VPN tunnel to. Make a note of this IP address (redacted in the above picture) and also make a note of the Shared Key, this you can get from the Manged Key button on the toolbar. Copy this to your clipboard and navigate to your Draytek admin page.

VPN007

Ensure that your router provides service for IPSec VPN’s and that this type of traffic is not being passed through the router to another device. This is available from VPN and Remote Access > Remote Access Control in the Draytek web admin pages.

DRAY001

Change to VPN and Remote Access > LAN to LAN and click an available LAN to LAN profile that is not being used. In section 1 give the profile a suitable name and enable it, disable Netbios naming packets from crossing the VPN and allow multicast if you will need it. Set the Call Direction to Dial-Out and check the Always on option if you require the connection to be up all the time. Scheduled connections are also possible.

DRAY002

Under Dial-Out Settings (section 2) ensure IPSec Tunnel is selected and the Server IP/Host Name for VPN matches the Gateway IP Address provided on the Azure management page. Under IKE Authentication ensure Pre-Shared Key is selected. Click the IKE Pre-Shared Key button and paste the pre-shared key from Azure.

DRAY003

Under IPSec Security Method select High (ESP) and ensure AES with Authentication is selected. Azure requires AES encryption. The Advanced options do not need changing as they are valid for Azure already.

DRAY004

Scroll down to section 5 (sections 3 and 4 do not need completing) and enter the network address space in use at Azure as the value for Remote Network IP and ensure the Remote Network Mask value is correct. This ensures that connections to this subnet are routed down this VPN tunnel. If you have multiple address spaces created at Azure then click the More button and add the rest of the Azure networks (not the individual subnets within the address space) if you added additional address spaces.

DRAY005

Save the VPN profile and navigate to VPN and Remote Access > Connection Management. In about 10 seconds you will see this page refresh and you should see the connection to Azure has been made.

DRAY006

Back on the Azure management console the VPN at the LAN side should be green and the Data In and Data Out values increasing. At the time of writing, an Azure VPN costs £1.44 per day and this does not include any network traffic across the link.

DRAY007

Creating Azure Virtual Machines on Your VPN

Ensure that your link is up by pinging the VPN endpoint at Azure. This will be the second IP address on the gateway subnet that was created earlier. In my example this is 192.168.4.197.

DRAY008

Virtual machines in Azure will get an IP address from your VPN and will be directly reachable to and from your LAN if they are associated with the VPN network created when the VPN was created. To do this either create a virtual machine from the gallery option (not Quick Create) to make a new virtual machine from a template or one of your existing unused VHDs or images and set the region/affinity group to the VPN network.

VM001

Note that you cannot change the network that an existing machine is associated with – you need to delete the virtual machine (but without deleting the disks) and also delete the associated cloud service. Then you can make the VM again and choose My Disks from the gallery and select the VPN as the Region/Affinity Group/Virtual Network value.

VM002

That is it. You virtual machines will come online and be provisioned and get an IP address on your virtual network. To see the IP address click the virtual machine and view the dashboard. Note that shutting down the virtual machine will release the IP and you cannot assign static IP’s in Azure or the machine will not be reachable – all connectivity to Azure machines is via resolved names.