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:\Temp\LSReport.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 с новым запросом на получение клиентской лицензии. Разумеется, желательно тщательно спланировать этот процесс, чтобы не получилось так, что в один момент на сервере лицензирования попросту не останется свободных клиентских лицензий, так как каждый клиент будет занимать по две лицензии. Именно поэтому самым удобным моментом для такого “наведения порядка” может стать перевод клиентов с одного сервера лицензирования на другой.

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

Всего комментариев: 3 Комментировать

  1. Александр /

    Подскажите, пожалуйста, добавление прав обычным пользователям создавать записи в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing ничем не грозит в плане безопасности? У нас периодически случаются проблемы со входом на терминальные сервера. В данным момент мы запускаем mstsc от имени администратора и указанная выше ветка реестра успешно обновляется. Если дадим права пользователям на эту ветку, то таких проблем быть не должно.

    1. Алексей Максимов / Автор записи

      мы запускаем mstsc от имени администратора

      Не уверен в том, что такое решение обрадует техподдержку, когда нужно "окучивать" несколько сотен машин.
      Как бы там ни было, каждый решает сам для себя, делая выбор между удобством (не надо никаких административных запусков mstsc) и безопасностью доступа к указанным ключам реестра.

      1. Александр /

        Спасибо за ответ. У нас старые терминальные сервера, лицензирование которых никто перенастраивать не будет. Вышеуказанные проблемы случается пару раз в месяц, а то и реже. Теперь я примерно понимаю причину их появления. А раз причина известна, то хотелось бы избавиться от нее полностью и желательно без ущерба безопасности.

Добавить комментарий