Home Lab Secrets: Building the Killer Home Lab Part 6 (Securely Publishing Exchange Server 2016)(New Azure Portal)


In Part 5 of this series we deployed a Exchange 2016 Server within our lab. In Part 6 we will securely publish our Exchange Services using Microsoft Active Directory Federation Services (ADFS) and Web Application Proxy (WAP).  For our lab we will deploy 1 On-Premise ADFS Server and 1 On-Premise WAP Server.   In part 5 of our series we deployed 1 Exchange 2016 Server within Azure to serve as our Edge Server which handles our mail flow over Port 25/TCP and another Exchange 2016 Server On-Premise to serve as our Mailbox Server which handles all of our Web traffic over Port 443/TCP for the following Services:

  • OWA
  • MAPI over HTTP
  • ActiveSync

Although this allows our users to connect, it is not the most secure method for accessing these services.  Deploying ADFS and WAP will also allow us to provide additional Authentication options such as Certificate Authentication as well as Phone Authentication.

ADFS VM Deployment

To fulfill our On-Premise ADFS Server requirement I would recommend building a VM with at least 2 GB or RAM, 1 Core and at least 100GB Dynamic Disk for Storage.  Once the VM has been deployed and fully patched on your Hypervisor follow the steps below to configure it’s IP Address:

  1. Log onto OP-ADFS
  2. Right-click on the Windows Logo and click on Run.
  3. Enter ncpa.cpl then click OK.
  4. Right-click on Ethernet then click Properties.
  5. Under the This connection uses the following items: section highlight Internet Protocol Version 4 (TCP/IPv4) then click Properties.
  6. Select Use the following IP address: and enter the following:

A

Once this is complete we will use nslookup from a command prompt to confirm that we are using OP-DC as our DNS Server as shown below:

op-ex2

Once we have confirmed we are actually using OP-DC as our DNS Server, we will join OP-ADFS to the killerhomelab.com domain following the steps below:

1.  Right-click on the Windows Logo and click on System.

2.  Under Computer name, domain and workgroup settings click on Change settings.

3.  At the pop-up screen click on Change.

4.  Under Member of select Domain: then enter killerhomelab.com and click OK.

5.  At the Computer Name/Domain Changes pop-up enter your Domain Admin and Password then click OK.

6.  At the Computer Name/Domain Changes pop-up click OK, OK, then Close.

7.  Click Restart Now.

WAP VM Deployment

To fulfill our On-Premise WAP Server requirement I would recommend building a VM with at least 2 GB or RAM, 1 Core and at least 100GB Dynamic Disk for Storage.  Once the VM has been deployed and fully patched on your Hypervisor follow the steps below to configure it’s IP Address:

  1. Log onto OP-WAP
  2. Right-click on the Windows Logo and click on Run.
  3. Enter ncpa.cpl then click OK.
  4. Right-click on Ethernet then click Properties.
  5. Under the This connection uses the following items: section highlight Internet Protocol Version 4 (TCP/IPv4) then click Properties.
  6. Select Use the following IP address: and enter the following:

wapdns1

Once this is complete we will use nslookup from a command prompt to confirm that we are using OP-DC as our DNS Server as shown below:

op-ex2

Once our Servers are done rebooting we will log into our ADFS Server (OP-ADFS) and install the ADFS Binaries.  Following the steps below let’s install the ADFS Binaries:

  1. From the taskbar click on Server Manager.
  2. Under the Configure this local server section click on Add roles and features.
  3. At the Before you begin Next.
  4. At the Select installation type screen click Next.
  5. At the Select destination server screen click Next.
  6. At the Select server roles screen select Active Directory Federation Services then click Next.
  7. At the Select features screen click Next.
  8. At the Active Directory Federation Services (AD FS) screen click Next.
  9. the Confirm installation selections screen click Install.
  10. When setup completes click Close.

Before we can configure our ADFS Server we must obtain an SSL Certificate for it. Although WAP will be our SSL Termination point for external clients, it communicates with ADFS over port 443/TCP and this connection must be secured using an SSL Certificate.  ADFS uses a URL called the Federation Service Name which is where WAP redirects external clients.  In addition to the certificate for the Federation Server Name URL we must also create a certificate for the ADFS Signing Token.  This is used to Sign the auth token that keeps the users claims. Log onto the ADFS Server  (KHL-ADFS) and follow the steps below to create and issue a Federation Service Certificate as well as a Token-Signing Certificate:

1.  Log onto OP-ADFS.

2.  Right-Click the Windows Log and select Run.

3.  Enter CERTLM.msc then click OK.

Run-CERTLM

4.  In the Left-Pane right-click Personal and select All Tasks | Request New Certificate.

Request-Cert

5.  At the Before You Begin screen click Next.

6.  At the Select Certificate Enrollment Policy screen click Next.

7.  At the Request Certificates screen select KHL Web Server then click More information is required….

Certificate-Enrollment

8.  Under Subject name: use the pull-down menu and select Common name then enter adfs.it.dmgva.com under Value then click Add.

adfscert1

9.  Click on the General tab and under Friendly name: enter ADFS Service then click OK, then Enroll.

ADFSServiceCert1

CA-Enroll

10.  At the Certificate Installation Results screen click Finish.

CA-Enroll-Finishadfs

11.  In the Left-Pane right-click Personal and select All Tasks | Request New Certificate.

12.  At the Before You Begin screen click Next.

13.  At the Select Certificate Enrollment Policy screen click Next.

14.  At the Request Certificates screen select KHL Web Server then click More information is required….

15.  Under Subject name: use the pull-down menu and select Common name then enter adfs-signing.it.dmgva.com under Value then click Add.

16.  Click on the General tab and under Friendly name: enter ADFS Signing then click OK, then Enroll.

We will be utilizing our ADFS Service Certificate not only on our ADFS Server, but also our WAP Server.  In order to do this we will need to export a copy of the certificate with it’s private key for later in the blog where we will import it on our WAP Server.  Let’s follow the steps below to do this:

1.  Right-click the Windows Logo and select Run.

2.  Enter certlm.msc then click OK.

3.  In the Left-Pane expand Personal and select Certificates then in the Right-Pane right-click the adfs.it.dmgva.com certificate and select All Tasks | Export.

adfsexport1

4.  At the Welcome to the Certificate Export Wizard click Next.

5.  At the Export Private Key screen select Yes, export the private key then click Next.

6.  At the Export File Format screen click Next.

7.  At the Security screen select Password then enter and re-enter a secure password of your choice then click Next.

8.  At the File to Export screen enter C:\ADFS-Service.pfx then click Next, then Finish.

9.  Click OK at the pop-up.

ADFS has the option of using a traditional Service Account which has been delegated the necessary permissions or a new option called a Group Managed Service Account (gMSA).  One advantage of sing a gMSA is the fact that you don’t have to worry about password expiration.  In order to create and use Managed Service accounts we must create what’s called an KDS (Key Distribution Service) Root Key within our forest.  The Root Key is used by the Domain Controllers to begin the generation of passwords for the gMSA.  In addition to creating our gMSA, we will also need to associate our Federation Service Name with it.  Follow the steps below to create our KDS Root key and associate the Federation Service Name with it:

1.  Log onto OP-DC.

2.  Open an Elevated Powershell Prompt.

3.  Type the following then hit Enter:

Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)
New-ADServiceAccount FsGmsa –DNSHostName adfs.it.dmgva.com –ServicePrincipalNames http/adfs.it.dmgva.com

Now that our KDS Root Key is successfully created, we can start our ADFS Configuration.  Log onto OP-ADFS then Klaunch Server Manager and follow the steps below:

1.  In the Right-Pane click on the Yellow Caution Sign then click Configure the federation service on this server.

2.  At the Welcome screen make sure Create the first federation server in a federation server farm is selected then click Next.

adfsconfig1

3.  At the Connect to Active Directory Domain Services click Next.

adfsconfig2

4.  At the Specify Service Properties screen select and enter the following then click Next:

SSL Certificate:                                          adfs.it.dmgva.com

Federation Service Name:                        adfs.it.dmgva.com

Federation Service Display Name:            Killer Home Lab

adfsconfig3

5.  At the Specify Service Account screen select Use an existing domain user account or group Managed Service Account then click the Select button then At the Select User or Service Account pop-up enter FsGmsa then click OK, then Next.

adfsconfig4

6.  At the Specify Configuration Database screen make sure Create a database on this server using Windows Internal Database is selected then click Next.

adfsconfig5

7.  At the Review Options screen click Next.

adfsconfig6

9.  At the Prerequisites Checks screen click Configure.

adfsconfig7

10.  At the Results screen click Close.

adfsconfig8

The last thing we need to do before configuring ADFS is creating a DNS A Record for our “Federation Service Name URL” which will point to the external IP of our WAP Server.  In Part 5 of this Series we migrated our External DNS Name Servers to point to an Azure DNS Zone.

In order to determine the IP address we need the ADFS A Record to point to we will need to retrieve our Public IP Address that our ISP has provided.  In order to do this we will need to log onto our On-Premise Router AZURE-VPN and run an ipconfig to see what IP has been assigned to our External Interface as shown below:

A Records

ADFS 98.175.27.234

In addition to creating the new A Record within our Azure DNS Zone, we will also have to modify our NAT Rule created on our On-Premise Windows Server 2012 R2 Router to point Port 443/TCP to our WAP Server (192.168.1.8) as well as creating a new NAT Rule for 49443/TCP, which is the port for Certificate Authentication.  To make these changes log onto AZURE-VPN1 and make the following changes:

1.  Navigate to C:\AzureConfig and open Azure.ps1.

2.  Once inside the file locate the following line:

$AzureIP =  $LocalNetworkGateway.GatewayIpAddress
  3.  Underneath the line that was located above paste the following lines within the Azure.ps1 script and save it:
$adfs = New-AzureRmDnsRecordSet -ResourceGroupname Killer-Home-Lab -ZoneName dmgva.com -Name adfs.it -RecordType A -Ttl 900
Add-AzureRmDnsRecordConfig -RecordSet $adfs -Ipv4Address $IP
Set-AzureRmDnsRecordSet -RecordSet $adfs
The above lines will update the following A Records within you Azure DNS Zone every time your ISP gives you a new IP.
  • adfs.it

4.  Right-click the Windows Logo and select Run then enter rrasmgmt.msc.

5.  At the Routing and Remote Access window in the Left-Pane expand IPv4 and select NAT.

6.  In the Right-Pane right-click External and select Properties.

7.  At the External Properties window select the Services and Ports.

8.  On the Services and Ports tab under Services select Secure Web Server (HTTPS) and click Edit.

9.  At the Edit Service window change the Private address: from 192.168.1.6 to 192.168.1.8 then click OK.

10.  At the External Properties window click Add.

11.  At the Add Service window enter the following then click OK, OK:

onpremisewap1

We will also need to create an Internal A Record for our ADFS Service under the <mydomainname>.com DNS Zone.  Follow the steps below to add this record:

1.  Logon to OP-DC

2.  Right-click on the Windows Logo and select Command Prompt (Admin).

3.  Type following commands then hit Enter:

dnscmd op-dc /RecordAdd it.dmgva.com adfs A 192.168.1.7

Now that we have finished , let’s connect to our ADFS VM (OP-ADFS) via remote desktop. e Untrusted Certificate pop-up click Yes.

Once we are logged into OP-WAP we need to install the WAP Binaries.  Follow the steps below to install the WAP which is actually a part of the Remote Access Role:

  1. From the taskbar click on Server Manager.
  2. Under the Configure this local server section click on Add roles and features.
  3. At the Before you begin Next.
  4. At the Select installation type screen click Next.
  5. At the Select destination server screen click Next.
  6. At the Select server roles screen select Remote Access then click Next.
  7. At the Select features screen click Next.
  8. At the Remote Access screen click Next.
  9. At the Select role services screen select Web Application Proxy then at the pop-up click Add Features then click Next.
  10. the Confirm installation selections screen click Install.
  11. When setup completes click Close.

You will remember that back when we were working on our ADFS Server we exported a certificate.  Now we must copy this certificate over to our WAP Server and import it into our Local Computer Certificate Store.  This can be done by copying the file C:\ADFS-Service.pfx from your RDP session on your ADFS Server to the RDP session of your WAP Server using a simple Cut & Paste.  Once the file has been copied follow the steps below to import.

1.  Log onto OP-WAP

2.  At the Command Prompt type the following then hit Enter.

certlm.msc

3.  In the Left-Pane right-click Personal and select All Tasks | Import.

4.  At the Welcome to the Certificate Import Wizard screen click Next.

ImportCert1

5.  At the File to Import screen enter C:\ADFS-Service.pfx then click Next.

ADFSCertImport1

6.  At the Private key protection screen enter the password you used to secure the Certificate Export then click Next.

ImportCert3

7.  At the Completing the Certificate Import Wizard screen click Finish then at the pop-up click OK.

ADFSCertImport2

We will also need to export a copy of our Exchange SAN Certificate that was created in Part 5 of the series and then import it on our WAP Server.  Log onto your Exchange Server OP-EX and follow the procedures listed below:

1.  Right-click the Windows Logo and select Run.

2.  Enter certlm.msc then click OK.

3.  In the Left-Pane expand Personal and select Certificates then in the Right-Pane right-click the owa.it.dmgva.com certificate and select All Tasks | Export.

4.  At the Welcome to the Certificate Export Wizard click Next.

5.  At the Export Private Key screen select Yes, export the private key then click Next.

6.  At the Export File Format screen click Next.

7.  At the Security screen select Password then enter and re-enter a secure password of your choice then click Next.

8.  At the File to Export screen enter C:\KHL-SAN.pfx then click Next, then Finish.

9.  Click OK at the pop-up.

Now we must copy this certificate over to our WAP Server and import it into our Local Computer Certificate Store.  This can be done by copying the file C:\KHL-SAN.pfx from your RDP session on your Exchange Server to the RDP session of your WAP Server using a simple Cut & Paste.  Once the file has been copied follow the steps below to import it

Now that we have exported our Exchange SAN Certificate lets use the steps below to import it onto our WAP Server:

1.  Log onto OP-WAP.

2.  At the Command Prompt type the following then hit Enter.

certlm.msc

3.  In the Left-Pane right-click Personal and select All Tasks | Import.

4.  At the Welcome to the Certificate Import Wizard screen click Next.

ImportCert1

4.  At the File to Import screen enter C:\KHL-SAN.pfx then click Next.

ImportCert2

5.  At the Private key protection screen enter the password you used to secure the Certificate Export then click Next.

ImportCert3

6.  At the Completing the Certificate Import Wizard screen click Finish then at the pop-up click OK.

ImportCert4

You will notice that their are actually 4 certificates that were imported.  Two are the KHL SAN  & ADFS-Service Certificates we will be using and the others are the Certificate Authority which was included within each certificate.  We will only need on copy of the Certificate Authority, so we can safely delete one of them by highlight it and hitting delete and then Yes to confirm.  We will need to copy the other copy of the Certificate Authority Certificate (KHL-CA) to the Trusted Root Certification Authority Store as shown below:

ImportCert5

ImportCert6

We will now head back over to our ADFS Server to create our Relying Party Trusts, but first we must also make sure that our Managed Service Account has rights to this certificate.  Use the steps below to grant rights to your MSA:

1.  Log onto OP-ADFS

2.  Right-click the Windows Logo and select Run.

3.  Enter certlm.msc then click OK.

4.  In the Left-Pane expand Personal then highlight Certificates.

5.  In the Right-Pane right-click adfs.it.dmgva.com and select All Tasks | Manage Private Keys.

6.  At the Select Users, Computers, Service Accounts, or Groups pop-up click on Object Types, select Service Accounts then click OK.

7.  Enter fsgmsa then click Check Names, then OK.

8.  Make sure the account has Read then click OK.

9.  Repeat this process for your adfs-signing.it.dmgva.com Certificate.

Now we will create our Relying Party Trusts on ADFS.  To do this we will start by creating 3 files in notepad with the content shown below:

IssuanceAuthorizationRules.txt
@RuleTemplate = “AllowAllAuthzRule”
=> issue(Type = “http://schemas.microsoft.com/authorization/claims/permit”,
Value = “true”);

IssuanceTransformRules.txt

@RuleName = “ActiveDirectoryUserSID”
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”]
=> issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”), query = “;objectSID;{0}”, param = c.Value);
@RuleName = “ActiveDirectoryUPN”
c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer == “AD AUTHORITY”]
=> issue(store = “Active Directory”, types = (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”), query = “;userPrincipalName;{0}”, param = c.Value);

RelyingPartyTrusts.ps1 (Each line below should show as 1 individual line within notepad)

[string]$IssuanceAuthorizationRules=Get-Content -Path C:\IssuanceAuthorizationRules.txt
[string]$IssuanceTransformRules=Get-Content -Path C:\IssuanceTransformRules.txt
Add-ADFSRelyingPartyTrust -Name “Outlook Web App” -Enabled $true -Notes “This is a trust for https://owa.it.dmgva.com/owa” -WSFedEndpoint https://owa.it.dmgva.com/owa -Identifier https://owa.it.dmgva.com/owa -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules
Add-ADFSRelyingPartyTrust -Name “Exchange Admin Center (EAC)” -Enabled $true -Notes “This is a trust for https://owa.it.dmgva.com/ecp” -WSFedEndpoint https://owa.it.dmgva.com/ecp -Identifier https://owa.it.dmgva.com/ecp -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules

Save each of these files at the root of C:\ as shown below:

C:\IssuanceAuthorizationRules.txt

C:\IssuanceTransformRules.txt

C:\RelyingPartyTrust.ps1

Launch an Elevated Powershell as shown below and run C:\RelyingPartyTrust.ps1

ElevatedPowershell

Within the Shell navigate to the root of C:\ and run .\RelyingPartyTrust.ps1

So far we have did all of our work from Powershell.  Time to take a look at the ADFS Console and make a few changes. Let’s open the ADFS Management Console and take a look at our newly created Relying Party Trusts.  Follow the steps below:

  1.  Click on the Windows Logo then click the Down Arrow then locate and open AD FS Management 
  2. In the Left-Pane expand Trust Relationships then select Relying Party Trusts.

RelyingPartyTrust1

As you can see our OWA and EAC Relying Party Trusts have been successfully created.

Now we will assign our ADFS Service and ADFS Signing Certificates to each of their respective purposes.  By default ADFS uses Self-Signed certificates for its Token-Decrypting and Token-Signing.  We will not be using the Token-Decrypting at this point so we will only be changing the Token-Signing for now.  In order for us to change these certificates will will have to disable the process by running the command below within an Elevated Powershell session:

Set-ADFSProperties -AutoCertificateRollover $False

Now follow the steps below to set our new certificates;

1.  In the Left-Pane expand Service then select Certificates.

2.  In the Right-Pane click on Add Token-Signing Certificate.

TokenSigning1

3.  At the Windows Security pop-up select the ADFS Signing certificate then click OK.

TokenSigning4

4.  At the Private Key warning click OK.

adfsprivatekey

(We can safely ignore this message since we have already  Granted our Managed Service Account Read Access to this Certificate’s Private Key)

5.  In the Middle-Pane under Token-signing select CN=adfs-signing.it.dmgva.com then in the Right-Pane click on Set as Primary.

6.  At the pop-up click Yes.

7.  In the Middle-Pane under Token-signing highlight the Self-Signed certificate and then in the Right-Pane click Delete.

8.  At the pop-up click Yes.

While we are on our ADFS Server we might as well get our Certificate Thumbprint for our ADFS Signing Certificate.  This will be needed later when we configure Exchange for ADFS Authentication.  Open an Elevated PowerShell prompt and enter the following command:

Get-AdfsCertificate | Where {$_.CertificateType -like “Token-Signing”} | ft Thumbprint > \\op-ex\c$\ADFSSigningThumb.txt -HideTableHeaders

This command will create an output of the Thumbprints of all the ADFS Certificates onto the Exchange Server.

Now that ADFS has had the initial configuration completed we will need to connect our WAP Server.  Let’s follow the steps below to configure our WAP Server:

1.  Right-click the Windows Logo and select Run then enter the following:

RAMgmtUI.exe

2.  At the Remote Management Console in the Left-Pane click on Web Application Proxy then in the Middle-Pane click on Run the Web Application Proxy Configuration Wizard.

wapconsole1

3.  At the Welcome screen click Next.

3.  At the Federation Server screen enter the following then click Next:

Federation service name:                         adfs.it.dmgva.com

Password:                                                  blueberries

User name:                                                killerhomelab\khl-admin

wapconsole2

4.  At the AD FS Proxy Certificate screen use the Select a certificate to be used by the AD FS proxy: and select adfs.it.dmgva.com then click Next.

wapconsole3

5.  At the Confirmation screen click Configure.

wapconsole4

6.  At the Results screen click Close.

wapconsole6

Before creating our Publishing Rules we will need to grab a copy

Now we will create our Publishing Rules on our WAP Server.  To do this we will start by creating a file in notepad with the content shown below.  Be sure to replace it.dmgva.com with your public domain:

WAP-Config.ps1 (Each line below should show as 1 individual line within notepad)
$ExchangeCert = Get-ChildItem -Path cert: -Recurse | where {$_.Subject -like “CN=owa.it.dmgva.com”}
Add-WebApplicationProxyApplication -BackendServerUrl ‘https://owa.it.dmgva.com/owa/’ -ExternalCertificateThumbprint $ExchangeCert.Thumbprint -ExternalUrl ‘https://owa.it.dmgva.com/owa/’ -Name ‘OWA’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Outlook Web App’
Add-WebApplicationProxyApplication -BackendServerUrl ‘https://owa.it.dmgva.com/ecp/’ -ExternalCertificateThumbprint $ExchangeCert.Thumbprint -ExternalUrl ‘https://owa.it.dmgva.com/ecp/’ -Name ‘ECP’ -ExternalPreAuthentication ADFS -ADFSRelyingPartyName ‘Exchange Admin Center (EAC)’

Save this file at the Root of C:\ as shown below:

C:\WAP-Config.ps1

Now we will launch an Elevated Powershell Session to run our script.

Initially the script will display both ports that utilize the adfs.it.dmgva.com certificate.  Highlight and copy one of them as shown below and then paste it in the “Enter the CertificateHash Shown Above” section:

certhash

Now that we have created our Publishing Rules lets take a look within the GUI to see if they have really been created.  While you are still within the PowerShell Session, enter to RAMgmtUI.exe to launch the WAP ConsoleAs shown below our rules should now be created.

wappublishing1

If you’ve been paying close attention, you should notice that we are missing some rules based on our previously configured services.  The rules above are only for OWA and ECP, which doesn’t include Outlook (MAPI over HTTP), Autodiscover, ActiveSync, or Web Services.  This is because none of these services can currently leverage pre-authentication.  Once our users are migrated to Office 365 we will have other methods we can use such as Modern Authentication or Phone Authentication.  For the simplicity of the lab we simply be creating Pass-through rules on or WAP Server which bypass ADFS and send any authentication requests directly to the BackEnd Server.  Follow the steps below to create Pass-through Rules for these remaining services:

ActiveSync

1.  Within the WAP Console in the Right-Pane click on Publish.

2.  At the Welcome screen click Next.

3.  At the Preauthentication screen select pass-through then click Next.

4.  At the Publish Settings screen enter the following then click Next:

Name:  ActiveSync

External URL:  https://eas.it.dmgva.com/Microsoft-Server-ActiveSync/

External certificate:  [select the owa.it.dmgva.com certificate]

Backend server URL:  https://eas.it.dmgva.com/Microsoft-Server-ActiveSync/

5.  At the Confirmation screen click Publish.

6.  At the Results screen click Close.

 

Autodiscover

1.  Within the WAP Console in the Right-Pane click on Publish.

2.  At the Welcome screen click Next.

3.  At the Preauthentication screen select pass-through then click Next.

4.  At the Publish Settings screen enter the following then click Next:

Name:  Autodiscover

External URL:  https://autodiscover.it.dmgva.com/Autodiscover/

External certificate:  [select the owa.it.dmgva.com certificate]

Backend server URL:  https://autodiscover.it.dmgva.com/Autodiscover/

5.  At the Confirmation screen click Publish.

6.  At the Results screen click Close.

 

MAPI over HTTP

1.  Within the WAP Console in the Right-Pane click on Publish.

2.  At the Welcome screen click Next.

3.  At the Preauthentication screen select pass-through then click Next.

4.  At the Publish Settings screen enter the following then click Next:

Name:  MAPI over HTTP

External URL:  https://outlook.it.dmgva.com/MAPI/

External certificate:  [select the owa.it.dmgva.com certificate]

Backend server URL:  https://outlook.it.dmgva.com/MAPI/

5.  At the Confirmation screen click Publish.

6.  At the Results screen click Close.

 

Web Services

1.  Within the WAP Console in the Right-Pane click on Publish.

2.  At the Welcome screen click Next.

3.  At the Preauthentication screen select pass-through then click Next.

4.  At the Publish Settings screen enter the following then click Next:

Name:  Web Services

External URL:  https://outlook.it.dmgva.com/EWS/

External certificate:  [select the owa.it.dmgva.com certificate]

Backend server URL:  https://outlook.it.dmgva.com/EWS/

5.  At the Confirmation screen click Publish.

6.  At the Results screen click Close.

 

Outlook Offline Address Book

1.  Within the WAP Console in the Right-Pane click on Publish.

2.  At the Welcome screen click Next.

3.  At the Preauthentication screen select pass-through then click Next.

4.  At the Publish Settings screen enter the following then click Next:

Name:  Outlook Offline Address Book

External URL:  https://outlook.it.dmgva.com/OAB/

External certificate:  [select the owa.it.dmgva.com certificate]

Backend server URL:  https://outlook.it.dmgva.com/OAB/

5.  At the Confirmation screen click Publish.

6.  At the Results screen click Close.

 

Now that ADFS and WAP are configured.  We can go back to our Exchange Server OP-EX and configure it for ADFS Authentication.

Now we will configure Exchange to use ADFS Authentication.  To do this we will start by creating a file in notepad with the content shown below.  Be sure to replace it.dmgva.com with your public domain and <ADFSSigningCertificateThumbprint> with the contents of C:\ADFSSigningThumb.txt:

Exchange-Config.ps1 (Each line below should show as 1 individual line within notepad)

$uris = @(” https://owa.it.dmgva.com/owa”,“https://owa.it.dmgva.com/ecp”)

Set-OrganizationConfig -AdfsIssuer “https://adfs.it.dmgva.com/adfs/ls/” -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint “<ADFSSigningCertificateThumbprint>”

# ADFS on FORMS off

Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false

Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false

Once Logged into the Exchange Server launch an Elevated Exchange Management Shell and run the following command:

C:\Exchange-Config.ps1

C:\iisreset /noforce

iisreset

(If the reset doesn’t complete simply re-run it)

Now we can try our Securely published OWA to make sure it is working.  From an External Client Launch Internet Explorer and go to the following URL:

https://owa.it.dmgva.com/owa

When presented with the page below enter the credentials for Test User1 and then click Sign-In as shown below:

adfslogon1

If all is well you will be presented with the page shown below:

adfslogon2

Now that we have successfully secured Exchange 2016 using ADFS/WAP.  Lets take a look at some of the Alternate Authentication Methods.  To do this we will need to head back over to our ADFS Server.  Follow the steps below to access ADFS’s Authentication Options:

1.  Logon to OP-ADFS.

2.  Click on the Windows Logo then click on the Down Arrow .

4.  Under Administrative Tools click on AD FS Management.

5.  In the Left-Pane right-click on Authentication Policies and select Edit Global Authentication Policy.

As you can see below there are multiple Authentication Methods based on whether the request comes from the Intranet or Extranet.

adfsauth1

Under the Extranet section lets add an additional Authentication option by selecting Certificate Authentication then click OK.

certauth2

Now that we have enabled Certificate Authentication we will need to get a User Certificate for our Test User1.  In order to issue a user certificate we will need to log onto a Domain Joined Machine and use our Certificate MMC to request a certificate to our Test User1.  Since this user is a regular user, we will need to add them to the Local Administrators group on a server before we can RDP into it.  Follow the steps below to grant Test User1 temporary Administrative Rights on our Exchange Server in order to issue a User Certificate:

1.  Log onto OP-EX using your Admin Credentials.
2.  Right-click on the Windows Logo the  select Computer Management.

3.  In the Left-Pane expand Local Users and Groups and select Groups.

4.  In the Right-Pane double-click on Administrators then at the Administrators Properties pop-up click Add.

5.  At the Select Users, Computers, Service Accounts, or Groups pop-up enter tuser1 then click Check Names, OK, OK.

6.  Log off of OP-EX.

Now that we have granted our Test User1 account Local Administrator Rights, let’s log on and issue a User Certificate following the steps below:

1.  Log onto OP-EX using your Test User1 Credentials. (Remember you can now user your Alternative UPN Suffix Logon – tuser1@it.dmgva.com)

2.  Right-click the Windows Logo and select Run.

3.  Enter certmgr.msc then click OK.

4.  In the Left-Pane right-click Personal then select All Tasks | Request New Certificate

5.  At the Before You Begin screen click Next.

6.  At the Select Certificate Enrollment Policy screen click Next.

7.  At the Request Certificates screen select Users then click Enroll.

8.  At the Certificate Installation Results screen click Finish.

Now we will need to export our Test User1 Certificate so we can use it to test our Certificate Authentication Externally.  This process will include us Exporting a copy of the Certificate to a .pfx file which contains the Private Key and importing it onto our Test Workstation we are using for our External Testing.  Follow the steps below to Export/Import the Test User1 Certificate from the Exchange Server and onto your Test Workstation:

  1. Within the certmgr in the Left-Pane expand Personal and then select Certificates.

3.  In the Left-Pane expand Personal and select Certificates then in the Right-Pane right-click the Test User1 certificate and select All Tasks | Export.

4.  At the Welcome to the Certificate Export Wizard click Next.

5.  At the Export Private Key screen select Yes, export the private key then click Next.

6.  At the Export File Format screen click Next.

7.  At the Security screen select Password then enter and re-enter a secure password of your choice then click Next.

8.  At the File to Export screen enter C:\TestUser1.pfx then click Next, then Finish.

9.  Click OK at the pop-up.

Now we must copy this certificate over to our Test Workstation and import it into our Local User Certificate Store.  This can be done by copying the file C:\TestUser1.pfx from your RDP session on your Exchange Server to your Test Workstation using a simple Cut & Paste.  Once the file has been copied follow the steps below to import it

Now that we have exported our Test User1 Certificate lets use the steps below to import it onto our Test Workstation:

1.  At a Command Prompt type the following then hit Enter.

certmgr.msc

2.  In the Left-Pane right-click Personal and select All Tasks | Import.

3.  At the Welcome to the Certificate Import Wizard screen click Next.

4.  At the File to Import screen enter C:\TestUser1.pfx then click Next.

5.  At the Private key protection screen enter the password you used to secure the Certificate Export then click Next.

6.  At the Certificate Store screen click Next.

7.  At the Completing the Certificate Import Wizard screen click Finish then at the pop-up click OK.

8.  At the pop-up click OK.

You will notice that their are actually 2 certificates that were imported.  One is your Test User1 Certificate and the other is the Certificate Authority which was included within each certificate.  We will need to copy the Certificate Authority Certificate (KHL-CA) to the Trusted Root Certification Authority Store as shown below:

ImportCert5

ImportCert6

Now we are ready to head back to our ADFS Portal and test our login with our Newly created Certificate.

From an External Client Launch Internet Explorer and go to the following URL:

https://owa.it.dmgva.com/owa

When presented with the page below you will now notice that instead of just having our Sign in button we now have an option for “Sign in using an X.509 certificate:

adfscertlogon2

Now click on the “Sign in using an X.509 certificate”.  You should be presented with an pop-up displaying your certificate or in the event that you have certificates already present on your workstation multiple certificates.  Select the Test User1 Certificate as shown below then click OK.

certpopup

As you can see we are now logged in using our Test User 1 Certificate and we have now successfully published Exchange utilizing WAP & ADFS.  In Part 7 of our Series (Syncing On-Premise with Office 365), we will be setting up an Office 365 Tenant and configuring our On-Premise Active Directory to Sync with it. Have fun with the lab!!!

Comments (0)

Skip to main content