Заметки сисадмина о интересных вещах из мира IT, инструкции и рецензии. Настраиваем Компьютеры/Сервера/1С/SIP-телефонию в Москве



Защита службы удаленного рабочего стола в Windows Server 2008 R2

2018-10-10 · Posted in Windows Server 2008

Служба удаленного рабочего стола (Remote Desktop Services – RDS) в Windows Server 2008 R2 имеет нечто большее, чем просто новое название; это вам не устаревшая служба терминалов. Благодаря новым компонентам (некоторые из них были представлены в Windows Server 2008), таким как RemoteApp, RD Gateway и RD Virtualization Host, эта роль сервера Windows теперь предоставляет вам гибкость в установке отдельных приложений или полных машин с помощью RDS или VDI решения – во многих случаях без необходимости в использовании Citrix или иных добавляемых модулей сторонних производителей.

Но как на счет безопасности? Все эти добавленные сложности сказываются на дополнительных моментах в области безопасности. В этой статье мы рассмотрим механизмы безопасности, встроенные в RDS, как использовать параметры конфигурации и групповую политику для повышения уровня безопасности, а также рекомендации к безопасности установки RDS.

Что нового в R2

Если вы приступаете к работе с RDS после работы со службами терминалов Windows Server 2008 Terminal Services, вы не встретите там много значительных изменений, как при переходе с Windows Server 2003. WS 2008 добавил некоторые значительные улучшения в службы терминалов, включая TS Web Access для подключения через браузер, TS Gateway для пользователей, подключающихся через интернет, RemoteApp для доставки отдельных приложений пользователям через Remote Desktop Protocol (RDP) протокол и Session Broker, который включает функцию балансировки нагрузки.

WS 2008 R2 добавил еще больше новинок:

  • Виртуализация удаленного рабочего стола (Remote Desktop Virtualization) для VDI решения
  • RDS Provider для PowerShell, чтобы администраторы могли изменять конфигурацию и выполнять задачи в интерпретаторе команд и с помощью сценариев
  • Виртуализация сетевого адреса (Remote Desktop IP Virtualization), которая позволяет присваивать IP адреса соединениям для каждого отдельного сеанса или программы
  • Новая версия RDP и Remote Desktop Connection (RDC) клиента, версия 7.0
  • Fair Share CPU планирование для динамического распределения времени обработки между сеансами на основе количества активных сеансов.
  • Совместимость с Windows Installer для упрощения установки программ, требующих настройки под отдельных пользователей.
  • Действительная поддержка нескольких мониторов (до 16 штук), благодаря которым программы работают так же, как они работают на клиентских машинах.

Также есть улучшения в аудио/видео и поддержке Windows Aero в RD сеансе (однако обратите внимание, что Desktop Composition, которая обеспечивает работу Aero, не поддерживается в сеансах с несколькими мониторами).

Аспекты и механизмы безопасности

Конечно потенциальные проблемы безопасности зависят от того, как устанавливать RDS. Если у вас более сложная конфигурация, в которой пользователи подключаются через интернет и/или браузер, у вас будет больше аспектов безопасности, которые нужно учитывать и прорабатывать, нежели при использовании простой конфигурации, в которой пользователи подключаются исключительно через RDC клиентов по LAN.

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

Проверка подлинности на сетевом уровне (Network Level Authentication)

Для максимального уровня безопасности следует требовать проверку подлинности на сетевом уровне (Network Level Authentication – NLA) для всех подключений. NLA требует, чтобы пользователи аутентифицировались на сервере RD Session Host, прежде чем сеанс будет создан. Это помогает защитить удаленные компьютеры от злоумышленных пользователей и вредоносного ПО. Чтобы использовать NLA, клиентский компьютер должен использовать операционную систему, которая поддерживает протоколы Credential Security Support Provider (CredSSP), то есть Windows XP SP3 и выше, а также иметь клиента RDC 6.0 или выше.

NLA настраивается на сервере RD Session Host в следующем разделе: Инструменты администрирования (Administrative Tools) | Службы удаленного рабочего стола (Remote Desktop Services) | Конфигурация узла сеансов удаленного рабочего стола (Desktop Session Host Configuration). Для настройки подключения на использование NLA, выполните следующие шаги:

  1. Нажмите правой клавишей Подключение (Connection)
  2. Выберите Свойства
  3. Перейдите в закладку Общие (General)
  4. Отметьте флажком опцию ‘ Разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности (Allow connections only from computers running Remote Desktop with Network Level Authentication)’, как показано на рисунке 1
  5. Нажмите OK.

*

Рисунок 1

Протокол Transport Layer Security (TLS)

Сеанс RDS может использовать один из трех уровней безопасности для защиты подключений между клиентами и сервером RDS Session Host:

  • Уровень безопасности RDP ‘ этот уровень использует собственное RDP шифрование и является наименее безопасным. Сервер RD Session Host не проходит проверку подлинности.
  • Согласовать (Negotiate) ‘ TLS 1.0 (SSL) шифрование будет использоваться, если клиент его поддерживает. Если нет, сеанс перейдет обратно на RDP безопасность.
  • SSL ‘ TLS 1.0 шифрование будет использоваться для проверки подлинности сервера и шифрования данных, передаваемых между клиентом и Session Host сервером. Это самая безопасная опция.

В соответствии с рекомендациями можно запросить SSL/TLS шифрование. Потребуется цифровой сертификат, который может быть выдан центром сертификации (желательно) или саморегистрируемым сертификатом.

Вдобавок к выбору уровня безопасности можно также выбрать уровень шифрования подключения. Здесь есть следующие варианты:

  • Низкий (Low) ‘ использует 56-разрядное шифрование для данных, пересылаемых с клиента на сервер. Не шифрует данные, пересылаемые с сервера клиенту.
  • Совместимый с клиентом (Client Compatible) ‘ это опция по умолчанию. Она шифрует данные передаваемые между клиентом и сервером с самым надежным ключом, который поддерживает клиент.
  • Высокий (High) ‘ эта опция шифрует данные в обоих направлениях между клиентом и сервером с помощью 128-битного шифрования.
  • FIPS-совместимый (FIPS Compliant) ‘ эта опция шифрует данные передаваемые в обоих направлениях между клиентом и сервером с помощью FIPS 140-1 утвержденного алгоритма шифрования.

Обратите внимание, что если выбрать опцию «Высокий» или «FIPS-совместимый», любые клиенты, не поддерживающие такие уровни шифрования, не смогут подключиться.

Вот, как настраивать параметры проверки подлинности и шифрования сервера:

  1. На сервере RD Session Host откройте раздел конфигурации Remote Desktop Session Host Configuration, а затем свойства подключения, как говорилось выше.
  2. В закладке Общие выберите соответствующий уровень безопасности и шифрования из раскрывающегося списка, как показано на рисунке 2.
  3. Нажмите OK.

*

Рисунок 2

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

Групповая политика

Есть ряд параметров групповой политики для RDS в Windows Server 2008 R2. Они расположены в разделе Конфигурация компьютера (Computer Configuration) Политики (Policies) Административные шаблоны (Administrative Templates) Компоненты Windows (Windows Components) Службы удаленного рабочего стола (Remote Desktop Services) в консоли управления групповой политикой вашего домена, как показано на рисунке 3.

*
Рисунок 3

Как вы видите, здесь есть политики для лицензирования RDC клиентов и сервера RD Session Host. Политики для сервера RD Session Host, связанные с безопасностью, включают:

  • Шаблон сертификата проверки подлинности сервера (Server Authentication Certificate Template): используйте эту политику, чтобы указать имя шаблона сертификата, которые определяет, какой сертификат будет автоматически выбираться для проверки подлинности сервера RD Session Host. Если включить эту политику, только сертификаты, создаваемые с помощью указанного шаблона, будут учитываться при выборе сертификата для проверки подлинности сервера RD Session Host.
  • Задать уровень шифрования клиентских подключений (Set Client Connection Encryption Level): эта политика используется, чтобы контролировать то, будет ли требоваться определенный уровень шифрования. Когда вы включаете эту политику, все соединения должны использовать указанный уровень шифрования. Уровнем шифрования по умолчанию является Высокий уровень.
  • Всегда запрашивать пароль при подключении (Always Prompt for Password upon Connection): можно использовать эту политику, чтобы заставить RDS всегда запрашивать пароль пользователя при входе в RD сеанс, даже если пароль введен на RDC клиенте. По умолчанию, пользователи могут входить автоматически, если пароль введен на клиенте RDC.
  • Требовать защищенные RPC соединения (Require Secure RPC Communication): включение этой политики означает, что только зашифрованные и прошедшие проверку подлинности запросы с клиентов будут разрешены. Соединения с не доверенными клиентами не будут разрешены.
  • Требовать использование определенного уровня безопасности для RDP подключений (Require Use of Specific Security Layer for Remote (RDP) Connections): если включить эту политику, все соединения между клиентами и серверами Session Host должны использовать уровень безопасности, который вы здесь укажете (RDP, Negotiate или SSL/TLS)
  • Не разрешать локальным администраторам настраивать разрешения (Do Not Allow Local Administrators to Customize Permissions): эта политика отключает права администраторов на изменение разрешений безопасности в инструментах настройки RD Session Host Configuration, что не позволяет локальным администраторам изменять группы пользователей в закладке Разрешений (Permissions) в инструменте конфигурации.
  • Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require User Authentication for Remote Connections by using Network Level Authentication): с помощью этой политики вы можете требовать NLA для всех удаленных подключений к серверу RD Session Host. Только клиенты с поддержкой NLA смогут подключаться.

Примечание: вот, как узнать, поддерживает ли клиентский компьютер проверку подлинности на сетевом уровне: откройте RDC клиент и нажмите значок в верхнем левом углу, затем выберите ‘О программе (about)‘. Если NLA поддерживается, вы увидите строку ‘Network Level Authentication Supported’.

Другие параметры групповой политики, о которых следует упомянуть, расположены в разделе клиентских соединений RD Connection Client. Они включают:

  • Не разрешать сохранение паролей (Do not allow passwords to be saved): включение этого параметра отключит опцию сохранения паролей в диалоге клиента RDC. Если пользователь откроет RDP файл и сохранит свои параметры, ранее сохраненные пароли будут удалены. Это заставляет пользователя вводить свой пароль при каждом входе.
  • Указывать отпечатки SHA1 сертификатов, представляющих доверенных издателей RDP (Specify SHA1 thumbprints of certificates representing trusted .rdp publishers): с помощью этого параметра можно указать список отпечатков SHA1 сертификатов, и если сертификат соответствует отпечаткам в списке, он будет считаться доверенным.
  • Запрашивать учетные данные на клиентском компьютере (Prompt for credentials on the client computer): эта политика включает запрос учетных данных на клиентских компьютерах, а не на сервере RD Session Host.
  • Настроить проверку подлинности сервера для клиента (Configure server authentication for client): с помощью этого параметра можно указать, сможет ли клиент создать подключение к RD Session Host серверу, когда не может проверить подлинность сервера RD Session Host. Самым безопасным параметром будет опция ‘Не подключаться при неудачной аутентификации (Do not connect if authentication fails).’

Можно также использовать групповую политику для настройки FIPS соответствия, но эту политику здесь не найти с другими RDS политиками безопасности. Она расположена в следующем разделе: Конфигурация компьютера (Computer Configuration)Настройки Windows (Windows Settings)Настройки безопасности (Security Settings) Локальные политики (Local Policies)Опции безопасности (Security Options). В правой панели пролистайте вниз к: Системная криптография: использовать FIPS-совместимые алгоритмы для шифрования, хеширования и подписывания (‘System Cryptography: use FIPS compliant algorithms for encryption, hashing and signing’). При включении этой политики она поддерживает только Triple DES (3DES) алгоритм шифрования для RDS соединений.

RD Web Access

На компьютерах, где не установлен RDC клиент, пользователи могут получать доступ к опубликованным приложениям, к которым они имеют доступ из веб браузера. Пользователь переходит на URL адрес, по которому опубликованы RDS ресурсы. Сервер веб доступа RD Web Access Server является отдельным от RD Session Host сервером. Вы указываете, какие RD Web Access серверы могут подключаться к каким RD Session Host серверам.

Веб интерфейс настраивается с SSL и пользователь должен пройти проверку подлинности с помощью своих учетных данных. Прошедший проверку подлинности пользователь сможет увидеть лишь те RemoteApp программы, использование которых разрешено для его учетной записи, поскольку эти опубликованные программы «урезаются» с помощью списка управления доступом (ACL).

Сервер Web Access использует X.509 сертификат для обеспечения шифрования. По умолчанию используется саморегистрирующийся сертификат. Для большей безопасности следует получить сертификат в публичном центре сертификации или в PKI вашей компании.

RD Gateway

The RD Gateway (RDG) используется для предоставления пользователям доступа к RD ресурсам через интернет. Сервер шлюза Gateway расположен на границе, и он фильтрует входящие RDS запросы в соответствии с Network Policy Server (NPS). NPS использует две политики: Политика авторизации подключений (Connection Authorization Policy – CAP), в которой указывается, какие пользователи могут иметь доступ к RDG и Политика авторизации ресурсов (Resource Authorization Policy – RAP), указывающая, к каким устройствам CAP пользователь может подключаться через RDG.

Заключение

Службы удаленного рабочего стола в Windows Server 2008 R2 значительно расширяют функционал своего предшественника, службы терминалов ‘ но они также представляют некоторые новые аспекты безопасности, которые следует учитывать. Следуя рекомендациям к обеспечению максимальной безопасности при настройке компонентов RDS конфигурации ‘ RD Session Host, RD Web Access Server, RD Gateway и клиент ‘ а также используя групповую политику для управления конфигурацией, вы сможете получить безопасную среду и воспользоваться преимуществами RDS доставки приложений и обеспечить своим пользователям ощущение работы на полноценных компьютерах.

Fixing Microsoft Office 2013 poor performance in RDS environment

2018-10-05 · Posted in Office

After upgrading Microsoft Office 2007 to 2013, our RDS Server (previously known as Terminal Server) keep staying at 100% CPU usage and it’s users were complaining extreme slow performance of their Windows sessions.

We realize that Microsoft Office 2013 had enabled hardware graphics acceleration by default that caused this issue and proceed to disable it one by one on the RDS user side. We immediately see some performance improvement. (Firefox has similar performance issue in RDS environment where you need to disable hardware graphics acceleration as well.)

However, we cannot possibly keep doing this for every new user connecting to the server and they also have an option to re-enabled this at the expense of other users sharing the same environment. Thus, disabling this thru the Group Policy will be the best option.

First, download the Office 2013 group policy add on from:
https://www.microsoft.com/en-us/download/details.aspx?id=35554

  • Place the office15.admx file in C:WindowsPolicyDefinitions
  • Place the office15.adml file in C:WindowsPolicyDefinitionsen-US
  • Run gpedit.msc and enabled “Do not use hardware graphics acceleration”

Once this is done, every user login to the RDS server will have this option automatically enabled and gray out to prevent them from unchecking it!

Details can be found here:
https://support.microsoft.com/en-us/kb/2768648
and
https://msdn.microsoft.com/en-us/library/bb530196.aspx

Fixing Google Chrome poor performance in RDS environment thru Group Policy

2018-10-05 · Posted in HTML

Google Chrome has recently add hardware acceleration and enable it by default. While this work fine for standalone PCs, it has created massive problem for our Thin Client users running in the Remote Desktop Server environment.

A quick solution is to send an email to get every RDS user to disable this themselves by typing this in the chrome URL address field: chrome://settings/?search=hardware and switch off hardware acceleration (gray instead of blue colour). Then close all your chrome windows and open it again to relaunch.

However, most users just do not bothered to read the email, less follow thru the given instruction. And to do this for every user who can connect to multiple RDS servers can be a huge administrative nightmare.

Fortunately, Google has created an enterprise chrome website designed for businesses filled with helpful information here: https://enterprise.google.com/chrome/chrome-browser/, and here, you can find the ADMX templates for Chrome so that you can change the default setting and lock them up to prevent users from changing them at one go from the group policy: https://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip

To add the template into the group policy, unzip the policy_templates.zip in your domain controller and copy the chrome.admx and google.admx files from the unzipped policy_templateswindowsadmx folder into C:WindowsPolicyDefinitions. And the language files chrome.adml and google.adml from the correct language folder from the unzipped policy_templateswindowsadmxen-US (I’m using US English) into C:WindowsPolicyDefinitionsen-US

To apply this group policy only to the RDS servers, I have create a subfolder in the Active Directory and label it TSServers (Remote Desktop Server used to call Terminal Server). I drag all the RDS servers into this folder.

Next I create a GPO under this TSServers in the Group Policy Management Editor:

The Google Chrome policies can be found under: Computer Configuration > Policies > Administrative Templates > Google Chrome:

The recommended items to enable and disable are:

  • Enable – always open pdf files externally (opening pdf inside chrome cause all kind of unnecessary problems, especially when user want to print or fill up a pdf form etc)
  • Disable – continue running background apps when Chrome is closed (don’t let chrome remain running after user quit it as this affect performance)
  • Enable – download restrictions – block all dangerous download (prevent virus and malware from getting downloaded)
  • Disable – use hardware acceleration when available (This is the main resource hogger that need to be disabled)
  • Enable – safe browsing (Provide warning when naive users intend to do stupid things)

Enable – extension installation blacklist: value = * (I block all extension first unless users need a particular extension for work)

With this, every user (including new future users) will have these options configured and locked.

How to enable TLS v1.1/v1.2 for Windows 7/8 and Outlook 2007/2010/2013/2016

2018-10-04 · Posted in Office, Windows - 7, Windows - 8

Please consider that we haven’t tried the following instructions for Outlook 2007, if you are using this version released around 10 years ago you should consider upgrading to a newer version.

Follow the instructions below:

a) Update Windows 7/8 using Windows Update and download/install all important updates. For windows 7 is important that you install Service Pack 1.

b) Install KB3140245 and reboot: http://catalog.update.microsoft.com/v7/site/search.aspx?q=kb3140245

c) Execute the EasyFix and reboot: https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1-1-and-tls-1-2-as-a-default-secure-protocols-in

d) Start > Search for Execute, Type Regedit and press Enter to access Windows Registry.

Check this registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel\Protocols

Under the Protocols key, add two new keys, if not already there: One called “TLS 1.1” and one called “TLS 1.2“. Inside both of these keys, add another key called “Client“. Now create a DWORD value in each Client key called “DisabledByDefault” whose value is 00000000.

Reboot and start Outlook.

If Outlook is still not able to send or can’t connect to port 465, change to port 25.

NOTE: If you are not confident editing the Windows registry keys, please open a support ticket and we will provide you with a .reg file which will add the keys for you.

ZyWALL USG to reboot automatically by schedule

You can upload shell script to ZyWALL/USG and issue command line to achieve this

Step 1 : Create a shell script

1. Run Notepad application
2. Input below content

configure terminal
reboot

3. Save this file as “reboot.zysh”

4. Upload to ZyWALL/USG

Step 2 : Issuing schedule-run command line

1. Login via console/telnet/SSH

2. Issuing below commands

configure terminal
schedule-run 1 reboot.zysh daily 06:00
write
(The device will reboot at 06:00 everyday)

configure terminal
schedule-run 1 reboot.zysh weekly 10:00 sun
write
(The device will reboot at 10:00 every Sunday)

configure terminal
schedule-run 1 reboot.zysh monthly 10:00 23
write
(The device will reboot at 10:00 every month on 23th)