Продолжаем знакомиться с новыми возможностями ОС Windows Server 2012 R2. Ранее мы рассказывали о корпоративном аналоге DropBox в Windows Server 2012 R2 под названием Work Folders. Сегодня речь пойдет о еще одном новшестве новой серверной платформы – функции Web Application Proxy. Web Application Proxy – это новая функция роли Remote Access в Windows 2012 R2, позволяющая публиковать HTTP/ HTTPS приложения, расположенные в периметре корпоративной сети на клиентских устройствах (в первую очередь подразумеваются мобильные устройства) за ее периметром. Благодаря возможности интеграции c AD FS (служба может выступать в качестве ADFS-прокси), возможно обеспечить аутентификацию внешних пользователей, пытающихся получить доступ к опубликованным приложениям.
Web Application Proxy предоставляет такие же возможности публикации приложений, как и Forefront Unified Access Gateway (UAG), однако данная служба также позволяет взаимодействовать с другими серверами и сервисами, обеспечивая тем самым более гибкую и рациональную конфигурацию.
Web Application Proxy по сути выполняет функцию обратного прокси сервера (HTTP reverse proxy), организуя ретрансляцию запросов клиентов из внешней сети на внутренний сервер, и является межсетевым экраном на прикладном уровне.
Сервер со службой Web Application Proxy получает внешний HTTP/HTTPS трафик и терминирует его, после чего от своего имени инициирует новое подключение ко внутреннему приложению (веб-серверу). Т.е. внешние пользователи прямого доступа к внутреннему приложению реально не получают. Любой другой трафик, получаемый Web Application Proxy, отклоняется (в том числе отклоняются HTTP/HTTPS запросы, которые могут быть использованы при DoS, SSL и 0-day атаках).
Требования к организации Web Application Proxy и ключевые особенности:
- Систему можно развернуть на серверах с ОС Windows Server 2012 R2, включенных в домен Active Directory, с ролями AD FS и Web Application Proxy. Эти роли должны быть установлены на разных серверах.
- Необходимо обновить схему Active Directory до Windows Server 2012 R2 (обновлять контроллеры домена до Windows Server 2012 R2 не нужно)
- В качестве клиентских устройств поддерживаются устройства с ОС Windows, IOS (iPad и iPhone). Работы над клиентами для Android и Windows Phone пока еще не окончены
- Аутентификация клиентов осуществляется службой Active Directory Federation Services (ADFS), которая также выполняет функции ADFS – проксирования.
- Типовая схема размещения сервера с ролью Web Application Proxy представлена на рисунке. Данный сервер располагается в выделенной DMZ зоне и отделен от внешней (Интернет) и внутренней сети (Интранет) межсетевыми экранами. В этой конфигурации для работы Web Application Proxy требует наличия двух интерфейсов – внутреннего (Intranet) и внешнего (DMZ)
Установка роли ADFS в Windows Server 2012 R2
Для обеспечения дополнительной безопасности преаутентифкация внешних клиентов выполняется на сервере ADFS, в противном случае используется pass-through аутентификация на конечном сервере приложения (что менее секьюрно). Поэтому первый шаг при настройке Web Application Proxy – установка на отдельном сервере роли Active Directory Federation Services.
При установке ADFS нужно выбрать SSL сертификат, который будет использоваться для шифрования, а также DNS имена, которые будут использоваться клиентами при подключении (соответствующие записи в DNS зоне придется создать самостоятельно).
Затем нужно указать сервисную учетную запись для службы ADFS. Необходимо учесть, что имя ADFS должно быть указано в атрибут Service Principal Name аккаунта. Сделать это можно командой:
setspn –F –S host/adfs.winitpro.ru adfssvc
И, наконец, указать базу данных, в которой будет хранится информация: это может быть встроенная база на этом же сервере (WID — Windows Internal Database) или отдельная база на выделенном SQL-сервере.
Установка службы Web Application Proxy
Следующий этап, настройка самой службы Web Application Proxy. Напомним, что служба Web Application Proxy в Windows Server 2012 R2 является частью роли “Remote Access”. Установите службу Web Application Proxy и запустите мастер ее настройки.
На первом этапе мастер предложит Вам указать имя ADFS сервера и параметры учетной записи, имеющей доступ к данной службе.
Далее нужно указать сертификат (убедитесь, что в альтернативных именах сертификата содержится имя сервера ADFS).
Совет. Проверьте, что ваши DNSзоны настроены корректно: сервер с ролью WAP должен иметь возможность отрезолвить имя сервера ADFS, а он в свою очередь может разрешить имя прокси сервера. Сертификаты на обоих серверах должны включать имя службы федерации.
Публикация приложения через Web Application Proxy
После того, как установлены роли ADFS и Web Application Proxy (которая работает еще и как ADFS Proxy), можно перейти непосредственно к публикации наружу конкретного приложения. Сделать это можно с помощью консоли Remote Access Management Console.
Запустите мастер публикации и укажите, хотите ли вы использовать для преаутентификации службу ADFS (это именно наш вариант).
Затем нужно задать имя публикуемого приложения, используемый сертификат, внешний URL (имеенно его для подключения будут использовать внешние пользователи) и внутрений URL-адрес сервера, на который будут пересылаться запросы.
Совет. Если необходимо перенаправить внешнее приложение на альтернативный порт, необходимо задать его в URL, указаывающем на внутренний сервер. Например, если необходимо перенаправить внешние https запросы (443 порт) на 4443 порт, нужно указать:
Backend server URL: lync.winitpro.local:4443
Завершите работу мастера, и на этом публикация приложений окончена. Теперь, если попытаться с помощью браузера зайти на опубликованный внешний URL-адрес, то браузер сначала будет перенаправлен на службу аутентификации (ADFS Proxy), а после успешной аутентификации пользователь будет отправлен непосредственно на внутренний сайт (веб приложение).
Благодаря новой службе Web Application Proxy в Windows Server 2012 R2 возможно реализовать функционал обратного прокси сервера с целью публикации внутренних служб предприятия наружу без необходимости использования задействовать сторонние файерволы и продукты, в том числе такие, как Forefront и пр.
Setting up a proxy server can be an essential task for improving security, managing internet traffic, and optimizing network performance. For businesses and advanced users working with Windows Server 2012, understanding how to configure a proxy server effectively can lead to enhanced control over network activities. This article provides a detailed guide on how to easily set up a proxy server on Windows Server 2012 using various methods. We’ll cover system settings, browser-specific configurations, and alternative approaches to ensure you have all the tools necessary for optimal proxy server management.
How to Set Up a Proxy in Windows Server 2012 System Settings
To configure it, you will need a proxy server. If you don’t have one, Proxy5.net provides high-quality proxies. They support HTTP, HTTPS and SOCKS5 protocols, which simplifies configuration on Windows Server 2012 and ensures stable connection.
Setting up a proxy server through the system settings of Windows Server 2012 involves several straightforward steps. This method ensures that all network requests from the server are routed through the proxy, providing a unified approach to managing internet traffic. Step-by-Step Instructions:
1. Access the Control Panel
- Click on the Start button and select Control Panel.
2. Navigate to Network and Sharing Center
- In the Control Panel, go to Network and Internet.
- Click on Network and Sharing Center.
3. Open Internet Options
- Within the Network and Sharing Center, click on Internet Options in the bottom left corner.
4. Configure Proxy Settings
- In the Internet Options window, go to the Connections tab.
- Click on LAN settings.
5. Enable Proxy Server
- In the Local Area Network (LAN) Settings window, check the box labeled Use a proxy server for your LAN.
- Enter the IP address and port number of your proxy server in the respective fields.
6. Bypass Proxy for Local Addresses
- Optionally, check the box labeled Bypass proxy server for local addresses if you don’t want the proxy to be used for local network traffic.
7. Save Settings
- Click OK to save your settings in the LAN settings window.
- Click OK again to close the Internet Options window.
8. Restart Network Services
- For the changes to take effect, you may need to restart your network services or the server itself.
How to Set Up a Proxy on Windows Server 2012 Through Mozilla Firefox
Configuring a proxy server specifically for the Mozilla Firefox browser allows you to manage internet traffic for that browser independently from the system-wide settings. This can be particularly useful if you need different proxy settings for different applications. Step-by-Step Instructions:
1. Open Mozilla Firefox
- Launch Mozilla Firefox on your Windows Server 2012 machine.
2. Access Options
- Click on the Menu button (three horizontal lines) in the upper-right corner.
- Select Options from the drop-down menu.
3. Navigate to Network Settings
- In the Options window, scroll down to the Network Settings section.
- Click on Settings.
4. Configure Proxy Settings
- In the Connection Settings window, select Manual proxy configuration.
- Enter the IP address and port number of your proxy server in the HTTP Proxy field.
- If you want the same proxy settings for all protocols, check the box labeled Use this proxy server for all protocols.
5. Bypass Proxy for Specific Hosts
- In the No Proxy for field, enter any addresses that should bypass the proxy. Separate multiple entries with commas.
6. Save Settings
- Click OK to save your proxy settings.
- Close the Options window.
Alternative Methods for Configuring a Proxy on Windows Server 2012
Apart from using system settings and browser-specific configurations, there are several alternative methods to set up a proxy server on Windows Server 2012. These methods can provide additional flexibility and control over network traffic management.
1. Using Group Policy:
- Group Policy allows administrators to configure proxy settings across multiple machines within a network. This method is ideal for large organizations needing a consistent proxy setup.
- To configure proxy settings using Group Policy:
- Open the Group Policy Management Console (GPMC).
- Create or edit a Group Policy Object (GPO).
- Navigate to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer.
- Configure the proxy settings under Proxy Settings.
2. Using a PAC File:
- A Proxy Auto-Configuration (PAC) file is a script that automatically configures proxy settings for clients. This method is beneficial for complex network environments where different proxies may be needed for different destinations.
- To use a PAC file:
- Create a PAC file with the necessary proxy configurations.
- Host the PAC file on a web server.
- Configure the clients to use the PAC file URL in their browser or system settings.
3. Using a Third-Party Proxy Software:
- There are various third-party proxy software solutions available that offer advanced features such as caching, filtering, and load balancing.
- Popular third-party proxy software includes Squid, WinGate, and CCProxy.
- These solutions typically involve installing the software on the server and configuring it according to your network requirements.
4. Using Command Line Interface (CLI):
- Advanced users can configure proxy settings using the Command Line Interface (CLI). This method provides a more scriptable approach to proxy configuration.
- To set a proxy using CLI:
- Open the Command Prompt with administrative privileges.
- Use commands like
netshto configure proxy settings.
5. Using PowerShell Scripts:
- PowerShell scripts offer another method for configuring proxy settings, especially useful for automation and batch configurations.
- Example PowerShell script to set a proxy:
netsh winhttp set proxy proxy-server="http=proxy-server-address:port" bypass-list="*.local"
6. Using Network Load Balancers:
- For high-availability and load-balanced proxy configurations, network load balancers can be used.
- Load balancers can distribute network traffic across multiple proxy servers, ensuring better performance and redundancy.
Choosing the best method to set up a proxy server on Windows Server 2012 depends on your specific needs and network environment. For most users, configuring the proxy through system settings or a browser like Mozilla Firefox provides a straightforward solution. However, for larger organizations or more complex requirements, using Group Policy, PAC files, third-party software, CLI, PowerShell scripts, or network load balancers may offer additional benefits. Each method has its advantages, and selecting the right one can significantly enhance your network management capabilities.
Frequently Asked Questions
What is a proxy server and why is it used?
A proxy server acts as an intermediary between a client device and the internet. It is used to improve security, manage internet traffic, and optimize network performance by filtering requests and caching content.
Can I use multiple proxy servers on Windows Server 2012?
Yes, you can configure multiple proxy servers using different methods, such as system settings, browser-specific settings, or using a PAC file that directs traffic to different proxies based on the destination.
Is it necessary to restart the server after configuring a proxy server?
It is recommended to restart network services or the server itself to ensure that the new proxy settings take effect properly.
Can proxy settings be enforced across a large network?
Yes, using Group Policy is an effective way to enforce proxy settings across multiple machines within a large network.
Are there any free third-party proxy software options available?
Yes, there are several free third-party proxy software options such as Squid and CCProxy, which offer robust features for managing proxy servers.
How can I verify that my proxy server configuration is working correctly?
You can verify your proxy configuration by visiting websites that display your IP address, such as whatismyip.com, to check if the IP address matches your proxy server’s IP address.
Setup of Web Application Proxy Server in Windows 2012 R2
When Microsoft discontinued
Threat
Management Gateway (which once was Proxy
and then ISA server)
I must admit I was disappointed; it was a relatively inexpensive authenticated reverse
proxy that worked with Exchange Server as well as many other complicated
products. In the interim we were told that Unified
Access Gateway would be the replacement, but that product isn’t as
well suited to the task.
Several alternatives are out there, including: Kemp, F5, Nginx, and Squid
but either the price or the relative difficulty of setup isn’t in line with
TMG. Fortunately starting in Windows 2012R2 Microsoft introduced Web
Application Proxy which largely fills the gap.
Web Application Proxy/Server 2012r2 release
party.Trust me, I paid big bucks for this insider photo.
What is Web Application Proxy?
Web Application Proxy
(WAP from henceforth) is based on and replaces Active
Directory Federation Services Proxy 2.0. In addition to the ADFS Proxy
functionality it also introduces the ability to expose internal resources to
external users. These users can be pre-authenticated (and then impersonated
for SSO) against
your Active Directory infrastructure using ADFS prior to being allowed
access to resources.
Wait, This is ADFS Proxy 3.0?
Yup! That and more. Here’s what you can do with it:
- Authorize external users for access to other claims-aware external or
internal resources (Generally SaaS). - Allow access (by «reverse» proxy) to multiple internal applications on
the same port. - Pre-Authenticate users against Active Directory via Kerberos
or NTLM
to facilitate SSO and access to internal applications (if desired) - Expose multiple internal resources on a single IP address/port
(generally 443) differentiated by hostname - Loadbalance using a session affinity based solution in front of WAP
Let’s Go!
This article will cover the following:
- WAP requirements
- Set up
- Forwarding a couple of sample applications
- Troubleshooting
Software Requirements
Web application proxy is available on Windows Server 2012 R2 and higher,
and it requires
ADFS 3.0 to be available on the back end. For assistance in setting
up ADFS 3.0, see my article here.
If you would like to proxy authentication for non-claims aware
applications, I.E. Exchange OWA pre-2013 SP1 (SP1
Claims) or Kerberos/NTLM apps, you will need to have the WAP server
joined to your domain.
Additionally, you’ll need the certificate (private and public key) from
your ADFS server and one certificate (again, private and public) for each
application you intend to proxy. These certificates must be trusted by
your clients, so generally external globally trusted (Digicert for
example) certificate authorities are preferred. The certificates need to
be installed under the «Personal» portion of the «Local Machine» store on
the machine you intend to use as your WAP proxy. If you only intend to
host internal resources to domain-joined computers connecting remotely you
can use an internal PKI provided your clients trust your issuing CA(s).
For information on how to setup an internal CA, see my article here.
If you need help exporting your public and private key from your ADFS
server and other services, see this
article. Note that if these certificates are marked as non-exportable you
will need new certificates for those services, so make sure you plan
accordingly.
Connectivity and Hardware/VM Requirements
Preferably, your WAP server should be placed in a De-Militarized
Zone with a firewall on either side of it. The machine
can operate with either one or two Network Interface
Cards, but for proper security I recommend two NICs; one
internal and one external. Other connectivity options will work, including
branching into your internal network on the inside interface, but I won’t
be covering those scenarios in detail. For all connectivity options see
the following diagram:
As for the hardware you can use either real hardware or a VM assuming you
have a proper DMZ NIC setup on your Hyper-V/ESX/Xen/whatever host(s). WAP
is not a particularly demanding application and uses very little I/O. It
is also horizontally scalable with a network level load balancer (f5) so I
won’t give direct guidance on specifications since it would likely have
little relevance to your configuration. As in most cases, performance
evaluation and configuration change is the way to go.
After deciding on your hardware and installing the OS, you’ll need to
configure the NICs. We’ll cover that in the next section…
Installation
Now that the hardware and OS are ready to go, let’s configure the NICs:
Network Configuration
- First open the «Network and Sharing Center» and click «Change Adapter
Settings». Re-name the NICs «External» and «Internal» according to how
they are connected to avoid confusion during set up and troubleshooting. - Give each NIC appropriate IP address settings. The subnet for each
will depend on your firewall/switch configuration. Some firewall
configurations may require communication stay on a single subnet but if
given a choice it is generally better to have them on different subnets.
(2 NICs) Leave the default gateway on the internal NIC blank. If your
WAP server is not domain joined because you intend on using only claims
auth or passthrough (not delegation) then leave your DNS servers blank
on the internal NIC as well and be sure to execute step 4. - If the WAP server needs to access resources (ADFS, DC, App) on a
subnet other than that the internal NIC is connected to, you will need
to add a static route to the server so it knows how to get to that
network. For example, if your WAP server is on 192.168.1.10/24, your
ADFS server is 192.168.2.5/24, and your gateway is 192.168.1.1, you
would issue the following command from an elevated command prompt: route
ADD 192.168.2.0 MASK 255.255.255.0 192.168.1.1 IF 192.168.1.10 -p .
For more information, see this
article. - <Only if you haven’t specified DNS servers on the internal
NIC>To look up the ADFS server for claims verification you will need
to add each internal ADFS server address to your
%SYSTEMROOT%\system32\drivers\etc\hosts file. Do this now; if you need
further instructions see this
article. - Now we’ll secure the external NIC. Open the properties of that NIC and
on the «Networking» tab unbind everything except for «QoS Packet
Scheduler» and the protocol you intend on using (IPv4 or IPv6). - If using IPv4, drill into the properties of that protocol and select
«Disable NetBIOS over TCP/IP» under the «WINS» tab. Also ensure you
disable «Register this connection’s address in DNS» on the «DNS» tab. - On your external firewall, open the ports for the services you wish to
forward. (443 would be common) - On your internal firewall, open ports necessary for AD/other
communication. Here
is an excellent guide.
WAP Installation
- In server manager, click «Manage->Add Roles and Features».
- Click «Next» on the «Before you begin» screen.
- For «Installation Type» select «Role-based or feature-based
installation» & click «Next».
- Select your desired WAP server and click «Next».
- On «Add Roles and Features Wizard», select the «Remote Access» role
and click «Next».
- You do not need to select any features; click «Next» on the «Select
features» page. - Read the dialog presented on the «Remote Access» screen and click
«Next». - Leave «Include management tools» checked and click «Add Features».
- On the «Select role services» page select «Web Application Proxy» and
click «Next».
- When presented with the confirmation screen, click «Install».
WAP Configuration
Prerequisite Note: For this step you will need the
public and private key for your internal ADFS server(s) installed to the
«Personal» section of the «Local Computer» store on your WAP server. For
more information, refer to «Software Requirements» above.
- After installation, server manager will notify you that configuration
is required. Click the notification flag and select «Open the Web
Application Proxy Wizard». - On the «Welcome» screen of the «Web Application Proxy Wizard» click
«Next». - On the «Federation Server» screen, enter the external
fully qualified domain name of your federation service. This needs to be
registered in external DNS (i.e. resolvable from the internet).
For more information, see my article linked under «Software
Requirements». Insert the username/password of a domain administrator
account to properly register this as a proxy server. This account will not
be used after this point, so a service account is not necessary. Click
«Next».
- Select the ADFS certificate you installed earlier from the dropdown
and click «Next».
- You’ll be presented with the configuration details. If you intend on
setting up another WAP server for load balancing copy the powershell
command down for later use. Click «Configure» to continue.
- You should see the message «Web Application Proxy was configured
successfully».
Setup Verification
To verify basic functionality:
- On the WAP server, open up Tools->Remote Access Management Console
- On the left-hand navigation pane, select «Operations Status»
- The status of the WAP server will be relayed in the middle pane. Do
not be surprised to see the server listed twice, once for the FQDN and
once for netbios. This is normal.
Now that setup is complete, let’s move on to publishing!
Example A: Proxying Exchange 2010 OWA (Pre-auth/Non-Claims/Delegated
Authentication)
Now that we’ve completed the ADFS/WAP setup, let’s walk through the setup
of a non-claims aware application using Kerberos/NTLM delegation. A
popular example would be Exchange Outlook Web Access; I’ll be using
version 2010 SP3.
Prerequisite Note: For this step you will need the
public and private key for the services you wish to host (Exchange OWA in
this case) installed to the «Personal» section of the «Local Computer»
store on your WAP server. Requests destined for your back-end service are
decrypted and re-encrypted at the WAP server. For more information, refer
to «Software Requirements» above.
Trust Setup
First, we must set up the new trust on the ADFS server. On your back-end
ADFS server (not the WAP server) do the following:
- Open the AD FS management tool and click the «Trust Relationships»
folder on the left hand navigation pane. - In the right hand action pane, click «Add Non-Claims-Aware Relaying
Party Trust».
- A wizard will pop up; click «Start» on the welcome screen.
- Give this rule a (human) meaningful name, i.e.» <Servername>
Exchange OWA» along with a description if desired and click «Next».
- Now we’ll add the non-claims aware relaying trust party identifier
(which in this case is simply a URL). Enter the external fully qualified
domain name of the server complete with url path ending in a trailing
forward slash, i.e. https://mail.company.com/owa/ and click «Next».
Note: WAP identifiers must end in a trailing slash even though the MSFT
example doesn’t look that way.
- On the next screen, «Configure Multi-Factor Authentication Now?», you
can set up multi-factor authentication should you desire. I will not be
configuring multi-factor for this demonstration, but note you can always
set it up later if desired. Leave «I do not want to configure…»
selected and click «Next».
- Review your configuration on the «Ready to Add Trust» screen and click
«Next». - The «Finish» screen will have a checkbox starting with «Open the Edit
Authorization Rules dialog…» that is checked by default. Leave it
checked because we will want to specify who is allowed access through to
the back-end via this rule right away. Click «Finish».
- A dialog box titled «Edit Claim Rules for <Rule Name>» will come
up allowing us to define who should be allowed access via this rule.
Click «Add Rule’. - You will be asked to select a rule template. What you select here will
depend on what is reasonable for your environment. You should create (a)
rule(s) that correspond with the least access required possible as
anyone getting past this point will be able to attempt to authenticate
directly against the target internal resource. You may, for example,
want to use a specific Active Directory group with only the users that
need access to this resources. For the purposes of testing and this
article, however, I will be using a simple «Permit All Users» rule. This
will allow anyone in AD through and is suitable for testing or in
addition to other rules. Select the rule template and click «Next».
- Click «Finish» to close the «Add Issuance Authorization Claim Rule
Wizard» - So long as you do not want any additional rules, click «OK» to close
the Edit Claim Rules dialog box.
Back-end Service Configuration
Now we need to configure our back-end service to accept the
authentication coming from the WAP server. In our case we will need to
change the authentication mechanism allowed by Exchange from forms
based to integrated authentication.Your steps here will differ depending
on what service you are offering up.
- Open the Exchange management console and Click on «Server
Configuration»->»Client Access» - For each server in your Exchange farm, click the «Outlook Web App»
tab, then right click «owa (Default Web Site)» and click «properties».
- Select the «Authentication» tab and click «Use one or more standard
authentication methods:» then select only «Integrated Windows
authentication». - Click «OK» on the warning.
- Repeat steps 2 and 3 for the «ecp (Default Web Site)» under «Exchange
Control Panel» on each server. - Using an elevated command prompt or PowerShell, execute «iisreset
-noforce» to restart IIS. (This should be done in a maintenance
window)
Configure Delegation
Now we’ll configure the WAP server AD computer object so that it can pass
authentication to your back-end server(s). Note the SPNs referenced to not
need to be manually registered at a domain level.
- With domain administrator privileges, open the Active Directory
Administrative Center. (Active Directory Users and Computers if you
prefer) - Navigate to and open the properties of the WAP server computer object.
- Click or scroll down to the «Delegation» section of the object.
- Select «Trust this computer for delegation to specified servers only»
and «Use any authentication protocol» (since we’ll be using NTLM here;
select Kerberos only for applications that support it) then click
«Add…» - When presented with the «Add Services» dialog, click «Add Users or
Computers…».
- Type the name of the back-end Exchange server(s) and click «Check
Names» and then «OK» - Scroll to the http/SERVERNAME.domain.ext (since we’re serving up the
HTTP protocol; change if your app differs) and select it, then click
«OK». Note: If using Active Directory Administrative
Center you need to add the FQDN
name and the NETBIOS name; if using Active Directory Users
Computers you need only add the FQDN and both will be added.
Configure Application Publishing on WAP Server
Finally we’ll configure WAP publishing for this application.
- On the WAP server, open the Remote Access Management Console (can be
found in admin tools or tools from Server Manager) - In the left hand navigation plane, select «Configuration»->»Web
Application Proxy» - On the right hand action pane, click «Publish»
- A wizard will come up. Click «Next» on the welcome screen.
- When prompted for preauthentication type, select «Active Directory
Federation Services (AD FS)». This ensures requests are authenticated by
ADFS prior to being passed onto the back-end server. Click «Next».
- For «Relying Party», select the trust rule we created earlier under
the «Trust Setup» section above and click «Next».
- Now the meat of the settings; on the «Publishing Settings» step enter
a meaningful name for this connection (i.e. Exchange 2010 OWA), the
external URL it will be accessed by (i.e.
https://mail.company.com/owa/), select the external certificate for that
service (see «Software Requirements» above), the internal URL
(preferably should match the external but doesn’t have to in all cases),
and the server SPN that we specified on the step above, then click
«Next».
- You will be shown the confirmation screen with the appropriate
PowerShell command line for the options you have configured. Should you
want to repeat a similar publishing step, copy and retain this command
line for use later. Click «Publish».
- The results screen will display the publishing status. Assuming all is
well, click «Close» to close the wizard.
Example B: RDP Proxy (No Pre-auth/Passthrough)
Passthrough applications are substantially easier (and less secure)
because they do not require any set up in ADFS and do not subject the user
connection attempt to any authentication before passing it on. This isn’t
to say the back-end service won’t require authentication, however, but it
is still less secure since you are opening your back-end service up to
processing logon requests directly from the internet.
Publish RDP Proxy on WAP Server
In this example I will publish RDP proxy direct to the internet proxied
through the WAP server. This allows me to serve up this application on the
same IP address and port as other services assuming the hostname requested
is unique. Again, this section assumes the public and private keys
associated with the URL you intend to use installed in the WAP server’s
«personal» store. In my example I use a hostname of «rdp.company.com»
- On the WAP server, open the Remote Access Management Console (can be
found in admin tools or tools from Server Manager) - In the left hand navigation plane, select «Configuration»->»Web
Application Proxy» - On the right hand action pane, click «Publish»
- A wizard will come up. Click «Next» on the welcome screen.
- When prompted for preauthentication type, select «Pass-through» and
click «Next».
- On the «Publishing Settings» step enter a meaningful name for this
connection (i.e. RDProxy), the external URL it will be accessed by (i.e.
https://rdp.company.com/), select the external certificate for that
service (see «Software Requirements» above), and the internal URL
(preferably should match the external but doesn’t have to in all cases).
Click «Next».
- You will be given a summary of the publishing rule about to be created
and a Powershell command of it’s equivalent. If you are satisfied with
the details click «Publish».
Troubleshooting
Something not working? Check out the following locations:
Event Logs
Applications and Services Logs->AD FS/Admin
Applications and Services
Logs->Microsoft->Windows->WebApplicationProxy/Admin
Other
Should you need to enable debug logging, there is an excellent article here
demonstrating how to do so. One word of caution, however; should you edit
the C:\Windows\ADFS\Config\microsoft.identityServer.proxyservice.exe.config
referenced therein I recommend backing it up first. If not formatted
correctly WAP will start up successfully with the values listed in the file,
but when it comes time to rotate the ADFS Proxy Trust certificate (an
automatic action that happens once every 3 weeks) the configuration of the
new cert will fail. In that case you would see an Event ID 422 logged to AD
FS/Admin stating «Unable to retrieve proxy configuration data from the
Federation Service.».
(Excellent!) References
Want more? Here are some wonderful resources!
Technet:
Web Application Proxy Overview
Technet:
Install and Configure the Web Application Proxy Server
Technet:
Installing and Configuring Web Application Proxy for Publishing Internal
Applications
Technet
Overview Guide: Connect to Applications and Services from Anywhere with
Web Application Proxy
Technet
Social: On WAP and IPv6
Technet Social: ADFS, WAP, and Logging
Technet
Blog: How to support non-SNI capable Clients with Web Application Proxy
and AD FS 2012 R2 (Needed to support Android clients for
Exchange ActiveSync or other clients that don’t support SNI hosted through
WAP)
Technet
Ask PFE: FAQ on ADFS Part 1, Excellent coverage of SQL vs. Internal DB and
certificates for AD FS (Not WAP per se)
Marc
Terblanche: Windows 2012 R2 Preview Web Application Proxy — Exchange 2013
Publishing Tests
Ask
the DS Team: Understanding the ADFS 2.0 Proxy (Not about WAP but
excellent coverage of AD FS proxy functionality)
Rob
Sanders: Troubleshooting ADFS 2.0 (Not about 3.0/WAP but too good not
to be mentioned)
Technet: Configure Event Logging on a Federation Server Proxy (Still
partially relevant)
Technet:
Things to check before troubleshooting ADFS 2.0 (Still partially
relevant)
Technet:
Configuring Computers for Troubleshooting AD FS 2.0 (Still partially
relevant)
Thanks for reading, if you have questions or comments leave them below!
Microsoft Web Application Proxy [WAP] is a new service added in Windows Server 2012 R2 that allows you to access web applications from outside your network. WAP functions as a reverse proxy and an Active Directory Federation Services [AD FS] proxy to pre-authenticate user access.
vBoring Blog Series:
- How to setup Microsoft Active Directory Federation Services [AD FS]
- How to setup Microsoft Web Application Proxy
Requirements:
- The only hard requirement of WAP is having an AD FS server. Refer to step 1 for setting that up.
- WAP cannot be installed on a server that AD FS is installed on. They must be separate servers.
Installing the Web Application Proxy Server Role:
Open Server Manager and click Manage -> Add Roles and Features:
Click Next:
Role-based or feature-based installation should be selected then click Next:
Select the server you want to install this role on to and then click Next:
Note: Web Application Proxy role and AD FS cannot be installed on the same computer.
Select Remote Access then click Next:
No additional Features are needed. Click Next:
Click Next:
Select Web Application Proxy:
On the pop up click Add Features:
The Web Application Proxy role does not required a reboot. Click Install:
Once complete click Close:
Web Application Proxy is now installed but you need the AD FS certificate to continue.
Export & Import the AD FS Certificate:
You need the certificate from your AD FS server added to your Web Application Proxy server. Login to your AD FS server and open MMC.exe:
Go to File -> Add/Remove Snap-ins -> select Certificates then click Add:
When you click OK you will get the following pop up. Select Computer account then click Next:
On AD FS Server: Drill down to Personal -> Certificates then right click the SSL certificate you used during setup of AD FS. Go to All Tasks -> Export. Save to a location that your Web Application Proxy can access. Ensure you export the Private Key and certificate as a .PFX file.
On Web Application Proxy: Right click on Personal -> Certificates then go to All Tasks -> Import:
This will bring up the Certificate Import Wizard. Click Next:
Browse to the certificate that you exported from your AD FS server and select it. Click Next:
Enter the password for the private key and check the box to make the key exportable. Click Next:
Leave the default certificate store as Personal. Click Next:
Click Finish:
You should now see the certificate from your AD FS servers on your Web Application Proxy server.
Now we are ready to perform the Post Configuration.
Post-Deployment Configuration:
Back on your Web Application Server open Server Manager then click Notifications then the message Open the Web Application Proxy Wizard:
Click Next:
Enter the FQDN of your AD FS name and the Service Account you created during AD FS setup. Click Next:
On the drop down menu select the certificate you imported from your AD FS server. Click Next:
Click Configure:
Once finished click Close:
Remote Access Management Console should open when you clicked Close. On Operations Status you should see all the objects as green.
Publish Web Applications:
Now we are finally ready for the magic. In the Remote Access Management Console click Web Application Proxy then Publish:
Click Next:
Pass-through will let WAP act like a reverse proxy. I will have documentation on setting up AD FS link soon!
Select Pass-through and click Next:
Name: Enter a display name
External URL: Enter the URL that will be coming in your the WAP server externally
External Certificate: The drop down menu will show certificates that are added on the WAP server. Select the same certificate that you used while setting up your application. In my case I used my wildcard certificate.
Backend server URL: Enter the web URL of the server you want the external URL forwarded
Click Next:
Copy the PowerShell command down and with some minor edits you can easily add additional PassThrough applications with ease.
Click Publish:
Click Close to finish:
You will now see the published web application and ready for testing.
You are ready to test the application!
Configure Firewall for 443 Port Forwarding:
Before you can test you need to ensure you have port 443 (HTTPS) being sent to your WAP server. This step does not involve configuration of your WAP environment but on your firewall. Since this can vary greatly I will give you two examples of this step:
For pfSense you would create a NAT: Port Forward Rule:
For DD-WRT you would go to NAT / QOS then Port Forwarding:
Once added you are ready to test!
From outside your network (like on your phone or a PC elsewhere) try to access your web link. You should get your internal web page through your WAP externally! Success!
Coming Soon!! Setting up Microsoft RDS to use AD FS authentication through WAP!
This Windows Server 2012 R2 feature allows online users to securely access internal resources.
With Windows Server 2012 R2, Microsoft has built in a reverse-proxy feature. The Web Application Proxy securely publishes internal resources out to the Internet for access by both corporate-owned devices and untrusted machines alike. Indeed, most deployments of, say, Work Folders or workplace join — key “work anywhere” features that Microsoft put into Windows Server 2012 R2 — demand a reverse proxy of some sort, so this requirement is likely to come up for you sooner or later.
As you may have heard, Microsoft killed its flagship reverse proxy product, Forefront Unified Access Gateway, back in December. Many organizations have used UAG to create DirectAccess tunnels as well as portals where applications could be securely accessed from all sorts of clients.
While UAG’s capabilities were vast, it may have represented overkill for many applications, so Microsoft has built a capable, if less full-featured, successor into Windows Server 2012 R2. That’s what this article is about.
Configuring the Web Application Proxy (WAP) role, however, involves a lot of moving parts, and in this piece I will walk through how to set up the WAP role in your lab with either an application of your choosing or a freely available sample claims application that Microsoft publishes as part of one of its software development kits. Let’s begin.
Installing and configuring Active Directory Federation Services
Follow these steps to get started on the ADFS server.
1. On the machine that will host the ADFS role, open Server Manager and go to Add Roles and Features, and then check the box for Active Directory Federation Services.
2. Click through the rest of the wizard — the screens are just descriptions of the service; there is no action required other than to read the text and click Next. Then press the Finish button to get the role installed.
3. Once the wizard finishes, click the yellow exclamation icon in Server Manager. This icon reminds you that even though the role is installed, ADFS is not functional yet; you need to further configure the service. Click the link within the status screen that pops up from the yellow icon to go directly to the configuration interface.
4. For this walkthrough, we can assume this is our first ADFS server, so choose the default option and click Next.
5. On the account selection page, choose an account that has domain administrator permissions and then click Next.
6. On the next screen, you need to select the secure certificate that ADFS will use in its connections. You cannot use the certificates from IIS Manager here, as you will need to have previously imported the certificate into the certificate store through the Microsoft Management Console (MMC) snap-in. You can also import a new wildcard or Subject Alternative Name certificate right from this screen.
Note that the wizard will automatically link the subject name of the certificate you are importing with the Federation Service Name, which may not be, and in fact probably is not, what you want. Instead, for the Federation Service Name, type in the URL you will want to use when applications request a connection to ADFS — some folks choose adfs.domain.tld, others choose id.domain.tld, still others choose federation.domain.tld. The key here is to not simply accept the default and to make sure the Federation Service Name lines up with the URL you will be using for Web applications that require any sort of transaction with your ADFS deployment.
7. Leave the wizard where it is now and click over to whatever application or service you are using to host your domain name service (DNS) records and add a “Record for the Federation Service Name” you just made in the previous step. Once you have created and saved that new record, come back to the ADFS configuration wizard.
8. Back in the wizard, add the Federation Service Display Name — this is a friendly name, so there are no special rules for how it is formatted or what it must be addressed to — and click Next.
9. Select the account you will run the ADFS service under, and then click Next.
10. On this database screen you can either create a new Windows internal database instance for ADFS or you can point the service to an existing database running in SQL Server. Click Next.
11. Review the options you selected to configure ADFS, and click Next to validate your choices. You can also take a look at the PowerShell script the wizard will actually run to perform the configuration, as most of the wizards in Windows Server 2012 R2 these days are really just front ends to PowerShell script generators.
12. The checks should pass and now you can click Finish to actually configure the service.
Next, you will need to spin up another client or server to test connectivity to the ADFS service. You can use any machine with a Web browser that can access the network on which your ADFS server is installed, as all you are doing here is browsing to a Web page on the ADFS deployment.
On this separate machine — NOT on the ADFS server itself, as it will fail — access the following URLs:
- https://adfs.domain.tld/federationmetadata/2007-06/federationmetadata.xml
- https://adfs.domain.tld/adfs/ls/idpinitiatedsignon.htm
Of course, replace adfs.domain.tld with whatever DNS name resolves to your instance of ADFS. The point here is to make sure that when you get to the first URL, you see the metadata from the ADFS server without any SSL or certificate validity errors. For the second URL, you must see the standard default ADFS sign-on page. If both of these pages come up without errors, you have successfully installed ADFS.
Back on the ADFS server, copy the SSL certificate you used in the configuration wizard to a network share or a thumb drive, so that you can copy it again onto the server on which we will be installing the WAP role (in the next section).
Installing the Web Application Proxy role
Continuing in this process, you will need to create a second machine — as mentioned before — on which the WAP role can be installed. However, this machine should NOT be joined to any domain; it can remain a standalone server.
First, we need to install the certificate you just copied from the ADFS server. You will need to manually import this certificate into the Windows certificate store by following these steps:
1. On the Start menu, type MMC and press Enter.
2. From the File menu, choose Add/Remove Snap-in.
3. In the left pane under “available snap-ins,” choose Certificates, and click the Add button in the middle of the window.
4. A window will pop up, asking which account this snap-in should manage. From the three choices, select Computer account at the bottom and then click Next.
5. Choose the local computer option, and then click Finish.
6. Click OK in the management window, and you will be returned to the MMC console with the certificates snap-in added.
7. In the left pane, expand “Certificates (Local Computer)” and then click on the Personal node.
8. Right click on the Personal node and select Import from the All Tasks menu.
9. Follow the wizard to select the certificate that you previously used and copied down, and finish the import.
Now that the certificate is safely in the certificate store, you can add the WAP role to this server. Open Server Manager, then go to Add Roles and Features and choose the Remote Access option. Follow the wizard through the confirmation screens until you are presented with a page where you are asked to select the remote access services you desire; here, check the box beside the WAP service.
Click Add Features in the screen that pops up asking you about related services that must be installed at the same time, and then click on through until you are finished. (The related services are just interdependencies; for example, to install WAP you need to install IIS, and the wizard preselects this for you. That screen just shows what other services will get installed.)
Within Server Manager, click the yellow warning icon and then follow the link to open the WAP configuration wizard. Enter the same Federation Service Name entry that you configured in the ADFS wizard and for which you set up a DNS entry, and then enter credentials for an account with local administrator privileges on the ADFS server.
Once you get to the certificate selection screen, choose the certificate that you imported earlier, review the PowerShell script that the wizard has again generated and then click the Configure button to set things into motion.
Note: If you get an SSL error relating to the failure to establish a trust relationship, make sure the root certificate authority that created the ADFS certificate that you imported into the WAP server’s certificate store is trusted by the WAP. You can look in the Certificates snap-in of the MMC to see whether the certificate is present. If it is not, import that root certificate using the previous procedure, only this time add it to the Trusted Certification Root Authority node in the MMC snap-in, and not the Personal node. See step 7.)
Setting up an application to use the WAP role
Now that you have set up ADFS on one machine and the WAP role on another machine, you can publish a new application on the WAP server. You do this by publishing rules for the specific URLs that need to pass through the WAP to some server on your network for which you are proxying transmissions.
For the purposes of this walkthrough, you can use the sample claims-based application that comes in the Windows Identity Foundation software development kit, or SDK. You can download the sample application here and get instructions here for setting up the prerequisites for this sample application. You can also use any other application you have at your disposal that works with federated identities as long as it has an external URL endpoint. You will just need to know that endpoint.
To set up a new application, follow these steps:
1. From the Start menu, open the Remote Access Management Console.
2. From the Tasks section on the right of the Remote Access Management Console, click Publish.
3. Click Next to page through the welcome screen.
4. The Preauthentication screen will appear. Select the first option, “Active Directory Federation Services (ADFS)” and click Next.
5. The Relying Party page will appear. Here, select the relying party for the application you are using and click Next. (The relying party is simply the application that needs the credentials that ADFS is federating — in other words, the application that will trust the credentials that ADFS authenticates.)
6. The Publishing Settings page appears. Enter a friendly name for your application, the URL at which external clients can access the application, the certificate that covers that name and the URL of the back-end server if different (for the purposes of this walkthrough, it is the same as the application’s external URL). Click Next.
7. Confirm these settings and click Publish.
Interestingly, you can wrap that entire seven-step sequence up into a single PowerShell command, which again is all the wizard does. (There is no PowerShell that makes sense to use for the steps given on previous pages; it would be a series of commands that is not really any more intuitive or any faster than using Server Manager and the various configuration wizards.)
Add-WebApplicationProxyApplication -BackendServerURL 'https://www.domain.tld/yourappgoeshere'
-ExternalCertificateThumbprint 'qwerty87239874923hjdf0df9'
-ExternalURL 'https://www.domain.tld/yourappgoeshere/'
-Name Test Application
-ExternalPreAuthentication ADFS
-ADFSRelyingPartyName Test Party
At this point, everything should be working, and you should be able to see your application being securely reverse-proxied using the WAP role to clients connecting from the wild Internet.
This article, How to set up Microsoft’s Web Application Proxy, was originally published at Computerworld.com.
Jonathan Hassell runs 82 Ventures LLC, a consulting firm based out of Charlotte, N.C. He’s also an editor with Apress Media LLC. Reach him at jhassell@gmail.com.