ADFS 4.0 Step by Step Guide: Federating With Google Apps

To integrate On-Premises SSO with Google Apps, you need the following items:

Step1: Export ADFS Token Signing Certificate

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Certificate
  3. Right-click the certificate and select View Certificate.
  4. Select the Details tab.
  5. Click Copy to File. The Certificate Export Wizard opens.
  6. Select Next. Ensure the No, do not export the private key option is selected, and then click Next.
  7. Select DER encoded binary X.509 (.cer), and then click Next.
  8. Select where you want to save the file and give it a name. Click Next.
  9. Select Finish.

Step2: Download Google Certificate

  1. Login to Google Admin console with administrator permission to add new apps.
  2. Go to Apps > SAML Appsand click “+” at the right bottom of the page to add a new SAML IDP (“Enable SSO for SAML Application”).
  3. Select the “Setup my own custom app” at the bottom of the window. You will see the “Google IdP Information” page. Click Download button to retrieve google certificate.

Step3: Create a Relying Party Trust

  1. Log into the ADFS 2016 server and open the management console.
  2. Right-click Service>Relying Party Trusts>Select Add Relying Party Trust from the top right corner of the window.
  3. Click Claims aware>Click Start
  4. Click Enter Data about the relying party manually
  5. Give it a display name such as GoogleApps>Click Next>Click Next
  6. On the Configure URL Page, Check Enable support for the SAML 2.0 WebSSO protocol and type  https://www.google.com/a/domain.com/acs, Click Next
  7. On the Configure RP Identifier Page, type the identifiers: google.com/a/domain.com, Click Add
  8. Ensure I do not want to configure multi-factor authentication […] is chosen, and click Next
  9. Permit all users to access this relying party.
  10. Click Next and clear the Open the Claims when this finishes check box.
  11. Close this page. The new relying party trust appears in the window.
  12. Right-click on the relying party trust and select Properties.
  13. Select to the Advanced tab and set the Secure hash algorithm to SHA-256.
  14. Under the Endpoints tab, click Add SAML Logout with a Post binding and a URL of https://sts.domain.com/adfs/ls/?wa=wsignout1.0
  15. Select to signature tab, Click Add.. Import the google certificate, you have exported from Google admin console. Click Apply, Click Ok.

Step4: Add Claim Rule for the Relying Party

  1. Log into the ADFS server and open the management console.
  2. Right-click on the GoogleApps relying party trust and select Edit Claim Rules.
  3. Click the Issuance Transform Rules tab.
  4. Click Add Rules. Add a Rule Type the Name as GoogleApps Rule
  5. Ensure Send LDAP Attributes as Claims is selected, and click Next
  6. Select the below details
  • Claim Rule Name =  Send Email Address As NameID
  • Attribute Store = Active Directory
  • LDAP Attribute = E-mail-Addresses
  • Outgoing Claim Type = Name-ID
  1. Click Finish. Click Apply

Step5: Configure Google Apps in Admin Console

  1. Sign into the Google Apps Admin Console using your administrator account.
  2. Click Security. If you don’t see the link, it may be hidden under the More Controls menu at the bottom of the screen.
  3. On the Security page, click Setup single sign-on (SSO).
  4. Perform the following configuration changes:
  1. In Google Apps, for the Verification certificate, replace and upload the ADFS token signing certificate that you have downloaded from ADFS.
  2. Click Save Changes.

Step6: Testing SSO

To test SSO, visit http://mail.google.com/a/domain.com.  You will be redirected to ADFS STS Signing Page. Enter your on-premises email address and password as the credential.  You should be redirected back to Google Apps and arrive at your mailbox.

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part II

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part I

Assumption:

I assume you have the following infrastructure ready.

  • Domain Controller: DC1PVDC01
  • Certificate Authority: DC1PVCA01
  • AD FS Server: DC1PVADFS01
  • Exchange Server: DC1PVEXCH01

Naming Convention:

  • DC1= Data Center 1 (location)
  • P=Production Systems
  • V=Virtual Server
  • DC=Domain Controller

So on so forth.

Proposed Web Application Proxy Server:

Option Description
Virtual Machine Name DC1PVWAP01
Memory 4GB
vCPU 1
Hard Disk 1 50GB
Network Adapter 2
Guest Operating System Windows Server 2012 R2
Hyper-v Integration Service Installed

Windows Server Role:

Role Web Application Proxy

 

Network Configuration

The network adapter name used within the operating system should be changed to closely match the associated WAP network name. The following binding order will be maintained within Windows operating systems:

  1. First in Order- WAP internal adapter connected to the trusted network.
  2. Second in Order- WAP external adapter connected to the un-trusted network.

The following are the network configuration for WAP server.

Option IP Address Subnet Default Gateway DNS
Internal Network 10.10.10.2 255.255.255.0 Not required 10.10.10.1
External Network 192.168.1.1 255.255.255.0 192.168.1.254 Not required

Important! External Network can be assigned public IP if WAP server isn’t placed behind frontend router/firewall. In an edge configuration WAP external network is configured with public IP and internal network is assigned an IP address of internal IP range.

Configuration Step 1 – Rename Network Adapters:

Rename all network adapters to descriptive names that ideally match the connection type and WAP wizard/console names. For example:

  • WAP adapter connected to the trusted network: Internal Network
  • WAP adapter connected to the un-trusted network: External Network

Configuration Step 2 – Configure Network Adapters:

The Internal Network adapter will normally be connected to your trusted environment. This could be your actual internal network (LAN) or could be a private DMZ (perimeter network) if using an intranet/back firewall.

Internal Network Adapter

  • Default Gateway should not be defined
  • DNS Servers should be defined
  • Client for Microsoft Networks binding – Enabled
  • File and Print Sharing for Microsoft Networks binding – Enabled
  • Register this connection’s address in DNS – Enabled
  • Enable LMHOSTS Lookup – Disabled
  • NetBIOS over TCP/IP – Default

The External Network adapter will normally be connected to your un-trusted environment. This could be your actual Internet connection if using an edge deployment, or could be a public DMZ (perimeter network) if using an existing edge/front firewall.

External Network Adapter

  • Default Gateway should be defined
  • DNS Servers should not be defined
  • Client for Microsoft Networks binding – Disabled
  • File and Print Sharing for Microsoft Networks binding – Disabled
  • Register this connection’s address in DNS – Disabled
  • Enable LMHOSTS Lookup – Disabled
  • NetBIOS over TCP/IP – Disabled

Please Note: The ‘File and Print Sharing for Microsoft Networks’ binding on the TMG internal adapter is left at the default settings of Enabled on the WAP Internal Network adapter. This allows for the use of the Internal Network adapter for intra-array services when using a WAP cluster.

Configuration Step 3 – Amend Bind Order:

Edit the network adapter bind order to place the Internal Network adapter at the top (highest) position and the External Network at the bottom (lowest) position. For example:

  1. Internal Network (Highest)
  2. External Network (Lowest)

To amend network binding follow the steps below:

1. Click Start, click Network, click Network and Sharing Center, and then click Change Adapter Settings.

2. Press the ALT key, click Advanced, and then click Advanced Settings. If you are prompted for an administrator password or confirmation, type the password or provide confirmation.

3. Click the Adapters and Bindings tab, and then, under Connections, click the connection you want to modify.

4. Under Bindings for <connection name>, select the protocol that you want to move up or down in the list, click the up or down arrow button, and then click OK.

DNS Forwarding:

The following Fully Qualified Domain Names (FQDN) will be forwarded from ISP to your router:

Purpose Public Host Name Public IP Address
Exchange webmail.yourdomain.com 203.17.x.x
SharePoint sharepoint.yourdomain.com 203.17.x.x

 

External Firewall Rules

The following NAT rules will be added into perimeter network to publish application and services through WAP. This rule is only apply if you please Web Application Proxy (WAP) behind a firewall or Cisco ASA otherwise you don’t need it.

Rule(s) Description Source IP Destination IP Address Port NAT Destination
1 Exchange Any 203.17.x.x 443 192.168.1.2
2 SharePoint Any 203.17.x.x 443 192.168.1.3

 

Building Web Application Proxy Server on Windows Server 2012 R2 Steps:

  1. Install Windows Server 2012 R2.
  2. Configure TCP/IP of Windows Server 2012 R2
  3. Join Web Application Proxy server to Domain
  4. Install Web Application Proxy Role
  5. Configure Kerberos Constraint Delegation
  6. Configure the firewall to allow HTTPS traffic on port 443 for clients to communicate with the AD FS server
  7. Configure Firewall if WAP Server placed behind a Cisco ASA
  8. Install Public certificate into Web Application Proxy Server
  9. Publish Application

Configure Kerberos Constraint delegation

1. On the domain controller, open Server Manager. To do this, click Server Manager on the Start screen.

2. Click Tools, and then click ADSI Edit.

3. On the Action menu, click Connect To, and then on the Connection Settings dialog box, accept the default settings to connect to the default naming context, and then click OK.

4. In the left pane, expand Default naming context, expand DC=yourdomain, DC=com, expand CN=Computers, right-click CN=DC1PVWAP01, and then click Properties.

5. On the CN=DC1PVWAP01 Properties dialog box, on the Attribute Editor tab, in the Attributes list, select servicePrincipalName, and then click Edit.

6. On the Multi-valued String Editor dialog box, in Value to add, enter HTTP/DC1PVWAP01.yourdomain.com and click Add. Then enter HTTP/DC1PVWAP01 and click Add. The Values list now contains two new entries; for example, HTTP/DC1PVWAP01.yourdomain.com and HTTP/DC1PVWAP01.

7. On the Multi-valued String Editor dialog box, click OK.

8. On the CN=DC1PVWAP01 Properties dialog box, click OK.

9. In Server Manager, click Tools, and then click Active Directory Users and Computers.

10. In the navigation pane, under yourdomain.com, click Computers. In the details pane, right-click the Web Application Proxy server, and then click Properties.

11. On the DC1PVWAP01 Properties dialog box, on the Delegation tab, click Trust this computer for delegation to specified services only, and then click Use any authentication protocol.

12. Click Add, and on the Add Services dialog box, click Users or Computers.

13. On the Select Users or Computers dialog box, in Enter the object names to select, enter the name of the web servers that use Integrated Windows authentication; for example, WebServ1, and then click OK.

14. On the Add Services dialog box, in the Available services list, select the http service type, and then click OK.

15. On the DC1PVWAP01 Properties dialog box, click OK.

Configure AD FS (Optional when using pass-through pre-authentication)

1. On the Start screen, type AD FS Management, and then press ENTER.

2. Under the AD FSTrust Relationships folder, right-click Relying Party Trusts, and then click Add Relying Party Trust to open the Add Relying Party Trust Wizard.

3. On the Welcome page, click Start.

4. On the Select Data Source page, click Import data about the relying party published online or on a local network. In Federation metadata address (host name or URL), type the federation metadata URL or host name for the partner, and then click Next.

5. On the Specify Display Name page type a name in Display name, under Notes type a description for this relying party trust, and then click Next.

6. On the Choose Issuance Authorization Rules page, select either Permit all users to access this relying party then click Next.

7. On the Ready to Add Trust page, review the settings, and then click Next to save your relying party trust information.

8. On the Finish page, click Close. This action automatically displays the Edit Claim Rules dialog box. For more information about how to proceed with adding claim rules for this relying party trust, see the Additional references.

9. in the AD FS Management console, you must set the endpoint to be Proxy Enabled

Configure Certificate Template in CA

Note: This steps is only applicable when using Enterprise certificate authority.

1. Open the Certificate Templates snap-in.

2. In the details pane, right-click an existing certificate that will serve as the starting point for the new certificate, and then click Duplicate Template.

3. Choose whether to duplicate the template as a Windows Server 2003–based template or a Windows Server 2008–based template.

4. On the General tab, enter the Template display name and the Template name, and then click OK.

5. Define any additional attributes such as mark “private key exportable” for the newly created certificate template.

Export & Import Certificates into Web Application Proxy Server

This is a very important steps for published app to work correctly. You must export .pfx certificate from application servers (Exchange, SharePoint or Lync Server) to Web Application Proxy Server so that internet explorer, web application proxy server and application servers validate same certificates.

Exporting a .pfx File

  1. On the Start menu click Run and then type mmc.
  2. Click File > Add/Remove Snap-in.
  3. Click Certificates > Add.
  4. Select Computer Account and then click Next. Select Local Computer and then click Finish. Then close the add standalone snap-in window and the add/remove snap-in window.
  5. Click the + to expand the certificates (local computer) console tree and look for the personal directory/folder. Expand the certificates folder.
  6. Right-click on the certificate you want to backup and select ALL TASKS > Export.
  7. Choose Yes, export the private key and include all certificates in certificate path if possible.
    Warning: Do not select the delete private key option.
  8. Leave the default settings and then enter your password if required.
  9. Choose to save the file and then click Finish. You should receive an “export successful” message. The .pfx file is now saved to the location you selected.

Importing from a .pfx File

  1. On the Start menu click Run and then type mmc.
  2. Click File > Add/Remove Snap-in.
  3. Click Certificates > Add.
  4. Select Computer Account and then click Next. Select Local Computer and then click Finish. Then close the add standalone snap-in window and the add/remove snap-in window.
  5. Click the + to expand the certificates (local computer) console tree and look for the personal directory/folder. Expand the certificates folder.
  6. Right-click on the certificate you want to backup and select ALL TASKS > Import.
  7. Follow the certificate import wizard to import your primary certificate from the .pfx file. When prompted, choose to automatically place the certificates in the certificate stores based on the type of the certificate.

Install Web Application Proxy Role

1. On the Web Application Proxy server, in the Server Manager console, in the Dashboard, click Add roles and features.

2. In the Add Roles and Features Wizard, click Next three times to get to the server role selection screen.

3. On the Select server roles dialog, select Remote Access, and then click Next.

4. Click Next twice.

5. On the Select role services dialog, select Web Application Proxy, click Add Features, and then click Next.

6. On the Confirm installation selections dialog, click Install.

7. On the Installation progress dialog, verify that the installation was successful, and then click Close.

Configure Web Application Proxy

1. On the Web Application Proxy server, open the Remote Access Management console: On the Start screen, click the Apps arrow. On the Apps screen, type RAMgmtUI.exe, and then press ENTER. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Yes.

2. In the navigation pane, click Web Application Proxy.

3. In the Remote Access Management console, in the middle pane, click Run the Web Application Proxy Configuration Wizard.

4. On the Web Application Proxy Configuration Wizard, on the Welcome dialog, click Next.

5. On the Federation Server dialog, do the following, and then click Next:

  • In the Federation service name box, enter the fully qualified domain name (FQDN) of the AD FS server; for example, fs.yourdomain.com.
  • In the User name and Password boxes, enter the credentials of a local administrator account on the AD FS servers.

6. On the AD FS Proxy Certificate dialog, in the list of certificates currently installed on the Web Application Proxy server, select a certificate to be used by Web Application Proxy for AD FS proxy functionality, and then click Next.

7. The certificate you choose here should be the one that whose subject is the Federation Service name, for example, fs.yourdomain.com.

8. On the Confirmation dialog, review the settings. If required, you can copy the PowerShell cmdlet to automate additional installations. Click Configure.

9. On the Results dialog, verify that the configuration was successful, and then click Close.

Publish Application using AD FS Pre-Authentication

1. On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.

2. On the Publish New Application Wizard, on the Welcome page, click Next.

3. On the Pre-authentication page, click Active Directory Federation Services (AD FS), and then click Next.

4. On the Relying Party page, in the list of relying parties select the relying party for the application that you want to publish, and then click Next.

5. On the Publishing Settings page, do the following, and then click Next:

  • In the Name box, enter a friendly name for the application.
  • This name is used only in the list of published applications in the Remote Access Management console.
  • In the External URL box, enter the external URL for this application; for example, https://sp.yourdomain.com/app1/.
  • In the External certificate list, select a certificate whose subject covers the external URL.
  • In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL and you should change it only if the backend server URL is different; for example, http://sp/app1/.
  • Web Application Proxy can translate host names in URLs, but cannot translate path names. Therefore, you can enter different host names, but you must enter the same path name. For example, you can enter an external URL of https://apps.yourdomain.com/app1/ and a backend server URL of http://app-server/app1/. However, you cannot enter an external URL of https://apps.yourdomain.com/app1/ and a backend server URL of https://apps.yourdomain.com/internal-app1/.

6. On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.

7. On the Results page, make sure that the application published successfully, and then click Close.

Publish an integrated Windows authenticated application

1. On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.

2. On the Publish New Application Wizard, on the Welcome page, click Next.

3. On the Pre-authentication page, click Active Directory Federation Services (AD FS), and then click Next.

4. On the Relying Party page, in the list of relying parties select the relying party for the application that you want to publish, and then click Next.

5. On the Publishing Settings page, do the following, and then click Next:

  • In the Name box, enter a friendly name for the application.
  • This name is used only in the list of published applications in the Remote Access Management console.
  • In the External URL box, enter the external URL for this application; for example, https://owa.yourdomain.com/.
  • In the External certificate list, select a certificate whose subject covers the external URL.
  • In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL and you should change it only if the backend server URL is different; for example, http://owa/.
  • Web Application Proxy can translate host names in URLs, but cannot translate path names. Therefore, you can enter different host names, but you must enter the same path name. For example, you can enter an external URL of https://apps.yourdomain.com/app1/ and a backend server URL of http://app-server/app1/. However, you cannot enter an external URL of https://apps.yourdomain.com/app1/ and a backend server URL of https://apps.yourdomain.com/internal-app1/.
  • In the Backend server SPN box, enter the service principal name for the backend server; for example, HTTP/owa.yourdomain.com.

6. On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.

7. On the Results page, make sure that the application published successfully, and then click Close.

Publish Application using Client Certificate Pre-Authentication

You can publish an application using pre-authenticated client certificate. This steps only be performed using Windows PowerShell. Open Elevated Windows PowerShell prompt in WAP Server. Change the following command as required and issue the command.

Add-WebApplicationProxyApplication

-BackendServerURL ‘https://app.yourdomain.com/&#8217;

-ExternalCertificateThumbprint ‘1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b’

-ExternalURL ‘https://app.yourdomain.com/&#8217;

-Name ‘Client certificate preauthentication application’

-ExternalPreAuthentication ClientCertificate

-ClientCertificatePreauthenticationThumbprint ‘123456abcdef123456abcdef123456abcdef12ab’

Publish Application using Pass-through Pre-Authentication

1. On the Web Application Proxy server, in the Remote Access Management console, in the Navigation pane, click Web Application Proxy, and then in the Tasks pane, click Publish.

2. On the Publish New Application Wizard, on the Welcome page, click Next.

3. On the Preauthentication page, click Pass-through, and then click Next.

4. On the Publishing Settings page, do the following, and then click Next:

  • In the Name box, enter a friendly name for the application.
  • This name is used only in the list of published applications in the Remote Access Management console.
  • In the External URL box, enter the external URL for this application; for example, https://maps.yourdomain.com/.
  • In the External certificate list, select a certificate whose subject covers the external URL.
  • In the Backend server URL box, enter the URL of the backend server. Note that this value is automatically entered when you enter the external URL and you should change it only if the backend server URL is different; for example, http://maps/.
  • Web Application Proxy can translate host names in URLs, but cannot translate path names. Therefore, you can enter different host names, but you must enter the same path name. For example, you can enter an external URL of https://apps.yourdomain.com/app1/ and a backend server URL of http://app-server/app1/. However, you cannot enter an external URL of https://apps.yourdomain.com/app1/ and a backend server URL of https://apps.yourdomain.com/internal-app1/.

5. On the Confirmation page, review the settings, and then click Publish. You can copy the PowerShell command to set up additional published applications.

6. On the Results page, make sure that the application published successfully, and then click Close.

Publish Application using Windows Store App or Oauth2

You can publish an application using pre-authenticated Windows Store App. This steps only be performed using Windows PowerShell. Open Elevated Windows PowerShell prompt in WAP Server. Change the following command as required and issue the command.

Set-WebApplicationProxyConfiguration –OAuthAuthenticationURL ‘https://fs.yourdomain.com/adfs/oauth2/&#8217;

Add-WebApplicationProxyApplication

-BackendServerURL ‘https://storeapp.yourdomain.com/&#8217;

-ExternalCertificateThumbprint ‘1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b’

-ExternalURL ‘https://storeapp.yourdomain.com/&#8217;

-Name ‘Windows Store app Server’

-ExternalPreAuthentication ADFS

-ADFSRelyingPartyName ‘Store_app_Relying_Party’

-UseOAuthAuthentication

Part 1: Install and Configure Forefront UAG Step by Step

Part 2: Publish RDS using Forefront UAG 2010 Step by Step

Part 3: Publish Exchange Server 2010 Using Forefront UAG 2010 Step by Step

Part 4: Redirect Web Application from HTTP to HTTPS using Forefront UAG 2010 Step by Step

Part 5: Publish SharePoint Server 2010 Using Forefront UAG 2010 Step by Step

Part 6: Forefront UAG Patching Order

Forefront TMG 2010: How to install and configure Forefront TMG 2010 —-Step by step

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part I

Deploy Web Application Proxy Role in Windows Server 2012 R2 –Part II

Web Application Proxy is a role in Windows Server 2012 R2. Web Application Proxy brings some functionality of Microsoft Forefront TMG and Microsoft Forefront UAG but not all of them. Since Microsoft phased out Forefront product line except FIM. Web Application Proxy provides functionality or role in Windows Server 2012 R2 for customer who still wants use Microsoft platform to publish their application such as Exchange 2013, Lync 2013 and SharePoint 2013 to external clients and vendors.

Web Application Proxy provides pre-authentication and authorization method using Active Directory Federation Services including multifactor authentication and access control. Deployment of ADFS is separate to Web Application Proxy which means you must have a separate server hosting ADFS role.

Benefits of Web Application Proxy

  • Pre-authentication—Only authenticated traffic can get into the corporate network.
  • Network Isolation—Incoming web traffic cannot directly access backend servers.
  • Selective Publishing—Only specific applications and paths within these applications are accessible.
  • DDoS Protection—Incoming traffic arrives at Web Application Proxy before hitting the corporate network. Because Web Application Proxy acts as a proxy, many DDoS attacks can be prevented from reaching the backend servers.
  • Selective Ports- Apply deny ALL and allow selected ports. This policy will prevent SQL injection.
  • Extended validation– URL validation and verification using public certificate authority. Support strong security and encryption using SHA and 2048 bit certificate encryption.

Web Application Proxy Infrastructure

  • Active Directory Domain Services (AD DS)
  • Internal Domain Naming System (DNS)
  • External DNS Name Resolver or ISP
  • Active Directory Federation Services (AD FS)
  • Active Directory Certificate Services (AD CS)
  • Web Application Proxy Server(s)
  • Public Certificate Authority
  • Internal Enterprise Certificate Authority
  • Backend Application Server(s)

Web Application Proxy Network

Web Application proxy can be deployed in several topologies. In all these scenario Web Application Proxy needs two network adapter.

Edge Firewall: Behind a frontend firewall like Cisco ASA to separate it from internet. Firewall must allow HTTPS (443) traffic to and from Web Application Proxy server.

DMZ: Behind a frontend firewall like Cisco ASA to separate it from internet and before corporate firewall like Cisco ASA to separate it from corporate network. Firewall must allow HTTPS (443) traffic to and from Web Application Proxy server. For client certificate authentication, you must also configure the firewall to allow traffic on port 49443.

Edge Configuration: One network adapter directly connected to internet and another network adapter connected to corporate network. Web Application Proxy can be a member of an Active Directory Domain.

TCP/IP Configuration Examples

Scenario Internal NIC External NIC
non-domain joined IP: 10.10.10.20Subnet: 255.255.255.0

Gateway: 10.10.10.254

DNS:10.10.10.21

IP:192.168.0.10Subnet: 255.255.255.0

Gateway: NIL

DNS: NIL

Domain Joined IP: 10.10.10.20Subnet: 255.255.255.0

Gateway: NIL

DNS:10.10.10.21

IP: 203.17.x.x Public IPSubnet: 255.255.255.0

Gateway:203.17.x.254 Public Gateway

DNS: 8.8.8.8 or Public DNS

DNS Requirement

  • Internal DNS: Web Application Proxy must resolve internal fully qualified domain name of backend application server such as Exchange or SharePoint server. You must configure correct DNS record and TCP/IP Settings of Web Application Proxy Server either using DNS server or editing hosts file in WindowsSystems32DriversEtc location.
  • External DNS: External client must resolve fully qualified domain name of application. In this case, you must configure HOST (A) record in public DNS server. Note that the external URL must resolve to the external IP address of the Web Application Proxy server, or the external IP address of a firewall or load-balancer placed in front of the Web Application Proxy server.

Load Balancer Consideration

Web Application Proxy does not have in-built load balancer or ISP redundancy functionality. Depending on your requirements, you can use any hardware or software load-balancer to balance load between two or more Web Application Proxy Servers.

Domain Joined or non-domain joined

Web Application Proxy can be deployed without joining the server to an Active Directory domain or by joining the Web Application Proxy server to a standalone domain in a perimeter network.

You can deploy Web Application Proxy with a read-only domain controller. However, if you want to deploy Web Application Proxy and DirectAccess on the same server, you cannot use a read-only domain controller.

Authentication Consideration

Web Application Proxy can work with the following authentication protocols.

  • AD FS pre-authentication
  • Integrated Windows authentication
  • Pass-through pre-authentication

Network Time Protocol (NTP)

You must have a proper NTP server in your organization. NTP server can be your domain controller or a Cisco Core Switch. Timestamp must identical between AD FS and Web Application Proxy Server.

Certificate Authority

There are two types of certificate requirements for Web Application Proxy Server- Public CA and Enterprise CA.

  • Public CA: External clients to be able to connect to published web applications using HTTPS, Web Application Proxy must present a certificate that is trusted by clients. In this case you must bind a public certificate with published application in backend server and web application proxy server.
  • Enterprise CA: AD FS certificates must match federation service value. AD FS can use internal Enterprise CA. For examples, Common Name (CN) of Certificate is adfs.superplaneteers.com

Supported Certificate Template

Web Server Certificate with single common name, subject alternative name (SAN) certificates, or wildcard certificates.

Pass-Through Pre-Authentication

When you publish Exchange and SharePoint using Web Application proxy Server, you can pass-through authentication to the specific application instead of AD FS or Web Application Proxy. In this case Web Application Proxy forwards the HTTPS request directly to the backend server using either HTTP or HTTPS. Pass-through authentication is still a worry-free deployment because it prevent DDoS and SQL injection and provide network isolation.

Replace Common Name (CN) and SAN Certificates with Wild Card Certificate— Step by Step

If you have a Common Name certificate or Subject Alternative Name certificate in Exchange webmail or other website and you would like to change that to wild card certificate to consolidate your certificate uses in wide variety of infrastructure and save money. You can do so safely with a minor downtime with no or little loss of productivity.

Microsoft accept certified SSL provider which are recorded in this url http://support.microsoft.com/kb/929395/en-us

Here is a guide lines how to accomplish this objective.

Step1: Check Current Exchange SSL Certificate

Open Exchange Management Shell and Issue Get-ExchangeCertificate Command. Record the information for future reference.

Step2: Record Proposed Exchange SSL Wildcard Certificate

  • Common Name: *.yourdomain.com.au
  • SAN: N/A
  • Organisation: Your Company
  • Department: ICT
  • City: Perth
  • State: WA
  • Country: Australia
  • Key Size: 2048

Step3: Generate a wildcard certificate request

You can use https://www.digicert.com/easy-csr/exchange2007.htm to generate a certificate command for exchange server.

New-ExchangeCertificate -GenerateRequest -Path c:star_your_company.csr -KeySize 2048 -SubjectName “c=AU, s=Western Australia, l=Perth, o=Your Company, ou=ICT, cn=*.yourdomain.com.au” -PrivateKeyExportable $True

Step4: Sign the certificate request and download SSL certificate in PKCS#7 format

For more information, you can go to help file of your certificate provider. But for example I am using rapidSSL. Reference https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&id=SO14293&actp=search&viewlocale=en_US&searchid=1380764656808

1. Click https://products.geotrust.com/geocenter/reissuance/reissue.do

2. Provide the common name, technical contact e-mail address associated with the SSL order,
and the image number generated from the Geotrust User Authentication page.

3. Select Request Access against the correct order ID. An e-mail will be sent to the technical contact e-mail address specified above.

4. Click on the link listed in the e-mail to enter the User Portal Click View Certificate Information. Select the appropriate PKCS#7 or  X.509 format from the drop down menu depending on the server requirements. NOTE: Microsoft IIS users select PKCS#7 format and save the file with .p7b extension.

5. Save the certificate locally and install per the server software. 

Step5: Locate and Disable the Existing CA certificate

Now this step is a disruptive step for webmail. You must do it after hours.

1. Create a Certificate Snap-In in Microsoft Management Console (MMC) by following the steps from this link: SO14292

2. With the MMC and the Certificates snap-in open, expand the Trusted Root Certification Authorities folder on the left and select the Certificates sub-folder.

3. Locate the following certificate in the MMC: If this certificate is present, it must be disabled. Right click the certificate, Select Properties

4. In the Certificate purposes section, select  Disable all purposes for this certificate
Click OK to close the MMC without saving the console settings.

Step6: Install Certificate

To install a SSL certificate onto Microsoft Exchange, you will need to use the Exchange
Management Shell (EMS). Microsoft reference http://technet.microsoft.com/en-us/library/bb851505(v=exchg.80).aspx

1. Copy the SSL certificate file, for example newcert.p7b and save it to C: on your Exchange server.

2. Run the Import-ExchangeCertificate and Enable-ExchangeCertificate commands together. For Example

Import-ExchangeCertificate -Path C:newcert.p7b | Enable-ExchangeCertificate –Services  “SMTP, IMAP, POP, IIS”

3. Verify that your certificate is enabled by running the Get-ExchangeCertificate command.

For Example Get-ExchangeCertificate -DomainName yourdomain.com.au

4. In the Services column, letters SIP and W stand for SMTP, IMAP, POP3 and Web (IIS). If your certificate isn’t properly enabled, you can re-run the Enable-ExchangeCertificate command by pasting the thumbprint of your certificate as the -ThumbPrint argument such as: Enable-ExchangeCertificate -ThumbPrint [paste] -Services ” IIS”

Step7: Configure Outlook settings

Microsoft reference http://technet.microsoft.com/en-us/library/cc535023(v=exchg.80).aspx

To use the Exchange Management Shell to configure Autodiscover settings by using the Set-OutlookProvider cmdlet if you are using Exchange 2007.

Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.yourdomain.com.au

To change Outlook 2007 connection settings to resolve a certificate error

1. In Outlook 2007, on the Tools menu, click Account Settings.

2. Select your e-mail address listed under Name, and then click Change.

3. Click More Settings. On the Connection tab, click Exchange Proxy Settings.

4. Select the Connect using SSL only check box.

5. Select the Only connect to proxy servers that have this principal name in their certificate: check box, and then, in the box that follows, enter msstd:*.yourdomain.com.au.

6. Click OK, and then click OK again.

7. Click Next. Click Finish. Click Close.

8. The new setting will take effect after you exit Outlook and open it again.

Step8: Export Certificate from Exchange in .pfx format

The following Step8 to Step 10 is for Forefront TMG 2010 configuration only. If you are using different method to publish Exchange then you don’t need to follow these steps. Use help file of your firewall/Edge product to configure SSL.

Open Exchange Management Shell, run

Export-ExchangeCertificate -Thumbprint D6AF8C39D409B015A273571AE4AD8F48769C61DB

010e -BinaryEncoded:$true -Path c:certificatesexport.pfx -Password:(Get-Credential).password

Step9: Import certificate in TMG 2010

1.Click Start and select Run and tape mmc
2.Click on the  File menu and select   Add/Remove Snap in
3.Click  Add, select Certificates among the list of   Standalone Snap-in and click   Add
4.Choose   Computer Account and click   Next
5.Choose   Local Computer and click   Finish
6.Close the window and click OK on the upper window
7.Go to Personal then Certificates
8.Right click, choose All tasks then Import
9.A wizard opens. Select the file holding the certificate you want to import.
10.Then validate the choices by default
11.Make sure your certificate appears in the list and that the intermediary and root certificates are in their respective files. If not, place them in the appropriate file and replace existing certificates if needed.

Step10: Replace Certificate in Web Listener

1. click Start Forefront Threat Management Gateway console. The Forefront TMG console starts.

2. In the console tree, expand the name of your Security Server, and then click Firewall Policy.

3. In the results pane, double-click Remote Web Workplace Publishing Rule.

4. In Remote Web Workplace Publishing Rule Properties, click the Listener tab.

5. Select External Web Listener from the list, and then click Properties.

6. In External Web Listener Properties, click the Certificates tab.

7. Select Use a single certificate for this Web listener or Assign a certificate for each IP address, and then click Select Certificate.

8. In the Select Certificate dialog box, click a certificate in the list of available certificates, and then click Select. Click OK twice to close the Properties dialog boxes.

9. To save changes and update the configuration, in the results pane, click Apply.

Step11: Test OWA from external and internal network

On the mobile phone, open browser, type webmail.yourdomain.com.au and log in using credential.

Make sure no certificate warning shows on IE.

Use the RapidSSL Installation Checker https://knowledge.rapidssl.com/support/ssl-certificate-support/index?page=content&actp=CROSSLINK&id=SO9556 to verify your certificate.
 

Relevant References

Request an Internet Server Certificate (IIS 7)

Using wildcard certificates