• Выпущены обновления Windows для закрытия критической уязвимости CVE-2019-0708 в службах удалённых рабочих столов Terminal Services и Remote Desktop Services с возможностью эксплуатации через протокол RDP

    RDP Remote Desktop Services Remote Code Execution Vulnerability14 Мая на портале Microsoft Security Response Center (MSRC) опубликована статья CVE-2019-0708 Remote Desktop Services Remote Code Execution Vulnerability, содержащая ссылки на обновления ОС Windows, закрывающие критическую уязвимость в работе служб удалённых рабочих столов Remote Desktop Services, которая может быть проэксплуатирована через протокол RDP. Ситуацию с данной уязвимостью можно считать довольно серьёзной, если взять во внимание то, что Microsoft выпустили обновления даже для служб Terminal Services снятых с поддержки систем Windows XP и Windows Server 2003.

    Читать далее...

  • Обновления для Windows Server Remote Desktop Services

    imageВ блоге Remote Desktop Services Blog опубликована заметка Staying current with Windows Server updates for Remote Desktop Services (RDS), в которой старший эскалационный инженер David Rankin (тех.поддержка Microsoft по направлению Remote Desktop) даёт полезную рекомендацию по использованию нескольких статей базы знаний Microsoft описывающих перечень исправлений/обновлений компонент служб RDS, применение которых может рассматриваться в качестве первоначальной меры по разрешению разнообразных проблем связанных с RDS.

    В соответствующих статьях перечисляются не только обновления доступные для загрузки и установки через службы Windows Update/WSUS (в основном из категории рекомендуемых обновлений), но и отдельные хот-фиксы, которых нет на Windows Update/WSUS (такие хот-фиксы должны применяться исключительно в ситуациях, описываемых в симптоматике соответствующих им статей KB). Заносим указанные статьи в Избранные ссылки, как отправные точки при решении проблем со службами RDS.

  • Загадочное поведение окна запуска баз 1С 7.7 настроенного через GPP Registry Wizard

    imageКак известно, программа запуска баз версии 7.7 (1cv7.exe) информацию о перечне зарегистрированных БД хранит в пользовательском ключе реестра HKEY_CURRENT_USER\Software\1C\1Cv7\7.7\Titles. При использовании 1С v7.7 в многопользовательской среде на серверах RDS в своё время у нас возник вопрос единообразной централизованной настройки указанного ключа реестра для всех пользователей, который мы успешно решили с помощью использования метода описанного в заметке Windows Server 2008 R2 – Добавление скриптов входа на сервере RDS через ключ реестра AppSetup. То есть фактически на серверы RDS был добавлен дополнительный winlogon-скрипт, выполняющий ряд необходимых настроек пользовательского окружения, в том числе и заполнение списка зарегистрированных БД 1С в указанном ключе реестра.

    Читать далее...

  • Windows Server и клиентские лицензии Per-Device RDS CAL

    imageНедавно, перебираясь на новый сервер лицензирования служб терминалов Remote Desktop Licensing на базе Windows Server 2012 с Windows Server 2008 R2 вспомнил про проблему, описанную в посте форума TechNet трёхлетней давности Terminal Services Licensing Warnings. На старом сервере лицензирования RD Licensing к настоящему моменту был настоящий бардак в смысле отображения имён клиентских компьютеров, получивших лицензии. Виной тому является информация хранящаяся на клиентских компьютерах в ключах реестра:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\HardwareID
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing\Store

    Не хотелось повторять ситуацию с именами клиентов на новом сервере лицензирования, и поэтому было решено немного углубиться в этот вопрос. В процессе изучения вопроса узнал для себя пару полезных утилит, которые на сегодня имеют уже почтенный возраст и найти их можно в пакете Windows Server 2003 Resource Kit Tools

    Утилита Terminal Server Client License Test tool (Tsctst.exe) запускается на клиентском компьютере с одним единственным ключом /A и позволяет в читаемом виде получить информацию, хранящуюся в выше указанных ключах реестра.

    image

    По каждой хранящейся в реестре лицензии TS/RDS CAL можно увидеть полную информацию о дате получения, сроке действия, сервере лицензирования и типе лицензии (License ID):

    A02-5.00-EX - Windows 2000 TS CAL from the “Built-in” pool.
    A02-5.00-S - Windows 2000 TS temporary or permanent CAL.
    A02-5.02-S - Windows server 2003 TS temporary or permanent CAL.
    A02-6.00-S - Windows server 2008 TS/2008 R2 RDS temporary or permanent CAL.


    Другая утилита Terminal Services Licensing Reporter (Lsreport.exe) позволяет получить более подробную информацию о выданных клиентских лицензиях с точки зрения самого сервера лицензирования.

    image

    Пример команды для построения отчета о всех выданных лицензиях включая информацию о клиентском HardwareID 

    LSREPORT /W /F C:TempLSReport.txt LICSERVER01

    image

    Итак, если на протяжении цикла жизни клиентского компьютера менялось его имя, то может получиться так, что в выше указанных ключах реестра будет храниться устаревшая информация и передаваться в таком же виде на сервер лицензирования, что в конечном итоге может привести к путанице и неразберихе. В качестве решения этой проблемы, да ещё и с учетом перехода на новый сервер лицензирования, может оказаться полезным выполнение очистки устаревшей информации из реестра на всех пользовательских компьютерах. Под очисткой подразумевается удаление соответствующих ключей реестра с добавлением прав на запись в родительский ключ, для того чтобы в дальнейшем у пользователей не возникло проблем с регенерацией этой информации в контексте их прав. Для решения этой задачи после ряда экспериментов получился следующий PowerShell скрипт:

    $REGKey = "HKLM:\SOFTWARE\Microsoft\MSLicensing"
    $ACLRKey = Get-ACL $REGKey
    [string]$SDDL = $ACLRKey.Sddl
    IF 
    (-NOT($SDDL -match "(A;CI;CCDCLCSWRPRC;;;)(IU|BU)")){
    Write-Host "ACL need to be update..."
    # S-1-5-4 (Interactive) / S-1-5-32-545 (Users)
    $RUser = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-545")
    $RList = [Enum]::Parse([Security.AccessControl.RegistryRights], "SetValue, CreateSubKey, ReadKey");
    $RType = [Enum]::Parse([Security.AccessControl.AccessControlType], "Allow");
    $RFlagInh = [Enum]::Parse([Security.AccessControl.InheritanceFlags], "ContainerInherit");
    $RFlagPro = [Enum]::Parse([Security.AccessControl.PropagationFlags], "None");
    $Rule = New-Object System.Security.AccessControl.RegistryAccessRule($RUser,$RList,$RFlagInh,$RFlagPro,$RType)
    $ACLRKey.AddAccessRule($Rule)
    Set-ACL $REGKey $ACLRKey
    }
    Remove-Item -Path $REGKey\* -Recurse


    Скрипт получает список разрешений на родительский ключ реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing и если в списке отсутствуют разрешения для групп Interactive Users (IU) или BUILTIN Users (BU), то добавляются разрешения для группы интерактивных пользователей, дающие право создания под-ключей и установки значений, после чего происходит рекурсивное удаление всего содержимого указанного ключа реестра.

    Скрипт выполняется на клиентских компьютерах в контексте системы (с полным набором прав). Доставку и запуск скрипта на клиентских компьютерах можно спланировать с помощью разных методов и средств, например GPO или SCCM.

    После этого, при следующем подключении к терминальным серверам, клиенты заново сгенерируют идентификационную клиентскую информацию и отправят её на сервер лицензирования RDS с новым запросом на получение клиентской лицензии. Разумеется, желательно тщательно спланировать этот процесс, чтобы не получилось так, что в один момент на сервере лицензирования попросту не останется свободных клиентских лицензий, так как каждый клиент будет занимать по две лицензии. Именно поэтому самым удобным моментом для такого “наведения порядка” может стать перевод клиентов с одного сервера лицензирования на другой.

    Дополнительные полезные источники информации:

    VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 1)
    VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 2)

    VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 3)

    VirtualizationAdmin.com - Troubleshooting Terminal Server Licensing Issues (Part 4)

    TechNet Library - Configuring a Computer for Troubleshooting Terminal Server Licensing

    KB315262 - How to transfer Terminal Services CAL from one client computer to another

  • Антивирус для Windows Server - настраиваем список исключений. Обновлено 11.08.2016

    imageВ ходе настройки политик управления клиентами любого антивирусного ПО необходимо определять список каталогов, имён процессов или даже расширений фалов, которые должны исключаться из Real-Time сканирования. Постараюсь собрать в одном месте информацию о рекомендуемых параметрах исключений и по мере необходимости буду его корректировать.  Стоит отметить, что список составлен исходя из приложений, которые эксплуатируются в моём рабочем окружении. Список разделен по основным категориям сервисов и там где возможно есть ссылки на официальные рекомендации производителей ПО. Во всех случаях подразумевается что программное обеспечение установлено в каталоги «по умолчанию».

    Читать далее...

  • GPP: Настраиваем ассоциацию на открытие графических типов файлов на терминальных серверах RDS

    На терминальных серверах под управлением Windows Server 2008 R2 по умолчанию отсутствует программа для просмотра графических файлов (именно для просмотра а не редактирования, типа Paint). Если используется Office 2010, то можно в качестве просмотрщика основных типов графических файлов использовать входящую в его состав программу “Диспетчер рисунков Microsoft Office”.

    Читать далее...

  • Remote Desktop Services/Terminal Services - Настройка прозрачной доменной авторизации (Single Sign-On)

    image02.03.2010
    Основное требование для SSO на стороне клиента:
    Клиентская ОС: Microsoft Windows XP SP3, Microsoft Windows Vista SP1, Microsoft Windows 7

    Для клиентов на базе Windows Vista никаких дополнительных настроек не требуется, т.к. данная функциональность уже присутствует в операционной системе, минимальное требование это наличие SP1. Для Windows 7 необходимый функционал работает в RTM.

    Для клиентов на базе Windows XP SP3 требуется правка системного реестра:

    HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders
    !Дописать! (не заменить а именно дополнить) значение параметра SecurityProviders строкой: credssp.dll

    HKLM\SYSTEM\CurrentControlSet\Control\Lsa
    !Дописать! (не заменить а именно дополнить) значение параметра Security Packages строкой: tspkg

    Вся информация по этому поводу изложена в статье Microsoft - Description of the Credential Security Service Provider (CredSSP) in Windows XP Service Pack 3
    Также привожу ссылку на пошаговую инструкцию по настройке доменных групповых политик для включения на клиентских компьютерах функции Single Sign-On -
    How to enable Single Sign-On for my Terminal Server connections
    Если в трёх словах - то для того чтобы у клиентских компьютеров работала прозрачная авторизация требуется в доменных групповых политиках настраивающих клиентские ПК изменить следующие параметры:

    Внимание! Перечисленные ниже параметры GPO доступны только при просмотре оснастки gpedit.msc в операционных системах Windows Vista / Windows Server 2008 и выше.

    Конфигурация компьютера > Административные шаблоны > Система > Передача учетных данных

    "Разрешить передачу учетных данных, настроенных по умолчанию" – Включить.
    "Связать настройки системы по умолчанию с введенными ранее" – Включить и в список серверов (по кнопке "Показать") добавить запись типа:

    TERMSRV/*
      (разрешена передача учётных данных любым терминальным серверам)
    или
    TERMSRV/*.mydom.com (разрешена передача учётных данных только к терминальным серверам домена mydom.com)

    "Разрешить сохраненные учетные данные с проверкой подлинности сервера "только NTLM" – Включено
    Список серверов в этом параметре настроить аналогично.

     image
    Замечание: для того чтобы это действительно работало при подключении к серверу имя сервера необходимо указывать полностью (FQDN).
    После написания полного имени сервера клиент RDP в поле имя пользователя автоматически подставит имя в формате
    user@domain.
    Сохранив таким образом на рабочем столе пользователя RDP ярлык мы предоставим ему возможность одним кликом мыши попасть на терминальный сервер без дополнительного ввода его учётных данных.

    Update 23.12.2011

    При попытке заставить работать SSO на Windows XP SP3 с фермой RD Connection Broker можно столкнуться с ситуацией когда после входа на сервер возникает запрос ввода учетных данных. Для разрешения этой проблемы нужно установить обновление, доступное в статье KB953760 - When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server. Через WSUS данное обновление не доступно и поэтому нужно его скачивать и устанавливать отдельно.

    Дополнительные источники информации:

    TechNet Blogs > if (ms) blog++; > XP Clients, CredSSP, SSO, Connection Broker and other animals

  • Remote Desktop Services - Используем перенаправление профилей пользователей и перемещаемые папки

    imageВ прошлый раз мы развернули отказоустойчивую ферму RD Connection Broker с участием трёх серверов RD Session Host. В этой заметке будет описана часть процесса настройки серверов фермы, в частности, в части настройки пользовательской среды – включение механизмов перемещаемых профилей (Roaming User Profiles) и перенаправления папок пользователей (Folder Redirection).

    Для управления параметрами настройки пользовательских профилей воспользуемся групповыми политиками. Создадим объект доменной групповой политики (GPO), который будет настраивать все сервера RD Session Host (RDSH) в нашей ферме RD Connection Broker

    Читать далее...

  • Remote Desktop Services - Строим отказоустойчивую ферму RD Connection Broker

    imageНачиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов Microsoft Windows Server 2008 R2 – серверной роли Remote Desktop Services (RDS). Для начала рассмотрим процесс создания фермы серверов RDS с использованием механизма балансировки нагрузки с помощью Remote Desktop Connection Broker (RDCB).

    Описание задачи

    Не будем заострять внимания на описании функций служб Remote Desktop Services, так как этой информации более чем достаточно в официальных источниках Microsoft. Предметом этой заметки будет пошаговое практическое описание процесса создания фермы из трёх виртуальных серверов, на каждом из которых будут совмещены компоненты RD Session Host и кластеризованная служба RD Connection Broker. То есть мы попробуем при минимуме серверных экземпляров Windows Server 2008 R2 собрать отказоустойчивое решение RDS.

    По информации доступной из блога TechNet Blogs > Mark Ghazai's Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker на каждом из серверов в кластере RD Connection Broker будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.

    Читать далее...

  • Windows Server 2008 R2 – Добавление скриптов входа на сервере RDS через ключ реестра AppSetup

    imageПри настройке сервера служб Remote Desktop Services (RDS) на Windows Server 2008 R2 c включённым UAC, столкнулся с интересной ситуацией. Стояла такая задача, чтобы при входе в систему для каждого пользователя отрабатывал *.cmd файл, в котором исполнялись бы все необходимые директивы дополнительной настройки пользовательского окружения.

    По старой памяти, запустив редактор реестра от имени Администратора, я открыл ветку реестра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon и с удивлением обнаружил отсутствие строкового параметра AppSetup (параметр служит для запуска скриптов обеспечения совместимости приложений в многопользовательской среде). Без задней мысли я создал этот параметр, вписал в него имя моего командного файла (USRLOGON_2.CMD), расположенного в папке C:\Windows\System32 и перезагрузил систему. Но к моему удивлению после перезагрузки, при входе пользователей в систему, файл не отрабатывал.

    Читать далее...