The Web application proxy organizations can provide selective access to applications running on servers
inside the organization to users located outside of the organization.
The process to make the application extremely available is known as public.
Unlike traditional virtual private network or VPN solutions, users can access only the applications
that you publish through a web application proxy server dependent on support from the application.
Access to these applications can be from essentially an enterprise, including mobile devices.
In addition to publish and federation services.
The Republication Proxies server is widely used to publish browser applications such as those for SharePoint
Exchange and Remote Desktop Gateway and to other custom line of business or LLB applications.
In fact, it is also possible to publish to the background services that are consumed by non browser
applications.
Some alerts about configuring your rail sounds or certificates for each application that your publisher
must configure an external URL and an internal storage URL.
External users access the application by using the external URL.
The Web Application Process Server uses the internal server URL to access the application on behalf
of external users.
If you use split DNS, it is common to have the same value for both the external URL and the internal
server.
Some applications experience errors when the external URL and the internal server URL differ.
When the external URL and the background server URL differ only the hostname in the general change of
the path to the application remains the same.
For example, if the external URL for an application is issued to press server 1.8. com slash app one,
you can not have an external url for as st-pierre's extra nat .8. com slash application one.
When you define the external URL, you also need to select a certificate that contains the hostname
and the external URL.
This certificate must be installed on the local server.
However, it does not need to match the certificate used on the back server hosting the application.
You can have one certificate for each hostname used on the web application proxies server or a single
certificate.
There's multiple names, some words about publish in SharePoint Services.
You can publish a SharePoint site through a Web Application Proxies server, while the SharePoint scientists
configured for claims based authentication or AWOL.
If you prefer to use the files for authentication, you must configure a relying party by using one
of these methods.
You can.
If the SharePoint site uses claims based authentication, use the out relying party trust wizard to
configure the rely on part of trust for the application.
And if the SharePoint site uses AWOL.
Use the out known claims based Rampart part trust wizard to configure the underlying part of trust for
the application.
If you want to use RWA with a claims based web application, you must deploy the Kerberos key distribution
center to the domain controllers in the domain.
Please note that to authenticate the users by using RWA, you must join the.
Web application server to the demand to provide RWA access to web publication proxies.
Server must be able to provide the impersonation of users to the published application.
This impersonation is called Kerberos Constraint Delegation and the application should be configured
to support impersonation.
You should configure the web application proxies server for delegation to the service principal names
as spans of the back end users.
Now, if you can figure your SharePoint site by using alternate access mappings or hostnames hosted
named site collections, you can publish your application with different external and back sorry URLs.
However, if your SharePoint site is not configured by using alternate access mapping or host named
side collections, the external and backend server URLs must be the same.
Know some words about publish and exchange services.
Exchange Server provides multiple services for administrators and users, including Outlook Web App
Exchange Control Panel.
Outlook and Irreverent Exchange ActiveSync These services are independent with different URLs and different
authentication configurations.
Let's review the following options login services that you can publish through the Web Application Proxy
and the supported proof authentication type for these services.
First Services Outlook Web app the supported person to kitchen types for the services ADA first use
non claimed non claims based authentication pass through and their first use and claims based authentication
for issuance or 2013.
The Next Services exchange control panel.
And supported person to person type is passed through outlook anywhere person to kitchen type pass through
as well and to exchange ActiveSync pass through for the outlook and aware of service to function correctly,
you need to publish three URLs the auto discovery URL, the external hostname of the exchange server
that is the URL that outlook clients access and the internal of Q the end of the exchange server instance
to publish outlook by about by using w l you must use the and non claims based for one party trust wizard
to configure the Reliant Portal Trust for the application.
Please note that to allow users to authenticate by using RWA, you must join the web application proxies
server to the domain and to provide RWA access, you should configure the application on the web application
proxies server to support Kerberos constrained delegation.
You should also register as p m for the service account of the web service and configure the Web Application
Proxies server for delegation to the SBN of the background servers in a highly available exchange environment.
This should to use an alternate service account.
Note some words about publishing remote desktop gateway services.
Some organizations provide access to our DB Gateway services from the Internet directly to the Gateway
Server.
However, you might consider publishing R&D Gateway services through the Web Application Proxy.
If you want to restrict access to your R&D gateway and add authentication for remote users when planning
your deployment, you have two options for publishing are D Gateway Services through the Web Application
Proxy Option one Publishing the application by using pass for authentication.
This provides a single point of entry into your remote desktop environment, and option two is publishing
the application by using pre authentication.
Similarly to the way that your publisher claims based application is, use the app to rely on Portal
Trust Wizard to create a manual.
Rely on part two Trust to the Audit Gateway of your data.