В свойствах сисемы при разрешении доступа по терминалу выбери доступ без проверки подлинности на уровне сети.
Источник
Linux xrdp ошибка проверки подлинности
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.
Как выглядит ошибка credssp
Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:
Ну и конечно в русском исполнении:
Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.
Назначение CredSSP
Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.
C redSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.
После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.
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) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.
Причины ошибки шифрования CredSSP
В марте 2018 года, компания Microsoft выпустила обновление безопасности для устранения уязвимостей для протокола поставщика поддержки безопасности учетных данных (CredSSP) под именем CVE-2018–0886 (https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018), используемого подключениями по протоколу удаленного рабочего стола (RDP) для клиентов Windows и Windows Server. Как только пользователи и системные администраторы произвели установку апдейтов, то по всему миру начались массовые жалобы, что люди не могут подключаться по протоколу RDP к серверам, компьютерам, получая ошибку, что причиной ошибки может быть шифрование CredSSP.
К сожалению 99% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.
Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8.1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.
Варианты исправления ошибки CredSSP
На самом деле вариантов много, есть правильные, есть и временные и обходные, которые нужно сделать быстро, чтобы хоть как-то работало, так как бизнес может в этот момент простаивать и терять деньги.
- Вы можете удалить новое обновление безопасности, самый плохой вариант, но в ответственные моменты, иногда используется, чтобы перенести работы на вечер или ночь
- Если нужно быстро получить доступ к серверу и избежать проверку подлинности credssp, то я вам советую отключить на принимающем подключении сервере галку NLA (Network Level Authentication) в русском варианте «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
- То же быстрый метод и на массовое применение, это использование групповой политики, которая изменит шифрование Oracle Remediation
- Ну и самый правильный метод , это установка обновлений на все ваши системы
Отключаем credssp в Windows через NLA
Данный метод выхода из ситуации я бы рассматривал, как быстрое, временное решение, до того, как вы установите обновления безопасности. Чтобы разрешить удаленное подключение к серверу и избегать ситуации, что произошла ошибка при проверке подлинности credssp, сделайте вот что. Откройте свойства моего компьютера, попав в систему, так же можно нажать одновременно WIN+Pause Breake или как вариант в командной строке ввести control /name Microsoft.System. В окне «Система» находим пункт меню «Настройка удаленного доступа»
Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:
- Использовать сетевой реестр Windows
- Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.
Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».
Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.
У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSPParameters, то нужно будет их создать):
Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.
Или можно так же отключить NLA, для этого найдите ветку реестра:
Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.
Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:
w10-cl01 — это имя компьютера.
Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:
Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:
Еще раз обращаю ваше внимание, что данный метод временный и самый не безопасный, применяемый в случаях, когда уже ничего сделать нельзя или дольше, а нужно уже вчера, обязательно установите все нужные обновления.
Отключаем шифрование credssp через GPO
Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.
Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc.
Вам необходимо перейти в ветку:
Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:
- Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
- Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
- Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.
Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.
После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра
На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory
Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName
Foreach ($computer in $PCs) <
Invoke-Command -ComputerName $computer -ScriptBlock <
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
>
>
Самый правильный метод, это установка обновлений
Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).
Раньше были вот такие KB, но они со временем могут меняться свой номер, поэтому пройдите по ссылке выше, так будет надежнее.
- 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
Источник
Adblock
detector
Содержание
- Предпосылки
- Шаг 1: Установите Xrdp на Ubuntu 20.04
- Установите Xrdp на Ubuntu
- Шаг 2: Настройка Xrdp на Ubuntu 20.04
- Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента
- Как исправить черный экран XRDP в Ubuntu
- Заключение
Xrdp — это аналог протокола Microsoft Remote Desktop Protocol (RDP). Если xrdp установлен в системе Linux, пользователи могут удаленно получить доступ к рабочему столу Linux с помощью RDP-клиента. Все это я покажу в этой статье. Его можно совершенно бесплатно скачать и использовать.
Без лишних слов давайте давайте приступим к установке Xrdp на Ubuntu Desktop 20.04 и 18.04.
Предпосылки
В этом руководстве предполагается, что у вас уже установлена Ubuntu 20.04 или Ubuntu 18.04. Если у вас есть минимальная установка без графического интерфейса – то рекомендуется установить среду рабочего стола или GNOME.
Чтобы установить среду рабочего стола Ubuntu, выполните команду:
$ sudo apt install ubuntu-desktop
Шаг 1: Установите Xrdp на Ubuntu 20.04
Для начала запустите терминал и выполните следующую команду для установки Xrdp в вашу систему.
$ sudo apt install xrdp
Когда появится запрос, просто нажмите 'Y'
, а далее нажмите enter, чтобы продолжить установку.
Установите Xrdp на Ubuntu
Служба Xrdp запускается автоматически после установки. Для проверки работоспособности сервиса XRDP, выполнив команду:
$ sudo systemctl status xrdp
Данные которые вы видите на рисунке подтверждают, что сервис XRDP работает.
Шаг 2: Настройка Xrdp на Ubuntu 20.04
При установке Xrdp ключ SSL сертификата ssl-cert-snakeoil. key помещается в папку /etc/ssl/private/. Нам требуется добавить пользователя xrdp в группу ssl-cert, чтобы сделать файл читаемым для пользователя. Это можно сделать командой:
$ sudo adduser xrdp ssl-cert
Xrdp прослушивает порт 3389 и если вы находитесь за брандмауэром UFW, то вам нужно открыть порт. Это делается для того чтобы разрешить входящий трафик от клиентов RDP. В этом примере я разрешу трафик на порт 3389 из всей моей подсети в систему Ubuntu.
$ sudo ufw allow from 192.168.2.0/24 to any port 3389
После этого требуется перезагрузить брандмауэр и проверить, открыт ли порт.
$ sudo ufw reload
$ sudo ufw status
Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента
На этом шаге мы попробуем подключится к системе Ubuntu из Windows 10. В этом нам поможет стандартный клиент удаленного рабочего стола (RDP). Но прежде чем продолжить, убедитесь что вы вышли из Ubuntu 20.04. Так как Xrdp поддерживает только один Xsession.
- Запустите RDP клиент на Windows
- Введите IP-адрес удаленной системы
- Нажмите кнопку «Подключиться«.
В окне которое требует проверку удаленной системы, игнорируйте ошибки сертификата и нажмите на кнопку «Далее«.
На странице входа в систему Xrdp введите свои учетные данные и нажмите кнопку «Ok«.
Примечание: в этот момент Вы можете столкнуться с пустым черным экраном вместо фона рабочего стола Ubuntu. Лично я столкнулся с таким багом. После долгих мучений, я нашел вариант как исправить этот баг.
Решение довольно простое. Откройте Ubuntu и отредактируйте /etc/xrdp/startwm.sh сценарий.
$ sudo vim /etc/xrdp/startwm.sh
Добавьте эти строки непосредственно перед строками, которые тестируют и выполняют Xsession, как показано на скриншоте ниже.
unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR
Далее требуется сохранить файл и выйдите. Не забудьте перезапуститm службу Xrdp.
$ sudo systemctl restart xrdp
Затем повторно подключитесь. После первоначальной аутентификации вам потребуется пройти повторную аутентификацию, как показано на рисунке.
Введите свои учетные данные и нажмите кнопку «аутентификация«.После проделанного в перейдете на экран стола удаленной системы Ubuntu.
Заключение
Ну вот и все, в этой статье вы узнали Как установить Xrdp на Ubuntu 20.04. Это совсем не сложно и это может сделать даже новичок Linux. Если у вас что-то не получилось или вы нашли ошибку, оставьте комментарий.
1. Remove previously installed xrdp:
$ sudo systemctl disable xrdp
$ sudo systemctl stop xrdp
$ sudo apt purge xrdp
$ sudo apt purge xserver-xorg-core
$ sudo apt purge xserver-xorg-input-all
$ sudo apt purge xorgxrdp
2. Re-install xrdp & required packages:
$ sudo apt install xrdp
$ sudo apt install xserver-xorg-core
$ sudo apt install xserver-xorg-input-all
$ sudo apt install xorgxrdp
You also need to grant access to the /etc/ssl/private/ssl-cert-snakeoil.key file for xrdp user. It is available to members of the ssl-cert group by default.
$ sudo adduser xrdp ssl-cert # add xrdp into ssl-cert group
$ sudo systemctl start xrdp # start xrdp service
$ systemctl is-active xrdp # check xrdp state
...
active
$ sudo systemctl enable xrdp # start xrdp on system start
3. Reboot system:
$ sudo reboot
4. Firewall configuration:
You need to open access on port 3389.
$ sudo ufw allow 3389
It is more secure to open it only for your IP address or network. For example:
$ sudo ufw allow from 10.5.5.0/24 to any port 3389
The best practice is to use an SSH tunnel to connect to the remote desktop and make xRDP listen only for local connections.
5. Setup your RDP-client
Please note that in some cases the user who will connect to xRDP must log out before doing so!
- Connect to your server using any RDP client.
- Enter the user credentials of your Ubuntu computer.
- Now you can see the remote desktop initial screen.
Related commands:
$ sudo systemctl status xrdp # display current xrdp status
$ sudo systemctl start xrdp # start xrdp service
$ sudo systemctl stop xrdp # stop xrdp service
$ sudo systemctl restart xrdp # restart xrdp service
$ sudo systemctl enable xrdp # enable xrdp on system start
$ sudo systemctl disable xrdp # disable xrdp on system start
Hi @matt335672, thanks for the reply. I did see some info regarding being logged in at the console. I tried logging out, and also following the wiki entry, but I’m still having the same issue. I then did what you asked, and here are the results:
date: Wed Jun 17 15:55:36 EDT 2020
Tried logging in over RDP, then here are the results of the command:
-- Logs begin at Wed 2020-04-01 13:23:43 EDT, end at Wed 2020-06-17 15:57:17 EDT. --
Jun 17 15:55:40 ubuntu dbus-daemon[17287]: [session uid=122 pid=17285] Activating service name='org.freedesktop.Noti>
Jun 17 15:55:40 ubuntu dbus-daemon[17287]: [session uid=122 pid=17285] Activating service name='org.xfce.Xfconf' req>
Jun 17 15:55:40 ubuntu dbus-daemon[17287]: [session uid=122 pid=17285] Successfully activated service 'org.xfce.Xfco>
Jun 17 15:55:40 ubuntu dbus-daemon[17287]: [session uid=122 pid=17285] Successfully activated service 'org.freedeskt>
Jun 17 15:55:41 ubuntu xrdp[1389]: (1389)(281473264242704)[INFO ] Socket 12: AF_INET6 connection received from ::fff>
Jun 17 15:55:41 ubuntu xrdp[1389]: (1389)(281473264242704)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:192.168.1.226 po>
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[INFO ] Using default X.509 certificate: /etc/xrdp/cert.>
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[INFO ] Using default X.509 key file: /etc/xrdp/key.pem
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[ERROR] Cannot read private key file /etc/xrdp/key.pem: >
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[DEBUG] TLSv1.3 enabled
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[DEBUG] TLSv1.2 enabled
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[DEBUG] Security layer: requested 11, selected 0
Jun 17 15:55:41 ubuntu xrdp[18426]: (18426)(281473264242704)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:192.168.1.226 >
Jun 17 15:55:42 ubuntu xrdp[1389]: (1389)(281473264242704)[INFO ] Socket 12: AF_INET6 connection received from ::fff>
Jun 17 15:55:42 ubuntu xrdp[1389]: (1389)(281473264242704)[DEBUG] Closed socket 12 (AF_INET6 ::ffff:192.168.1.226 po>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] Closed socket 11 (AF_INET6 :: port 3389)
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] Using default X.509 certificate: /etc/xrdp/cert.>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] Using default X.509 key file: /etc/xrdp/key.pem
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[ERROR] Cannot read private key file /etc/xrdp/key.pem: >
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] TLSv1.3 enabled
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] TLSv1.2 enabled
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] Security layer: requested 0, selected 0
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] connected client computer name: PAULRYZEN
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] adding channel item name rdpdr chan_id 1004 flag>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] adding channel item name rdpsnd chan_id 1005 fla>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] adding channel item name cliprdr chan_id 1006 fl>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] adding channel item name drdynvc chan_id 1007 fl>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] Non-TLS connection established from ::ffff:192.1>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] xrdp_000047fb_wm_login_mode_event_00000001
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] Loading keymap file /etc/xrdp/km-00000409.ini
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[WARN ] local keymap file for 0x00000409 found and doesn>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0>
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: (1353)(281473614072064)[INFO ] A connection received from ::1 port 37930
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] xrdp_wm_log_msg: sesman connect ok
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] xrdp_wm_log_msg: sending login info to session m>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] return value from xrdp_mm_connect 0
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: pam_unix(xrdp-sesman:auth): Couldn't open /etc/securetty: No such file or >
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: pam_unix(xrdp-sesman:auth): Couldn't open /etc/securetty: No such file or >
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: (1353)(281473614072064)[INFO ] ++ created session (access granted): userna>
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: (1353)(281473614072064)[INFO ] starting Xorg session...
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: (1353)(281473614072064)[DEBUG] Closed socket 9 (AF_INET6 :: port 5910)
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: (1353)(281473614072064)[DEBUG] Closed socket 9 (AF_INET6 :: port 6010)
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: (1353)(281473614072064)[DEBUG] Closed socket 9 (AF_INET6 :: port 6210)
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] xrdp_wm_log_msg: login successful for display 10
Jun 17 15:55:42 ubuntu xrdp-sesman[1353]: (1353)(281473614072064)[DEBUG] Closed socket 8 (AF_INET6 ::1 port 3350)
Jun 17 15:55:42 ubuntu xrdp-sesman[18428]: (18428)(281473614072064)[INFO ] calling auth_start_session from pid 18428
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] xrdp_wm_log_msg: started connecting
Jun 17 15:55:42 ubuntu xrdp-sesman[18428]: pam_unix(xrdp-sesman:session): session opened for user ubuntu by (uid=0)
Jun 17 15:55:42 ubuntu systemd-logind[1273]: New session c7 of user ubuntu.
Jun 17 15:55:42 ubuntu systemd[1]: Started Session c7 of user ubuntu.
Jun 17 15:55:42 ubuntu xrdp-sesman[18428]: (18428)(281473614072064)[DEBUG] Closed socket 7 (AF_INET6 ::1 port 3350)
Jun 17 15:55:42 ubuntu xrdp-sesman[18428]: (18428)(281473614072064)[DEBUG] Closed socket 8 (AF_INET6 ::1 port 3350)
Jun 17 15:55:42 ubuntu xrdp-sesman[18430]: (18430)(281473614072064)[INFO ] /usr/lib/xorg/Xorg :10 -auth .Xauthority >
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[INFO ] lib_mod_log_peer: xrdp_pid=18427 connected to X1>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] xrdp_wm_log_msg: connected ok
Jun 17 15:55:42 ubuntu xrdp-sesman[18428]: (18428)(281473614072064)[CORE ] waiting for window manager (pid 18429) to>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] xrdp_mm_connect_chansrv: chansrv connect success>
Jun 17 15:55:42 ubuntu xrdp[18427]: (18427)(281473264242704)[DEBUG] Closed socket 16 (AF_INET6 ::1 port 37930)
Jun 17 15:55:43 ubuntu dbus-daemon[18477]: [session uid=1000 pid=18475] AppArmor D-Bus mediation is enabled
Hello world,
In a previous post (xRDP – New “Authentication Required…” Popup showing up in Ubuntu 19.04), we have discussed about a minor issue that has been introduced with the release of Ubuntu 19.04. After installing xRDP on top of Ubuntu 19.04 operating system, and when performing the remote connection, you would notice that a authentication popup is showing up. This popup will be showing up each time you perform a remote connection to your Ubuntu machine.
The issue was similar to the “infamous Authentication required to create managed color device” and same approach would be used to fix this new annoying popup dialog box. However, we have found that the proposed solution in our previous post (xRDP – New “Authentication Required…” Popup showing up in Ubuntu 19.04) was actually introducing a new issue. This issue was basically preventing software installation from remote sessions.
After some investigations, we have been able to identify the issue and we are now writing up a new post that would explain what to do in order to fix both issues (the authentication popup and the no permissions to perform software installation within remote Session.)
So, let’s quickly tackle this….
Note : xrdp-installer-1.0.sh script already contains the fix and you can use the script to automate xRDP installation and provide the best remote session experience to your users…
Reminder – Quick Problem Description
All Ubuntu Releases
If you are using xRDP on top of Ubuntu for a long time, you probably remember the infamous authentication popup annoyance (see here). If you have performed a manual installation of xRDP package on Ubuntu, when performing your remote connection, you would see an annoying authentication popup showing up. You can decide to enter your credentials or dismiss the popup but chances are that you will be prompted two or three times and the popup will be displayed again. This popup would appear each time that you perform a remote connection to your Ubuntu machine.
Click on picture for better Resolution
Luckily, this issue is well known and we already provided a fix for it. You can find more information about this issue and the solution in the following posts
- xRDP – The Infamous “Authentication Required to create Managed color device” Explained
- xRDP – How to Fix the Infamous system crash popups in Ubuntu 18.04 (and previous versions)
If you are using our famous xRDP installation scripts, you do not need to perform these actions as they are carried out by the script. Our scripts is basically taking care of most of annoyances a user can get when performing a remote connection to Ubuntu through xRDP.
Ubuntu 19.04 Release and later
Since the release of Ubuntu 19.04, when installing xRDP software on top of it, a new authentication popup is showing up when performing a remote desktop connection. The new authentication popup is showing the following message
Authentication required to refresh system repositories.
This issue, started to show up in Ubuntu 19.04. Ubuntu 19.10, is also behaving in a similar way.
Click on picture for better Resolution
We initially tackled this issue in the following post but this solution is generating another side effect. So, we have been working hard to find what was causing the side effect. After some investigations, we found out what the problem was and we are providing the correct way to fix this issue in this post. Keep reading and jump to the solution section….
Fixing the issue the proper way….
Based on our previous posts about these kind of issues (see here, here and here), we know that the problem is related to Polkit technology used within Ubuntu operating system. Polkit check if a user is authorized to perform a certain number of actions. Different Polkit rules are being applied when a user is logged on locally on a machine or when remotely connected to the system. Basically, when remotely connected, the Polkit rules are more restrictive and we need to create exceptions in order for the user to perform actions that would not prompt for authentication dialog box when locally connected on a computer.
To create these polkit exceptions, we will need to create some additional files that would override the default authorization rules. These files needs to be created in the following location ( you need to have admin rights to copy/create files in this location !!!)
/etc/polkit-1/localauthority/50-local.d/
We already know that to fix the “Authentication required to create managed color device” popup, we simply have created a file called 45-allow-colord.pkla and populate it with the following content.
[Allow Colord all Users] Identity=unix-user:* Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile ResultAny=no ResultInactive=no ResultActive=yes
You should create this file on machines running Ubuntu 16.04 and later in order to avoid the authentication color device popup to show up. Again, as a reminder, using our famous installation script, this file will be created automatically for you and you should not experience the issue.
The pkla file above only fixes the manage color device popup dialog box. To fix the “Infamous Authentication required to refresh system repositories”, we will be creating another polkit exception file that we have called 46-allow-update-repo.pkla (also saved under /etc/polkit-1/localauthority/50-local.d). This file should contains the following information
[Allow Package Management all Users] Identity=unix-user:* Action=org.freedesktop.packagekit.system-sources-refresh ResultAny=yes ResultInactive=yes ResultActive=yes
When done, try to perform a remote connection and if everything works as expected, you should have access to your remote desktop with no “Authentication Required popup” showing up. You are basically ready to work with no more annoying popups.
Compared to the previous fix, we simply simplified the polkit exception file and we are tackling only the system-sources-refresh rules with the new *.pkla file presented here above. This action has basically fixed the authentication issue but also allows now users to perform software installation from software center within their remote session…. Please note that this specific file should be only created on Ubuntu 19.04 and later as previous versions of Ubuntu does not present such issue….
Final Notes
This is it for this post !
Based on user feedback and customer feedback, we have been able to identify a minor issue that was preventing users to perform software installation through software center. In this post, we have been specifically tackling the authentication popups that would show up on Ubuntu machines if no polkit exception files were not created. This post was focusing on the new Authentication popup showing up in Ubuntu 19.04 and later and how to deal correctly with it.
The proper fix has been implemented in the new xrdp-installer-1.0.sh script only !!! From now on, you should be only using a single script in order to perform either a standard installation or a custom installation of xRDP on top of Ubuntu 16.04 or later…. You should now be able to enjoy your remote connection to Ubuntu with no annoying popups showing up and with the possibility to install software from software center in the similar way you would do as if logged on locally….. Enjoy !
The coming post will quickly cover the software install issue….so everybody knows about the issue and the fix…
Till next time
See ya
References :
- xRDP – The infamous “ahtnetication Required to Create Managed color device explained
- xRDP – How to fix the infamous system crash popups in Ubuntu 18.04 (and previous version)
- xRDP – New “Authentication Required…” Popup showing up in Ubuntu 19.04
Хороший мануал, простой, понятный, без излишеств.
Сегодня устанавливал связку Ubuntu SERVER 18.04 LTS + LXDE + xRDP на VMWare ESXi 5.5.
Отличия от мануала:
Предварительно при установке самого 18.04 server на вопрос об установке OpenSSH сервера отвечаем утвердительно (кончено, можно установить и позже, но зачем нам лишний геморрой?).
Дальнейшая настройка производилась по SSH.
Совершенно внезапно в убунту-сервере отсутствует unzip. Лечится
sudo apt-get install unzip
Далее устанавливаем DE по вкусу. Лично я ставлю LXDE (нравится она мне, да и на винду похожа, меньше вопросов у пользователей, особенно тех кто ещё помнит XP-шку).
sudo apt-get install lxde-core
Обращаю внимание что эта команда установит именно ЯДРО LXDE безо всяких дополнительных программ. В смысле даже firefox нужно будет устанавливать ручками. Если вам такого не надо то используйте apt-get install lxde (впрочем, с таким же успехом можно поставить MATE, Gnome, Untiy или что угодно ещё).
Дальше действуем по приведённой уважаемым автором инструкции:
mkdir ~/Downloads
sudo apt-get install xrdp-pulseaudio-installer -y
wget https://adminguide.ru/wp-content/uploads/2018/11/install-xrdp-2.2.zip
unzip ./install-xrdp-2.2.zip
chmod +x ./Install-xrdp-2.2.sh
./Install-xrdp-2.2.sh
sudo reboot
Замечу в скобках что при попытке установки xrdp из репозитория я сталкивался с описанным некоторыми из предыдущих ораторов «окирпичиванием» системы с основной консоли (в моем случае — консоли ESXi). Однако, если действовать по инструкции, всё заканчивается благополучно.
Совершенно внезапным побочным эффектом оказалось то, что некоторые старые системы Windows отказались подключаться к установленному серверу по RDP с ошибкой «Произошла ошибка проверки подлинности. Указанная функция не поддерживается».
Не буду рассусоливать, суть в том что свежая реализация xrdp закрывает некоторые уязвимости, что влияет на совместимость со старыми непропатчеными форточками. Для решения проблемы требуется перейти по этой ссылке:
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2018-0886
и скачать обновление безопасности для вашей системы.
Кстати, поскольку Windows XP официально больше не поддерживается, то ответ на заданный выше вопрос о том, сможет ли такой терминальный сервер работать с XP, скорее всего будет отрицательным. А вот версия xrdp из репозитория убунты скорее всего с ХРюшей работать будет, хотя и не поручусь.
Еще раз спасибо за отличный мануал, лично мне он сэкономил кучу времени и нервов. Надеюсь мой небольшой вклад поможет как автору так и читателям.
Лично с автором с удовольствием пообщался бы на тему установки 1C под получившуюся систему, есть несколько вопросов, но это не для папблика по ряду причин.
В настоящее время существует множество вариантов удалённого подключения к рабочим местам. Кроме того, стоимость аренды виртуальной машины хорошей производительности в облаке в месяц, сопоставима с ценой кружки хорошего кофе. Такие удалённые виртуальные машины удобно использовать с офисных слабых компьютеров, из поездок с ноутбуком и слабым Интернет-соединением, запускать на них длительные задачи, как например перепроведение документов в 1С, скачивание больших файлов.
Ещё можно организовать общий сервер на базе Ubuntu 20.04 в облаке или на мощном компьютере и совместно использовать его ресурсы с помощью удалённого доступа. В этой статье мы рассмотрим как выполняется установка XRDP Ubuntu 20.04.
XRDP – это реализация протокола удалённого рабочего стола Microsoft (RDP) с открытым исходным кодом, которая позволяет графически управлять удалённой системой.
В отличие от коммерческого продукта, XRDP в Linux позволяет работать одновременно с одним компьютером или виртуальной машиной неограниченному числу пользователей, что позволяет активно использовать XRDP для разворачивания терминальных серверов на базе Ubuntu 20.04.
Установка XRDP на Ubuntu 20.04
Шаг 1. Поиск пакета
В Ubuntu 20.04 можно получить установить программу с помощью утилиты apt. Давайте установим XRDP из репозитория Ubuntu 20.04. Для этого, с помощью терминала, вы можете проверить, есть ли пакет xrdp в хранилище пакетов Ubuntu 20.04:
sudo apt searh xrdp
Шаг 2. Обновление системы
Такой пакет есть, поэтому вы можете, предварительно обновив систему, простым путём установить xrdp на Ubuntu 20.04. Обновляем и перезагружаем для принятия изменений в ОС:
sudo apt –y update && sudo apt –y upgrade && sudo reboot
Шаг 3. Установка пакетов
После перезагрузки можно устанавливать XRDP из репозитория Ubuntu 20.04
sudo apt install xrdp
Обращаю внимание, что при установке генерируется сертификат, который необходим для функционирования RDP протокола, строка ниже указывает, что сертификат успешно создан:
ssl_gen_key_xrdp1 ok
Шаг 3. Настройка службы XRDP
В связи с особенностями системы Ubuntu 20.04, необходимо ввести пользователя xrdp, от имени которого работает XRDP в системе, в группу ssl-cert. Выполните команду:
sudo adduser xrdp ssl-cert
Затем добавьте службу xrdp в автозапуск и перезапустите её для применения изменений:
sudo systemct enable xrdp
sudo systemctl restart xrdp
sudo systemctl status xrdp
Если результат выполнения команды выглядит так, как на скриншоте, то все прошло успешно. В финале предоставьте доступ из внешней сети к порту 3389 в файрволле Ubuntu 20.04:
sudo ufw allow from 192.168.2.0/24 to any port 3389
sudo ufw allow 3389
Шаг 4. Поиск IP адреса
С помощью любого клиента RDP можно подключаться по имени компьютера, возможно для этого нужно дополнительно настроить DNS. Лучше получить доступ по IP-адресу сервера, на котором установлен XRDP. Чтобы узнать IP-адрес, необходимо в терминале ввести команду:
sudo ip a
На моём скриншоте обведён IP-адрес виртуальной машины с Ubuntu 20.04, который автоматически присвоен сетевому интерфейсу eth1. Сетевых интерфейсов может быть несколько, у каждого из них могут быть свои IP-адреса, к которым так же можно подключаться по RDP.
Шаг 5. Проверка подключения
Стандартный клиент RDP для Windows называется Подключение к удалённому рабочему столу. В нем необходимо ввести IP-адрес или имя сервера, можно указать логин и пароль для входа в удалённую машину, настроить различные параметры взаимодействия.
На скриншоте ниже можно видеть окно для входа Xorg, куда требуется ввести логин, в моем случае user и пароль, в моем случае 1. Для смены раскладки клавиатуры в Ubuntu 20.04 используется комбинация клавиш Super+Пробел (с моей клавиатуры клавиши Windows + Пробел). Если в окне раскладка не меняется, и вводится пароль не на том языке, то необходимо отключить клиент RDP, закрыть его, поменять язык в Windows на нужный и снова подключиться к удалённой машине.
Настройка XRDP Ubuntu 20.04 практически завершена.
Для исправления такой ошибки необходимо внести изменение в файл, расположенный в папке /etc/xrdp, запускающий каждую сессию удалённого доступа XRDP с именем startwm.sh:
Внесите изменения в файле startwm.sh:
unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR
Перед строкой:
test –x /etc/X11/Xsession && exec /etc/X11/Xsession
как показано на скриншоте. Это обнуляет системные переменные, сформированные предыдущими сеансами. В результате, мы избавляемся от чёрного экрана при подключении по RDP к Ubuntu 20.04
После внесения изменений необходимо перезапустить службу XRDP:
sudo systemctl restart xrd
И можно выполнить подключение к Ubuntu по RDP:
Выводы
Сегодня мы выяснили как подключиться к Ubuntu по RDP и настроить XRDP сервер. Клиенты RDP существуют для любого устройства: телефона, планшета, ноутбука, любого компьютера. Местонахождение этой виртуальной или реальной машины с Ubuntu 20.04 теперь не играет никакой роли, лишь бы был доступ к ней через интернет и установлен и настроен XRDP.
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна .
В свойствах сисемы при разрешении доступа по терминалу выбери доступ без проверки подлинности на уровне сети.
Источник
Linux xrdp ошибка проверки подлинности
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.
Как выглядит ошибка credssp
Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:
Ну и конечно в русском исполнении:
Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.
Назначение CredSSP
Что такое CredSSP — это Win32 API, используемый системами Microsoft Windows для выполнения различных операций, связанных с безопасностью, таких как аутентификация. SSPI функционирует, как общий интерфейс для нескольких поставщиков поддержки безопасности (SSP). Поставщик поддержки безопасности — это библиотека динамической компоновки (DLL), которая делает один или несколько пакетов безопасности доступными для приложений.
C redSSP позволяет приложению делегировать учетные данные пользователя от клиента целевому серверу для удаленной аутентификации. CredSSP предоставляет зашифрованный канал протокола безопасности транспортного уровня . Клиент проходит проверку подлинности по зашифрованному каналу с использованием протокола SPNEGO (Simple and Protected Negotiate) с Microsoft Kerberos или Microsoft NTLM.
После проверки подлинности клиента и сервера клиент передает учетные данные пользователя на сервер. Учетные данные дважды шифруются с использованием ключей сеанса SPNEGO и TLS. CredSSP поддерживает вход в систему на основе пароля, а также вход в систему с использованием смарт-карт на основе X.509 и PKINIT.
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) — обеспечивает одноранговую аутентификацию с использованием цифровых сертификатов между системами, которые не являются частью домена.
Причины ошибки шифрования CredSSP
В марте 2018 года, компания Microsoft выпустила обновление безопасности для устранения уязвимостей для протокола поставщика поддержки безопасности учетных данных (CredSSP) под именем CVE-2018–0886 (https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018), используемого подключениями по протоколу удаленного рабочего стола (RDP) для клиентов Windows и Windows Server. Как только пользователи и системные администраторы произвели установку апдейтов, то по всему миру начались массовые жалобы, что люди не могут подключаться по протоколу RDP к серверам, компьютерам, получая ошибку, что причиной ошибки может быть шифрование CredSSP.
К сожалению 99% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.
Под раздачу попали буквально все, клиентские ОС Windows 7, Windows 8.1, Windows 10 с которых были попытки подключиться к RDS ферме или RemoteApp приложениям работающим на Windows Server 2008 R2 и выше. Если бы вы читали ветки обсуждений в эти дни, то вы бы поняли все негодование людей, особенно с запада.
Варианты исправления ошибки CredSSP
На самом деле вариантов много, есть правильные, есть и временные и обходные, которые нужно сделать быстро, чтобы хоть как-то работало, так как бизнес может в этот момент простаивать и терять деньги.
- Вы можете удалить новое обновление безопасности, самый плохой вариант, но в ответственные моменты, иногда используется, чтобы перенести работы на вечер или ночь
- Если нужно быстро получить доступ к серверу и избежать проверку подлинности credssp, то я вам советую отключить на принимающем подключении сервере галку NLA (Network Level Authentication) в русском варианте «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
- То же быстрый метод и на массовое применение, это использование групповой политики, которая изменит шифрование Oracle Remediation
- Ну и самый правильный метод , это установка обновлений на все ваши системы
Отключаем credssp в Windows через NLA
Данный метод выхода из ситуации я бы рассматривал, как быстрое, временное решение, до того, как вы установите обновления безопасности. Чтобы разрешить удаленное подключение к серверу и избегать ситуации, что произошла ошибка при проверке подлинности credssp, сделайте вот что. Откройте свойства моего компьютера, попав в систему, так же можно нажать одновременно WIN+Pause Breake или как вариант в командной строке ввести control /name Microsoft.System. В окне «Система» находим пункт меню «Настройка удаленного доступа»
Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:
- Использовать сетевой реестр Windows
- Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.
Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».
Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.
У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSPParameters, то нужно будет их создать):
Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.
Или можно так же отключить NLA, для этого найдите ветку реестра:
Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.
Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:
w10-cl01 — это имя компьютера.
Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:
Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:
Еще раз обращаю ваше внимание, что данный метод временный и самый не безопасный, применяемый в случаях, когда уже ничего сделать нельзя или дольше, а нужно уже вчера, обязательно установите все нужные обновления.
Отключаем шифрование credssp через GPO
Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.
Напоминаю, что оснастку управление групповой политикой вы можете найти на контроллере домена или компьютере с установленным пакетом RSAT, открыть ее можно через команду в окне «Выполнить» gpmc.msc. Если нужно открыть локальный редактор групповых политик, то в окне «Выполнить» введите gpedit.msc.
Вам необходимо перейти в ветку:
Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:
- Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
- Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
- Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.
Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.
После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра
На просторах интернета ходит скрипт PowerShell, который поможет включить данную политику на всех компьютерах в Active Directory
Import-Module ActiveDirectory
$PSs = (Get-ADComputer -Filter *).DNSHostName
Foreach ($computer in $PCs) <
Invoke-Command -ComputerName $computer -ScriptBlock <
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
>
>
Самый правильный метод, это установка обновлений
Когда вам удалось везде подключиться и подошло время обслуживания ваших серверов, быстренько производим установку обновлений закрывающих брешь (CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability).
Раньше были вот такие KB, но они со временем могут меняться свой номер, поэтому пройдите по ссылке выше, так будет надежнее.
- 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
Источник
Adblock
detector
Содержание
- Предпосылки
- Шаг 1: Установите Xrdp на Ubuntu 20.04
- Установите Xrdp на Ubuntu
- Шаг 2: Настройка Xrdp на Ubuntu 20.04
- Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента
- Как исправить черный экран XRDP в Ubuntu
- Заключение
Xrdp — это аналог протокола Microsoft Remote Desktop Protocol (RDP). Если xrdp установлен в системе Linux, пользователи могут удаленно получить доступ к рабочему столу Linux с помощью RDP-клиента. Все это я покажу в этой статье. Его можно совершенно бесплатно скачать и использовать.
Без лишних слов давайте давайте приступим к установке Xrdp на Ubuntu Desktop 20.04 и 18.04.
Предпосылки
В этом руководстве предполагается, что у вас уже установлена Ubuntu 20.04 или Ubuntu 18.04. Если у вас есть минимальная установка без графического интерфейса – то рекомендуется установить среду рабочего стола или GNOME.
Чтобы установить среду рабочего стола Ubuntu, выполните команду:
$ sudo apt install ubuntu-desktop
Шаг 1: Установите Xrdp на Ubuntu 20.04
Для начала запустите терминал и выполните следующую команду для установки Xrdp в вашу систему.
$ sudo apt install xrdp
Когда появится запрос, просто нажмите 'Y'
, а далее нажмите enter, чтобы продолжить установку.
Установите Xrdp на Ubuntu
Служба Xrdp запускается автоматически после установки. Для проверки работоспособности сервиса XRDP, выполнив команду:
$ sudo systemctl status xrdp
Данные которые вы видите на рисунке подтверждают, что сервис XRDP работает.
Шаг 2: Настройка Xrdp на Ubuntu 20.04
При установке Xrdp ключ SSL сертификата ssl-cert-snakeoil. key помещается в папку /etc/ssl/private/. Нам требуется добавить пользователя xrdp в группу ssl-cert, чтобы сделать файл читаемым для пользователя. Это можно сделать командой:
$ sudo adduser xrdp ssl-cert
Xrdp прослушивает порт 3389 и если вы находитесь за брандмауэром UFW, то вам нужно открыть порт. Это делается для того чтобы разрешить входящий трафик от клиентов RDP. В этом примере я разрешу трафик на порт 3389 из всей моей подсети в систему Ubuntu.
$ sudo ufw allow from 192.168.2.0/24 to any port 3389
После этого требуется перезагрузить брандмауэр и проверить, открыт ли порт.
$ sudo ufw reload
$ sudo ufw status
Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента
На этом шаге мы попробуем подключится к системе Ubuntu из Windows 10. В этом нам поможет стандартный клиент удаленного рабочего стола (RDP). Но прежде чем продолжить, убедитесь что вы вышли из Ubuntu 20.04. Так как Xrdp поддерживает только один Xsession.
- Запустите RDP клиент на Windows
- Введите IP-адрес удаленной системы
- Нажмите кнопку «Подключиться«.
В окне которое требует проверку удаленной системы, игнорируйте ошибки сертификата и нажмите на кнопку «Далее«.
На странице входа в систему Xrdp введите свои учетные данные и нажмите кнопку «Ok«.
Примечание: в этот момент Вы можете столкнуться с пустым черным экраном вместо фона рабочего стола Ubuntu. Лично я столкнулся с таким багом. После долгих мучений, я нашел вариант как исправить этот баг.
Как исправить черный экран XRDP в Ubuntu
Решение довольно простое. Откройте Ubuntu и отредактируйте /etc/xrdp/startwm.sh сценарий.
$ sudo vim /etc/xrdp/startwm.sh
Добавьте эти строки непосредственно перед строками, которые тестируют и выполняют Xsession, как показано на скриншоте ниже.
unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR
Далее требуется сохранить файл и выйдите. Не забудьте перезапуститm службу Xrdp.
$ sudo systemctl restart xrdp
Затем повторно подключитесь. После первоначальной аутентификации вам потребуется пройти повторную аутентификацию, как показано на рисунке.
Введите свои учетные данные и нажмите кнопку «аутентификация«.После проделанного в перейдете на экран стола удаленной системы Ubuntu.
Заключение
Ну вот и все, в этой статье вы узнали Как установить Xrdp на Ubuntu 20.04. Это совсем не сложно и это может сделать даже новичок Linux. Если у вас что-то не получилось или вы нашли ошибку, оставьте комментарий.
Hello world,
In a previous post (xRDP – New “Authentication Required…” Popup showing up in Ubuntu 19.04), we have discussed about a minor issue that has been introduced with the release of Ubuntu 19.04. After installing xRDP on top of Ubuntu 19.04 operating system, and when performing the remote connection, you would notice that a authentication popup is showing up. This popup will be showing up each time you perform a remote connection to your Ubuntu machine.
The issue was similar to the “infamous Authentication required to create managed color device” and same approach would be used to fix this new annoying popup dialog box. However, we have found that the proposed solution in our previous post (xRDP – New “Authentication Required…” Popup showing up in Ubuntu 19.04) was actually introducing a new issue. This issue was basically preventing software installation from remote sessions.
After some investigations, we have been able to identify the issue and we are now writing up a new post that would explain what to do in order to fix both issues (the authentication popup and the no permissions to perform software installation within remote Session.)
So, let’s quickly tackle this….
Note : xrdp-installer-1.0.sh script already contains the fix and you can use the script to automate xRDP installation and provide the best remote session experience to your users…
Reminder – Quick Problem Description
All Ubuntu Releases
If you are using xRDP on top of Ubuntu for a long time, you probably remember the infamous authentication popup annoyance (see here). If you have performed a manual installation of xRDP package on Ubuntu, when performing your remote connection, you would see an annoying authentication popup showing up. You can decide to enter your credentials or dismiss the popup but chances are that you will be prompted two or three times and the popup will be displayed again. This popup would appear each time that you perform a remote connection to your Ubuntu machine.
Click on picture for better Resolution
Luckily, this issue is well known and we already provided a fix for it. You can find more information about this issue and the solution in the following posts
- xRDP – The Infamous “Authentication Required to create Managed color device” Explained
- xRDP – How to Fix the Infamous system crash popups in Ubuntu 18.04 (and previous versions)
If you are using our famous xRDP installation scripts, you do not need to perform these actions as they are carried out by the script. Our scripts is basically taking care of most of annoyances a user can get when performing a remote connection to Ubuntu through xRDP.
Ubuntu 19.04 Release and later
Since the release of Ubuntu 19.04, when installing xRDP software on top of it, a new authentication popup is showing up when performing a remote desktop connection. The new authentication popup is showing the following message
Authentication required to refresh system repositories.
This issue, started to show up in Ubuntu 19.04. Ubuntu 19.10, is also behaving in a similar way.
Click on picture for better Resolution
We initially tackled this issue in the following post but this solution is generating another side effect. So, we have been working hard to find what was causing the side effect. After some investigations, we found out what the problem was and we are providing the correct way to fix this issue in this post. Keep reading and jump to the solution section….
Fixing the issue the proper way….
Based on our previous posts about these kind of issues (see here, here and here), we know that the problem is related to Polkit technology used within Ubuntu operating system. Polkit check if a user is authorized to perform a certain number of actions. Different Polkit rules are being applied when a user is logged on locally on a machine or when remotely connected to the system. Basically, when remotely connected, the Polkit rules are more restrictive and we need to create exceptions in order for the user to perform actions that would not prompt for authentication dialog box when locally connected on a computer.
To create these polkit exceptions, we will need to create some additional files that would override the default authorization rules. These files needs to be created in the following location ( you need to have admin rights to copy/create files in this location !!!)
/etc/polkit-1/localauthority/50-local.d/
We already know that to fix the “Authentication required to create managed color device” popup, we simply have created a file called 45-allow-colord.pkla and populate it with the following content.
[Allow Colord all Users] Identity=unix-user:* Action=org.freedesktop.color-manager.create-device;org.freedesktop.color-manager.create-profile;org.freedesktop.color-manager.delete-device;org.freedesktop.color-manager.delete-profile;org.freedesktop.color-manager.modify-device;org.freedesktop.color-manager.modify-profile ResultAny=no ResultInactive=no ResultActive=yes
You should create this file on machines running Ubuntu 16.04 and later in order to avoid the authentication color device popup to show up. Again, as a reminder, using our famous installation script, this file will be created automatically for you and you should not experience the issue.
The pkla file above only fixes the manage color device popup dialog box. To fix the “Infamous Authentication required to refresh system repositories”, we will be creating another polkit exception file that we have called 46-allow-update-repo.pkla (also saved under /etc/polkit-1/localauthority/50-local.d). This file should contains the following information
[Allow Package Management all Users] Identity=unix-user:* Action=org.freedesktop.packagekit.system-sources-refresh ResultAny=yes ResultInactive=yes ResultActive=yes
When done, try to perform a remote connection and if everything works as expected, you should have access to your remote desktop with no “Authentication Required popup” showing up. You are basically ready to work with no more annoying popups.
Compared to the previous fix, we simply simplified the polkit exception file and we are tackling only the system-sources-refresh rules with the new *.pkla file presented here above. This action has basically fixed the authentication issue but also allows now users to perform software installation from software center within their remote session…. Please note that this specific file should be only created on Ubuntu 19.04 and later as previous versions of Ubuntu does not present such issue….
Final Notes
This is it for this post !
Based on user feedback and customer feedback, we have been able to identify a minor issue that was preventing users to perform software installation through software center. In this post, we have been specifically tackling the authentication popups that would show up on Ubuntu machines if no polkit exception files were not created. This post was focusing on the new Authentication popup showing up in Ubuntu 19.04 and later and how to deal correctly with it.
The proper fix has been implemented in the new xrdp-installer-1.0.sh script only !!! From now on, you should be only using a single script in order to perform either a standard installation or a custom installation of xRDP on top of Ubuntu 16.04 or later…. You should now be able to enjoy your remote connection to Ubuntu with no annoying popups showing up and with the possibility to install software from software center in the similar way you would do as if logged on locally….. Enjoy !
The coming post will quickly cover the software install issue….so everybody knows about the issue and the fix…
Till next time
See ya
References :
- xRDP – The infamous “ahtnetication Required to Create Managed color device explained
- xRDP – How to fix the infamous system crash popups in Ubuntu 18.04 (and previous version)
- xRDP – New “Authentication Required…” Popup showing up in Ubuntu 19.04
1. Remove previously installed xrdp:
$ sudo systemctl disable xrdp
$ sudo systemctl stop xrdp
$ sudo apt purge xrdp
$ sudo apt purge xserver-xorg-core
$ sudo apt purge xserver-xorg-input-all
$ sudo apt purge xorgxrdp
2. Re-install xrdp & required packages:
$ sudo apt install xrdp
$ sudo apt install xserver-xorg-core
$ sudo apt install xserver-xorg-input-all
$ sudo apt install xorgxrdp
You also need to grant access to the /etc/ssl/private/ssl-cert-snakeoil.key file for xrdp user. It is available to members of the ssl-cert group by default.
$ sudo adduser xrdp ssl-cert # add xrdp into ssl-cert group
$ sudo systemctl start xrdp # start xrdp service
$ systemctl is-active xrdp # check xrdp state
...
active
$ sudo systemctl enable xrdp # start xrdp on system start
3. Reboot system:
$ sudo reboot
4. Firewall configuration:
You need to open access on port 3389.
$ sudo ufw allow 3389
It is more secure to open it only for your IP address or network. For example:
$ sudo ufw allow from 10.5.5.0/24 to any port 3389
The best practice is to use an SSH tunnel to connect to the remote desktop and make xRDP listen only for local connections.
5. Setup your RDP-client
Please note that in some cases the user who will connect to xRDP must log out before doing so!
- Connect to your server using any RDP client.
- Enter the user credentials of your Ubuntu computer.
- Now you can see the remote desktop initial screen.
Related commands:
$ sudo systemctl status xrdp # display current xrdp status
$ sudo systemctl start xrdp # start xrdp service
$ sudo systemctl stop xrdp # stop xrdp service
$ sudo systemctl restart xrdp # restart xrdp service
$ sudo systemctl enable xrdp # enable xrdp on system start
$ sudo systemctl disable xrdp # disable xrdp on system start
Содержание
- Предпосылки
- Шаг 1: Установите Xrdp на Ubuntu 20.04
- Установите Xrdp на Ubuntu
- Шаг 2: Настройка Xrdp на Ubuntu 20.04
- Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента
- Как исправить черный экран XRDP в Ubuntu
- Заключение
Xrdp — это аналог протокола Microsoft Remote Desktop Protocol (RDP). Если xrdp установлен в системе Linux, пользователи могут удаленно получить доступ к рабочему столу Linux с помощью RDP-клиента. Все это я покажу в этой статье. Его можно совершенно бесплатно скачать и использовать.
Без лишних слов давайте давайте приступим к установке Xrdp на Ubuntu Desktop 20.04 и 18.04.
Предпосылки
В этом руководстве предполагается, что у вас уже установлена Ubuntu 20.04 или Ubuntu 18.04. Если у вас есть минимальная установка без графического интерфейса – то рекомендуется установить среду рабочего стола или GNOME.
Чтобы установить среду рабочего стола Ubuntu, выполните команду:
$ sudo apt install ubuntu-desktop
Шаг 1: Установите Xrdp на Ubuntu 20.04
Для начала запустите терминал и выполните следующую команду для установки Xrdp в вашу систему.
$ sudo apt install xrdp
Когда появится запрос, просто нажмите 'Y'
, а далее нажмите enter, чтобы продолжить установку.
Установите Xrdp на Ubuntu
Служба Xrdp запускается автоматически после установки. Для проверки работоспособности сервиса XRDP, выполнив команду:
$ sudo systemctl status xrdp
Данные которые вы видите на рисунке подтверждают, что сервис XRDP работает.
Шаг 2: Настройка Xrdp на Ubuntu 20.04
При установке Xrdp ключ SSL сертификата ssl-cert-snakeoil. key помещается в папку /etc/ssl/private/. Нам требуется добавить пользователя xrdp в группу ssl-cert, чтобы сделать файл читаемым для пользователя. Это можно сделать командой:
$ sudo adduser xrdp ssl-cert
Xrdp прослушивает порт 3389 и если вы находитесь за брандмауэром UFW, то вам нужно открыть порт. Это делается для того чтобы разрешить входящий трафик от клиентов RDP. В этом примере я разрешу трафик на порт 3389 из всей моей подсети в систему Ubuntu.
$ sudo ufw allow from 192.168.2.0/24 to any port 3389
После этого требуется перезагрузить брандмауэр и проверить, открыт ли порт.
$ sudo ufw reload
$ sudo ufw status
Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента
На этом шаге мы попробуем подключится к системе Ubuntu из Windows 10. В этом нам поможет стандартный клиент удаленного рабочего стола (RDP). Но прежде чем продолжить, убедитесь что вы вышли из Ubuntu 20.04. Так как Xrdp поддерживает только один Xsession.
- Запустите RDP клиент на Windows
- Введите IP-адрес удаленной системы
- Нажмите кнопку «Подключиться«.
В окне которое требует проверку удаленной системы, игнорируйте ошибки сертификата и нажмите на кнопку «Далее«.
На странице входа в систему Xrdp введите свои учетные данные и нажмите кнопку «Ok«.
Примечание: в этот момент Вы можете столкнуться с пустым черным экраном вместо фона рабочего стола Ubuntu. Лично я столкнулся с таким багом. После долгих мучений, я нашел вариант как исправить этот баг.
Как исправить черный экран XRDP в Ubuntu
Решение довольно простое. Откройте Ubuntu и отредактируйте /etc/xrdp/startwm.sh сценарий.
$ sudo vim /etc/xrdp/startwm.sh
Добавьте эти строки непосредственно перед строками, которые тестируют и выполняют Xsession, как показано на скриншоте ниже.
unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR
Далее требуется сохранить файл и выйдите. Не забудьте перезапуститm службу Xrdp.
$ sudo systemctl restart xrdp
Затем повторно подключитесь. После первоначальной аутентификации вам потребуется пройти повторную аутентификацию, как показано на рисунке.
Введите свои учетные данные и нажмите кнопку «аутентификация«.После проделанного в перейдете на экран стола удаленной системы Ubuntu.
Заключение
Ну вот и все, в этой статье вы узнали Как установить Xrdp на Ubuntu 20.04. Это совсем не сложно и это может сделать даже новичок Linux. Если у вас что-то не получилось или вы нашли ошибку, оставьте комментарий.
Содержание
- Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается — Решение
- В чем суть ошибки проверки подлинности RDP
- Установка апдейта, если указанная функция не поддерживается
- Изменение настроек групповых политик
- Отключение NLA для решения ошибки проверки RPD
- Заключение
- Не удается подключиться по rdp «Ошибка проверки подлинности»
- Как исправить ошибку
- При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.
- Симптомы
- Причина
- Решение
- Произошла ошибка проверки подлинности. Указанная функция не поддерживается
- Ответ
- Отключение NLA для протокола RDP в Windows
- Устранение ошибок проверки подлинности при использовании RDP для подключения к Azure VM
- Симптомы
- Причина
- Перед устранением неполадок
- Создание снимка резервного копирования
- Подключение удаленное доступ к VM
- Клиентская служба групповой политики
- Обходной путь
- Устранение неполадок
- Устранение неполадок в VMs, присоединились к домену
- Устранение неполадок автономных VMs
- Проверка MinEncryptionLevel
- Версия TLS
- Проверка подключений к алгоритмам, совместимым с fiPs
Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается — Решение
При попытке подключения к серверу через протокол удалённого рабочего стола (RPD) пользователь может столкнуться с ошибкой подключения, сопровождающейся сообщением « Произошла ошибка проверки подлинности. Указанная функция не поддерживается ». Возникновение данной проблемы обычно связано с отсутствием необходимых обновлений на ПК клиента. А также рядом настроек на машинах сервера или клиента, блокирующих отдалённое подключение к ПК. Разберём, что является причиной проблемы, и как её исправить.
Уведомление об дисфункции при проверке подлинности
В чем суть ошибки проверки подлинности RDP
Сценарий использования уязвимости
В апреле «Майкрософт» выпустила следующий апдейт, снабжающий пользователя более детальной информацией об ошибке во время использования клиента удалённого рабочего стола (RDP).
В мае 2018 года вышел финальный Update, изменяющий настройки сессии RDP c использованием CredSSP по умолчанию с « Vulnerable » (Уязвимый) до « Mitigated » (Смягчённый). Также это означало, что любое клиентское приложение, задействующее «CredSSP», будет невозможно откатить до небезопасной версии.
Если ваша рабочая станция получила майское обновление, а сервер его не получал, тогда рабочая станция (клиент) будет отображать сообщение об ошибке при попытке подключения к серверу с использованием RDP.
Разберём перечень способов, позволяющих эффективно избавиться от проблемы проверки подлинности RDP.
Установка апдейта, если указанная функция не поддерживается
Соответственно, основным способом, позволяющим исправить ошибку проверки подлинности RPD, является установка необходимого обновления ( CVE-2018-0886 ) как на клиентскую, так и на серверную ОС.
Выберите свою версию OS из списка снизу, и установите на вашу машину необходимый ей апдейт CVE-2018-0886:
Также можно перейти на сайт Майкрософта (при необходимости поставьте галочку и нажмите «Accept»), слева отыскать версию вашей системы (если не знаете, нажмите Win+Pause). Далее нажать справа на « Security Update », после чего вы получите возможность скачать нужное обновление.
Изменение настроек групповых политик
Если вы по каким-либо причинам не можете установить требуемые апдейты, существует паллиативное решение проблемы проверки подлинности RPD, состоящее в изменении настроек групповых политик. Не рекомендуется рассматривать его как основной вариант, так как таким образом вы сохраняете уязвимость вашей системы для действий злоумышленников.
Установите указанные параметры
Также вы можете осуществить данную операцию с помощью специальной команды, выполненной в командной строке с правами админа:
REG ADD HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
Отключение NLA для решения ошибки проверки RPD
Ещё одним способом решить ошибку проверки подлинности RPD является отключение NLA (аутентификации на уровне сети).
Заключение
Появление сообщения «Произошла ошибка проверки подлинности RDP. Указанная функция не поддерживается» обычно связано с отсутствием на ПК (обычно клиентском) необходимого обновления CVE-2018-0886, позволяющего ликвидировать ряд уязвимостей в системе. Необходимо установить требуемые обновления для вашей системы, а если такое временно невозможно – просто переключите параметр шифрующего оракула на «Vulnerable» (т.е. «Оставить уязвимость»), что позволит решить ошибку.
Источник
Не удается подключиться по rdp «Ошибка проверки подлинности»
При подключение к удаленному компьютеру по RDP возникают различные проблемы и ошибки. Их достаточно много и решаются все они по разному. Сегодня разберем наверно самую популярную ошибку которая связанная с проверкой подлинности.
Как исправить ошибку
И так при попытке подключения к удаленному рабочему столу вы видите сообщение.
Произошла ошибка при проверки подлинности
Указанная функция не поддерживается
Удаленный компьютер 192.168.0.0
Причиной ошибки может быть исправление шифрования CredSSP
Дополнительную информацию смотрите в статье …
Для её решение необходим на компьютере к которому не удается подключиться изменить групповую политику. Для этого нажимаем Win + R вводим gpedit.msc.
Откроется редактор групповой политики. В нем необходимо открыть раздел «Безопасность». Путь до него такой «Конфигурация компьютера» — «Административные шаблоны» — «Компоненты Windows» — «Службы удаленных рабочих столов» — «Узел сеансов удаленных рабочих столов» — «Безопасность».
Тут открываем политику «Требовать проверку подлинности пользователя …»
Дальше открывает политику «Требовать использования специального уровня…», включаем и в пункте «Уровень безопасности выбираем» RDP.
Пробуем подключиться к удаленному рабочему столу. Если вы все сделали правильно то должны без проблем подключиться.
Источник
При подключении к серверу терминала, который работает Windows Server 2008 или Windows Server 2008 R2, вы получаете различные сообщения об ошибках, связанных с сертификатом.
В этой статье предоставляется решение для различных сообщений об ошибках, связанных с сертификатом, при подключении к серверу терминала.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 2000960
Симптомы
При подключении к серверу терминала, который работает Windows Server 2008, или удаленному настольному серверу, который работает Windows Server 2008 R2, вы получаете одно из следующих сообщений об ошибке.
Подключение удаленного рабочего стола не удалось из-за невозможности проверки подлинности удаленного компьютера
Удаленный компьютер не удалось проверить подлинность из-за проблем с сертификатом безопасности. Продолжить работу может быть небезопасно.
Несоответствие имен
Запрашивается удаленный компьютер
Имя в сертификате
Ошибки сертификата
При проверке сертификата удаленного компьютера были допущены следующие ошибки: имя сервера в сертификате неверно.
Невозможно продолжить, так как требуется проверка подлинности.
Невозможно проверить удостоверение удаленного компьютера. Вы хотите подключиться в любом случае?
Удаленный компьютер не удалось проверить подлинность из-за проблем с сертификатом безопасности. Продолжить работу может быть небезопасно.
Несоответствие имен
Запрашивается удаленный компьютер
Имя в сертификате
Ошибки сертификата
Имя сервера в сертификате неверно
сертификат не из доверенного органа сертификации.
Вы хотите подключиться, несмотря на эти ошибки сертификата?
Причина
Проблема возникает из-за неправильного сертификата, который используется для сеанса сервера терминала или удаленного рабочего стола.
Решение
Ниже ниже 1000 действий по проверке выбранного сертификата.
Источник
Произошла ошибка проверки подлинности. Указанная функция не поддерживается
После установки обновления 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 приложений.
Почему это происходит? Дело в том, что на вашем компьютере установлены актуальные обновления безопасности (выпущенные после мая 2018 года), в которых исправляется серьёзная уязвимость в протоколе CredSSP (Credential Security Support Provider), использующегося для аутентификации на RDP серверах (CVE-2018-0886) (рекомендую познакомится со статьей Ошибка RDP подключения: CredSSP encryption oracle remediation). При этом на стороне RDP / RDS сервера, к которому вы подключаетесь со своего компьютера, эти обновления не установлены и при этом для RDP доступа включен протокол NLA (Network Level Authentication / Проверку подлинности на уровне сети). Протокол NLA использует механизмы CredSSP для пре-аутентификация пользователей через TLS/SSL или Kerberos. Ваш компьютер из-за новых настроек безопасности, которые выставило установленное у вас обновление, просто блокирует подключение к удаленному компьютеру, который использует уязвимую версию CredSSP.
Что можно сделать для исправления эту ошибки и подключиться к вашему RDP серверу?
Отключение 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) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.
Источник
Устранение ошибок проверки подлинности при использовании RDP для подключения к Azure VM
В этой статье можно устранить ошибки проверки подлинности, которые возникают при подключении к виртуальной машине Azure (VM) с помощью подключения к протоколу удаленного рабочего стола (RDP).
Симптомы
Вы запечатлете снимок экрана azure VM, который показывает экран Welcome и указывает, что операционная система запущена. Однако при попытке подключения к VM с помощью удаленного подключения к рабочему столу вы получаете одно из следующих сообщений об ошибке:
Причина
Существует несколько причин, по которым NLA может заблокировать доступ RDP к VM:
Перед устранением неполадок
Создание снимка резервного копирования
Чтобы создать снимок резервного копирования, выполните действия в Моментальный снимок диска.
Подключение удаленное доступ к VM
Чтобы подключиться к VM удаленно, используйте один из методов в How to use remote tools to troubleshoot Azure VM issues.
Клиентская служба групповой политики
Если это VM, присоединившись к домену, сначала остановите клиентскую службу групповой политики, чтобы предотвратить переоценку изменений в политике Active Directory. Для этого выполните следующую команду.
После решения проблемы восстановим возможность этого VM связаться с доменом для получения последнего GPO из домена. Для этого запустите следующие команды:
Если изменение возвращается, это означает, что из-за политики Active Directory возникает проблема.
Обходной путь
В качестве работы по подключению к VM и устранению причины можно временно отключить NLA. Чтобы отключить NLA, используйте нижеугодные команды или используйте DisableNLA скрипт в командной таблице Run.
Затем перезапустите VM и перезапустите раздел устранения неполадок.
После решения проблемы повторно включить NLA, запустите следующие команды, а затем перезапустите VM:
Устранение неполадок
Устранение неполадок в VMs, присоединились к домену
Чтобы устранить эту проблему:
Чтобы проверить состояние dc, можно использовать другой VM, который находится в том же VNET, подсети и использует тот же сервер logon.
Подключение к VM, который имеет проблемы с помощью последовательной консоли, удаленной CMD или удаленной PowerShell,в соответствии с шагами в Подключение в раздел VM удаленно.
Определите dc, к который пытается подключиться VM. выполнить следующую команду в консоли:
Проверьте состояние защищенного канала между VM и DC. Для этого запустите Test-ComputerSecureChannel команду в экземпляре PowerShell с повышенными уровнями. Эта команда возвращает True или False, указывающее, жив ли защищенный канал:
Если канал не работает, запустите следующую команду для его восстановления:
Убедитесь, что пароль учетной записи компьютера в Active Directory обновляется в VM и DC:
Если связь между dc и VM хороша, но dc недостаточно здорова для открытия сеанса RDP, можно попытаться перезапустить dc.
Если предыдущие команды не исправят проблему связи с доменом, вы можете повторно войдлять этот VM в домен. Для этого выполните следующие действия:
Создайте сценарий с именем Unjoin.ps1 с помощью следующего контента, а затем развернйте сценарий в качестве настраиваемой расширения скрипта на портале Azure:
Этот скрипт принудительно удаляет VM из домена и перезапускает VM через 10 секунд. Затем необходимо очистить объект Computer на стороне домена.
После очистки снова вступай в этот VM в домен. Для этого создайте сценарий с именем JoinDomain.ps1 с помощью следующего контента, а затем разместим сценарий в качестве настраиваемой расширения скрипта на портале Azure:
Это присоединяется к VM на домене с помощью указанных учетных данных.
Если канал Active Directory здоров, пароль компьютера обновляется, а контроллер домена работает, как и ожидалось, попробуйте следующие действия.
Если проблема сохраняется, проверьте отключение учетных данных домена. Для этого откройте окно командной подсказки, а затем запустите следующую команду, чтобы определить, настроен ли VM для отключения учетных записей домена для входа в VM:
Если для ключа установлено значение 1, это означает, что сервер был настроен не для того, чтобы разрешить учетные данные домена. Измените этот ключ на 0.
Устранение неполадок автономных VMs
Проверка MinEncryptionLevel
В экземпляре CMD запустите следующую команду для запроса значения реестра MinEncryptionLevel:
Исходя из значения реестра, выполните следующие действия:
4 (FIPS): Проверьте подключения алгоритмов, совместимых с fiPs.
3 (128-битное шифрование): Установите степень серьезности до 2, выстроив следующую команду:
2 (максимально возможное шифрование, как это продиктовывает клиент): вы можете попытаться установить шифрование до минимального значения 1, задав следующую команду:
Перезапустите VM, чтобы изменения в реестре вступили в силу.
Версия TLS
В зависимости от системы RDP использует протокол TLS 1.0, 1.1 или 1.2 (сервер). Чтобы узнать, как эти протоколы настроены в VM, откройте экземпляр CMD и запустите следующие команды:
Если возвращенные значения не все 1, это означает, что протокол отключен. Чтобы включить эти протоколы, запустите следующие команды:
Для других версий протокола можно выполнить следующие команды:
Получите версию SSH/TLS x.x из журналов гостевой оси на ошибках SCHANNEL.
Проверка подключений к алгоритмам, совместимым с fiPs
Удаленный рабочий стол может применяться для использования только подключений алгоритмов, совместимых с FIPs. Это можно установить с помощью ключа реестра. Для этого откройте окно командной подсказки, а затем запросив следующие клавиши:
Если команда возвращает 1, измените значение реестра на 0.
Проверьте, какой является текущий MinEncryptionLevel в VM:
Если команда возвращает 4, измените значение реестра на 2
Перезапустите VM, чтобы изменения в реестре вступили в силу.
Источник
Всем привет!
Практически все вы уже знакомы с советниками на форекс и многие из вас их применяют на своих демо или реальных счетах. Чаще всего для удобства многие используют VPS сервисы, как платные, так и бесплатные, слабенькие сервисы, которые оптимизируют определенным способом под работу терминалов.
Если вы регулярно обновляете свою операционную систему, то вы, скорее всего, установили и обновление от 8 мая 2018 года, после чего, возможно, не смогли подключаться к вашим терминалам на ВПС, как раньше из-за сообщения:
«Произошла ошибка при проверке подлинности….»
Как справиться с этой проблемой — в нашем сегодняшнем материале.
Также большинство из вас используют на своих компьютерах операционную систему Windows и подключаются к своему серверу при помощи утилиты «Подключение к удаленному рабочему столу».
Но дело в том, что если вы регулярно обновляете свою систему, то вы, скорее всего, уже столкнулись вот с такой проблемой:
«Произошла ошибка при проверке подлинности.
Указанная функция не поддерживается
Удаленный компьютер:
Причиной ошибки может быть исправление шифрования CredSSP.»
При попытках подключения к VPS, скорее всего, вы видите такую ошибку.
Нужно ли вообще обновлять Windows?
Кто-то после покупки нового компьютера или переустановки операционной системы сразу же выключает автоматические обновления, считая их ненужными. Кто-то постоянно устанавливает последние системные обновления, думая, что они обязательны для безопасности и стабильной работы Windows. Кто же прав?
Действительно, обновления системы позволяют быть более защищенным от различных программ-шпионов. С новыми обновлениями Microsoft выпускают улучшенную защиту, закрывая различные «дыры» в операционной системе, через которые могут проникнуть вредоносные программы. И если у вас недостаточно мощный антивирус, либо его нет вообще и вы не обновляете систему, то риск, что на ПК проникнет вирус, очень высок.
С новыми обновлениями выпускаются и различные исправления багов в системе. Если не обновлять систему, то через какое-то время можно заметить ухудшение производительности компьютера: различные лаги и торможения в системе, замедленная работа «тяжелых» программах (типа Photoshop, 3DMax и так далее), а еще глюки в терминалах и различных играх. С помощью обновлений многие такие проблемы, которые появляются по вине неисправности системы — исчезают.
В центре обновлений системы можно включить автоматическую установку новых компонентов Windows. Плюс здесь в том, что они вас не будут тревожить и устанавливаются автоматически.
Теперь, для объективности, несколько слов о минусах. И самых главный минус обновлений – это огромное разнообразие компьютерного оборудования. Разработчики системы не могут, даже при всем желании, выпускать обновления, которые бы работали одинаково хорошо у всех пользователей. На одной аппаратной конфигурации обновления будут отлично устанавливаться и работать, а на другой – приведут к полному отказу системы и критической ошибке BSOD (т.н. синий экран) при включении компьютера. Отсюда следует вывод: любые обновления для системы несут потенциальную угрозу для её работы. Из-за «кривых» обнов компьютер может потерять в производительности, а в некоторых случаях и вовсе перестанет загружаться.
Мой совет тут очень прост — устанавливайте обновления только в том случае, если они вам реально необходимы. Если для запуска какой-то программы требуется определенное обновление, то эти приложения обычно сами сообщат, что конкретно требуется. Вы же сможете выборочно поставить только то, что нужно. Во всех остальных случаях работает главное правило админа: «работает – не лезь». Если ваш компьютер стабильно работает без глюков и зависаний, а все установленные программы шустро выполняют свои задачи – обновляться не обязательно.
Я уже обновил ОС и получил ошибку при подключении. Что теперь?
Сегодня мы рассмотрим целых три способа исправления этой ошибки. Первый способ — является наиболее правильным и именно его необходимо использовать, в случае, если вы столкнулись с данной проблемой. Второй и третий способ, хоть и позволяют убрать ошибку, но пользоваться ими стоит, только если нет возможности установить патч.
Способ 1: Установка обновления для исправления шифрования CreedSSP
Причиной данной ошибки является отсутствие обновления CVE-2018-0886 на стороне сервера или того компьютера, к которому вы пытаетесь подключиться, используя удаленный рабочий стол (RDP). Для её устранения достаточно просто установить данное обновление на том компьютере, который выступает в роли сервера. Это обновление можно легко найти, просто забив в поисковик его название – «CVE-2018-0886» и выбрав подходящий для вашей операционной системы вариант.
Если этот вариант вам не подойдет и не решит проблему, попробуйте второй способ.
Способ 2: Отключение уведомления об ошибке шифрования CreedSSP через групповые политики
Если же установить обновления по какой-то причине невозможно, то можно отключить данное уведомление об ошибке. Для этого на компьютере, который выступает в роли клиента, проводим следующие действия:
В окне «Выполнить», в «Командной строке» или PowerShell нужно выполнить команду gpedit.msc.
После этого произойдет загрузка консоли управления групповыми политиками:
В ней нужно перейти по следующему пути: Конфигурация компьютера — Административные шаблоны — Система — Передача учетных данных. Для английской версии данный путь выглядит следующим образом: Computer Configuration — Administrative Templates — System — Credentials Delegation:
Открываем параметр «Исправление уязвимости шифрующего оракула» («Encryption Oracle Remediation» в английской версии), и нажимаем «Включено» («Enabled»). Уровень защиты ставим как «Оставить уязвимость» («Vulnerable»).
Нажимаем «ОК», и выходим из управления групповыми политиками.
Если не поможет и это, тогда придется немного поковыряться в реестре.
Способ 3: Отключение уведомления об ошибке шифрования CreedSSP путем правки реестра
В том случае, если в вашей редакции Windows отсутствует редактор групповых политик (например, Windows 10 Домашняя), или же предыдущий способ не решил проблему, то тогда придется внести нужные правки в реестр самостоятельно. Для этого на компьютере, который выступает в роли клиента, проводим следующие действия:
Находим редактор реестра:
Открываем его:
Переходим по следующему пути:
HKLMSoftwareMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters
Ищем параметр DWORD под названием AllowEncryptionOracle, и ставим значение 2. Если такого параметра нет, то создаем его.
Перезагружаем компьютер.
Для тех, кто не хочет возиться с реестром, достаточно просто выполнить команду, приведенную ниже, в командной строке с правами администратора. Делается это еще проще.
Находим cmd:
Включаем:
Копируем эту команду (Ctrl+c):
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
Кликаем правой кнопкой мыши по окну консоли и жмем «Вставить»:
Нажимаем Enter.
Заключение
Как видите — ничего сложного. Один из этих трех способов обязательно должен был подействовать. Ну а решать, обновлять ли операционную систему, или нет — конечно же, только вам. Тем не менее, если вы плохо разбираетесь в компьютерах, я порекомендовал бы вам все же включить автоматическое обновление и заодно поставить хороший антивирус – сейчас довольно большой выбор достойных вариантов даже в бесплатном сегменте.
С уважением, Дмитрий аkа Silentspec
TradeLikeaPro.ru