Настроить прокси сервер на windows server 2016 - Доктор Windows

Remove From My Forums

Question
Hi,

I have a web proxy server which can reach all internet addresses:

webproxy.myorg.org

What would be the best way to configure the proxy server for my ‘Windows 2016’ server?

I’m told that this would work:

netsh winhttp set proxy «webproxy.myorg.org:8080»

The server is part of an AD domain, so will this get removed by Group Policy.

Thanks for any help.

All replies

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.
Good day!

As we haven’t heard from you for a few days, may I confirm with you on the latest status?

Much appreciated for your response in advance.

Jolin

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.
Believe you are doing well.

This is a kind follow up on this case. May I know the latest status?

Thanks and looking forward to your reply

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.

Источник

Below we may get step-by-step screenshots,

Step 1 — Verify and ensure appropriate IP addresses are assigned to all required fields.

Step 2 — Click on «Local Server«.

Step 3 — Click on «WORKGROUP«.

Step 4 — Click on «Change…«.

Step 5 — Click on «More…«.

Step 6 — Type the domain name and click on «OK«.

Step 10 — Click on «Close«.

Step 11 — Save rest of your background work, if any and click on «Restart Now«. If planning to restart after some time then click on «Restart Later«.

Step 12 — Click on «Add roles and features«.

Step 13 — Click on «Next«.

Step 14 — Keep selected «Role-based or feature-based installation» and click on «Next«.

Step 15 — Select/Verify the server name and IP address, then click on «Next«.

Step 16 — Locate «Remote Access» and click the check box.

Step 17 — Confirm the Tick mark and click on «Next«.

Step 18 — Click on «Next«.

Step 19 — Click on «Next«.

Step 20 — Locate «Web Application Proxy» and click the check box.

Step 21 — Click on «Add Features«.

Step 22 — Confirm the Tick mark and click on «Next«.

Step 23 — Click on «Install«.

Step 24 — Wait for some time until installation completes.

Step 25 — Click on «Open the Web Application Proxy Wizard«.

Step 26 — Click on «Next«.

Step 27 — Type «Federation Service Name«, «User name and Password» of a local administrator account on the federation servers.

Step 28 — Click on «Next«.

Step 29 — Select appropriate SSL Certificate from the drop down list and click on «Next«.

Step 30 — Review all selections and click on «Configure«.

Step 31 — Wait for some time until configuration completes.

Step 32 — Click on «Close«.

Step 33 — Click on «Publish«.

Step 34 — Click on «Next«.

Step 35 — Click on «Pass-through«.

Step 36 — Click on «Next«.

Step 37 — Type «Name«, «External URL» & «Backend server URL«, for example — «https://sso.dskoli.work/«, select appropriate «External certificate» from the drop down list.

Step 38 — Locate «Enable HTTP to HTTPS redirection«, click the check box, confirm the Tick mark and click on «Next«.

Step 39 — Review all selections and click on «Publish«.

Step 40 — Click on «Close«.

Step 41 — Published Web Application will be displayed in the list.

Step 42 — On the Public DNS Panel of domain, add «Host (A)» record for federation service name pointing to WAP server on Perimeter Network. For example, «sso.dskoli.work» pointing to Public IP.

“Thank You for being with me.”

— Divyaprakash Shamrao Koli (Narmada)

Источник

В этой статье мы рассмотрим, как централизованно задать настройки прокси на компьютерах с Windows 10 в домене Active Directory с помощью групповых политик. Большинство распространенных браузеров (таких как Microsoft Edge, Google Chrome, Internet Explorer, Opera) и большинство приложений автоматически используют для доступа в интернет параметры прокси сервера, заданные в Windows. Также мы рассмотрим, как задать параметры системного WinHTTP прокси.

Содержание:

Как задать параметры прокси сервера в Windows через GPO?
Настройка параметров прокси через реестр и GPO
Настройка параметров WinHTTP прокси групповыми политиками

В этой статье мы рассмотрим особенности настройки прокси сервера политиками в поддерживаемых версиях Windows (Windows 10, 8.1 и Windows Server 2012/2016/2019). Обратите внимание, что в снятых с поддержки Windows 7/Server 2008R2, Windows XP/Windows Server 2003 параметры прокси сервера задаются по другому.

Как задать параметры прокси сервера в Windows через GPO?

До выхода Windows Server 2012/Windows 8 для настройки параметров Internet Expolrer (и в том числе настроек прокси) использовался раздел Internet Explorer Maintenance (IEM) из пользовательской секции GPO (User configuration –> Policies –> Windows Settings –> Internet Explorer Maintenance). В современных версиях Windows 10 /Windows Server 2016/2019 этот раздел отсутствует.

В новых версиях Windows для настройки параметров IE и прокси в редакторе GPO нужно использовать предпочтения групповых политик GPP (Group Policy Preferences). Также есть вариант использования специального расширения Internet Explorer Administration Kit 11 (IEAK 11) – но применяется он редко.

Откройте консоль редактора доменных GPO (Group Policy Management Console –
GPMC.msc
), выберите OU с пользователями, для которых нужно назначить параметры прокси-сервера и создайте новую политику Create a GPO in this domain, and Link it here.

Перейдите в раздел User Configuration -> Preferences -> Control Panel Settings -> Internet Settings. В контекстном меню выберите пункт New -> и выберите Internet Explorer 10.

Для настройки параметров прокси в Windows 10/Windows Server 2016 нужно использовать пункт Internet Explorer 10.

Совет. Несмотря на то, что отдельной настройки для Internet Explorer 11 нет, политика Internet Explorer 10 будет применяться на все версии IE >=10 (в файле политики InternetSettings.xml можно увидеть, что опция действительна для всех версии IE, начиная c 10.0.0.0 и заканчивая 99.0.0.0). Все версии Internet Explorer ниже 11 на данный момент сняты с поддержки Microsoft и более не обновляются.

<FilterFile lte="0" max="99.0.0.0" min="10.0.0.0" gte="1" type="VERSION" path="%ProgramFilesDir%Internet Exploreriexplore.exe" bool="AND" not="0" hidden="1"/>

Перед вами появится специальная форма, практически полностью идентичная настройкам параметра обозревателя в панели управления Windows. Например, вы можете указать домашнюю страницу (Вкладка General, поле Home page).

Важно. Не достаточно просто сохранить внесенные изменения в редакторе политики. Обратите внимание на красные и зеленые подчеркивания у настраиваемых параметров Internet Explorer 10. Красное подчеркивание говорит о том, что эта настройка политики не будет применяться. Чтобы применить конкретную настройку, нажмите F5. Зеленое подчеркивание у параметра означает, что этот параметр IE будет применяться через GPP.

Доступные функциональные клавиши

F5 – Включить все настройки на текущей вкладке
F6 – Включить выбранный параметр
F7 – Отключить выбранный параметр
F8 – Отключить все настройки на текущей вкладке

Чтобы указать параметры прокси-сервера, перейдите на вкладку Connections и нажмите кнопку Lan Settings). Прокси сервер можно настроить одним из следующих способов:

Automatically detect settings — автоматическое определение настроек прокси с помощью файла wpad.dat;
Use automatic configuration script — скрипт автоконфигурации (proxy.pac);
Proxy Server – можно вручную указать IP адрес или DNS имя прокси сервера и порт подключения. Это самый простой способ настроить прокси в Windows, его и будем использовать.

Поставьте галку Use a proxy server for your LAN, а в полях Address и Port соответственно укажите IP/FQDN имя прокси-сервера и порт подключения.

Включив опцию Bypass Proxy Server for Local Addresses можно запретить приложениям (в том числе браузеру) использовать прокси-сервер при доступе к локальным ресурсам (в формате
http://intranet
). Если вы используете адреса ресурсов вида
https://winitpro.ru
или
http://192.168.20.5
, то эти адреса не распознаются Windows как локальные. Эти адреса и адреса других ресурсов, для доступа к которым не нужно использовать прокси, нужно указать вручную. Нажмите кнопку Advanced и в поле Exceptions введите адреса в формате:
10.*;192.168.*;*.loc;*.contoso.com

Совет. Параметры прокси-сервера в Google Chrome можно задать централизованно через GPO с помощью специальных административных шаблонов. Для Mozilla Firefox можно использовать такое решение.

После сохранения политики вы можете просмотреть XML файл с заданными настройками браузера в каталоге политики на контроллере домена \DC1SYSVOLwinitpro.ruPolicies(PolicyGuiID) UserPreferencesInternetSettingsInternetSettings.xml

В GPP есть возможность более тонко нацелить политику на клиентов. Для этого используется GPP Item Level Targeting. Перейдите на вкладку Common, включите опцию Item-level targeting -> Targeting.

В открывшейся форме укажите условия применения политики. В качестве примера я указал, что политика настройки прокси будет применена только к пользователям, которые состоят в доменной группе ruspb_proxy_users. Вы можете использовать собственную логику назначения параметров прокси (в зависимости от IP подсети, сайта AD и т.д.).

Осталось назначить политику IE на контейнер с пользователями и обновить политики на них. После обновления политики на компьютерах пользователей должны примениться новые настройки прокси в IE. В Windows 10 текущие параметры прокси можно посмотреть в разделе Settings -> Network and Internet -> Proxy. Как вы видите, на компьютере теперь заданы настройки прокси, указанные в доменной политике.

Чтобы запретить пользователям менять настройки прокси-сервера, воспользуйтесь этой статьей.

Настройка параметров прокси через реестр и GPO

Кроме того, настроить параметры IE можно и через реестр, политиками GPP. К примеру, чтобы включить прокси для пользователя нужно настроить следующие параметры реестра в ветке HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionInternet Settings.

Перейдите в редакторе GPO в раздел User Configuration -> Preferences -> Windows Settings -> Registry и создайте три параметра реестра в указанной ветке:

ProxyEnable
(REG_DWORD) =
00000001
ProxyServer
(REG_SZ) =
192.168.0.50:3128
ProxyOverride
(REG_SZ) =
*winitpro.ru;https://*.contoso.com;192.168.*;<local>

Здесь также можно использовать Item level targeting для более тонкого нацеливания политик.

Если вам нужно создать политики не для каждого пользователя (per-user), а для всех пользователей компьютера (per-computer), используйте параметры GPP из раздела GPO Computer Configuration -> Preferences -> Windows Settings -> Registry. Используйте аналогичные параметры реестра в ветке HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsCurrentVersionInternet Settings.

Настройка параметров WinHTTP прокси групповыми политиками

Некоторые системные сервисы или приложения (например, служба обновлений Wususerv или PowerShell) по-умолчанию не используют пользовательские настройки прокси сервера из параметров Internet Explorer. Чтобы такие приложения работали корректно и получали доступ в интернет, вам нужно задать в Windows настройки системного прокси WinHTTP.

Чтобы проверить, настроен ли на вашем компьютере WinHTTP прокси, выполните команду:

netsh winhttp show proxy

Ответ “
Direct access (no proxy server)
” говорит о том, что прокси не задан, система использует прямой интернет доступ.

Вы можете задать на компьютере прокси для WinHTTP вручную командой:

netsh winhttp set proxy 192.168.0.50:3128 "localhost;192.168.*;*.winitpro.com"

Или импортировать настройки прокси из параметров Internet Explorer теекщего пользователя:

netsh winhttp import proxy source=ie

Однако настроить WinHTTP через GPO не получится – в редакторе GPO нет соответствующего параметра, а в реестре параметры хранятся в бинарном виде и не подходят для прямого редактирования.

Единственный вариант задать параметры WinHTTP прокси – настроить их на эталонном компьютере, выгрузить значение параметра WinHttpSettings в ветке реестра HKLMSOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsConnections в reg файл и распространить этот параметр на компьютеры в домене через GPP registry.

Источник

Microsoft Web Application Proxy was introduced in Windows Server 2012 R2. It allows you to access web applications from outside your network and it acts as a reverse proxy and an Active Directory Federation Services proxy to pre-authenticate user access.

This guide walks you through the steps to install and configure web application proxy role on Windows Server 2016.

Web Application Proxy New Features

Preauthentication for HTTP Basic application publishing
HTTP Basic is the authorization protocol used by many protocols, including ActiveSync, to connect rich clients, including smartphones, with your Exchange mailbox. Web Application Proxy traditionally interacts with AD FS using redirections which is not supported on ActiveSync clients. This new version of Web Application Proxy provides support to publish an app using HTTP basic by enabling the HTTP app to receive a non-claims relying party trust for the application to the Federation Service.
Wildcard domain publishing of applications
To support scenarios such as SharePoint 2013, the external URL for the application can now include a wildcard to enable you to publish multiple applications from within a specific domain, for example, https://*.sp-apps.contoso.com. This will simplify publishing of SharePoint apps.
HTTP to HTTPS redirection
In order to make sure your users can access your app, even if they neglect to type HTTPS in the URL, Web Application Proxy now supports HTTP to HTTPS redirection.
HTTP Publishing
It is now possible to publish HTTP applications using pass-through preauthentication
Publishing of Remote Desktop Gateway apps
New debug log for better troubleshooting and improved service log for complete audit trail and improved error handling
Administrator Console UI improvements
Propagation of client IP address to backend applications

The following diagram explains the architectural layout of Web Application Proxy.

Prerequisites

Web Application Proxy and Active Directory Federation Services can not be deployed on same server. You need an additional server to set up web proxy. We assume that the following services are already installed and configured accordingly.

Active Directory Domain Services
Active Directory Federation Services

Installing the Web Application Proxy Server Role

To begin, Open up Server Manager and click Manage click Add Roles and Features

Click Next:

Select Role-based or feature-based installation, click Next:

Select the server you want to install this role on to and then click Next:

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.

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: Scroll 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. Make sure you export the Private Key and certificate as a .pfx file format.

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 you are ready to start the Post Configuration settings.

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

Finally, its time to publish apps. In the Remote Access Management Console click Web Application Proxy then Publish

Click Next:

Pass-through will let WAP act like a reverse proxy.

Here you have two options: (AD FS and Pass-through) self-explanatory. I have already set up AD FS in your environment then go with the first option otherwise 2nd is my choice since at the moment I don’t have AD FS.

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:

Here you can see the published web application is ready for testing.

Before you move to test your published app, ask your network guy to set up 443 port redirection to WAP server on firewall to make it possible to access web applications from the external network.

Once done.

Then from the external network (for example on your smartphone or a PC) from home, try to access your web link like https://rds.techsupportpk.com and the following page will show up.

You have successfully deployed Web Application Proxy in your environment.

Источник

В этой статье мы рассмотрим, как в Windows Server 2016, для получения доступа к информации из любого места, можно использовать обновлённый Web Application Proxy.

Содержание:

1 Web Application Proxy и новые возможности публикации
2 Сценарии Remote Desktop Gateway
- 2.1 Аудит доступа к ресурсам
- 2.2 Применение прокси приложений в современном мире ИТ

Web Application Proxy и новые возможности публикации

Пользователи могут получить доступ к данным компании с помощью различных устройств, например, портативных компьютеров, планшетов и смартфонов. С этих устройств можно отправлять запросы из любого места, но пользователи ожидают иметь тот же функционал, к которому они привыкли находясь на своей территории. IT должно гарантировать, что весь канал связи защищён, от данных, находящихся в центре обработки (на месте или в облаке), до данных в пути к целевому устройству. Там, они также должны быть защищены.

Чтобы предоставить пользователям безопасный доступ к данным компании, Web Application Proxy в Windows Server 2016 был расширен, охватывая больше сценариев с приложением (BYOD), например Pre-Auth с Microsoft Exchange Server. Web Application Proxy, для аутентификации и авторизации, по-прежнему используют Active Directory Federation Services (AD FS) и AD DS.

Эта интеграция очень важна для BYOD сценариев, потому что даёт возможность создавать свои пользовательские правила для локальных пользователей, отличные от тех, что даются через Интернет.

Примечание. Если вы не знакомы с Web Application Proxy в Windows Server 2012 R2, читайте статьи на http://technet.microsoft.com/library/dn584107.aspx.

Опыт установки Web Application Proxy аналогичен предыдущей версии Windows Server 2012 R2. Таким образом для его установки в Windows Server 2016 можно использовать те же шаги. После завершения установки, вам предлагается выполнить конфигурацию после развёртывания.

Конфигурация после развёртывания для Web Application Proxy

Примечание. Перед развёртыванием Web Application Proxy, убедитесь, что вы спланировали инфраструктуру согласно рекомендациям из статьи на http://technet.microsoft.com/library/ dn383648.aspx. Эта статья была написана для Windows Server 2012 R2, но рекомендации по-прежнему применяются к Windows Server 2016.

Когда вы закончите шаги post-deployment, которые в основном подключают Web Application Proxy для сервера AD FS, можно использовать Publish New Application Wizard. Вы заметите, что в этой новой версии были введены некоторые изменения. Первое изменение вы увидите при нажатии кнопки «Опубликовать», под инструментом управления Web Application Proxy (параметры доступны в левой панели). Например на странице предварительной проверки подлинности, вы можете выбрать либо Active Directory Federation Services (AD FS) или метод предварительной аутентификации Pass-Through.

Выбор предварительной проверки подлинности

В этом примере, как метод предварительной проверки подлинности, выберите Active Directory Federation Services (AD FS) и затем нажмите кнопку «Далее». На странице Supported Clients ваши варианты — Web And MSOFBA, HTTP Basic или OAuth2.

Поддерживаемые клиенты

Чтобы выполнять предварительную проверку подлинности клиентов с использованием протокола Microsoft Office Forms Based Authentication (MSOFBA), можно использовать параметр Web and MSOFBA. MSOFBA при использовании клиентских приложений Office, обеспечивает проверку подлинности на основе форм базовой или NTLM аутентификации. Второй вариант — базовая проверка подлинности HTTP, которую можно использовать в таких сценариях, как Exchange Active Sync (ActiveSync). Это новые, добавленные в этот выпуск Web Application Proxy, возможности.

Для сценария, ActiveSync процесс аутентификации включает четыре основных этапа:

WAP, останавливает запрос и передаёт все учётные данные AD FS.
AD FS проверяет, применяет политику и отвечает с маркером.
После успеха Web Application Proxy разрешает передачу запроса на сервер Exchange.
Web Application Proxy кэширует маркер для будущего использования.

Третий вариант — OAuth2, который является основой авторизации многих производителей, включая Microsoft. Web Application Proxy поддерживает OAuth2 с Windows Server 2012 R2. Однако параметр не был доступен в пользовательском интерфейсе (UI).

Подробнее. Чтобы узнать больше о OAuth2, перейдите на http://tools.ietf.org/html/rfc6749. Вы можете найти дополнительную информацию о поддержке AD FS для OAuth2 на http://technet.microsoft.com/ library/dn383640.aspx.

После того, как вы выберите соответствующего клиента для публикации, нажмите кнопку «Далее». Страница «Параметры публикации» включает в себя одну новую опцию, где вы можете включить перенаправление HTTP на HTTPS.

Параметры публикации

Это большое дополнение, так как чтобы включить перенаправление HTTP на HTTPs в Windows Server 2012 R2, необходимо установить и настроить Internet Information Services (IIS). Обратите внимание, что этот параметр отмечен по умолчанию. Но, перед нажатием кнопки «Дальше» и переходом к странице подтверждения, убедитесь, что он выбран для вашего приложения.

Сценарии Remote Desktop Gateway

Изменения, которые впервые были сделаны в пакете обновления Windows Server 2012 R2 августа 2014, относительно того как Web Application Proxy обрабатывает публикации Remote Desktop Gateway, включены в этом выпуске. Это изменение упрощает процесс развёртывания для ИТ-администраторов, которые планируют публиковать RDP через Web Application Proxy и позволяет Remote Desktop Gateway собирать использованный Remote Desktop Web Access для аутентификации трафика RDP через HTTP, файл cookie сеанса.

Аудит доступа к ресурсам

Windows Server 2016 вводит новые возможности, что позволяет администраторам улучшить аудит доступа к опубликованным ресурсам. Теперь Web Application Proxy, чтобы проверить существует ли заголовок X-Forwarded-For (XFF), добавляет его каждому запросу. Если это так, Web Application Proxy связывает IP клиента с этим заголовком.

Примечание. XFF это нестандартный заголовок HTTP, который стал стандартом де-факто. Он широко используется с прокси-серверами для определения IP возникающего запроса. Дополнительные сведения об этом прочитайте на http://tools.ietf.org/html/rfc7239.

Ещё один важный аспект Web Application Proxy — возможность аудита событий, которые регистрируются в Event Viewer. В этом выпуске средство просмотра событий включает в себя множество событий, таких как журналы отладки и аналитики.

Применение прокси приложений в современном мире ИТ

Несколько лет назад у нашей команды была большая дилемма. У нас на рынке было два продукта: Forefront Threat Management Gateway и Forefront Unified Access Gateway. Оба эти продукта существовали в течение многих лет и были развёрнуты десятками тысяч клиентов. Оба они развивались с тех пор, как были впервые представлены в 1990-х годах.

Однако оба продукта имели схожие проблемы: они были очень сложными, сложными для развёртывания, устранения неполадок и обслуживания. Отчасти это было потому, что за эти годы они накопили много возможностей, которые стали неуместными. В то же время не хватало или имелась ограниченная поддержка современных технологий, таких как OAuth2. Вдобавок ко всему, это были дорогие продукты, со своими лицензиями.

Это было жёсткое решение, но мы решили начать с чистого листа, изучить все функции обратного прокси, выбрать и отобрать только те технологии, которые имеют значение сегодня, и реализовать их, используя новую базу кода, построенную на большинстве современных стандартов. Основная часть этого решения заключалась в том, что мы хотели встроить в Windows Server обратный прокси. Мы хотели сделать это точно так же, как и любую другую службу роли, доступной для установки из диспетчера сервера. Для нас это означало соблюдение самых строгих стандартов в отношении кода и управления. Клиенты Microsoft ожидают, что все службы роли Windows Server будут управляться одинаково, в том числе в Windows PowerShell, пользовательский интерфейс администратора, удалённый пользовательский интерфейс администратора, счётчики производительности, пакет System Center Operations Manager, журналы событий и т. д.

Именно так в Windows Server 2012 R2 появился Web Application Proxy. Мы не делали компромиссов по обеспечению безопасности кода, управлению и стандартизации. И мы были счастливы, что клиенты получили его. Компании смогли легко внедрить и интегрировать Web Application Proxy в свою инфраструктуру.

Недостаток этого подхода в том, что мы не смогли включить все функциональные возможности, которые хотели иметь — функциональность, которая позволила бы всем клиентам перейти с Threat Management Gateway и Unified Access Gateway к новому решению. Однако теперь, когда мы создали прочную основу, стало проще добавить больше функциональности, чтобы сделать Web Application Proxy очевидным выбором для публикации локальных ресурсов, таких как Microsoft SharePoint, Lync и Exchange удалённым пользователям. Эта версия знаменует важную веху в путешествии, которое мы начали довольно много лет назад.

Теперь пришло время начать ещё одно путешествие и обеспечить удалённый доступ к облачной эре. В качестве другого инструмента для публикации пользователями приложений в облачных решениях, мы создали Azure Active Directory Application Proxy. К счастью, Web Application Proxy в Windows Server и Azure Active Directory Application Proxy используют много кода. Более того, они используют одни и те же концепции и восприятие удалённого доступа, делая их простыми в развёртывании и лёгкими в поддержке.

В будущем мы продолжим развивать оба продукта. Мы планируем предложить заказчикам Microsoft выбор в использовании архитектуры. Облако предлагает пользователям уникальный и высокоэффективный способ реализации удалённого доступа, с использованием богатых функциональных возможностей и надёжных механизмов безопасности Azure Active Directory, без необходимости изменения их периметрической сети. Тот же сервис, который обслуживает 18 миллиардов запросов на проверку подлинности в неделю, обрабатывает ваши локальные приложения.

Меир Менделович, старший менеджер программы

Источник

Рубрика:

Безопасность /
Механизмы защиты

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

СЕРГЕЙ ЯРЕМЧУК, автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС, grinder@samag.ru

Использование Web Application Proxy
в Windows Server 2012 R2/2016

Знакомимся с возможностями роли WAP, появившейся в Windows Server 2012 R2, которая позволяет обеспечить безопасный доступ к приложениям

Возможности Web Application Proxy

Роль Web Application Proxy (прокси-сервер веб-приложений) пришла на замену продукту Forefront Unified Access Gateway, поддержка которого была завершена в 2013 году. Сервер WAP размещается в DMZ и позволяет публиковать приложения для доступа извне, обеспечивая требуемый уровень безопасности. Для этого он выступает как прокси, принимая HTTPS-запрос на внешний адрес и транслируя его на сервис, работающий по протоколу HTTP или HTTPS. Вотличие от традиционно используемых для доступа к внутренним ресурсам VPN пользователю будут доступны только разрешенные ему приложения. Такой прокси обеспечивает дополнительную защиту, т.к. любой нецелевой трафик иизвестные сетевые атаки отбрасываются, не достигая приложения. Примечательно, что приложения могут использовать один IP-адрес или порт, это не вызовет проблем, т.к. WAP определяет нужное по имени. WAP также поддерживает функцию Workplace Join, дающую возможность пользователям получать доступ к корпоративным ресурсам с мобильных устройств. Поддержка технологии Single-Sign-On (SSO) позволяет после подключения к домену больше не вводить пароль для доступа к разрешенным приложениям.

В своей работе WAP опирается на Active Directory Federation Service (AD FS), которому передает все запросы на подключение, для аутентификации пользователя средствами Active Directory и контроля доступа на основе заявок (Claims Based Access). В случае удачи AD FS выдает SSO-маркер безопасности, содержащий идентификатор пользователя и ресурса, к которому запрашивались доступ и срок. WAP сохраняет всю информацию в Cookies и инициирует соединение кприложению. Приложение после проверки маркера допускает пользователя без ввода пароля.

Использование AD FS упрощает масштабирование, т.к. теперь можно легко подключить к AD FS любое количество серверов с ролью WAP, но, естественно, требует обязательного наличия домена. Сервер с ролью AD FS традиционно находится во внутренней сети, WAP при этом повышает его защищенность, не позволяя обращаться к нему напрямую. AD FS обеспечивает все современные технологии безопасности: многофакторная аутентификация (Multifactor authentication) и контроль доступа (Мultifactor Access control) c использованием дополнительных ступеней – одноразовый пароль или смарт-карта. Для старых приложений, не поддерживающих аутентификацию через AD FS, предусмотрен режим Pass-through preauthentication, при котором соединение просто пробрасывается дальше, а аутентификация производится самим приложением. Естественно, в этом случае о MFA и MAC речи не идет.

Кроме аутентификации пользователя, WAP совместно со службой Device Registration Service может проверять сертификат устройства пользователя, разрешая доступ к корпоративным ресурсам только с одобренных устройств. WAP нетребует дополнительных лицензий клиентского доступа (CAL), необходима лишь лицензия на сам сервер.

На основании отзывов пользователей в Windows Server 2016 WAP был доработан и получил новые возможности. Теперь автоматически происходит перенаправление на защищенный сайт, т.е. HTTP к HTTPS. Раньше это требовало дополнительных настроек и установки IIS, теперь же достаточно отметить флажок. Возможна публикация HTTP-приложений со сквозной проверкой подлинности, ранее это не разрешалось по причинам безопасности, но HTTP, какоказалось, все-таки нужен. WAP совместим с Lync Server, поддерживает Exchange Active Sync (EAS) и Remote Desktop Gateway. Поддерживается возможность преаутентификации HTTP Basic, используемого многими приложениями, в том числе и Exchange ActiveSync. Логин и пароль будут автоматически извлечены из URL и на их основании выдан маркер. Стала доступной публикация нескольких приложений внутри одного домена с помощью шаблона URL, вроде https://*.example.org/.

Статью целиком читайте в журнале «Системный администратор», №04 за 2016 г. на страницах 45-47.

PDF-версию данного номера можно приобрести в нашем магазине.

Facebook

Twitter

Мой мир

Вконтакте

Одноклассники

Google+

Источник

В данной статье представлена настройка взаимодействия контроллера SoftWLC с Active Directory, развернутом на Windows Server 2016. А также генерация TSL сертификатов на стороне Windows Server посредством Certificate Services с последующей автоматической выдачей сертификатов пользователям, для авторизации в сети Wi-Fi.
Настройка взаимодействия контроллера SoftWLC с более ранними версиями Windows Server будет отличаться только внешним видом вкладок. Логика и последовательность настройки взаимодействия аналогична.

Перед тем как устанавливать какие либо компоненты на сервер AD, убедитесь что у вас есть актуальный, рабочий бекап.

Ключевые моменты будут выделены на скринах красным цветом.

Схема проксирования

Рассмотрим схему проксирования RADIUS трафика через SoftWLC.

На SoftWLC настроено несколько доменов, в которые заведены точки доступа. SSID можно привязать к определенному домену, и при подключении пользователя к сети Wi-Fi , трафик будет проксироваться на radius сервер который установлен на Windows сервере. Далее AD, согласно настроенных политик проверит сертификат TLS и разрешит подключение к сети Wi-Fi . Чтобы схема работала, нам необходимо:

Вынести точки доступы в отдельный домен, в нашем случае winad.root
Настроить Radius proxy на определенный домен
Настроить AD, Сервер политик сети, Центр сертификации и саму выдачу сертификатов.

Создаем отдельный домен

2. Выносим ТД в этот домен, и проверяем что SSID закреплен за этим доменом, при необходимости меняем.

Так же это можно посмотреть на самой точке доступа.

3. Настраиваем Raduis proxy v1.13_Проксирование на внешний RADIUS -сервер

# Proxying
proxy_auth=1
proxy_domain_regex="winad.root$"
proxy_host="ip_address_windows"
proxy_port=1812
proxy_secret="eltex"

На этом настройка SoftWLC заканчивается.

Установка AD (Windows Server 2016)

Сначала необходимо установить роль AD и повысить роль сервера до контроллера домена.

В диспетчере серверов нажмите «Добавить роли и компоненты»

Мастер установки напоминает нам о важных моментах на которые необходимо обратить внимание.

В качестве типа установки укажите «Установка ролей или компонентов».

Выбираете ваш сервер из списка.

Не устанавливайте одновременно все роли сервера. Для корректной установки «Центра сертификации» необходимо сначала повысить роль сервера до контроллера домена и только потом устанавливать «Центр сертификации», иначе могут возникнуть некоторые ошибки.

Далее необходимо выбрать роль «Доменные службы Active Directory».

После выбора «Доменные службы Active Directory», появится всплывающее окно, ничего не изменяем и нажимаем «Добавить компоненты».

В установке данных компонентов нет необходимости, нажимаем «Далее»

Мастер установки поясняет некоторые моменты службы AD, нажимаем «Далее»

Подтверждаем установку необходимых средств и модулей, нажимаем «Установить»

Дожидаемся окончания установки, нажимаем «Закрыть»

В настоящий момент на сервере установлена AD, но нет контроллера домена. Нажимаем на флажок рядом с желтым треугольником и повышаем роль сервера.

Далее создадим новый домен в котором будем заводить пользователей.

Выбираем «Добавить новый лес» и вводим имя нового корневого домена.

Запишите и сохраните данный пароль, в некоторых случаях восстановления он жизненно необходим.

В нашем случае мы нажимает «Далее»

Указываем доменное имя NetBIOS

Если вы хотите вынести журналы и путь до базы данных измените данные параметры.

Проверка выставленных параметров для повышения роли, еще раз проверьте что верно указали домен и прочие службы.

Перед началом повышения роли, будет «Проверка предварительных требований».

Если все прошло успешно сервер будет установлен как контроллер домена, и ему понадобится перезагрузка.

Далее установим «Службу политики сети и доступа» и «Службу сертификатов Active Directory».

Мастер установки напоминает нам о важных моментах на которые необходимо обратить внимание.

В качестве типа установки укажите «Установка ролей или компонентов».

Выбираете ваш сервер из списка.

Далее необходимо выбрать роль «Службу политики сети и доступа» и «Службу сертификатов Active Directory».

В обоих случаях жмем «Добавить компоненты» и ничего не изменяем.

В установке данных компонентов нет необходимости, нажимаем «Далее»

Ознакомительная информация о «Службе политики сети», нажимаем «Далее»

Ознакомительная информация о «Службе сертификатов», нажимаем «Далее»

Так как в конце данной статьи мы рассмотрим автоматическую генерацию сертификатов для всех пользователей группы, необходимо установить только центр сертификации.

Подтверждаем установку служб.

Если установка завершилась удачно, закрываем мастер установки.

После установки настроим «Службу сертификации Active Directory».

Лучше не менять учетные данные если на то нет веских причин, нажимаем «Далее»

Так как мы установили только «Центр сертификации», при конфигурировании можем выбрать только его.

Выбираем «ЦС предприятия»

Так как мы устанавливаем ЦС с нуля и у нас нет подчиненных ЦС, он будет являться корневым.

В данном примере мы создадим новый закрытый ключ, так как не планируем поддерживать ранее выданные сертификаты.

Укажем необходимый алгоритм и длину ключа который удовлетворяет нашим параметрам безопасности.

Если необходимо можно изменить имя ЦС, чаще всего это делают если есть подчиненные ЦС, в нашем случае оставим предложенный вариант.

Срок действия сертификата, по истечению которого сертификат будет считаться не действительным.

Настоятельно рекомендую не изменять данные параметры.

Подтверждение перед настройкой, лучше еще раз убедиться во всех заданных значениях.

Если все прошло успешно будет установлен «Центр сертификации».

После того как мы установили необходимые компоненты они отобразятся в «Диспетчере серверов»

Настройка сервера сетевых политик

Выберем второй вариант сценария из списка и нажимаем кнопку «Настройка 802.1Х»

Задаем имя подключения и выбираем «Безопасные беспроводные подключения»

Далее необходимо добавить «RADUIS- клиентов»

Так как сервер SoftWLC будет проксировать RADIUS трафик на AD необходимо указать его адрес и секрет который он будет пересылать.

Нажимаем «Далее»

Так как аутентификацию мы будем осуществлять по сертификату, выбираем данный тип проверки.

Сдесь нам необходимо выбрать группы пользователей на которых будет распространятся данная политика.

В нашей схеме мы добавили группу «Пользователи домена» чтобы каждый пользователь смог подключиться к Wi-Fi по сертификату.

Можно указать несколько груп при необходимости.

В нашем примере настройка управления трафиком рассматриваться не будет.

Завершаем настройку нажав кнопку «Готово»

Создание новых пользователей

В нашем случае домен пустой и необходимо добавить пользователей.

Создаем пользователя

Задаем имя.

Задаем пароль, при необходимости установите соответствующие галочки.

Подтверждаем создание пользователя

После создания пользователя необходимо зайти в него и заполнить поле «Эл. почта», иначе могут возникнуть ошибки при автоматическом получении сертификата.

Создание шаблона сертификата

В Диспетчере серверов перейдите во вкладку «Служба сертификации AD». Кликните правой кнопкой мыши на сервер. В выпавшем списке выберите «Центр сертификации».

Переходим в управление шаблонов

Копируем шаблон пользователя, он уже обладает необходимыми свойствами.

Меняем имя у скопированного шаблона, чтобы в дальнейшем не путаться

Обязательно проверьте что выставлено «Разрешить экспортировать закрытый ключ».

Для автоматической выдачи сертификата, во вкладке безопасность на группе «Пользователи домена» необходимо выставить разрешение «Автоматическая подача заявок»

Добавление шаблона сертификата в оснастку «Шаблоны сертификатов»

После создания шаблона сертификата, его необходимо добавить в оснастку «Шаблоны сертификатов»

Выбираем ранее созданный шаблон

Теперь он должен отобразится в меню «Шаблоны сертификатов»

Настройка групповой политики автоматической выдачи сертификата

Теперь необходимо настроить групповую политику автоматической выдачи сертификата.

Создадим групповую политику выдачи сертификатов.

Политики именуйте по их назначению, чтобы в дальнейшем не запутаться.

После создания политики, выбираем ее в домене и нажимаем «Изменить»

По дереву переходим в «Политики открытого ключа», выбираем «Клиент служб сертификации: автоматическая регистрация» и нажимаем «Свойства»

Меняем модель конфигурации на «Включена»

Выставляем «Обновлять сертификаты, использующие шаблоны сертификатов», затем «Применить» и «ОК»

Сейчас мы добавим группу на которую будет распространятся данная политика.

Теперь необходимо обновить политики на сервере, в «Командной строке» набираем команду

Теперь клиентские хосты, которые введены в домен, при загрузке получат пользовательский сертификат и смогут с его помощью авторизоваться в Wi-Fi сети.

Пример настройки клиента Windows10

После того как мы настроили автоматическую выдачу сертификатов, необходимо проверить был ли он выдан на нашу учетную запись.

Необходимо перейти в хранилище сертификатов, для этого выполните команду mmc.

Затем «Файл», «Добавить или удалить оснастку» выбрать «Сертификаты»

Далее перейти в личное хранилище сертификатов, на скрине ниже видно что сертификат выдан на пользователя «Anton» и был использован шаблон «wifi»