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 5 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://portal.azure.com
Once we are within the portal follow the steps below to create our Exchange Azure VM
KHL-ADFS
1. In the Left-Pane click + | Compute | Windows Server 2012 R2 Datacenter.
2. At the Windows Server 2012 R2 Datacenter screen click Create.
3. At the Basics screen enter the following then click OK.
***Note: The virtual machine name will need to be unique for your lab since it’s a hostname within eastus.cloudapp.azure.com. So KHL-ADFS is no longer available.
4. At the Choose a size screen select DS1_V2 Standard VM then click Select.
6. At the Settings screen accept the defaults then click OK.
7. At the Summary screen review your settings then click OK.
Sit back and wait for you Azure VM to be created. It normally takes about 5-10 minutes.
Once the VM is finished being created (About 5-10 minutes), we will need to make a few modifications to the VM to make sure we can access it consistently remotely. This will involve, setting Static IP’s for the VM (Internal/External) as well as an external DNS name for the computer, that can be used to access it via Remote Desktop. Follow the steps below to make these change
1. In the Left-Pane click on Virtual Machines then click on KHL-ADFS.
2. At the KHL-ADFS screen click on the Public IP address as shown below:
3. At the KHL-ADFS-ip – Configuration screen under Assignment click Static, under DNS name label enter khl-adfs, then click Save.
4. In the top-right corner click on the Bell to confirm the public ip addres change has been saved.
5. Scroll back to the Left-Side of the screen then click on Virtual Machines | KHL-ADFS.
6. Under KHL-ADFS click on Network interfaces.
7. At the KHL-ADFS – Network interfaces screen click on the Network Interface as shown below:
8. Under the Network Interface click on IP configurations.
9. At the IP configurations screen click on ipconfig1 as shown below:
10. At the ipconfig1 screen under Assignment select Static then click Save.
KHL-WAP
1. In the Left-Pane click + | Compute | Windows Server 2012 R2 Datacenter.
2. At the Windows Server 2012 R2 Datacenter screen click Create.
3. At the Basics screen enter the following then click OK.
***Note: The virtual machine name will need to be unique for your lab since it’s a hostname within eastus.cloudapp.azure.com. So KHL-WAP is no longer available.
4. At the Choose a size screen select DS1_V2 Standard VM then click Select.
6. At the Settings screen accept the defaults then click OK.
7. At the Summary screen review your settings then click OK.
Sit back and wait for you Azure VM to be created. It normally takes about 5-10 minutes.
Once the VM is finished being created (About 5-10 minutes), we will need to make a few modifications to the VM to make sure we can access it consistently remotely. This will involve, setting Static IP’s for the VM (Internal/External) as well as an external DNS name for the computer, that can be used to access it via Remote Desktop. Follow the steps below to make these change
1. In the Left-Pane click on Virtual Machines then click on KHL-WAP.
2. At the KHL-WAP screen click on the Public IP address as shown below:
3. At the KHL-WAP-ip – Configuration screen under Assignment click Static, under DNS name label enter khl-wap, then click Save.
4. In the top-right corner click on the Bell to confirm the public ip addres change has been saved.
5. Scroll back to the Left-Side of the screen then click on Virtual Machines | KHL-WAP.
6. Under KHL-WAP click on Network interfaces.
7. At the KHL-WAP – Network interfaces screen click on the Network Interface as shown below:
8. Under the Network Interface click on IP configurations.
9. At the IP configurations screen click on ipconfig1 as shown below:
10. At the ipconfig1 screen under Assignment select Static then click Save.
If you completed Part 4 of this series you should have already be familiar with Network Security Groups. These objects are used within Azure to determine which ports are opened for a VM. This group includes the Inbound and Outbound Rules that allow connectivity to the VM. A Network Security Group is created for each VM that you create within Azure. Following the steps below to modify the Network Security Group that was created for KHL-WAP to allow ports 49443/TCP for Certificate Authentication & 443/TCP Web traffic:
1. Log into the portal by accessing the URL listed below:
https://portal.azure.com
2. In the Left-Pane click on Resource Groups then select Killer-Home-Lab.
3. Under the Killer-Home-Lab Resource Group click on the KHL-WAP-nsg Network Security Group.
4. Under KHL-WAP-nsg click on Inbound security rules.
5. Under KHL-WAP-nsg – Inbound security rules click on Add.
6. At the Add inbound security rule screen enter the Name “CERTAUTH-Inbound” and under Port range enter 49443 then click OK.
7. At the Add inbound security rule screen enter the Name “HTTPS-Inbound” and use the Service pull-down menu to select HTTPS then click OK
Follow the steps below to connect to KHL-WAP.
1. In the Left-Pane click on Virtual Machines then click on KHL-WAP.
2. At the KHL-WAP screen click on Connect.
3. At the Pop-up click Save.
4. At the next pop-up click on Open Folder.
5. Under the Downloads double-click on KHL-WAP then at the pop-up click Connect, and enter your Credentials.
Once we are logged into KHL-WAP we need to verity that it is using KHL-DC as its DNS Server. We can do that by running an NSLookup.
Once it is confirmed that we can communicate with KHL-DC we will connect to KHL-ADFS.
Follow the steps below to connect to KHL-ADFS.
1. In the Left-Pane click on Virtual Machines then click on KHL-ADFS.
2. At the KHL-ADFS screen click on Connect.
3. At the Pop-up click Save.
4. At the next pop-up click on Open Folder.
5. Under the Downloads double-click on KHL-ADFS then at the pop-up click Connect, and enter your Credentials.
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.
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:
- From the taskbar click on Server Manager.
- Under the Configure this local server section click on Add roles and features.
- At the Before you begin Next.
- At the Select installation type screen click Next.
- At the Select destination server screen click Next.
- At the Select server roles screen select Active Directory Federation Services then click Next.
- At the Select features screen click Next.
- At the Active Directory Federation Services (AD FS) screen click Next.
- the Confirm installation selections screen click Install.
- 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.
4. In the Left-Pane right-click Personal and 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 KHL Web Server then click More information is required….
8. Under Subject name: use the pull-down menu and select Common name then enter adfs.it.dmgva.com under Value then click Add.
9. Click on the General tab and under Friendly name: enter ADFS Service then click OK, then Enroll.
10. At the Certificate Installation Results screen click 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.
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.
3. At the Connect to Active Directory Domain Services click Next.
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
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.
6. At the Specify Configuration Database screen make sure Create a database on this server using Windows Internal Database is selected then click Next.
7. At the Review Options screen click Next.
9. At the Prerequisites Checks screen click Configure.
10. At the Results screen click Close.
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.eastus.cloudapp.azure.com
In my case the IP assigned was13.92.38.77 so my records would need be:
A Records
ADFS 13.92.38.77
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 10.1.0.7
Now that we have finished , let’s connect to our ADFS VM (KHL-ADFS) via remote desktop. e 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:
- From the taskbar click on Server Manager.
- Under the Configure this local server section click on Add roles and features.
- At the Before you begin Next.
- At the Select installation type screen click Next.
- At the Select destination server screen click Next.
- At the Select server roles screen select Remote Access then click Next.
- At the Select features screen click Next.
- At the Remote Access screen click Next.
- At the Select role services screen select Web Application Proxy then at the pop-up click Add Features then click Next.
- the Confirm installation selections screen click Install.
- 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.
5. At the File to Import screen enter C:ADFS-Service.pfx then click Next.
6. At the Private key protection screen enter the password you used to secure the Certificate Export then click Next.
7. At the Completing the Certificate Import Wizard screen click Finish then at the pop-up click OK.
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.
4. At the File to Import screen enter C:KHL-SAN.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 Completing the Certificate Import Wizard screen click Finish then at the pop-up click OK.
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:
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
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:
- Click on the Windows Logo then click the Down Arrow then locate and open AD FS Management
- In the Left-Pane expand Trust Relationships then select Relying Party Trusts.
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.
3. At the Windows Security pop-up select the ADFS Signing certificate then click OK.
4. At the Private Key warning click OK.
(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-exc$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.
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: killerhomelabkhl-admin
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.
4. At the Confirmation screen click Configure.
5. At the Results screen click Close.
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:
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 Console. As shown below our rules should now be created.
Now that ADFS and WAP are configured. We can go back to our Exchange Server KHL-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.<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
(If the reset doesn’t complete simply re-run it)
To keep our Logon consistent with our Email Addresses and in preparation for our Part 7 (Syncing On-Premise with Office 365) we will be creating a new UPN Suffix. A UPN Suffix is an alternate User Principal Name that can be used to logon instead of your default User Logon Name. Once we have added this UPN Suffix we will change our Test User 1. Follow the steps below to complete this task:
1. Logon to KHL-DC.
2. Right-click on the Windows Logo and select Run then enter the following and click OK:
domain.msc
3. At the Active Directory Domains and Trusts pop-up in the Left-Pane right-click Active Directory Domains and Trusts [KHL-DC.killerhomelab.com] then click Properties.
4. At the pop-up enter it.dmgva.com under Alternative UPN suffixes: then click Add, OK.
5. Close the Active Directory Domains and Trusts mmc.
6. Right-click on the Windows Logo and select Run then enter the following and click OK:
dsa.msc
7. At the Active Directory Users and Computers mmc in the Left-Pane expand killerhomelab.com and select Users.
8. Locate Test User1 and double-click it.
9. At the Test User1 Properties click on the Account tab.
10. Under the User logon name: use the pull-down to change the value from killerhomelab.com to it.dmgva.com then click OK.
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:
If all is well you will be presented with the page shown below:
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.
Under the Extranet section lets add an additional Authentication option by selecting Certificate Authentication then click OK.
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:
- 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:
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:
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.
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!!!