- 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.
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.
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.”
В этой статье мы рассмотрим, как в 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 миллиардов запросов на проверку подлинности в неделю, обрабатывает ваши локальные приложения.
Меир Менделович, старший менеджер программы
В этой статье мы рассмотрим, как централизованно задать настройки прокси на компьютерах с 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.
|
Рубрика: Безопасность / Механизмы защиты |
Мой мир Вконтакте Одноклассники 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-версию данного номера можно приобрести в нашем магазине.
Мой мир
Вконтакте
Одноклассники
Google+
In this article, we’ll take a look at how to centrally configure proxy settings on Windows 10 computers in a domain using Group Policy. Most popular browsers (such as Microsoft Edge, Google Chrome, Internet Explorer, Opera) and most applications automatically use the proxy settings set in Windows to access the Internet. We’ll also look at how to set up WinHTTP proxy settings on Windows.
Contents:
- How to Set Proxy Settings on Windows via GPO?
- Configure Proxy Setting via Registry and GPO
- Change WinHTTP Proxy Settings via GPO
In this article, we will look at the specifics of configuring a proxy server through Group Policy in supported versions of Windows (Windows 10, 8.1, and Windows Server 2012/2016/2019). Note that proxy settings are set differently in Windows 7/Server 2008R2, Windows XP/Windows Server 2003 with discontinued support.
How to Set Proxy Settings on Windows via GPO?
Originally, to centrally configure Internet Explorer settings (including proxy settings) using Group Policies in the Active Directory domain environment, the Internet Explorer Maintenance (IEM) policy was used. This policy option was located in the user GPO section: User configuration –> Policies –> Windows Settings –> Internet Explorer Maintenance. But since Windows Server 2012/Windows 8, the IEM policy has been deprecated. This section is missing in modern versions of Windows 10/Windows Server 2016/2019.
On the latest Windows versions, you must use Group Policy Preferences (GPP) to configure IE and proxy settings in the GPO Editor. There is also the option of using a special extension of Internet Explorer Administration Kit 11 (IEAK 11) – but it is rarely used.
Open the domain GPO Editor console (Group Policy Management Console – GPMC.msc), select the OU with the users to which you want to apply proxy settings, and create a new policy Create a GPO in this domain, and Link it here.
Go to User Configuration -> Preferences -> Control Panel Settings -> Internet Settings. In the context menu, select New -> Internet Explorer 10.
To configure proxy settings on Windows 10/Windows Server 2016, you need to use the Internet Explorer 10 item.
Tip. Although there is no separate option for Internet Explorer 11, the Internet Explorer 10 policy should apply to all versions of IE above 10 (in the InternetSettings.xml policy file, you can see that the option is valid to all IE versions from 10.0.0.0 to 99.0.0.0).
<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"/>
A special Group Policy Preferences IE form will appear in front of you, almost completely identical to the Internet Options settings in the Windows Control Panel. For example, you can specify a home page (General tab -> Home page field).
Important. It is not enough to simply save your changes in the Group Policy Editor. Notice the red and green underlines for the Internet Explorer 10 configurable settings. A red underline indicates that the setting won’t be applied. To save and apply a specific setting, press F5. A green underline of a parameter means that this IE parameter will be applied via GPP.
The following function keys are available:
- F5 – Enable all settings on the current tab
- F6 – Enable the selected setting
- F7 – Disable the selected setting
- F8 – Disable all settings in the current tab
To specify proxy settings, go to the Connections tab and click the Lan Settings button. The proxy server can be configured in one of the following ways:
- Automatically detect settings – automatic detection of settings using the wpad.dat file;
- Use automatic configuration script – auto-configuration script (proxy.pac);
- Proxy Server – the IP address or DNS name of the proxy server is specified directly in the policy settings. This is the easiest way, and we will use it.
Check the option Use a proxy server for your LAN, and specify the IP/FQDN name of the proxy server and the connection port in the corresponding Address and Port fields.
By enabling the Bypass proxy server for local addresses option, you can prevent applications (including the browsers) from using a proxy server when accessing local resources (in the format http://localnetwork). If you use resource addresses like http://web1.woshub.loc or http://192.168.1.5, then these addresses are not recognized by the Windows as local ones. These addresses and addresses of other resources, for access to which you do not need to use a proxy, must be specified manually. Press Advanced button and add this addresses to the field Do not use proxy servers for addresses beginning with in the following format: 10.1.*;192.168.*;*.woshub.loc;*.local.net.
Tip. Proxy settings in Google Chrome also can be set through the GPO using special administrative templates. Also, you can install the ADMX templates for Mozilla Firefox.
After you save the policy, you can view the InternetSettings.xml file with the specified browser settings in the policy folder on the domain controller:
\UKDC1SYSVOLwoshub.comPolicies{PolicyGuiID}UserPreferencesInternetSettingsInternetSettings.xml
GPP allows you to more finely target policy to users/computers. For this, GPP Item Level Targeting is used. Go to the Common tab, enable the option Item-level targeting -> Targeting.
In the form that opens, specify the conditions for applying the policy. As an example, I indicated that the proxy configuration policy will be applied only to users who are members of the proxy_users domain security group. You can use your own logic for assigning proxy parameters.
It remains to link the proxy policy to the AD container with the users and update policy settings on them. After applying policies on the users’ computers, new IE settings should be used. You can check the current proxy settings on Windows 10 in the Settings -> Network and Internet -> Proxy. As you can see, the computer now uses the proxy settings specified in the domain policy.
To prevent users from changing the proxy server settings, you can use this article.
Configure Proxy Setting via Registry and GPO
In addition, you can configure IE settings through the registry using GPP policies. For example, to enable proxy server, you need to configure the following registry parameter in the registry key HKEY_CURRENT_USERSoftwareMicrosoft WindowsCurrentVersionInternet Settings. In the GPO editor go to the section User Configuration -> Preferences -> Windows Settings -> Registry and create three registry parameters under the specified reg key:
ProxyEnable(REG_DWORD) =00000001ProxyServer(REG_SZ) =192.168.0.11:3128ProxyOverride(REG_SZ) =https://*.woshub.com;192.168.*;10.1.*;*.contoso.com;<local>
You can also use Item-level targeting here to target your policy settings for specific users/devices.
If you need to create proxy policies not per-user, but for the entire computer (per-computer), use the GPP settings from the GPO section Computer Configuration -> Preferences -> Windows Settings -> Registry. Set the same registry parameters under the registry key HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsCurrentVersionInternet Settings.
Change WinHTTP Proxy Settings via GPO
Some system services or applications (for example, the Wususerv update service or PowerShell) don’t use user’s proxy settings by default. For such applications to work correctly and access the Internet, you need to configure the WinHTTP proxy settings in Windows.
To check if WinHTTP proxy is configured on your computer, run the command:
netsh winhttp show proxy
The answer “Direct access (no proxy server)” means that no proxy is set. 
You can manually set a proxy for WinHTTP on your computer with the command:
netsh winhttp set proxy proxy.woshub.com:3128 "localhost;10.1.*;192.168.*;*.woshub.com"
Or import proxy settings from user’s Internet Explorer settings:
netsh winhttp import proxy source=ie
However, you won’t be able to configure WinHTTP through the GPO – there is no corresponding parameter in the GPO editor, and the parameter are stored in binary registry attribute that is not suitable for direct editing.
The only way to set WinHTTP proxy settings on Windows via GPO is to configure WinHTTP proxy on the reference computer, export the value of the WinHttpSettings parameter from the registry key HKLMSOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsConnections, and deploy this parameter to domain computers through the GPP registry extension.
