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


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 Azure ADFS Server and 1 Azure WAP Server.   In part 6 of our series we deployed an Exchange 2016 Server within Azure and provided access to it’s services by creating an 443/TCP End Point 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.

Azure VM Deployment

Let’s head to Azure now and deploy our ADFS and WAP VM’s using the URL listed below:

 

https://manage.windowsazure.com

 

Once we are within the portal follow the steps below to create our VM’s

 

  1. On the Left-Pane click on NEW.
  2. From the menu select COMPUTE | VIRTUAL MACHINES | FROM GALLERY.

3.  At Choose an image screen select in the Middle-Pane select Windows Server 2012 R2 Datacenter then click Next.

4.  At the Virtual machine configuration screen use the table and information below to create the following VM’s then click Next:

VIRTUAL MACHINE NAME SIZE REGION/AFFINITY Group /Virtual network
KHL-ADFS A1 (1 core, 1.75 GB memory) VPNLAB
KHL-WAP A1 (1 core, 1.75 GB memory) VPNLAB

***Note:  The virtual machine names will need to be unique since it’s a hostname within cloudapp.net. 

 

      5.  Use the following as a temporary Username and Password then click Next

  • NEW USER NAME:                                       khl-admin
  • NEW PASSWORD:                                        blueberries
  • CONFIRM:                                                      blueberries

6.  At the next screen click Complete.

 

Sit back and wait for you Azure VMs to be created.  It normally takes about 5-10 minutes.

 

Once your VM’s are complete we will need to reserve their IP addresses.  Since Azure VM’s are given DHCP addresses, we will have to set ours to Static.  I have already posted an article on how to set a Azure VM’s IP to static.  It can be found here:

 

http://blogs.technet.com/b/elliottf/archive/2015/06/12/assigning-static-ip-s-to-azure-vm-s.aspx

Creating Endpoints

1.  Log into the portal by accessing the URL listed below:

https://manage.windowsazure.com

2.  In the Left-Pane click on VIRTUAL MACHINES then in the Right-Pane click on KHL-WAP.

3.  Under khl-wap  click on ENDPOINTS.

4.  On the Bottom-Bar click ADD.

5.  At the Add an endpoint to a virtual machine window click the Arrow to proceed.

EndPoint1

6.  At the Specify the details of the endpoint screen use the NAME pull-down menu and select HTTPS, then click the Check Box to complete.

EndPoint

7.  On the Bottom-Bar click ADD.

8.  At the Add an endpoint to a virtual machine window click the Arrow to proceed.

9.  At the Specify the details of the endpoint screen use configure the endpoint as shown below then click the Check Box to complete.

CERTAUTH

Now that we have finished adding our endpoint’s to our WAP Server, let’s connect to our ADFS VM (KHL-ADFS) via remote desktop.  To do this follow the steps below:

1.  On the Left-Pane click on VIRTUAL MACHINES.

2.  In the Middle-Pane highlight KHL-ADFS then on the Bottom-Bar click CONNECT.

3.  At the download pop-up click Save | Save As.

4.  At the Save As pop-up enter KHL-ADFS under File name: then click Save.

5.  Navigate to the file and double-click on KHL-ADFS.

6.  At the Remote Desktop Connection pop-up click Connect.

7.  At the Windows Security screen enter your credentials.

8.  At the Untrusted Certificate pop-up click Yes.

Once we are logged into KHL-ADFS we need to verity that it is using KHL-DC as its DNS Server.  We can do that by running an NSLookup as shown below:

nslookup

Once it is confirmed that we can communicate with KHL-DC we will join this server to the domain using 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.

Once our Server is done rebooting we will connect back up using the .RDP file we saved earlier 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 KHL-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-Finish

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 KHL-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.  Launch 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.  Each Name Registrar has different procedures on creating DNS Records.  Since this is out of scope for this lab please review your Name Registrar’s procedures to create the necessary DNS Records.  In order to determine the IP address, we need these A Records to point to we will ping the Azure FQDN which will be in the following format:

KHL-WAP.cloudapp.net

In my case the IP assigned was 13.72.189.113 so my records would need be:

A Records

ADFS 13.72.189.113

Change the following records also

OWA

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 KHL-DC

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

3.  Type following commands then hit Enter:

dnscmd khl-dc /RecordAdd it.dmgva.com adfs A 192.168.111.7

Now that we have finished adding our endpoint’s to our WAP Server, let’s connect to our ADFS VM (KHL-ADFS) via remote desktop.  To do this follow the steps below:

1.  On the Left-Pane click on VIRTUAL MACHINES.

2.  In the Middle-Pane highlight KHL-WAP then on the Bottom-Bar click CONNECT.

3.  At the download pop-up click Save | Save As.

4.  At the Save As pop-up enter KHL-WAP under File name: then click Save.

5.  Navigate to the file and double-click on KHL-WAP.

6.  At the Remote Desktop Connection pop-up click Connect.

7.  At the Windows Security screen enter your credentials. (Remember not use your Domain Account since KHL-WAP is Non-Domain Joined)

8.  At the Untrusted Certificate pop-up click Yes.

Once we are logged into KHL-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 KHL-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 KHL-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 KHL-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 KHL-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 or 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

(At the end of this process we will Grant 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 > \\khl-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

4.  At the Confirmation screen click Configure.

wapconsole4

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

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

1.  On the Left-Pane click on VIRTUAL MACHINES.

2.  In the Middle-Pane highlight KHL-EX then on the Bottom-Bar click CONNECT.

3.  At the download pop-up click Save | Save As.

4.  At the Save As pop-up enter KHL-EX under File name: then click Save.

5.  Navigate to the file and double-click on KHL-EX.

6.  At the Remote Desktop Connection pop-up click Connect.

7.  At the Windows Security screen enter your credentials.

8.  At the Untrusted Certificate pop-up click Yes.

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.<mydomainname>.com/owa”,“https://owa.<mydomainname>.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 KHL-ADFS1.

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 KHL-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 KHL-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 KHL-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