This is pretty much PART TWO, of presenting ‘Exchange Web Services’ using Web Application Proxy. Back in PART ONE we looked at publishing OWA and ECP, and that required having an ADFS server. To present the other web services, e.g Outlook Anywhere, Exchange Active Sync, Offline address book etc. You don’t needADFS, you simply use ‘pass through‘ authentication with your WAP Server, directly to Exchange.
Solution
Before you start, you need to make sure in addition to the DNS records we used for OWA and ECP, you also need to be able to publicly resolve your Autodiscover record. I prefer doing this with public SRV records, see the following article for clarification;
Make sure your internal URLS are resolvable inside and your external/public URL’s are resolvable outside, (To the public IP address of your WAP Server).
Exchange URLS To Publish with WAP
As with the URLs we published previously remember to publish them with a trailing ‘slash’. You need to publish and ‘Reverse Proxy‘ the following URLs;
Outlook Anywhere: https://mail.ubique.com/rpc/ Offline Address Book: https://mail.ubique.com/oab/ Active-Sync: https://mail.ubique.com/Microsoft-Server-ActiveSync/ Exchange Web Services: https://mail.ubique.com/EWS/ MAPI: https://mail.ubique.com/MAPI/ Autodiscover: https://mail.ubique.com/Autodiscover/
Note: Obviously your domain will have a different name!
Publish Outlook Anywhere with WAP
From the ‘Remote Access Management Console’ > Publish > Next.
Select ‘Pass-Through’ > Next.
Give the Published rule a sensible name like “Outlook Anywhere” > Enter the URL’s, and select your public certificate > Next.
Publish.
Close
Publish Active Sync with WAP
Active Sync is required for phones and mobile devices that cannot use Outlook Anywhere. To publish this rule repeat the procedure above, but at the Publishing Setting page use the following settings.
Publish Offline Address Book with WAP
Offline Address Book is required by devices to download a cached copy of the global address list. To publish this rule repeat the procedure above, but at the Publishing Setting page use the following settings.
Publish Exchange Web Services with WAP
Exchange Web Services allow clients to access calendars, contacts and scheduling information remotely. To publish this rule repeat the procedure above, but at the Publishing Setting page use the following settings.
Publish Exchange MAPI with WAP
Mail Application Programming Interface (over HTTPS) if the default connection protocol in modern Exchange deployments. To publish this rule repeat the procedure above, but at the Publishing Setting page use the following settings.
Publish Exchange Web Services with WAP
If you’ve used Exchange since version 2007, you will know how important Autodiscover is, (probably because of the headaches caused when it’s not setup correctly!) To publish this rule repeat the procedure above, but at the Publishing Setting page use the following settings.
Final Sanity Check
When complete, your WAP settings should look like this, (this is for all the pass-through, AND ADFS published settings).
Once setup correctly, Outlook should work fine externally, like so;
Related Articles, References, Credits, or External Links
If you are going to use ‘self signed’ certificates then before you deploy ADFS, (Active Directory Federation Services,) you will want to Deploy Certificate Services. Here I’m going to use a self signed wildcard certificate. In production however, I would suggest you use a wildcard certificate signed by a public CA authority. (Click the Certificate link above).
To deploy ADFS simply follow the steps in this article;
There are a few ‘Web’ Services that Exchange provides, Outlook Web App, and Exchange Control Panel (Exchange Administration Centre), are ‘tied’ together and need to be presented in the same way, so we will cover them first.
IMPORTANT: You need to change OWA and ECP together, BE AWARE that means your Exchange Administration panel will be secured by ADFS, (and ADFS ONLY!) So you may need to change the way you do Exchange administration, (or leave one Exchange server without ADFS secured ECP for internal management).
So you create the ‘trusts’ for OWA and ECP in ADFS, then the WAP server will use those ‘trusts’. CARRY OUT THE FOLLOWING PROCEDURE TWICE, once for OWA, and once for ECP.
Open the ADFS management console > Relying Party Trusts > Add Relying Part Trust > (With ‘claims aware’ selected) > Next.
Enter data about the relying party manually > Next.
Give the trust a name e.g. ‘Outlook Web App’ > Next.
Next
Enter the ORL for OWA (with a trailing slash) e.g. https://mail.domainname.com/owa/
Permit everyone > Next.
Next
Close.
NOW REPEAT THE ABOVE PROCEDURE FOR ECP (https://mail.domain.com/ecp/)
ADFS Create “Claims Issuance Policies”
Why are you doing this? This allows you to connect to the WAP server and enter your username and password ONCE. To enable you to only supply usernames and passwords once, you need two things, 1) Claims Issuance Policies, that can query AD and collect your UPN and check your password, and 2) Exchange set to allow ADFS authentication, (instead of the usual basic, and ‘forms based’ authentication is uses for OWA and ECP out of the box).
AGAIN CARRY THIS PROCEDURE OUT TWICE, ONCE FOR OWA AND ONCE FOR ECP
From ADFS Management > Relying Party Trusts > Select your OWA Trust > Edit Claim Issuance Policy > Add Rule.
The WAP server either needs a Static public IP address that is registered in public DNS to the URLS you will be pointing to it, or HTTPS port forwarding form the firewalls outside IP address to the internal IP of the WAP server, (if you don’t have spare public IP addresses).
WAP Server requires TCP Port 443 (HTTPS) open TO it from the outside world.
WAP Server requires TCP Port 443 (HTTPS) open FROM it to BOTH the exchange server and the ADFS Server.
Installing Web Application Proxy
To be honest, this is pretty simple, the server itself does not have to be a domain member (which is good for a DMZ server!) For productions I’d disable the local administrator account and harden the server somewhat also. Make sure you have a copy of your wildcard certificate on this server also.
Server Manger > Manage > Add Roles and Features > Next > Next > Next > ‘Remote Access’ > Next > Next > Next > “Web Application Proxy” > Next > Install
Launch the post deployment configuration wizard > Next.
Enter the FQDN of your ADFS Server, and administrative credentials > Next > Select Your Wildcard Certificate > Next.
Configure > Close.
All being well the Remote Access management console should open and should show ‘All Green’ on the Operational Status.
Configure Web Application Proxy for OWA and ECP
Navigate to > Configuration > Web Application Proxy > Publish > Next.
Select Active Directory Federation Services > Next > Select ‘Web and MSOFBA > Next.
Select the ‘Relying Trust’ object that WAP can see for Outlook Web app > Next > Give the Published Rule a Name > Set the Public URL > Select the wildcard certificate > Set the Backend URL > Next.
Publish > Close.
REPEAT TO PUBLISH ECP
When you have finished it should look something like this;
x
Solution – Step 4 Configure Exchange for ADFS Authentication
Your Exchange needs a copy of the ADFS Signing certificate, this certificate is a ‘self signed’ certificate created on the ADFS server itself, you can find it here;
By Default this certificate only lasts a year, and will need to be manually imported onto Exchange, you can change the certificate duration by suing the following PowerShell and changing the Day value, (in this example to three years).
Exporting the ADFS Signing Certificate
With the certificate selected, navigation to the ‘Details‘ tab > Copy to File > Follow the instructions, (accept the defaults).
Importing the ADFS Signing Certificate Into Exchange
Physically copy the exported certificate to the Exchange server, and double click it > Install Certificate > Local Machine > Next > Place Into the Following Store > Trusted Root Certification Authorities > Next > Finish.
Now the certificate has been imported you need to get its thumbprint, open and Exchange Administration Console, and issue the following command. locate the ADFS certificate and copy its thumbprint to the clipboard.
Finally you need to set the OWA and ECP virtual directories to accept ADFS authentication, then restart the IIS services, to make the changes take effect.
[box]
Set-EcpVirtualDirectory -Identity "EX-SERVER\ecp (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
Set-OwaVirtualDirectory -Identity "EX-SERVER\owa (Default Web Site)" -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
net stop was /y
net start w3svc
SHA CERTIFICATE WARNING: Note This article was written some time ago, ensure your CA environment does NOT use SHA1 for your certificates, if it does, Please visit the following link for migration instructions;
I need to setup wireless authentication based on computer certificates, I’ve done similar jobs before by manually issuing certificates for Cisco AnyConnect, but this will be for NAP/RADIUS authentication to MSM. I’ll be working with Server 2008 R2 and Windows 7 clients. So task one was getting my head round ‘auto enrollment’. As stated I’m deploying Computer certificates but the process is practically the same for issuing User certificates (I’ll point out the differences where applicable).
Solution
Prerequisites: A Windows domain environment, with working DNS.
Setup a Certification Authority
1. Launch Server Manager (Servermanager.msc) Roles > Add Roles > Active Directory Certificate Services > Next > I’m going to accept all the defaults.
2. The only thing I’m going to change is the lifetime, I usually change that from 5 to 10 years (force of habit, after 5 years it will probably still be my problem, in 10 years it will be replaced, or in a skip!)
Create a Computer Certificate Template and Issue it.
4. Locate and make a copy of the Workstation Authentication template. If you were using User certificates the you would copy the User template.
Note: I got an email a few months ago form someone who had an argument about whether to make copies or edit the originals, and was asking what I thought was best practice. Well I would ALWAYS copy a template and edit that copy. Then if you ‘stuff it up’ you still have the original. It’s always best practice to avoid looking like a cretin!
5. If you still have Server 2003 servers choose the default, if not pick 2008 > OK.
6. General Tab > Give the template a sensible name.
7. Subject Name Tab: Tick User principle name (UPN).
8. Security Tab: Ensure Domain Computers have the rights to Read and Autoenroll > OK > Close the template console.
9. Certificate templates > New > Certificate Template to Issue.
10. Pick the one you just created > OK.
11. Make sure it’s listed > Close the Certificate Authority management console.
Deploy Auto-enrolled Certificates via Group Policy
Note: You could just add this to the to the default domain group policy, and all computers would get a certificate, but for this exercise I’ve created an OU, and I’m going to create a new policy and link it there.
12. Select an OU or container that contains the computer objects you want to send certificates to.
Note: Obviously if you are sending out User certificates then link it to a user OU, (you would be surprised!)
13. Navigate to;
[box]
Computer Certificate Auto-Enrollment
Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment
User Certificate Auto-Enrollment
User Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrolment
[/box]
WARNING: If deploying user certificates read this article.
14. Enable the policy > Select the two options available > Apply > OK > Close the GPO management editor.
Test Windows Certificate Auto-Enrollment
15. Before we do anything else, you can see there are no certificates on the Windows 7 client machine, and there are no certificates ‘issued’ from the server.
Note: To see a computers certificates, you need to be logged in with administrative rights, run mmc and add in the certificates snap-in for ‘local computer’.
16. Now if I move this machine into the OU that I’ve linked the GPO to.
17. And then force that client to refresh its group policies, (or reboot it).
18. Now when you check, you can see it has received a certificate, and the server is now showing one certificate issued.
Now I’ve got to work out NAP and RADIUS and force them to use the certificates, but I’ve got a headache and I need a brew, watch this space….
Related Articles, References, Credits, or External Links