Как проверить подлинность windows server 2008
Переход от служб терминалов Windows Server 2003 к службам удаленных рабочих столов в Windows Server 2008 R2 стал стандартной процедурой обновления. После обновления многие интересуются, почему работа с этими версиями так отличается.
При подключении к службам терминалов Windows 2003 пользователь инициирует создание сеанса и вводит свои учетные данные. А при использовании сервера узла сеансов удаленных рабочих столов пользователь обычно вводит учетные данные в диалоговом окне на стороне клиента. По умолчанию клиентам, которые не поддерживают технологию проверки подлинности на уровне сети (Network-Level Authentication, NLA), подключиться не удается. В чем же разница? Есть причины, по которым Microsoft реализовала NLA, и это хорошие причины.
Что такое NLA
NLA заставляет клиентский компьютер представить учетные данные клиента для проверки подлинности до создания сеанса с этим сервером. По этой причине такой процесс иногда называют фронтальной проверкой подлинности. Серверы под управлением Windows Server 2008, Vista или более поздней ОС, а также клиенты с Windows XP SP3 или более поздней ОС поддерживают NLA. Так как NLA основана на технологии, которая называется протоколом CredSSP (Credential Security Support Provider), при использовании клиента удаленного рабочего стола для другой ОС нужно сначала поинтересоваться у разработчика, поддерживает ли этот клиент NLA.
Так чем же так хорошо предоставление учетных данных до создания сеанса? Есть два положительных момента в создании сеанса только после того, как вы убедитесь, что пользователь является именно тем, за кого себя выдает: это позволяет создать дополнительный уровень защиты от DoS-атак, а также ускоряет процесс посредничества.
При создании сеанса, даже просто для того, чтобы отобразить окно входа, требует от сервера создания многих процессов, необходимых для поддержки такого сеанса, таких как Csrss.exe и Winlogon.exe. По этой причине создание сеанса является дорогой и занимающей значительное время операцией. Если несколько посторонних пользователей попытаются подключиться к сеансу одновременно, они могут заблокировать другим, возможно легальным пользователям, возможность создания сеансов.
Вопрос производительности намного важнее. На базе Windows Server 2003 редко создаются фермы. Начиная с Windows Server 2008, фермы создают чаще. Не забывайте, что каждый сервер в ферме узла сеансов удаленных рабочих столов может одновременно быть перенаправителем. Если серверу узла нужно создавать полноценный сеанс перед перенаправлением подключения посреднику подключений удаленных рабочих столов, это увеличивает время подключения.
В NLA используется CredSSP для представления учетных данных серверу для проверки подлинности перед созданием сеанса. Этот процесс позволяет избежать обоих этих проблем. У использования CredSSP есть и другие преимущества. CredSSP позволяет снизить количество операций вход, выполняемых пользователем, за счет хранения учетных данных подключения.
При первом подключении к новому серверу, виртуальной машине или даже другому компьютеру пользователи должны предоставить свои учетные данные. Вместе с тем, у них есть возможность сохранить их. В этом случае при подключении не придется снова предоставлять учетные данные, пока не поменяется пароль.
Как CredSSP поддерживает NLA
Протокол CredSSP позволяет приложениям безопасно делегировать учетные данные пользователя от клиента к целевому серверу. Этот протокол сначала создает зашифрованный канал между клиентом и сервером с применением протокола TLS (Transport Layer Security) (в соответствии со спецификацией RFC2246).
Вы наверняка заметили, что при подключении клиента RDC 6.x или более поздней версии к серверу узла сеансов удаленных рабочих столов при предоставлении учетных данных вы не подключаетесь непосредственно к окну входа узла сеансов удаленных рабочих столов. Вместо этого диалоговое окно для ввода учетных данных открывается на клиенте. Это диалоговое окно является «лицом» CredSSP.
При вводе учетных данных в это окно, даже если вы решите их не сохранять, они поступают в CredSSP. Затем учетные данные передаются на сервер узла сеансов удаленных рабочих столов по безопасному каналу. Этот сервер начнет создание пользовательского сеанса, только получив эти учетные данные.
Клиенты, поддерживающие CredSSP и RDP 6.x и более поздних версий, всегда используют NLA, если этот протокол доступен. Так как CredSSP (технология, поддерживающая NLA) является частью ОС, а не протокола RDP, для нормальной работы NLA клиентская операционная система должна поддерживать CredSSP.
Поэтому хотя в Windows XP SP2 и есть клиент RDC 6.0, использование NLA в этой ОС невозможно. Клиенты под управлением Windows XP SP3, Windows Vista и Windows 7 поддерживают CredSSP. Кроме того, в окне About (О программе) окна подключения к удаленному рабочему столу указано, поддерживается ли NLA. Чтобы открыть это окно, в окне подключения к удаленному рабочему столу щелкните в левом верхнем углу значок компьютера и выберите About (О программе). В открывшемся окне будет указано, поддерживается ли проверка подлинности на уровне сети.
Windows XP SP3 поддерживает CredSSP, но по умолчанию этот протокол отключен. В статье «Описание учетных данных поставщика поддержки безопасности (CredSSP) в Windows XP с пакетом обновления 3» базы знаний Microsoft есть ссылка для включения этого протокола, а также описано, как включить его вручную. После включения CredSSP нужно перезагрузить компьютер.
Как обеспечить принудительное использование NLA
По умолчанию серверы узла сеансов удаленных рабочих столов не требуют NLA. Но их можно настроить на поддержку подключений только с компьютеров, поддерживающих NLA — средствами групповой политики или, для конкретных компьютеров, в конфигурации узла сеансов удаленных рабочих столов.
Чтобы требовать NLA при подключении к серверу узла сеансов удаленных рабочих столов, откройте окно конфигурации узла сеансов удаленных рабочих столов. Дважды щелкните RDP-Tcp (в разделе Connections) и на вкладке General отметьте флажком Allow Connections Only From Computers Running Remote Desktop with Network Level Authentication (Разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности). Это не позволит подключиться к серверу клиентам, не поддерживающим NLA (а именно клиентам с RDC версии более ранней, чем 6.x, и под управлением ОС, не поддерживающей CredSSP).
Чтобы включить NLA средствами групповой политики, включите следующую политику и примените ее к подразделению, в котором находится сервер узла сеансов удаленных рабочих столов: Computer Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/Remote Desktop Session Host/Security/Require User Authentication For Remote Connections By Using Network Level Authentication (Конфигурация компьютера/Политики/Административные шаблоны/Компоненты Windows/Службы удаленных рабочих столов/Узел сеансов удаленных рабочих столов/Безопасность/Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети).
Если отключить или не сконфигурировать эту политику, поддержка NLA требоваться не будет.
VDI-запросы
В средах виртуализации настольных компьютеров (VDI) можно заставить Windows Vista и Windows 7 принимать подключения только от клиентов, поддерживающих NLA. Выберите апплет Control Panel/System/Remote Settings (Панель управления/Система/Настройка удаленного доступа). На вкладке Remote (Удаленный доступ) окна свойств системы установите флажок Allow Connections Only From Computers Running Remote Desktop With Network Level Authentication (More Secure) [Разрешать подключения только от компьютеров с удаленным рабочим столом с сетевой проверкой подлинности (безопаснее)].
В этой статье рассказано, почему так важно включать NLA на серверах узла сеансов удаленных рабочих столов и в средах виртуализации настольных компьютеров. Вы должны понимать, как требовать использования NLA на серверах и на виртуальных машинах среды VDI, а также как настраивать клиентские компьютеры для поддержки NLA.
Хотя мы не упоминали о сертификатах, но они являются обязательным компонентом любой среды, где используются удаленные рабочие столы. И это касается не только NLA, но и серверной проверки подлинности, использования шлюза удаленных рабочих столов, веб-доступа к удаленным рабочим столам и даже посредника подключений к удаленному рабочему столу. В следующей статье мы поговорим подробнее о требованиях к сертификатам в средах доступа к удаленным рабочим столам.
Часто задаваемые вопросы по NLA
Вопрос У меня компьютер под управлением Windows XP SP3. Я включил CredSSP, но при попытке подключения к серверу узла сеансов удаленных рабочих столов, требующему NLA, получаю ошибку: «An authentication error has occurred» (Произошла ошибка проверки подлинности).
Ответ В моем блоге есть исправление, позволяющее устранить эту проблему.
Эта ошибка наблюдается при наличии следующих условий:
- Клиент работает под управлением Windows XP SP3, и на нем включен CredSSP.
- Вы сконфигурировали сервер на использование реального SSL-сертификата при идентификации (а не автоматически сгенерированного сертификата, который имеется по умолчанию).
- Клиент не доверяет центру сертификации, который подписал этот SSL-сертификат.
NLA требуется безопасный канал, по которому он получает учетные данные, но он не может создать туннель, если не доверяет сертификату. Поэтому NLA не работает. Для исправления ситуации надо позаботиться, чтобы на клиентской машине с Windows XP сертификат, использованный для подписания SSL-сертификата сервера узла сеансов удаленных рабочих столов, был помещен в хранилище сертификатов Trusted Root Certification Authorities (Доверенные корневые центры сертификации).
Вопрос правильного лицензирования серверных продуктов Microsoft один из наиболее актуальных для системного администратора. Необходимо правильно определить тип и количество необходимых лицензий, что не так то просто сделать. Схема лицензирования довольно сложна и запутана, а многочисленные советы, руководства и памятки на сайтах и форумах зачастую вносят еще большую неясность.
Основы лицензирования
Среди всего многообразия семейства Windows Server 2008 наибольший интерес для малого и среднего бизнеса представляют две его редакции: Standart и Enterprise, поэтому мы будем рассматривать схему лицензирования применительно к этим версиям. Взяв за основу информацию только с официального сайта Microsoft мы постараемся сделать краткий конспект, позволяющий быстро определиться с необходимой схемой лицензирования и количеством лицензий.
Основная схема лицензирования для данных редакций это Сервер + Лицензия клиентского доступа (CAL). Это означает, что для каждого сервера в организации должна быть приобретена лицензия на серверную ОС + необходимое количество лицензий клиентского доступа. Серверную лицензию можно присвоить другому серверу не ранее, чем через 90 дней после последнего присвоения, или раньше, если исходный сервер окончательно вышел из строя.
Лицензия Windows Server 2008 дает право использовать 32-битную либо 64-битную версию ПО, однако следует помнить, что некоторые средства (например технологию виртуализации Hyper-V) можно запустить только на 64-битной версии Windows Server.
Типы лицензий и модели лицензирования
Существуют два типа клиентской лицензии (CAL):
- на устройство (per Devices) - позволяет любому числу пользователей получать доступ к серверу с одного устройства. Данный тип лицензий удобно применять когда количество пользователей в сети больше количества устройств. Например когда шесть пользователей посменно работают с трех ПК.
- на пользователя (per Users) - позволяет одному пользователю получать доступ к серверу с неограниченного числа устройств. Данный тип лицензий удобен для организаций имеющий много мобильных пользователей или пользователей которым необходим доступ к серверу с нескольких устройств сети.
Лицензии на пользователя и устройство имеют одинаковую стоимость и при их выборе следует исходить из реальной инфраструктуры предприятия. Допустимо использовать оба типа лицензий одновременно.
Для Windows Server существует две модели лицензирования:
- на пользователя или устройство, эта модель предусматривает наличие лицензии CAL на каждого пользователя или устройство в сети не зависимо от количества серверов и дает возможность подключаться к любому из них. Данная модель обычно применяется в сети с несколькими серверами и применяется для любых серверных продуктов Microsoft (например SQL Server). Общее количество лицензий при такой схеме лицензирования должно быть равно общему числу ПК или пользователей в сети.
- на сервер, эта модель подразумевает ограничение количества подключений к серверу по количеству купленных лицензий. Лицензии приобретаются для конкретного сервера и их количество должно соответствовать максимальному количеству подключений к серверу в каждый конкретный момент времени. При достижении максимального числа подключений к серверу остальные устройства и пользователи сети, пытающиеся получить доступ к серверу не будут иметь такой возможности. Данная модель обычно применяется в сети с одним сервером или с редким использованием базовых функций сервера, а также для серверов удаленного доступа. Такая схема лицензирования применяется только для Windows Server.
Лицензирование сервера терминалов
Службы терминалов Windows Server 2008 требуют отдельного лицензирования. Для использования возможностей служб терминалов (TS) помимо клиентской лицензии (CAL) необходима клиентская лицензия на службы терминалов (TS CAL).
TS CAL, также как и CAL предусматривает два вида лицензий: на устройство и на пользователя, предусматривающие аналогичные правила использования. Модель лицензирования предусмотрена только одна: на пользователя или устройство.
Hyper-V
Средство виртуализации Hyper-V является одной из ключевых возможностей базовой ОС Windows Server 2008, однако не все пользователи испытывают потребность в виртуализации, поэтому предусмотрены версии Windows Server 2008 без Hyper-X, что явно отражено в их наименовании. Хотя стоимость этих версий несколько ниже, они имеют одинаковые с базовыми условия лицензирования, в т.ч. и по использованию виртуализации. В этом случае потребуется отдельно приобрести лицензию на средство виртуализации, будь то Hyper-V, Microsoft Virtual Server R2 или технология другого производителя (например VMware).
Для лицензирования виртуальных машин предусмотрена следующая схема: 1+1 для Standart и 1+4 для Enterprise. Цифры обозначают количество виртуальных экземпляров ОС которые могут быть запущены на одном физическом экземпляре. Общее количество экземпляров ОС доступных для клиентов в каждый текущий момент времени не должно превышать 1 для Standart и 4 для Enterprise, т.е. при запущенной виртуальной системе физический экземпляр ОС Windows Server 2008 Standart можно использовать только для обслуживания виртуальной системы. Windows Server 2008 Enterprise позволяет использовать физическую систему вместе с тремя виртуальными. При запуске четвертой виртуальной системы физическую ОС также можно использовать только для обслуживания виртуальных машин.
Данные правила распространяются не только на Hyper-V, но и на любую иную технологию виртуализации (MS Virtual Server, VMware и т.п.)
Сколько нужно лицензий?
Теперь, ознакомившись с основами лицензирования можно попытаться грамотно ответить на этот вопрос. При этом надо учитывать, что клиентская лицензия CAL не требуется в следующих случаях:
- Доступ к серверу осуществляется только через Интернет, причем не выполняется проверка подлинности или какая-то другая процедура идентификации ни с помощью серверного ПО, ни как-то иначе. Пример: доступ к веб-серверу на базе IIS.
- Для каждой лицензии на сервер доступ могут иметь устройства или пользователи (не более двух) исключительно с целью администрирования этого сервера.
Клиентские лицензии CAL требуются также для пользователей или устройств имеющих опосредованный доступ к серверным функциям, например использующих DHCP-сервер.
Рассмотрим несколько примеров.
Пример 1.
Наиболее простой и распространенный случай. Сервер используется как файловый сервер и роутер, для организации общего доступа в интернет, также используется DHCP сервер для конфигурирования внутренней сети. На сервере используется гостевой доступ, идентификация пользователей не производится. Многие ошибочно считают, что в данном случае достаточно одной серверной лицензии, а лицензии клиентского доступа не требуются (особенно когда сервер используется только как роутер и DHCP). Однако это не так, необходимо иметь лицензии CAL общим количеством равные количеству устройств или пользователей в сети (в нашем случае 5).
Пример 2.
Организация имеет сеть на 9 ПК из них пять машин должны иметь доступ к файловому серверу для 1С Предприятие. В данном случае можно применить схему лицензирования "на сервер" и приобрести 5 CAL лицензий.
Пример 3.
Организация имеет файловый сервер и сервер терминалов, имеет парк из 9 ПК, 4 из которых должны иметь доступ к файловому серверу, а на 5 ПК работают в терминальном режиме посменно 10 пользователей, также имеется два мобильных пользователя, которые должны иметь доступ через VPN к серверу терминалов. Также имеется рабочее место администратора. В данном случае наиболее оптимальной будет следующая схема: для всех стационарных ПК приобретается 9 САL лицензий на устройство, для 5 ПК использующих службы терминалов дополнительно приобретается 5 TS CAL на устройство. Для мобильных пользователей более правильным будет использовать лицензии CAL + TS CAL на пользователя. Администратору клиентская лицензия не требуется, так как он получает доступ к серверам исключительно с целью администрирования.
Дополнительные сведения по лицензированию Windows Server 2008 можно найти на сайте Microsoft.
После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:
Произошла ошибка проверки подлинности.
Указанная функция не поддерживается.
Удаленный компьютер: computername
После того, как я удалил обновление KB4103718 и перезагрузил компьютер, RDP подключение стало работать нормально. Если я правильно понимаю, это только временное обходное решение, в следующем месяце приедет новый кумулятивный пакет обновлений и ошибка вернется? Можете что-нибудь посоветовать?
Ответ
Вы абсолютно правы в том, что бессмысленно решать проблему удалением обновлений Windows, ведь вы тем самым подвергаете свой компьютер риску эксплуатации различных уязвимостей, которые закрывают патчи в данном обновлении.
В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:
The function requested is not supported.
Remote computer: computername
Ошибка RDP “An authentication error has occurred” может появляться и при попытке запуска RemoteApp приложений.
Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?
- Самый правильный способ решения проблемы – установка последних кумулятивных обновлений безопасности Windows на компьютере / сервере, к которому вы подключаетесь по RDP;
- Временный способ 1 . Можно отключить проверку подлинности на уровне сети (NLA) на стороне RDP сервера (описано ниже);
- Временный способ 2 . Вы можете на стороне клиента разрешить подключение к RDP серверам с небезопасной версией CredSSP, как описано в статье по ссылке выше. Для этого нужно изменить ключ реестра AllowEncryptionOracle (команда REG ADD
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters /v AllowEncryptionOracle /t REG_DWORD /d 2 ) или изменить настройки локальной политики Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула), установив ее значение = Vulnerable / Оставить уязвимость).
Отключение NLA для протокола RDP в Windows
Если на стороне RDP сервера, которому вы подключаетесь, включен NLA, это означает что для преаутентификации RDP пользователя используется CredSPP. Отключить Network Level Authentication можно в свойствах системы на вкладке Удаленный доступ (Remote), сняв галку «Разрешить подключения только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети / Allow connection only from computers running Remote Desktop with Network Level Authentication (recommended)» (Windows 10 / Windows 8).
В Windows 7 эта опция называется по-другому. На вкладке Удаленный доступ нужно выбрать опцию «Разрешить подключения от компьютеров с любой версией удаленного рабочего стола (опасный) / Allow connections from computers running any version of Remote Desktop (less secure)».
Также можно отключить проверку подлинности на уровне сети (NLA) с помощью редактора локальной групповой политики — gpedit.msc (в Windows 10 Home редактор политик gpedit.msc можно запустить так) или с помощью консоли управления доменными политиками – GPMC.msc. Для этого перейдите в разделе Конфигурация компьютера –> Административные шаблоны –> Компоненты Windows –> Службы удаленных рабочих столов – Узел сеансов удаленных рабочих столов –> Безопасность (Computer Configuration –> Administrative Templates –> Windows Components –> Remote Desktop Services – Remote Desktop Session Host –> Security), отключите политику Требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети (Require user authentication for remote connections by using Network Level Authentication).
Также нужно в политике «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» (Require use of specific security layer for remote (RDP) connections) выбрать уровень безопасности (Security Layer) — RDP.
Для применения новых настроек RDP нужно обновить политики (gpupdate /force) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.
↑ Как узнать, лицензионная ли Windows установлена на компьютере
Друзья, настоятельно рекомендую вам прежде ознакомиться со статьей о сути и специфике лицензирования компанией Microsoft системы Windows. Это сложная и извилистая тема, Microsoft развела много дебрей в ней, но мы всё же попытались изложить её как можно проще и понятней. Так, обман может крыться не только в факте подлинности ключей ОС, но и в типе лицензий (в частности, пробных бесплатных), к которым эти ключи дают доступ. Так что необходимо иметь хотя бы базовое представление о видах лицензий Windows.↑ Неактивированная, пиратская и лицензионная Windows
ОС от Microsoft в контексте её активации можно условно поделить на три типа:- Неактивированная;
- Активированная пиратская;
- Активированная лицензионная.
Если сторонняя сборка Windows изначально поставляется активированной, в ней может быть проведено вмешательство в функционал – что-то вырезано, что-то отключено, что-то (в том числе вредоносное) доустановлено. О всех «за» и «против» пиратских сборок читаем здесь. Недостатки пиратской активации:
• Файлы и процессы активатора блокируются антивирусами;- Примечание: почитать на досуге судебную практику по делам о нарушении авторских прав разработчиков особенно рекомендую всем тем «умникам», которые в комментариях сайта оскорбляют тех, кто выбрал путь использования платного лицензионного ПО.
↑ Наклейки подлинности Windows
Узнать, лицензионная ли Windows установлена, можно по наклейкам подлинности на компьютерном устройстве. Что это за наклейки? Это: • Сертификат подлинности (COA) – наклейка на корпусе ПК, на днище ноутбука или внутри его аккумуляторного отсека, а также внутри последнего на планшетах Surface; • Наклейка GML – наклейка-голограмма с меняющимися цветами в зависимости от угла обзора, внедрена с сентября 2017 года, места наклеивания те же, что и у COA. Если лицензионный ключ приобретался отдельно от устройства, путём покупки коробочной версии Windows – установочных DVD-диска или флешки, наклейки подлинности должны быть, соответственно, на их упаковках. Для коробочных версий используются те же типы наклеек,что и для корпусов устройств - сертификат подлинности (COA) и голограммы.
Детальнее о наклейках коробочных версий Windows можно почитать здесь:↑ Как узнать, лицензионная ли Windows, с помощью командной строки
Если продавец б/у компьютера клятвенно утверждает, что продаёт его с лицензионной Windows, если новое устройство покупается в магазине с доселе неизвестной нам репутацией, факт подлинности ОС можно проверить, попросив кое-что ввести в командную строку. Запускаем её от имени администратора. И вводим: Но ежели система подлинная, увидим в скрипте надпись «Активация выполнена успешно». Кроме непосредственной надписи об активации в окошке скрипта важно ещё обратить внимание на редакцию Windows. Если в названии редакции есть дописка «Eval», например, «EnterpriseSEval», проку от такой подлинности активации, увы, немного.↑ Как узнать, лицензионная ли Windows, с помощью планировщика задач или принцип работы пиратских активаторов
Необходимо заметить, что последние операционные системы от Майкрософт (Windows 8.1, 10) имеют довольно сильный механизм защиты от активации пиратскими средствами и на данный момент существуют всего лишь несколько активаторов, способных активировать вышеупомянутые OS, самый известный - KMSAuto Net. Но работает он очень просто и без труда обнаруживается в системе. KMSAuto Net создаёт папку по адресу: C:\ProgramData\KMSAutoS и размещает в ней свои файлы.Для постоянной переактивации ОС он также вынужден создать свою задачу в планировщике.
Один раз, приятель принёс мне ноутбук с установленной и активированной Windows 10
и спросил, лицензионная ли на нём установлена система. Я тупо открыл командную строку и ввёл уже знакомую вам команду: slmgr –ato , результат был весьма красноречивым.
Затем я открыл планировщик и показал приятелю задачу, созданную KMSAuto Net. Вопросы отпали сами собой.
↑ Как проверить Windows 7 на подлинность
Если перед вами встанет задача определить подлинность Windows 7, то в первую очередь смотрите наклейку с лицензионным ключом на корпусе ПК или на днище ноутбука, если таковой нет, то задача усложняется во много раз, так как данная OS имеет слабый механизм защиты от активации пиратскими инструментами. Если вы зададите этот вопрос на официальном сайте Майкрософт, то вам посоветуют установить обновление KB971033 , созданное специально для проверки подлинности ОС, но к примеру, на этом ПК данное обновление установлено,
а система активирована пиратским активатором и я вам это чуть позже докажу.
Также на оф. сайте Майкрософт вам посоветуют скачать инструмент MGADiag.exe,
предоставляющий подробную информацию о подлинности Windows, но часто он тоже не сможет отличить пиратскую OS от лицензионной, как в нашем случае. Утилита выдаёт результат "V alidation status - Genuine" или "Статус проверки - Подлинная".
В окне "Licensing" вы можете увидеть частичный ключ продукта - 7TP9F и "Состояние лицензии: имеет лицензию".
Но ключ YKHFT-KW986-GK4PY-FDWYH-7TP9F может быть на Win 7, установленной на ноутбуках Acer, но никак не на Win 7, установленной на обычный стационарный компьютер,
он постоянно попадается мне на пиратских семёрках. Данный ключ устанавливает программа пиратской активации Windows 7 Loader by DaZ Activator или Windows7 ULoader 8.0.0.0.
Настоящий лицензионный ключ вообще не будет "гуглиться", так как информации о нём не должно быть в интернете.
Читайте также: