Решаем проблему с невозможностью подключения к удаленному пк

Нужно ли вообще обновлять Windows?

Кто-то после покупки нового компьютера или переустановки операционной системы сразу же выключает автоматические обновления, считая их ненужными. Кто-то постоянно устанавливает последние системные обновления, думая, что они обязательны для безопасности и стабильной работы Windows. Кто же прав?

Действительно, обновления системы позволяют быть более защищенным от различных программ-шпионов. С новыми обновлениями Microsoft выпускают улучшенную защиту, закрывая различные «дыры» в операционной системе, через которые могут проникнуть вредоносные программы. И если у вас недостаточно мощный антивирус, либо его нет вообще и вы не обновляете систему, то риск, что на ПК проникнет вирус, очень высок.

С новыми обновлениями выпускаются и различные исправления багов в системе. Если не обновлять систему, то через какое-то время можно заметить ухудшение производительности компьютера: различные лаги и торможения в системе, замедленная работа «тяжелых» программах (типа Photoshop, 3DMax и так далее), а еще глюки в терминалах и различных играх. С помощью обновлений многие такие проблемы, которые появляются по вине неисправности системы — исчезают.

В центре обновлений системы можно включить автоматическую установку новых компонентов Windows. Плюс здесь в том, что они вас не будут тревожить и устанавливаются автоматически.

Теперь, для объективности, несколько слов о минусах. И самых главный минус обновлений – это огромное разнообразие компьютерного оборудования. Разработчики системы не могут, даже при всем желании, выпускать обновления, которые бы работали одинаково хорошо у всех пользователей. На одной аппаратной конфигурации обновления будут отлично устанавливаться и работать, а на другой – приведут к полному отказу системы и критической ошибке BSOD (т.н. синий экран) при включении компьютера. Отсюда следует вывод: любые обновления для системы несут потенциальную угрозу для её работы. Из-за «кривых» обнов компьютер может потерять в производительности, а в некоторых случаях и вовсе перестанет загружаться.

Мой совет тут очень прост — устанавливайте обновления только в том случае, если они вам реально необходимы. Если для запуска какой-то программы требуется определенное обновление, то эти приложения обычно сами сообщат, что конкретно требуется. Вы же сможете выборочно поставить только то, что нужно. Во всех остальных случаях работает главное правило админа: «работает – не лезь». Если ваш компьютер стабильно работает без глюков и зависаний, а все установленные программы шустро выполняют свои задачи – обновляться не обязательно.

Ошибка RDP подключения: исправление шифрования CredSSP

Утро пятницы началось с жалоб некоторых пользователей на невозможность подключится к удаленному рабочему столу Windows Server 2008 R2 и Windows Server 2012 R2.

Причиной отказа в подключении послужило обновление безопасности Windows, закрывающее уязвимости в протоколе CredSSP (бюллетень CVE-2018-0886), в результате чего клиентам запрещалось подключаться к удаленным RDP серверам с непропатченой версией CredSSP. Таким образом, клиентские машины, установившие майские обновления остались не при делах.

Есть несколько путей решения проблемы. Наиболее правильным я считаю всё-таки установку обновления для закрытия уязвимости CredSSP на сервере, однако такое решение может выйти боком в некоторых случаях. Приведу простой пример когда не стоит гнаться за обновлениями.

В сети имеются компьютеры на старой версии Mac OS X (10.7.5), для которых не существует свежей версии RDP-клиента и после такого обновления теряется возможность работы с сервером. Вопрос безопасности соединения мобильных пользователей в таком случае решается VPN туннелем.

Так что, для начала рассмотрим вариант, позволяющий убрать уведомление безопасности и блокировку подключения с установленным обновлением безопасности без обновления самого сервера. Удаление самого обновления, конечно решает проблему, но неужели вы будете заниматься этим постоянно?

Отключение уведомления об ошибке шифрования CreedSSP на клиенте

Можно пойти двумя путями – внести изменения через редактор локальных групповых политик (не прокатит в редакциях Windows Home), либо напрямую в реестр с помощью командной строки. Второй способ более быстрый и универсальный – в командной строке, запущенной от имени администратора, выполним:

REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

Если же вам удобнее использовать редактор локальных групповых политик, то запустив редактор gpedit.msc, переходим в раздел:

Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учетных данных (Computer Configuration -> Administrative Templates -> System -> Credentials Delegation)

Открываем параметр с именем “Исправление уязвимости шифрующего оракула” (Encryption Oracle Remediation), и нажимаем “Включено” (“Enabled”). Уровень защиты ставим как “Оставить уязвимость” (Vulnerable).

Обновить политики на компьютере можно командой, после чего подключение по RDP должно заработать:

Установка обновления для исправления шифрования CreedSSP на сервере

Установить отсутствующие обновления безопасности на сервере можно через службу Windows Update или вручную. Чтобы не тянуть кучу лишнего, вот прямые ссылки на обновления для разных версий Windows Server:

• Windows Server 2012 R2 / Windows 8: KB4103715
• Windows Server 2008 R2 / Windows 7: KB4103712
• Windows Server 2016 / Windows 10 1607: KB4103723

Учтите, что после установки обновления сервер уйдет в перезагрузку.

Если считаете статью полезной,не ленитесь ставить лайки и делиться с друзьями.

Пользователю не удается выполнить вход с помощью смарт-картыUser can’t sign in using a smart card

В этом разделе рассматриваются три типичных сценария, когда пользователь не может войти на удаленный рабочий стол с помощью смарт-карты.This section addresses three common scenarios where a user can’t sign in to a remote desktop using a smart card.

Эта проблема возникает в развертываниях, в которых задействован сервер RDSH на сайте филиала, где используется RODC.This issue occurs in deployments that include an RDSH server at a branch site that uses a RODC. Сервер RDSH размещен в корневом домене.The RDSH server is hosted in the root domain. Пользователи на сайте филиала относятся к дочернему домену и используют смарт-карты для проверки подлинности.Users at the branch site belong to a child domain, and use smart cards for authentication. Контроллер домена RODC настроен на кэширование паролей и принадлежит к группе с разрешением реплицировать пароли RODC.The RODC is configured to cache user passwords (the RODC belongs to the Allowed RODC Password Replication Group). Когда пользователи пытаются выполнить вход в сеанс на сервере RDSH, они получают сообщение, например: «Неудачная попытка входа в систему.When users try to sign in to sessions on the RDSH server, they receive messages such as „The attempted logon is invalid. Указано неверное имя пользователя или другие неверные личные данные.“This is either due to a bad username or authentication information.»

Эта проблема связана с тем, как корневой контроллер домена и RDOC управляют шифрованием учетных данных пользователей.This issue is caused by how the root DC and the RDOC manage user credential encryption. Корневой контроллер домена использует ключ шифрования, чтобы зашифровать учетные данные, а RODC предоставляет ключ расшифровки клиенту.The root DC uses an encryption key to encrypt the credentials and the RODC gives the client the decryption key. Если пользователь получает ошибку «Недопустимо», значит два ключа не совпадают.When a user receives the «invalid» error, that means the two keys don’t match.

Чтобы решить эту проблему, выполните одно из указанных ниже действий:To work around this issue, try one of the following things:

• измените топологию контроллера домена, отключив кэширование паролей на RODC, или разверните на сайте филиала контроллер домена с доступом на запись;Change your DC topology by turning off password caching on the RODC or deploy a writeable DC to teh branch site.
• переместите сервер RDSH в тот же дочерний домен, где находятся пользователи;Move the RDSH server to the same child domain as the users.
• разрешите пользователям выполнять вход без смарт-карты.Allow users to sign in without smart cards.

Учтите, что эти решения предполагают наличие компромисса между производительностью и уровнем безопасности.Be advised that all of these solutions require compromises in either performance or security level.

Эта проблема возникает, когда пользователи выполняют вход в систему компьютера Windows Server 2008 с пакетом обновления 2 (SP2), на котором установлено обновление KB4093227 (2018.4B).This issue occurs when users sign in to a Windows Server 2008 SP2 computer that has been updated with KB4093227 (2018.4B). Когда пользователи пытаются выполнить вход с помощью смарт-карты, они получают отказ в доступе с сообщениями, например: «Действительные сертификаты не найдены.When users attempt to sign in using a smart card, they are denied access with messages such as „No valid certificates found. Убедитесь, что эта карта вставлена правильно и плотно сидит в разъеме“.Check that the card is inserted correctly and fits tightly.» В то же время на компьютере Windows Server регистрируется событие приложения с сообщением «При получении цифрового сертификата с вставленной смарт-карты произошла ошибка:At the same time, the Windows Server computer records the Application event „An error occurred while retrieving a digital certificate from the inserted smart card. неправильная подпись.“Invalid Signature.»

Чтобы устранить эту проблему, обновите на компьютере ОС Windows Server до повторного выпуска 2018.06 B (обновление KB4093227). См. статью Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018 (Описание обновления системы безопасности для защиты протокола RDP в Windows от уязвимости службы в Windows Server 2008 (10 апреля 2018 г.).To resolve this issue, update the Windows Server computer with the 2018.06 B re-release of KB 4093227, Description of the security update for the Windows Remote Desktop Protocol (RDP) denial of service vulnerability in Windows Server 2008: April 10, 2018.

Настройка удаленного десктопа средствами Windows

Чтобы компьютеры могли взаимодействовать, они должны быть правильно настроены. Технически задача не выглядит слишком сложной, хотя здесь есть свои нюансы, особенно в случае управления через интернет. Итак, давайте посмотрим, как настроить удаленный рабочий стол средствами системы. Во-первых, на ПК, к которому будет осуществляться доступ, должна быть установлена версия Windows не ниже Pro, управлять же можно и с домашней версии

Второе и очень важно условие – это необходимость наличия статического IP-адреса на удаленном ПК

Конечно, можно попробовать настроить его вручную, но тут есть проблема. Дело в том, что внутренний IP дается ПК DHCP-сервером интернет-центра на определенный срок, по истечении которого компьютеру нужно будет запросить новый IP. Он может оказаться тем же самым, но может и измениться, тогда вы не сможете использовать протокол RDP. Так бывает с серыми, динамическими адресами, и, надо сказать, именно такие адреса выделяют своим клиентам большинство провайдеров. Поэтому самым правильным было бы обращение в службу поддержки провайдера с просьбой выделить вашему компьютеру статический адрес.

Если не хотим платить за белый IP (услуга предоставляется за дополнительную плату), пробуем настроить подключение вручную. Командой control /name Microsoft.NetworkAndSharingCenter
откройте «Центр управления сетями и общим доступом», кликните по вашему подключению и нажмите в открывшемся окошке кнопку «Сведения».

Запишите данные IPv4, маски подсети, шлюза по умолчанию и DNS-сервера.

Эти же данные вы можете получить, выполнив в консоли CMD или PowerShell команду ipconfig /all
. Закройте окошко сведений и откройте свойства в окне состояния.

Выберите в списке IPv4, перейдите в его свойства и введите полученные данные в соответствующие поля. Сохраните настройки.

Статический адрес у вас есть, теперь нужно включить разрешение доступа подключения. Откройте командой systempropertiesremote
вкладку «Удаленный доступ» в свойствах системы и включите радиокнопку «Разрешить удаленные подключения к этому компьютеру».

Если нужно, добавляем юзеров, которым хотим предоставить возможность удаленного подключения.

В Windows 10 1709 получить доступ ко всем этим настройкам можно из подраздела «Удаленный рабочий стол» приложения «Параметры».

При использовании стороннего фаервола откройте в нем порт TCP 3389. На данном этапе общая настройка удаленного рабочего стола завершена.

Если подключение выполняется в локальной сети, можете приступать к работе немедленно. Запустите командой mstsc
встроенное приложение RDP, введите в открывшемся окошке IP-адрес или имя удаленного хоста, выберите пользователя и нажмите «Подключить».

Игнорируем его, отключаем запросы на подключение (снять галку) и жмем «Да». В случае удачного соединения вы увидите рабочий стол удаленного хоста.

Настроить удаленный рабочий стол через интернет сложнее, так как здесь придется выполнить проброс порта 3389 на IP-адрес вашего ПК, а затем подключиться к внешнему IP маршрутизатора, что может стать для пользователя настоящей головной болью, так как придется копаться в настройках роутера. Узнать свой публичный IP не составляет труда, достаточно зайти на сайт 2ip.ua/ru
либо аналогичный ресурс.

В случае с необходимо зайти в раздел Переадресация – Виртуальные серверы
, нажать «Добавить» и ввести в поля «Порт сервера» и «Внутренний порт» 3389, в поле «IP-адрес» указывается используемый компьютером IP, в полях «Протокол» и «Состояние» должно быть выставлено «Все» и «Включено» соответственно. Сохраните настройки.

Теперь можно пробовать подключиться к удаленному десктопу с основного ПК. Запустите командой mstsc программу RDP и введите в поле «Компьютер» ранее полученный внешний IP-адрес с номером порта через двоеточие, например, 141.105.70.253:3389. Далее все точно так же, как и в примере с подключением в локальной сети.

Назначение CredSSP

Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.

CredSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.

После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.

Подробнее на Microsoft https://docs.microsoft.com/en-us/windows/desktop/secauthn/credential-security-support-provider

Windows SSP

Следующие поставщики общих служб устанавливаются вместе с Windows:

• NTLM (Представлено в Windows NT 3.51 ) (msv1_0.dll) — обеспечивает проверку подлинности NTLM с запросом/ответом для клиент-серверных доменов до Windows 2000 и для не доменной аутентификации (SMB /CIFS).
• Kerberos (Представлен в Windows 2000 и обновлен в Windows Vista для поддержки AES ) (kerberos.dll). Предпочтителен для взаимной аутентификации клиент-серверного домена в Windows 2000 и более поздних версиях. 
• Согласование (введено в Windows 2000) (secur32.dll) — выбирает Kerberos и, если не доступно, протокол NTLM. SSP обеспечивает возможность единого входа , иногда называемую встроенной аутентификацией Windows (особенно в контексте IIS). В Windows 7 и более поздних версиях представлен NEGOExts, в котором согласовывается использование установленных пользовательских SSP, которые поддерживаются на клиенте и сервере для аутентификации.
• Безопасный канал (он же SChannel) — Представлен в Windows 2000 и обновлен в Windows Vista и выше для поддержки более надежного шифрования AES и ECC. Этот поставщик использует записи SSL/TLS для шифрования полезных данных. (Schannel.dll)
• PCT (устарел) реализация Microsoft TLS/SSL — криптография SSP с открытым ключом, которая обеспечивает шифрование и безопасную связь для аутентификации клиентов и серверов через Интернет. Обновлено в Windows 7 для поддержки TLS 1.2.
• Digest SSP (Представлено в Windows XP ) (wdigest.dll) — Обеспечивает проверку подлинности HTTP и SASL на основе запросов/ответов между системами Windows и не-Windows, где Kerberos недоступен.
• Учетные данные (CredSSP) (Представлено в Windows Vista и доступно в Windows XP с пакетом обновления 3 (SP3)) (credssp.dll) — обеспечивает SSO и проверку подлинности на уровне сети для служб удаленных рабочих столов.
• Аутентификация с распределенным паролем (DPA) — (Представлено в Windows 2000) (msapsspc.dll) — Обеспечивает аутентификацию через Интернет с использованием цифровых сертификатов.
• Криптография с открытым ключом «пользователь-пользователь» (PKU2U) (представлена ​​в Windows 7 ) (pku2u.dll) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.

Подробнее на https://en.wikipedia.org/wiki/Security_Support_Provider_Interface

Проверка состояния протокола RDP

Проверка состояния протокола RDP на локальном компьютере

Сведения о том, как проверить и изменить состояние протокола RDP на локальном компьютере, см. в разделе How to enable Remote Desktop (Как включить удаленный рабочий стол).

Проверка состояния протокола RDP на удаленном компьютере

Важно!

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

Чтобы проверить и изменить состояние протокола удаленного рабочего стола на удаленном компьютере, используйте подключение сетевого реестра:

1. Сначала откройте меню Пуск и выберите Выполнить. В появившемся текстовом поле введите regedt32.
2. В редакторе реестра нажмите Файл и выберите пункт Подключить сетевой реестр.
3. В диалоговом окне Выбор: “Компьютер” введите имя удаленного компьютера, выберите Проверить имена и нажмите кнопку ОК.
4. Перейдите к записи HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server.
   • Если раздел fDenyTSConnections имеет значение , значит протокол RDP включен.
   • Если раздел fDenyTSConnections имеет значение 1, значит протокол RDP отключен.
5. Чтобы включить протокол RDP, для fDenyTSConnections замените значение 1 на .

Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере

Если не удается включить протокол RDP в пользовательском интерфейсе или для fDenyTSConnections возвращается значение 1 после его изменения, объект групповой политики может переопределять параметры на уровне компьютера.

Чтобы проверить конфигурацию групповой политики на локальном компьютере, откройте окно командной строки с правами администратора и введите следующую команду:

gpresult /H c:gpresult.html

Когда команда будет выполнена, откройте файл gpresult.html. Выберите Конфигурация компьютераАдминистративные шаблоныКомпоненты WindowsСлужбы удаленных рабочих столовУзел сеансов удаленных рабочих столовПодключения и найдите политику Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.

• Если для параметра этой политики задано значение Включено, групповая политика не блокирует подключения по протоколу RDP.

• Если же для параметра этой политики задано значение Отключено, проверьте результирующий объект групповой политики. Ниже показано, какой объект групповой политики блокирует подключения по протоколу RDP.

Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере

Чтобы проверить конфигурацию групповой политики на удаленном компьютере, нужно выполнить почти такую же команду, что и для локального компьютера.

gpresult /S <computer name> /H c:gpresult-<computer name>.html

В файле (gpresult-<computer name>.html), который создается после выполнения этой команды, используется такой же формат данных, как в версии файла для локального компьютера (gpresult.html).

Изменение блокирующего объекта групповой политики

Эти параметры можно изменить в редакторе объектов групповой политики (GPE) и консоли управления групповыми политиками (GPM). Дополнительные сведения об использовании групповой политики см. в статье Advanced Group Policy Management (Расширенное управление групповыми политиками).

Чтобы изменить блокирующую политику, используйте один из следующих методов.

• В GPE укажите определенный уровень для объекта групповой политики (локальный или доменный) и выберите Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Узел сеансов удаленных рабочих столов > Подключения > Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.
  1. Задайте для политики значение Включена или Не задана.
  2. На затронутых компьютерах откройте окно командной строки с правами администратора и выполните команду gpupdate /force.
• В GPM перейдите к подразделению, в котором блокирующая политика применяется к соответствующим компьютерам, и удалите эту политику.

Использование редактора реестра

То же самое можно сделать через реестр Windows. Вот шаги:

• Перейдите в Run -> regedit, чтобы открыть редактор реестра.
• Перейти к следующему ключу:
• HKLM \ Software \ Microsoft \ Windows \ Текущая версия \ Policies \ CredSSP \ System \ Parameters
• На правой панели измените значение DWORD ключа AllowEncryptionOracle на 2.
• Если вы не можете найти ключ, вы должны его создать.

Теперь вы сможете успешно установить подключение к удаленному рабочему столу!

Совет экспертов:

Эд Мойес

CCNA, веб-разработчик, ПК для устранения неполадок

Я компьютерный энтузиаст и практикующий ИТ-специалист. У меня за плечами многолетний опыт работы в области компьютерного программирования, устранения неисправностей и ремонта оборудования. Я специализируюсь на веб-разработке и дизайне баз данных. У меня также есть сертификат CCNA для проектирования сетей и устранения неполадок.

Сообщение Просмотров: 499

Похожие посты:

Ошибка при проверке подлинности код 0x80090304 rdp windows xp

Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc

Еще раз обращаю ваше внимание, что данный метод временный и самый не безопасный, применяемый в случаях, когда уже ничего сделать нельзя или дольше, а нужно уже вчера, обязательно установите все нужные обновления

Бонусные и дисконтные карты
Как пользоваться Личным Кабинетом
Официальные сайты магазинов
Телефоны и горячие линии
Мобильные приложения
Регистрация в программе
Активация карты
Как проверить баланс
О банковских картах

В чем суть ошибки проверки подлинности RDP

В апреле «Майкрософт» выпустила следующий апдейт, снабжающий пользователя более детальной информацией об ошибке во время использования клиента удалённого рабочего стола (RDP).

В мае 2018 года вышел финальный Update, изменяющий настройки сессии RDP c использованием CredSSP по умолчанию с « Vulnerable » (Уязвимый) до « Mitigated » (Смягчённый). Также это означало, что любое клиентское приложение, задействующее «CredSSP», будет невозможно откатить до небезопасной версии.

Если ваша рабочая станция получила майское обновление, а сервер его не получал, тогда рабочая станция (клиент) будет отображать сообщение об ошибке при попытке подключения к серверу с использованием RDP.

Разберём перечень способов, позволяющих эффективно избавиться от проблемы проверки подлинности RDP.

Изменение пароля безопасности

Мы уже подробно писали, Как узнать пароль от своего Wi-Fi. Если вкратце, то вам нужно:

1. Ввести IP-адрес, логин и пароль роутера в браузере. Посмотреть их можно на задней или нижней поверхности устройства либо в инструкции пользователя. Если не получается найти, введите Win+R — cmd — ipconfig. В строке «Основной шлюз» отображён адрес роутера. Логин и пароль по умолчанию — admin/admin.
2. Пройти во вкладку безопасности Wi-Fi. В строке «Ключ шифрования» или «Пароль безопасности» проглядите существующий или же введите новый пароль.
3. На вашем Samsung или другом Android-планшете включить Вай-Фай, пройти в Настройки — Беспроводные сети — Wi-Fi — зажмите пальцем название подключения — Изменить эту сеть. Отметьте галочкой «Показать пароль», введите его по новой, тщательно сверяя с введённым в маршрутизаторе.

Причины ошибки Windows не может получить доступ к компьютеру в локальной сети

Сама ошибка сложная и запутанная. Одной из причин ее возникновения считается случай, когда сеть после настройки вроде бы функционирует правильно, но пользователь вводит некорректный путь

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

Ошибки подключения PPPoE

Неправильно настроены параметры безопасности PPPoE соединения, PPPoE-трафик блокируется на пути к шлюзу, либо настройки PPPoE не вступили в действие. В свойствах PPPoE соединения откройте вкладку «Безопасность» — должно быть выбрано «Обычные (рекомендуемые параметры)» и должна быть выбрано «Небезопасный пароль». Перезагрузите компьютер и попробуйте подключиться еще раз. Проверьте настройки Вашего брандмауэра, и если не уверены в их правильности, отключите его. Если проблема сохраняется – позвонить в Службу технической поддержки.

Ошибка: 691:(Доступ запрещен, поскольку такие имя пользователя или пароль недопустимы в этом домене).

Чаще всего эта ошибка возникает у пользователей InterCom, если они действительно не правильно набирают Имя пользователя и Пароль, либо под Вашим логином уже произведено PPPoE подключение к сети. Решение проблемы: Внимательно набрать Имя пользователя и Пароль. Логин вводится прописными английскими буквами и/или цифрами. Убедиться в том, что включена английская раскладка клавиатуры. Вспомните не давали ли Вы свои учетные данные друзьям/знакомым. Если проблема сохраняется – позвонить в Службу технической поддержки .

Ошибка: 678,815,651:(Удаленный компьютер не отвечает).

Такой тип ошибки возникает, когда отсутствует связь между вашим компьютером и сервером доступа. Скорее всего причиной этой ошибки являются: неисправности на нашем активном оборудовании, у клиента отключена сетевая карта, подключение заблокировано антивирусной программой или файрволом. Решение проблемы:

• Возможно не подключен кабель локальной сети или плохой контакт в разъемах.
• Возможно неправильно работает сетевой адаптер вашего компьютера. Для устранения неисправности может потребоваться переустановка драйвера сетевого адаптера или замена сетевого адаптера.
• Возможно произошел обрыв кабеля или сервер доступа отключен.
• Возможно сетевой адаптер отключен в диспетчере устройств. Включите сетевой адаптер и повторите попытку подключения.

Проверить подключение по локальной сети (Пуск-> Панель управления -> Сетевые подключения -> нажать правой кнопкой мыши на Подключение по локальной сети — > выбрать Включить). Отключить антивирусную программу или файрвол. Если проблема сохраняется – позвонить в Службу технической поддержки.

Ошибка: 769:(Указанное назначение недостижимо).

Причиной возникновения данной ошибки является то, что сетевая карта на вашем компьютере отключена. Решение проблемы: Необходимо включить сетевой адаптер в диспетчере устройств (Пуск-> Панель управления-> Система-> Оборудование-> Диспетчер устройств-> Сетевые Платы) Нажав правой кнопкой мыши, выбрать Задействовать и повторить попытку подключения. Если проблема сохраняется – позвонить в Службу технической поддержки.

Ошибка: 734, 735:(Протокол управления PPP-связью был прерван)

. Эта ошибка может возникнуть в том случае, если протоколы безопасности на сервере, к которому устанавливается подключение, несовместимы с локальными параметрами безопасности. Решение проблемы: В папке Сетевые подключения щелкните используемое PPPoE подключении правой кнопкой мыши. Выберите команду Свойства и откройте вкладку Безопасность. В списке При проверке используется выберите Небезопасный пароль. Если проблема сохраняется – позвонить в Службу технической поддержки.

Ошибка: 680 и 676:(Линия занята).

Такая ошибка возникает, если не правильно работает сетевая карта на вашем компьютере, или имеются неисправности на нашем активном оборудовании. Решение проблемы: Необходимо выключить и заново включить сетевой адаптер в диспетчере устройств (Пуск-> Панель управления-> Система-> Оборудование-> Диспетчер устройств-> Сетевые Платы) Нажав правой кнопкой мыши, выбрать Отключить, а затем Задействовать и повторить попытку подключения PPPoE . Если проблема сохраняется Перегрузить компьютер и повторить попытку подключения. Если проблема сохраняется – позвонить в Службу технической поддержки.

Не забывайте! Если у Вас стоит Роутер, то большинство проблем решается перезагрузкой роутера

(Выключить его с розетки и снова включить)

Самый правильный метод, это установка обновлений

Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886

• Windows Server 2012 R2 / Windows 8: KB4103715
• Windows Server 2008 R2 / Windows 7: KB4103712
• Windows Server 2016 / Windows 10 1607 — KB4103723
• Windows Server 2016 / Windows 10 1703 — KB4103731
• Windows Server 2016 / Windows 10 1709 — KB4103727
• Windows Server 2016 / Windows 10 1803 — KB4103721

На этом у меня все, надеюсь, что вы разобрались в работе CredSSP и научились ей управлять. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.

Отключение 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 7 можно увидеть ошибку: «Произошла ошибка проверки подлинности. Указанная функция не поддерживается»

В Windows 10 ошибка расписана более подробно, в частности сказано «Причиной ошибки может быть исправление шифрования CredSSP»:

Для обхода ошибки со стороны клиента многие советуют отключить групповую политику, путём установки значения Encryption Oracle Remediation в Vulnerable: с помощью gpedit.msc в Конфигурация компьютера / Административные шаблоны / Система / Передача учётных данных, слева выбрать «Исправление уязвимости шифрующего оракула» (забавный конечно перевод), в настройках поставить «Включено» и выбрать «Оставить уязвимость».

или через реестр (т.к., например, в Windows Home нет команды gpedit.msc):

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

НО! Так делать не нужно! Т.к. таким образом вы оставляете уязвимость и риски перехвата вашего трафика и пр. конфиденциальные данные, включая пароли. Единственный случай, когда это может быть необходимо, это когда у вас вообще нет другой возможности подключиться к удалённому серверу, кроме как по RDP, чтобы установить обновления (хотя у любого облачного провайдера должна быть возможность подключения к консоли сервера). Сразу после установки обновлений, политики нужно вернуть в исходное состояние.

Если доступ к удалённому серверу есть, то ещё, как временная мера, можно отключить требование NLA (Network Level Authentication), и сервер перестанет использовать CredSSP. Для этого достаточно в Свойствах системы, на вкладке удалённые подключения снять соответствующую галку «Разрешить подключения только с компьютеров, на которых работает удалённый рабочий стол с проверкой подлинности на уровне сети»:

Но, это тоже неправильный подход.

Подсоединившись к его рабочему столу через TeamViewer и при подключение по RDP к серверу Windows 2012 у нас вылетела ошибка:

начал разбираться и вот что могу рассказать об этой ошибке: