Назад | Перейти на главную страницу

Ошибка RDP: уровень безопасности сервера обнаружил ошибку (0x80090304) в потоке протокола и на клиенте.

Я пытаюсь использовать удаленный рабочий стол для входа на сервер Dynamics 365 AOS, размещенный в Azure, с помощью Файл RDP и учетные данные отображается на окружающей среде LCS страница.

Сервер Dynamics 365 AOS - это Windows Server 2016 Datacenter Edition коробка.

При доступе к нему через Windows Server 2012 R2 сервер (т.е. RDPing на сервер, затем загрузка RDP-файла DFO365 из LCS на этот компьютер и запуск RDP-клиента на «прокси-сервере») все работает, но попытки доступа напрямую с моего Windows 7 SP1 машина выходит из строя. Коллега, тоже работает Windows 7 SP1, имеет точно такую ​​же проблему.

Мой общедоступный IP-адрес (т.е. как видно из WhatsMyIp) внесен в белый список для RDP (через LCS Maintain > Enable Access).

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

Пройдя через «прокси-сервер», я смог просмотреть журналы событий на удаленном сервере Dynamics 365 AOS. Глядя на Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational журнал событий Я мог видеть попытки подключения к этому серверу, поскольку были предупреждающие сообщения, в которых говорилось: The server security layer detected an error (0x80090304) in the protocol stream and the client (Client IP:123,45,67,89) has been disconnected. (где 123,45,67,89 соответствует моему общедоступному IP-адресу). По обе стороны от предупреждения есть несколько других информационных событий:

Эти события повторяются 3 раза, что означает, что MSTSC делает 3 попытки подключения, прежде чем сообщить об ошибке.

Просматривая Интернет, я видел упоминания о некоторых свидетельство и ключевые вопросы. Я заметил, что в папке 120 078 файлов. C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, включая одно начало f686aace6942fb7f7ceb231212eef4a4_ (TSSecKeySet1). Я не пробовал удалять или изменять какие-либо из них, так как не знаю, какими будут последствия, / не видел никаких объяснений, почему такие исправления должны работать. Мне кажется, что с проблемой может быть связан огромный объем файлов в этом каталоге.

Вопрос

Кто-нибудь знает, что может блокировать эти попытки подключения / что требуется для разрешения подключений?

Обновлено 30.04.2018: решение, которое работало для сред разработки и сборки, не работает для сред песочницы.


Для сред песочницы (уровень 2)

TL; DR

Обновите клиентский протокол RDP, чтобы включить DTLS и RDP 8.0 (возможно, требуется только первая часть; не тестировалось).

Деталь

  • Проверьте версию своего протокола RDP
    • Удерживайте Windows key и нажмите R чтобы вызвать приглашение к запуску
    • Тип MSTSC затем щелкните OK
    • Щелкните правой кнопкой мыши в строке заголовка и выберите About
    • В нижней строке текста будет указано Remote Desktop Protocol #.# supported. Если это меньше 8,0, вам нужно будет обновить (для меня это было 6,1)
  • Обновить RDP
    • Скачайте и установите DTLS (KB2574819). Дополнительная информация об этой зависимости указана на Википедия(!)
    • Скачайте и установите RDP 8.0 (KB2592687)
    • При появлении запроса перезагрузите компьютер.
  • Теперь вы должны иметь возможность успешно подключиться к удаленному серверу по протоколу RDP.

NB: также доступен RDP 8.1 (KB2923545); однако это не требуется / для меня не будет устанавливаться (по-видимому, есть дополнительные недокументированные предпосылки).


Для сред DEV / Build (Tier 1) это решение работает:

TL; DR

Повторно разверните среду.

Деталь

Начиная с обновления платформы 12 MS больше не поддерживает использование учетной записи администратора. Это описано здесь: https://blogs.msdn.microsoft.com/lcs/2017/10/31/restricted-admin-access-with-platform-12-updates/

Вместо этого нам нужно было использовать стандартную учетную запись пользователя; однако этого не было в наших экземплярах. Чтобы получить эту учетную запись, мы должны повторно развернуть среду, выполнив следующие действия: https://community.dynamics.com/enterprise/b/dynamicsaxand365/archive/2017/04/30/tips-and-tricks-to-successfully-set-up-your-dynamics-365-for-operations-platform- часть-5-среда-настройка (NB: развертывание может занять до 48 часов, а не 12 часов, как указано в сообщении / комментариях).

После повторного развертывания среды у нас были правильные учетные записи, и мы могли успешно использовать RDP в среде с помощью User### скорее, чем Admin### Учетная запись RDP (указана под Локальные пользователи скорее, чем Местные администраторы раздел.

Непонятно, почему мы смогли получить доступ с "прокси-сервера", но не с наших локальных машин, учитывая эту причину ... Я думаю, что сервер в нашем центре обработки данных каким-то образом выиграл от наличия того же внешнего IP-адреса, что и другие устройства в той же локальной сети, которые, возможно, уже имели открытые соединения; и таким образом не были заблокированы ... но это чистая догадка.

Благодарим службу поддержки Microsoft за указание причины / решения.