Xrdp ошибка при проверке подлинности

Содержание

  1. Предпосылки
  2. Шаг 1: Установите Xrdp на Ubuntu 20.04
  3. Установите Xrdp на Ubuntu
  4. Шаг 2: Настройка Xrdp на Ubuntu 20.04
  5. Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента
  6. Как исправить черный экран XRDP в Ubuntu
  7. Заключение

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 на Ubuntu

Проверьте статус Xrdp на Ubuntu

Данные которые вы видите на рисунке подтверждают, что сервис XRDP работает.

Шаг 2: Настройка Xrdp на Ubuntu 20.04

При установке Xrdp ключ SSL сертификата ssl-cert-snakeoil. key помещается в папку /etc/ssl/private/. Нам требуется добавить пользователя xrdp в группу ssl-cert, чтобы сделать файл читаемым для пользователя. Это можно сделать командой:

$ sudo adduser xrdp ssl-cert

Добавить пользователя Xrdp в группу SSL

Добавить пользователя Xrdp в группу SSL

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

Откройте порт Xrdp на брандмауэре Ubuntu

Откройте порт Xrdp на брандмауэре Ubuntu

Шаг 3: Доступ к удаленному рабочему столу Ubuntu с помощью RDP клиента

На этом шаге мы попробуем подключится к системе Ubuntu из Windows 10. В этом нам поможет стандартный клиент удаленного рабочего стола (RDP). Но прежде чем продолжить, убедитесь что вы вышли из Ubuntu 20.04. Так как Xrdp поддерживает только один Xsession.

  1. Запустите RDP клиент на Windows
  2. Введите IP-адрес удаленной системы
  3. Нажмите кнопку «Подключиться«.

Подключение удаленной системы Ubuntu с помощью RDP

Подключение удаленной системы Ubuntu с помощью RDP

В окне которое требует проверку удаленной системы, игнорируйте ошибки сертификата и нажмите на кнопку «Далее«.

Проверка подлинности удаленной системы Ubuntu

Проверка подлинности удаленной системы Ubuntu

На странице входа в систему Xrdp введите свои учетные данные и нажмите кнопку «Ok«.

Введите свои учетные данные для в хода в Ubuntu через RDP

Введите свои учетные данные для в хода в Ubuntu через RDP

Примечание: в этот момент Вы можете столкнуться с пустым черным экраном вместо фона рабочего стола Ubuntu. Лично я столкнулся с таким багом. После долгих мучений, я нашел вариант как исправить этот баг.

Решение довольно простое. Откройте Ubuntu и отредактируйте /etc/xrdp/startwm.sh сценарий.

$ sudo vim /etc/xrdp/startwm.sh

Добавьте эти строки непосредственно перед строками, которые тестируют и выполняют Xsession, как показано на скриншоте ниже.

unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR

Как исправить черный экран XRDP в Ubuntu

Как исправить черный экран XRDP в Ubuntu

Далее требуется сохранить файл и выйдите. Не забудьте перезапуститm службу Xrdp.

$ sudo systemctl restart xrdp

Затем повторно подключитесь. После первоначальной аутентификации вам потребуется пройти повторную аутентификацию, как показано на рисунке.

Аутентификация пользователя XRDP

Аутентификация пользователя XRDP

Введите свои учетные данные и нажмите кнопку «аутентификация«.После проделанного в перейдете на экран стола удаленной системы Ubuntu.

Удаленный Доступ К Рабочему Столу Ubuntu

Удаленный Доступ К Рабочему Столу 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.

manualxrdp_7

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.

manualxrdp_9

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

aCOhrPoejVMAAAAASUVORK5CYII=

Шаг 2. Обновление системы

Такой пакет есть, поэтому вы можете, предварительно обновив систему, простым путём установить xrdp на Ubuntu 20.04. Обновляем и перезагружаем для принятия изменений в ОС:

sudo apt –y update && sudo apt –y upgrade && sudo reboot

BwrmmDYoSnOJAAAAAElFTkSuQmCC

Шаг 3. Установка пакетов

После перезагрузки можно устанавливать XRDP из репозитория Ubuntu 20.04

sudo apt install xrdp

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

ssl_gen_key_xrdp1 ok

DfbbccYc54AAAAAElFTkSuQmCC

Шаг 3. Настройка службы XRDP

В связи с особенностями системы Ubuntu 20.04, необходимо ввести пользователя xrdp, от имени которого работает XRDP в системе, в группу ssl-cert. Выполните команду:

sudo adduser xrdp ssl-cert

Затем добавьте службу xrdp в автозапуск и перезапустите её для применения изменений:

sudo systemct enable xrdp

sudo systemctl restart xrdp

3r3tgckokiLAAAAAElFTkSuQmCC

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

+pQaqmDqAAGAAAAAElFTkSuQmCC

На моём скриншоте обведён IP-адрес виртуальной машины с Ubuntu 20.04, который автоматически присвоен сетевому интерфейсу eth1. Сетевых интерфейсов может быть несколько, у каждого из них могут быть свои IP-адреса, к которым так же можно подключаться по RDP.

Шаг 5. Проверка подключения

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

На скриншоте ниже можно видеть окно для входа Xorg, куда требуется ввести логин, в моем случае user и пароль, в моем случае 1. Для смены раскладки клавиатуры в Ubuntu 20.04 используется комбинация клавиш Super+Пробел (с моей клавиатуры клавиши Windows + Пробел). Если в окне раскладка не меняется, и вводится пароль не на том языке, то необходимо отключить клиент RDP, закрыть его, поменять язык в Windows на нужный и снова подключиться к удалённой машине.

YPPzk8h+9BcAAAAASUVORK5CYII=

Настройка XRDP Ubuntu 20.04 практически завершена.

Ошибка черный экран XRDP в Ubuntu

B8YC4whhvEr+QAAAABJRU5ErkJggg==

Для исправления такой ошибки необходимо внести изменение в файл, расположенный в папке /etc/xrdp, запускающий каждую сессию удалённого доступа XRDP с именем startwm.sh:

n5a4x+AgAAAABJRU5ErkJggg==

Внесите изменения в файле startwm.sh:

unset DBUS_SESSION_BUS_ADDRESS
unset XDG_RUNTIME_DIR

Перед строкой:

test –x /etc/X11/Xsession && exec /etc/X11/Xsession

как показано на скриншоте. Это обнуляет системные переменные, сформированные предыдущими сеансами. В результате, мы избавляемся от чёрного экрана при подключении по RDP к Ubuntu 20.04

w9SurgbSddChAAAAABJRU5ErkJggg==

После внесения изменений необходимо перезапустить службу XRDP:

sudo systemctl restart xrd

И можно выполнить подключение к Ubuntu по RDP:

385ngK0YuG6VgAAAABJRU5ErkJggg==

Выводы

Сегодня мы выяснили как подключиться к Ubuntu по RDP  и настроить XRDP сервер. Клиенты RDP существуют для любого устройства: телефона, планшета, ноутбука, любого компьютера. Местонахождение этой виртуальной или реальной машины с Ubuntu 20.04 теперь не играет никакой роли, лишь бы был доступ к ней через интернет и установлен и настроен XRDP.

Creative Commons License

Статья распространяется под лицензией 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. Для этого вы можете пойти двумя путями:

  1. Использовать сетевой реестр Windows
  2. Использовать удаленное управление компьютером, например 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

Обновлено 25.11.2019

rdp logo

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org, в прошлый раз мы с вами чинили HDD с поврежденной файловой системой и состоянием RAW уверен, что вам удалось это сделать. Сегодня я в очередной раз переведу наш вектор траблшутера в сторону терминальных столов, а именно мы рассмотрим ситуацию, что когда вы пытаетесь  подключиться к удаленному серверу по RDP протоколу, а у вас после ввода логина и пароля, выскакивает ошибка, что вы не прошли проверку подлинности и причиной ошибки может быть исправление шифрования CredSSP. Давайте разбираться, что за зверь, этот CredSSP и как вам получить доступ к вашему серверу.

Как выглядит ошибка credssp

Перед тем, как я покажу вам известные мне методы ее устранения, я бы как обычно хотел подробно описать ситуацию. Вчера при попытке подключиться к своему рабочему компьютеру, работающему на Windows 10 1709, с терминального стола, входящего в RDS ферму на Windows Server 2012 R2, я получил ошибку после ввода логина и пароля:

An authentication error has occurred. The function requested is not supported. Remote computer name. This coild be to CredSSP encryption oracle remediation.

credSSP encryption oracle remediation

Ну и конечно в русском исполнении:

Произошла ошибка при проверке подлинности. Указанная функция не поддерживается. Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP

Причиной ошибки может быть исправление шифрования CredSSP

Получается двоякая ситуация, что RDP как бы работает, но вот по какой-то причине ваши учетные данные на принимающей стороне не соответствуют, каким-то критериям, давайте разбираться, что это за зверь CredSSP.

Назначение CredSSP

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

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

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

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

Windows SSP

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

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

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

Причины ошибки шифрования 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

Уязвимость в протоколе Credential Security Support Provider (CredSSP — провайдер поддержки безопасности учетных данных) допускала удаленный запуск произвольного кода на уязвимой системе и 8 мая 2018 г. Microsoft изменила уровень безопасности подключения с Vulnerable на Mitigated и начались проблемы подключения к удаленному рабочему столу по RDP. Ранее вы могли удаленно подключаться с обновленной машины к машинам без обновления безопасности, так сказать в мягком режиме. Однако с последним обновлением, Microsoft усилила безопасность, и вы больше не можете подключаться к компьютерам без обновления закрывающего брешь CVE-2018–0886.

Под раздачу попали буквально все, клиентские ОС 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. В окне «Система» находим пункт меню «Настройка удаленного доступа»

Отключение NLA для CredSSP

Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол  с проверкой подлинности на уровне сети»

Отключение NLA для CredSSP-2

После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:

  1. Использовать сетевой реестр Windows
  2. Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.

Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».

отключить credssp через реестр Windows

Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.

Подключение сетевого реестра

У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSPParameters, то нужно будет их создать):

HKLMSoftwareMicrosoftWindowsCurrentVersion PoliciesSystemCredSSPParameters

Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.

credssp в реестре windows

Или можно так же отключить NLA, для этого найдите ветку реестра:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl Terminal ServerWinStationsRDP-Tcp

Найдите там ключ SecurityLayeи выставите ему значение 0, чтобы деактивировать Network Level Authentication.

Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:

PsExec.exe \w10-cl01 -u rootАдминистратор -p пароль cmd

w10-cl01 — это имя компьютера.

исправление ошибки credssp windows

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

REG ADD HKLMSoftwareMicrosoftWindows CurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2 (0 вернет все как было)

rdp ошибка credssp

Аналогично можно сделать и для отключения Network Level Authentication, команда будет такой:

REG ADD «HKEY_LOCAL_MACHINESYSTEM CurrentControlSetControlTerminal ServerWinStationsRDP-Tcp» /v SecurityLayer /t REG_DWORD /d 0

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

Отключаем шифрование credssp через GPO

Если у вас большая инфраструктура, в которой сотни компьютеров и сотни серверов, то вы можете до установки нужных обновлений в вечернее время, временно отключить новый уровень шифрования CredSSP и убрать ошибку «Удаленный компьютер имя. Причиной ошибки может быть исправление шифрования CredSSP». Для этого мы можем воспользоваться всеми плюсами доменной инфраструктуры Active Directory. Тут два варианта, вы можете создать массовую политику для распространения ее на нужные OU или если у вас требование для одного или двух локальных компьютеров, то на них можно запустить локальный редактор групповых политик, тем самым внеся изменения только на них.

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

gpedit.msc windows 10

Вам необходимо перейти в ветку:

Конфигурация компьютера — Административные шаблоны — Система — Передача учетных данных — Исправление уязвимости шифрующего оракула (Computer Configuration — Administrative Templates — System — Credentials Delegation — Encryption Oracle Remediation

Исправление уязвимости шифрующего оракула

Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:

  • Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
  • Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
  • Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.

Настройка Encryption Oracle Remediation

Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.

Оставить уязвимость credSSp

После чего вам нужно обновить политику, для этого откройте командную строку и введите gpupdate /force. Если у вас не доменный компьютер, да и еще Windows 10 Home, которая не имеет встроенного локального редактора политик, то вам как я описывал выше, нужно производить правку реестра

REG ADD HKLMSoftwareMicrosoftWindows CurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2 (0 вернет все как было)

На просторах интернета ходит скрипт 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).

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

Раньше были вот такие 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

CVE-2018-0886 CredSSP Remote Code Execution Vulnerability

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

Всем привет!

Практически все вы уже знакомы с советниками на форекс и многие из вас их применяют на своих демо или реальных счетах. Чаще всего для удобства многие используют 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

После установки обновления KB4103718 на моем компьютере с Windows 7 я не могу удаленно подключится к серверу c Windows Server 2012 R2 через удаленный рабочий стол RDP. После того, как я указываю адрес RDP сервера в окне клиента mstsc.exe и нажимаю «Подключить», появляется ошибка:

Подключение к удаленному рабочему столу

Произошла ошибка проверки подлинности.

Указанная функция не поддерживается.

Удаленный компьютер: computername

RDP Произошла ошибка проверки подлинности. Указанная функция не поддерживается

После того, как я удалил обновление KB4103718 и перезагрузил компьютер, RDP подключение стало работать нормально. Если я правильно понимаю, это только временное обходное решение, в следующем месяце приедет новый кумулятивный пакет обновлений и ошибка вернется? Можете что-нибудь посоветовать?

Ответ

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

В своей проблеме вы не одиноки. Данная ошибка может появится в любой операционной системе Windows или Windows Server (не только Windows 7). У пользователей английской версии Windows 10 при попытке подключится к RDP/RDS серверу аналогичная ошибка выглядит так:

An authentication error has occurred.

The function requested is not supported.

Remote computer: computername

An authentication error has occurred. The function requested is not supported

Ошибка 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 серверу?

  1. Самый правильный способ решения проблемы – установка последних кумулятивных обновлений безопасности Windows на компьютере / сервере, к которому вы подключаетесь по RDP;
  2. Временный способ 1. Можно отключить проверку подлинности на уровне сети (NLA) на стороне RDP сервера (описано ниже);
  3. Временный способ 2. Вы можете на стороне клиента разрешить подключение к RDP серверам с небезопасной версией CredSSP, как описано в статье по ссылке выше. Для этого нужно изменить ключ реестра AllowEncryptionOracle (команда
    REG ADD
    HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2

    ) или изменить настройки локальной политики Encryption Oracle Remediation / Исправление уязвимости шифрующего оракула), установив ее значение = Vulnerable / Оставить уязвимость).

    Это единственный способ доступа к удаленному серверу по RDP, если у вас отсусвует возможность локального входа на сервер (через консоль ILO, виртуальной машины, облачный интерфейс и т.д.). В этом режиме вы сможете подключиться к удаленному серверу и установить обновления безопасности, таким образом перейдете к рекомендуемому 1 способу. После обновления сервера не забудьте отключить политику или вернуть значение ключа AllowEncryptionOracle = 0 :
    REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 0

Отключение 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).

win 10 отключить nla

В 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) или перезагрузить компьютер. После этого вы должны успешно подключиться к удаленному рабочему столу сервера.

Понравилась статья? Поделить с друзьями:
  • Xrdebugnew cpp как исправить ошибку
  • Xrcore dll ошибка сталкер тень чернобыля
  • Xray engine ошибка при запуске в сталкере как исправить
  • Xray engine ошибка в сталкере что это
  • Xray engine ошибка в сталкере тени чернобыля что делать