Protect Remote Desktop credentials with Windows Defender Remote Credential Guard

Applies to

• Windows 10
• Windows Server 2016

Introduced in Windows 10, version 1607, Windows Defender Remote Credential Guard helps you protect your credentials over a Remote Desktop connection by redirecting Kerberos requests back to the device that’s requesting the connection. It also provides single sign-on experiences for Remote Desktop sessions.

Administrator credentials are highly privileged and must be protected. By using Windows Defender Remote Credential Guard to connect during Remote Desktop sessions, if the target device is compromised, your credentials are not exposed because both credential and credential derivatives are never passed over the network to the target device.

For information on Remote Desktop connection scenarios involving helpdesk support, see Remote Desktop connections and helpdesk support scenarios in this article.

Comparing Windows Defender Remote Credential Guard with other Remote Desktop connection options

The following diagram helps you to understand how a standard Remote Desktop session to a server without Windows Defender Remote Credential Guard works:

The following diagram helps you to understand how Windows Defender Remote Credential Guard works, what it helps to protect against, and compares it with the Restricted Admin mode option:

As illustrated, Windows Defender Remote Credential Guard blocks NTLM (allowing only Kerberos), prevents Pass-the-Hash (PtH) attacks, and also prevents use of credentials after disconnection.

Use the following table to compare different Remote Desktop connection security options:

Feature	Remote Desktop	Windows Defender Remote Credential Guard	Restricted Admin mode
Protection benefits	Credentials on the server are not protected from Pass-the-Hash attacks.	User credentials remain on the client. An attacker can act on behalf of the user only when the session is ongoing	User logs on to the server as local administrator, so an attacker cannot act on behalf of the “domain user”. Any attack is local to the server
Version support	The remote computer can run any Windows operating system	Both the client and the remote computer must be running at least Windows 10, version 1607, or Windows Server 2016.	The remote computer must be running at least patched Windows 7 or patched Windows Server 2008 R2. For more information about patches (software updates) related to Restricted Admin mode, see Microsoft Security Advisory 2871997.
Helps prevent В В В В В В В В В В В В В В В В	В В В В N/A В В В В В В В В	Pass-the-Hash Use of a credential after disconnection	Pass-the-Hash Use of domain identity during connection
Credentials supported from the remote desktop client device	Signed on credentials Supplied credentials Saved credentials	Signed on credentials only	Signed on credentials Supplied credentials Saved credentials
Access	Users allowed, that is, members of Remote Desktop Users group of remote host.	Users allowed, that is, members of Remote Desktop Users of remote host.	Administrators only, that is, only members of Administrators group of remote host.
Network identity	Remote Desktop session connects to other resources as signed-in user.	Remote Desktop session connects to other resources as signed-in user.	Remote Desktop session connects to other resources as remote host’s identity.
Multi-hop	From the remote desktop, you can connect through Remote Desktop to another computer	From the remote desktop, you can connect through Remote Desktop to another computer.	Not allowed for user as the session is running as a local host account
Supported authentication	Any negotiable protocol.	Kerberos only.	Any negotiable protocol

For further technical information, see Remote Desktop Protocol and How Kerberos works.

Remote Desktop connections and helpdesk support scenarios

For helpdesk support scenarios in which personnel require administrative access to provide remote assistance to computer users via Remote Desktop sessions, Microsoft recommends that Windows Defender Remote Credential Guard should not be used in that context. This is because if an RDP session is initiated to a compromised client that an attacker already controls, the attacker could use that open channel to create sessions on the user’s behalf (without compromising credentials) to access any of the user’s resources for a limited time (a few hours) after the session disconnects.

Therefore, we recommend instead that you use the Restricted Admin mode option. For helpdesk support scenarios, RDP connections should only be initiated using the /RestrictedAdmin switch. This helps ensure that credentials and other user resources are not exposed to compromised remote hosts. For more information, see Mitigating Pass-the-Hash and Other Credential Theft v2.

To further harden security, we also recommend that you implement Local Administrator Password Solution (LAPS), a Group Policy client-side extension (CSE) introduced in Windows 8.1 that automates local administrator password management. LAPS mitigates the risk of lateral escalation and other cyberattacks facilitated when customers use the same administrative local account and password combination on all their computers. You can download and install LAPS here.

Remote Credential Guard requirements

To use Windows Defender Remote Credential Guard, the Remote Desktop client and remote host must meet the following requirements:

The Remote Desktop client device:

Must be running at least Windows 10, version 1703 to be able to supply credentials, which is sent to the remote device. This allows users to run as different users without having to send credentials to the remote machine.

Must be running at least Windows 10, version 1607 or Windows Server 2016 to use the user’s signed-in credentials. This requires the user’s account be able to sign in to both the client device and the remote host.

Must be running the Remote Desktop Classic Windows application. The Remote Desktop Universal Windows Platform application doesn’t support Windows Defender Remote Credential Guard.

Must use Kerberos authentication to connect to the remote host. If the client cannot connect to a domain controller, then RDP attempts to fall back to NTLM. Windows Defender Remote Credential Guard does not allow NTLM fallback because this would expose credentials to risk.

The Remote Desktop remote host:

• Must be running at least Windows 10, version 1607 or Windows Server 2016.
• Must allow Restricted Admin connections.
• Must allow the client’s domain user to access Remote Desktop connections.
• Must allow delegation of non-exportable credentials.

There are no hardware requirements for Windows Defender Remote Credential Guard.

Remote Desktop client devices running earlier versions, at minimum Windows 10 version 1607, only support signed-in credentials, so the client device must also be joined to an Active Directory domain. Both Remote Desktop client and server must either be joined to the same domain, or the Remote Desktop server can be joined to a domain that has a trust relationship to the client device’s domain.

GPO Remote host allows delegation of non-exportable credentials should be enabled for delegation of non-exportable credentials.

For Windows Defender Remote Credential Guard to be supported, the user must authenticate to the remote host using Kerberos authentication.

The remote host must be running at least Windows 10 version 1607, or Windows Server 2016.

The Remote Desktop classic Windows app is required. The Remote Desktop Universal Windows Platform app doesn’t support Windows Defender Remote Credential Guard.

Enable Windows Defender Remote Credential Guard

You must enable Restricted Admin or Windows Defender Remote Credential Guard on the remote host by using the Registry.

Open Registry Editor on the remote host.

Enable Restricted Admin and Windows Defender Remote Credential Guard:

Go to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa.

Add a new DWORD value named DisableRestrictedAdmin.

To turn on Restricted Admin and Windows Defender Remote Credential Guard, set the value of this registry setting to 0 to turn on Windows Defender Remote Credential Guard.

Close Registry Editor.

You can add this by running the following command from an elevated command prompt:

Using Windows Defender Remote Credential Guard

Beginning with Windows 10 version 1703, you can enable Windows Defender Remote Credential Guard on the client device either by using Group Policy or by using a parameter with the Remote Desktop Connection.

Turn on Windows Defender Remote Credential Guard by using Group Policy

From the Group Policy Management Console, go to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation.

Double-click Restrict delegation of credentials to remote servers.

Under Use the following restricted mode:

If you want to require either Restricted Admin mode or Windows Defender Remote Credential Guard, choose Restrict Credential Delegation. In this configuration, Windows Defender Remote Credential Guard is preferred, but it will use Restricted Admin mode (if supported) when Windows Defender Remote Credential Guard cannot be used.

Neither Windows Defender Remote Credential Guard nor Restricted Admin mode will send credentials in clear text to the Remote Desktop server.

If you want to require Windows Defender Remote Credential Guard, choose Require Remote Credential Guard. With this setting, a Remote Desktop connection will succeed only if the remote computer meets the requirements listed earlier in this topic.

If you want to require Restricted Admin mode, choose Require Restricted Admin. For information about Restricted Admin mode, see the table in Comparing Windows Defender Remote Credential Guard with other Remote Desktop connection options, earlier in this topic.

Click OK.

Close the Group Policy Management Console.

From a command prompt, run gpupdate.exe /force to ensure that the Group Policy object is applied.

Use Windows Defender Remote Credential Guard with a parameter to Remote Desktop Connection

If you don’t use Group Policy in your organization, or if not all your remote hosts support Remote Credential Guard, you can add the remoteGuard parameter when you start Remote Desktop Connection to turn on Windows Defender Remote Credential Guard for that connection.

The user must be authorized to connect to the remote server using Remote Desktop Protocol, for example by being a member of the Remote Desktop Users local group on the remote computer.

Considerations when using Windows Defender Remote Credential Guard

Windows Defender Remote Credential Guard does not support compound authentication. For example, if you’re trying to access a file server from a remote host that requires a device claim, access will be denied.

Windows Defender Remote Credential Guard can be used only when connecting to a device that is joined to a Windows Server Active Directory domain, including AD domain-joined servers that run as Azure virtual machines (VMs). Windows Defender Remote Credential Guard cannot be used when connecting to remote devices joined to Azure Active Directory.

Remote Desktop Credential Guard only works with the RDP protocol.

No credentials are sent to the target device, but the target device still acquires Kerberos Service Tickets on its own.

The server and client must authenticate using Kerberos.

Рекомендации по использованию Credential Guard в Защитнике Windows Considerations when using Windows Defender Credential Guard

Область применения Applies to

• Windows 10 Windows 10
• Windows Server 2016 Windows Server 2016

Пароли по-прежнему небезопасны, Passwords are still weak. поэтому мы рекомендуем организациям не только развертывать Credential Guard в Защитнике Windows, но и переходить от использования паролей к другим методам проверки подлинности, например физическим смарт-картам, виртуальным смарт-картам или Windows Hello для бизнеса. We recommend that in addition to deploying Windows Defender Credential Guard, organizations move away from passwords to other authentication methods, such as physical smart cards, virtual smart cards, or Windows Hello for Business.

Credential Guard в Защитнике Windows использует аппаратные функции безопасности, поэтому некоторые функции, например Windows To Go, не поддерживаются. Windows Defender Credential Guard uses hardware security, so some features such as Windows To Go, are not supported.

Рекомендации, связанные с Wi-Fi и VPN Wi-fi and VPN Considerations

Когда вы включаете Защитник Windows, вы больше не можете использовать классическую проверку подлинности NTLM для единого входа. When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for Single Sign-On. Вы будете вынуждены вводить учетные данные для использования этих протоколов и не сможете сохранить учетные данные для использования в будущем. You will be forced to enter your credentials to use these protocols and cannot save the credentials for future use. Если вы используете конечные точки Wi-Fi и VPN на основе MS-CHAPv2, то они подвержены атакам, схожим с атаками на NTLMv1. If you are using WiFi and VPN endpoints that are based on MS-CHAPv2, they are subject to similar attacks as for NTLMv1. Для подключений через Wi-Fi и VPN Майкрософт рекомендует организациям перейти с подключений на основе MSCHAPv2, таких как PEAP-MSCHAPv2 и EAP-MSCHAPv2, на проверку подлинности на основе сертификатов, такую как PEAP-TLS или EAP-TLS. For WiFi and VPN connections, Microsoft recommends that organizations move from MSCHAPv2-based connections such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication such as PEAP-TLS or EAP-TLS.

Рекомендации по использованию Kerberos Kerberos Considerations

После того как вы включите Credential Guard в Защитнике Windows, вы больше не сможете использовать неограниченное делегирование Kerberos или шифрование DES. When you enable Windows Defender Credential Guard, you can no longer use Kerberos unconstrained delegation or DES encryption. Благодаря неограниченному делегированию злоумышленники могут извлечь ключи Kerberos из изолированного процесса LSA. Unconstrained delegation could allow attackers to extract Kerberos keys from the isolated LSA process. Вместо этого следует использовать ограниченное делегирование Kerberos или делегирование Kerberos на основе ресурсов. Use constrained or resource-based Kerberos delegation instead.

Рекомендации по сторонним поставщикам поддержки безопасности 3rd Party Security Support Providers Considerations

Некоторые сторонние поставщики поддержки безопасности (SSP и AP) могут быть не совместимы с Credential Guard в Защитнике Windows, так как это средство не разрешает сторонним SSP запрашивать хэши паролей из LSA. Some 3rd party Security Support Providers (SSPs and APs) might not be compatible with Windows Defender Credential Guard because it does not allow third-party SSPs to ask for password hashes from LSA. При этом SSP и AP все равно получают уведомление о пароле, когда пользователь входит в систему или меняет пароль. However, SSPs and APs still get notified of the password when a user logs on and/or changes their password. Никакое использование недокументированных API с другими поставщиками общих служб и AP не поддерживается. Any use of undocumented APIs within custom SSPs and APs are not supported. Рекомендуется проверять взаимодействие пользовательских реализаций SPP и AP с Credential Guard в Защитнике Windows. We recommend that custom implementations of SSPs/APs are tested with Windows Defender Credential Guard. SSP и AP, зависящие от недокументированного или неподдерживаемого поведения, использовать не удастся. SSPs and APs that depend on any undocumented or unsupported behaviors fail. Например, не поддерживается использование API KerbQuerySupplementalCredentialsMessage. For example, using the KerbQuerySupplementalCredentialsMessage API is not supported. Замена SSP NTLM или Kerberos другими SSP и AP. Replacing the NTLM or Kerberos SSPs with custom SSPs and APs. Более подробную информацию см. в статье Ограничения на регистрацию и установку пакетов безопасности на веб-сайте MSDN. For more info, see Restrictions around Registering and Installing a Security Package on MSDN.

Вопросы обновления Upgrade Considerations

По мере увеличения масштабов защиты, осуществляемой Credential Guard в Защитнике Windows, последующие выпуски Windows10 с работающим Credential Guard в Защитнике Windows могут повлиять на сценарии, которые работали в прошлом. As the depth and breadth of protections provided by Windows Defender Credential Guard are increased, subsequent releases of Windows 10 with Windows Defender Credential Guard running may impact scenarios that were working in the past. Например, Credential Guard в Защитнике Windows может заблокировать использование определенного типа учетных данных или определенного компонента, чтобы не позволить вредоносному ПО воспользоваться уязвимостями. For example, Windows Defender Credential Guard may block the use of a particular type of credential or a particular component to prevent malware from taking advantage of vulnerabilities. Следует проверять сценарии, необходимые для работы организации, перед обновлением устройств, на которых используется Credential Guard в Защитнике Windows. Test scenarios required for operations in an organization before upgrading a device using Windows Defender Credential Guard.

Защита сохраненных учетных данных Windows Saved Windows Credentials Protected

Начиная с Windows 10 версии 1511, учетные данные домена, которые хранятся в диспетчере учетных данных, защищены с помощью Credential Guard в Защитнике Windows. Starting with Windows 10, version 1511, domain credentials that are stored with Credential Manager are protected with Windows Defender Credential Guard. Диспетчер учетных данных может хранить три типа учетных данных: учетные данные Windows, учетные данные на основе сертификатов и универсальные учетные данные. Credential Manager allows you to store three types of credentials: Windows credentials, certificate-based credentials, and generic credentials. Универсальные учетные данные, такие как имена пользователей и пароли, используемые для входа на веб-сайтах, не защищены, так как приложениям требуется пароль в виде открытого текста. Generic credentials such as user names and passwords that you use to log on to websites are not protected since the applications require your cleartext password. Если приложению не нужна копия пароля, оно может сохранять учетные данные как защищенные учетные данные Windows. If the application does not need a copy of the password, they can save domain credentials as Windows credentials that are protected. Учетные данные Windows используются для подключения к другим компьютерам в сети. Windows credentials are used to connect to other computers on a network. В отношении данных, хранящихся в диспетчере учетных данных и защищенных с помощью Credential Guard в Защитнике Windows, действуют следующие ограничения: The following considerations apply to the Windows Defender Credential Guard protections for Credential Manager:

• Учетные данные Windows, сохраненные клиентом удаленного рабочего стола, нельзя отправить на удаленный узел. Windows credentials saved by Remote Desktop Client cannot be sent to a remote host. Вам не удастся использовать сохраненные учетные данные Windows, при этом будет отображаться сообщение «Попытка входа в систему неудачна». Attempts to use saved Windows credentials fail, displaying the error message «Logon attempt failed.»
• Приложения, извлекающие учетные данные Windows, использовать не удастся. Applications that extract Windows credentials fail.
• Учетные данные невозможно восстановить при их резервном копировании с компьютера, на котором включена функция Credential Guard в Защитнике Windows. When credentials are backed up from a PC that has Windows Defender Credential Guard enabled, the Windows credentials cannot be restored. Если необходимо создать резервную копию учетных данных, это нужно сделать до включения Credential Guard в Защитнике Windows. If you need to back up your credentials, you must do this before you enable Windows Defender Credential Guard. В противном случае восстановить эти учетные данные будет невозможно. Otherwise, you cannot restore those credentials.

Вопросы, связанные с очисткой доверенного платформенного модуля Clearing TPM Considerations

Функция обеспечения безопасности на основе виртуализации использует доверенный платформенный модуль для защиты своего ключа. Virtualization-based Security (VBS) uses the TPM to protect its key. Поэтому при очистке доверенного платформенного модуля защищенный им ключ, который используется для шифрования секретов VBS, теряется. So when the TPM is cleared then the TPM protected key used to encrypt VBS secrets is lost.

Очистка доверенного платформенного модуля приводит к потере защищенных данных всех функций, использующих VBS для защиты данных. Clearing the TPM results in loss of protected data for all features that use VBS to protect data.
При очистке доверенного платформенного модуля ВСЕ функции, использующие VBS для защиты данных, теряют возможность расшифровки своих защищенных данных. When a TPM is cleared ALL features, which use VBS to protect data can no longer decrypt their protected data.

В результате, Credential Guard больше не может расшифровывать защищенные данные. As a result Credential Guard can no longer decrypt protected data. VBS создает новый ключ, защищенный доверенным платформенным модулем, для Credential Guard. VBS creates a new TPM protected key for Credential Guard. Credential Guard использует новый ключ для защиты новых данных. Credential Guard uses the new key to protect new data. Однако ранее защищенные данные теряются безвозвратно. However, the previously protected data is lost forever.

Credential Guard получает ключ во время инициализации, Credential Guard obtains the key during initialization. поэтому утеряны будут только постоянные данные после следующего запуска системы. So the data loss will only impact persistent data and occur after the next system startup.

Учетные данные Windows, сохраненные в диспетчере учетных данных Windows credentials saved to Credential Manager

Поскольку диспетчер учетных данных не может расшифровать сохраненные учетные данные Windows, они удаляются. Since Credential Manager cannot decrypt saved Windows Credentials, they are deleted. Приложения будут запрашивать ранее сохраненные учетные данные. Applications should prompt for credentials that were previously saved. При очередном сохранении учетные данные Windows защищаются Credential Guard. If saved again, then Windows credentials are protected Credential Guard.

Автоматически подготовленный открытый ключ устройства, присоединенного к домену Domain-joined device’s automatically provisioned public key

Начиная с Windows 10 и Windows Server 2016, устройства, присоединенные к домену, автоматически подготавливают привязанный открытый ключ. Дополнительные сведения об автоматической подготовке открытых ключей см. в разделе Проверка подлинности открытого ключа устройства, присоединенного к домену. Beginning with Windows 10 and Windows Server 2016, domain-devices automatically provision a bound public key, for more information about automatic public key provisioning, see Domain-joined Device Public Key Authentication.

Поскольку Credential Guard не может расшифровать защищенный закрытый ключ, Windows проверяет подлинность домена с помощью пароля компьютера, присоединенного к домену. Since Credential Guard cannot decrypt the protected private key, Windows uses the domain-joined computer’s password for authentication to the domain. При отсутствии дополнительно развернутых политик все функции должны остаться доступными. Unless additional policies are deployed, there should not be a loss of functionality. Если устройство настроено для использования только открытого ключа, оно не может пройти проверку подлинности с помощью пароля, пока соответствующая политика не будет отключена. If a device is configured to only use public key, then it cannot authenticate with password until that policy is disabled. Дополнительные сведения о настройке устройств для использования только открытого ключа см. в разделе Проверка подлинности открытого ключа устройства, присоединенного к домену. For more information on Configuring devices to only use public key, see Domain-joined Device Public Key Authentication.

Кроме того, если для каких-либо проверок управления доступом, включая политики проверки подлинности, необходимо, чтобы устройства имели известные идентификаторы безопасности KEY TRUST IDENTITY (S-1-18-4) или FRESH PUBLIC KEY IDENTITY (S-1-18-3), эти проверки доступа завершатся ошибкой. Also if any access control checks including authentication policies require devices to have either the KEY TRUST IDENTITY (S-1-18-4) or FRESH PUBLIC KEY IDENTITY (S-1-18-3) well-known SIDs, then those access checks fail. Дополнительные сведения о политиках проверки подлинности см. в разделе Политики проверки подлинности и приемники команд политик проверки подлинности. For more information about authentication policies, see Authentication Policies and Authentication Policy Silos. Дополнительные сведения об известных идентификаторах безопасности см. в разделе 2.4.2.4 [MS-DTYP] «Структуры известных идентификаторов безопасности». For more information about well-known SIDs, see [MS-DTYP] Section 2.4.2.4 Well-known SID Structures.

Неисправность DPAPI на устройствах, присоединенных к домену Breaking DPAPI on domain-joined devices

На устройствах, присоединенных к домену, DPAPI может восстановить ключи пользователей с помощью контроллера домена пользователя. On domain-joined devices, DPAPI can recover user keys using a domain controller from the user’s domain. Если устройство, присоединенное к домену, не подключено к контроллеру домена, восстановление невозможно. If a domain-joined device has no connectivity to a domain controller, then recovery is not possible.

При очистке доверенного платформенного модуля на устройстве, присоединенном к домену, рекомендуется обеспечить сетевое подключение к контроллерам домена. Best practice when clearing a TPM on a domain-joined device is to be on a network with connectivity to domain controllers. Это необходимо, чтобы интерфейс DPAPI работал исправно, а пользователь не сталкивался с ошибками в поведении. This ensures DPAPI functions and the user does not experience strange behavior.
Автоматическая конфигурация VPN защищена с использованием DPAPI пользователя. Auto VPN configuration is protected with user DPAPI. Пользователь может потерпеть неудачу при попытке подключения к контроллерам домена с помощью VPN, так как конфигурации VPN утеряны. User may not be able to use VPN to connect to domain controllers since the VPN configurations are lost.

При очистке доверенного платформенного модуля на устройстве, присоединенном к домену, без подключения к контроллерам домена необходимо учесть следующее. If you must clear the TPM on a domain-joined device without connectivity to domain controllers, then you should consider the following.

Вход пользователя домена на устройстве, присоединенном к домену, после очистки доверенного платформенного модуля при условии отсутствия подключения к контроллеру домена: Domain user sign-in on a domain-joined device after clearing a TPM for as long as there is no connectivity to a domain controller:

Тип учетных данных Credential Type	Версия Windows 10 Windows 10 version	Поведение Behavior
Сертификат (смарт-карта или Windows Hello для бизнеса) Certificate (smart card or Windows Hello for Business)	Все All	Все данные, защищенные DPAPI пользователя, непригодны для использования, а DPAPI пользователя не работает вообще. All data protected with user DPAPI is unusable and user DPAPI does not work at all.
Пароль Password	Windows 10 версии 1709 или более поздней версии Windows 10 v1709 or later	Если пользователь вошел с помощью сертификата или пароля до очистки доверенного платформенного модуля, можно выполнить вход с использованием пароля без каких-либо последствий для DPAPI пользователя. If the user signed-in with a certificate or password prior to clearing the TPM, then they can sign-in with password and user DPAPI is unaffected.
Пароль Password	Windows 10 версии 1703 Windows 10 v1703	Если пользователь вошел с помощью пароля до очистки доверенного платформенного модуля, можно выполнить вход с использованием этого пароля без каких-либо последствий. If the user signed-in with a password prior to clearing the TPM, then they can sign-in with that password and are unaffected.
Пароль Password	Windows 10 версии 1607 или более ранней версии Windows 10 v1607 or earlier	Существующие данные, защищенные DPAPI пользователя, непригодны для использования. Existing user DPAPI protected data is unusable. DPAPI пользователя может защитить новые данные. User DPAPI is able to protect new data.

После подключения устройства к контроллерам домена DPAPI восстанавливает ключ пользователя, а данные, находившиеся под защитой до очистки доверенного платформенного модуля, можно расшифровать. Once the device has connectivity to the domain controllers, DPAPI recovers the user’s key and data protected prior to clearing the TPM can be decrypted.

Влияние сбоев DPAPI на Windows Information Protection Impact of DPAPI failures on Windows Information Protection

Если данные, защищенные DPAPI пользователя, непригодны для использования, пользователь теряет доступ ко всем рабочим данным, находящимся под защитой Windows Information Protection. When data protected with user DPAPI is unusable, then the user loses access to all work data protected by Windows Information Protection. Последствия: Outlook 2016 не запускается, а защищенные рабочие документы невозможно открыть. The impact includes: Outlook 2016 is unable to start and work protected documents cannot be opened. Если DPAPI работает, новые созданные рабочие данные защищены и доступны. If DPAPI is working, then newly created work data is protected and can be accessed.

Решение. Для решения проблемы пользователи могут подключить устройство к домену и перезагрузить его или воспользоваться сертификатом агента восстановления данных шифрованной файловой системы. Workaround: Users can resolve the problem by connecting their device to the domain and rebooting or using their Encrypting File System Data Recovery Agent certificate. Дополнительные сведения о сертификате агента восстановления данных шифрованной файловой системы см. в разделе Создание и проверка сертификата агента восстановления данных (DRA) шифрованной файловой системы (EFS). For more information about Encrypting File System Data Recovery Agent certificate, see Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA) certificate.

См. также: See also

Связанные видео Related videos