New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Comments
rdesktop host
ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
Failed to connect, CredSSP required by server.
When I login using MS client (from both Android and Windows), everything just works.
Maybe I just don’t understand how to configure this properly, but then I suppose it has to be explained better in the man page, because moderate amount of googling didn’t really help me.
In this specific case, I can disable network level authentication (what google suggests), but it’s not really a solution.
—
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/39133406-credssp-does-not-work?utm_campaign=plugin&utm_content=tracker%2F19353203&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F19353203&utm_medium=issues&utm_source=github).
rdesktop supports CredSSP with kerberos and lack the implementation of NTLM. That’s why there are a differences from MS client and rdesktop. To get this working, you need to configure kerberos on the client side against MS KDC (Active directory service) to be able to obtain a ticket used for NLA.
I added issue #72 for the lack of NTLM.
On this issue, we should look into adding information about how this works, maybe a section on our web site.
Is this about automatic login on windows? I noticed when i login to windows from windows that i don’t have to fill in my credentials. With rdesktop i have to enter my user name and password as if i was sitting at the pc itself.
Is this about automatic login on windows?
Yes it is. On a windows client you have a credential cache that is used to authenticate against services in your network (NTLM). RDP have support for such «Single-Sign-On» authentication, however Linux clients does not have this cached authentication and there for you need to provide credentials, either via rdesktop command line or in login window at remote session.
However, there is something called Kerberos which is an authentication mechanism for requesting access to services based on a initial «ticket». Windows AD (Active Directory) provides a Kerberos infrastructure and a Linux box can be configure to authenticate against that. This means that when you login to you linux box, you will authenticate for a initial kerberos «ticket» that is used to access other services such as RDP. Then when running rdesktop, CredSSP will check if you have a ticket for accessing the remote service and use that for authentication «Singel-Sign-On» against the remote RDS server. If there is not ticket, rdesktop will fallback to plain TLS connection.
Hi,
As long this issue isn’t fixed (by documentation and/or code) no one (or at least I ) is not able to login into Microsoft Azure provisioned Windows Server 2016 (v1607) virtual machines with rdesktop.
I notice, that freerdp (on centos 7, somehow) is able to connect with above virtual machine. However, freerdp isn’t behaving nicely not keeping meta-keypresses inside the client, even though it is setup to do so, by default.
/Henrik
Henrik, I can connect to a Windows server 2016 build 1607 using rdesktop 1.8.3 (this is not on Azure though, maybe it could have an effect on the Kerberos port ? the port 88 was used for this test, I have no idea how it can work with Azure). The idea is pretty simple: install krb5-user, setup /etc/krb5.conf, launch rdesktop
If my windows username is billg, the win domain is contoso.local, you have to set up /etc/krb5.conf with something like that:
[libdefaults]
default_realm = CONTOSO.LOCAL
[realms]
CONTOSO.LOCAL = {
kdc = 10.1.0.5:88
admin_server = 10.1.0.5:749
default_domain = CONTOSO.LOCAL
}
[domain_realm]
.contoso.local = CONTOSO.LOCAL
then (no need to reboot or anything)
kinit billg
rdesktop -u billg -d CONTOSO.LOCAL -f MYSERVER
with MYSERVER defined in /etc/hosts
This has been tested with a Mandriva 2010 distro from the Mesozoic age and a more modern Ubuntu 16.04 LTS, it worked basically the same (a bit easier with Ubuntu)
The only trouble is that I suffer from a double login: kinit is basically a login, but the server connection screen complains that the password is invalid; if I enter again the password at this stage, I am good to go.
Please note that kinit should not return any error. If you get an error about an unexpected reply and it works with -C option, you have probably an upper/lower case problem with the domain name.
Also do not use an ip address on the rdesktop call, use a symbolic name like I have shown you otherwise it will not work.
Last thing: rdesktop is not very user-friendly for windows errors: first try I did, the user was not
allowed to connect, and rdesktop just terminated silently after saying ‘connection established using CredSSP’ , it was only after a connection was attempted on a Windows computer that I was allowed to bang my head against the keyboard.
Good luck ! it’s not really rocket science.
@gp54321 Thanks for your response, please if you do stumble upon any fishy with Window 2016 server, report it and link to issue #101, TIA.
CREDSSP WORKING [ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ? ]
1 ) First create the /etc/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
EXAMPLE.COM = {
admin_server = example.com
default_domain = example.com
kdc = example.com
}
vdi.com = EXAMPLE.COM
.vdi.com = EXAMPLE.COM
- Make sure you have /etc/gssapi_mech.conf [which searches for libgssapi_krb5.so.2 ]
- kinit USERNAME_OF_ABC.EXAMPLE.COM
- Above command will create a temporary file in /tmp/krb5cc_0
- Now run rdesktop ABC.EXAMPLE.COM
@ppokhriyal: thanks for posting. But since «domain names» are ambiguous in a Windows environment I can’t grasp the understanding of what you write.
I have a local Windows 2k12 server on the network and the Linux client should connect to it.
The login domain is 2k12-DC. The server is local on the LAN, no connection to the outside.
The FQDN of the 2k12 server is 2k12-DC.2k12test.local. So I assume the domain is 2k12test.local. (At least according to the 2k12 DNS server)
The Linux client running rdesktop does not use the Windows 2k12 box as DNS server. It is not connected to the Windows domain or AD at all.
On the linux client I can edit the hosts file. The DNS is normally pointing to the internet router. Not to the 2k12 box. Should I add entries in the hosts file so it can find 2k12test.local?
Summarizing, if I log in as 2k12-DCAdministrator to 2k12-DC.2k12test.local how should I compose the krb5.conf file?
jlinkels
@jlinkels : In my environment i am trying to take rdesktop from my customize Linux machine to a Windows machine which is a member of a domain example:vdi.com
So, when i fire rdesktop command from my linux machine
example : rdesktop WIN12.vdi.com
i get this output >>ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ?
So, in order to resolve this Error i have followed the below steps
###My apologizes i didn’t mentioned the ADS part ####
Domain: vdi.com
Hostname:xyz
1 . First you have to join your Linux Machine to the DOMAIN in my case it is vdi.com
Steps for NET ADS JOIN
a) First edit the krb.conf file
[libdefaults]
default_realm = VDI.COM
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
VDI.COM = {
admin_server = vdi.com
default_domain = vdi.com
kdc = vdi.com
}
vdi.com = VDI.COM
.vdi.com = VDI.COM
b) /etc/host
IP-ADDRESS xyz.vdi.com xyz localhost
IP-ADDRESS xyz xyz.vdi.com
c) /etc/samba/smb.conf
#START#
# Global parameters
[global]
unix charset = ISO-8859-1
workgroup = VDI
realm = VDI.COM
winbind separator = +
security = user
winbind use default domain = yes
server string = WORKGROUP
winbind enum users = Yes
winbind enum groups = Yes
winbind refresh tickets = Yes
winbind offline logon = Yes
winbind normalize names = Yes
idmap config DOMAIN:range = 10000-999999
idmap config DOMAIN:schema_mode = rfc2307
idmap config DOMAIN:backend = ad
idmap config *:range = 2000-9999
idmap config * : backend = tdb
ldap ssl = No
read only = No
create mask = 0777
directory mask = 0777
client signing = mandatory
server signing = mandatory
guest account = nobody
map to guest = Never
restrict anonymous = 2
[smb-share]
path = /tmp/smb-share
read only = No
guest ok = Yes
public = Yes
browseable = Yes
writable = Yes
create mode = 0700
#END#
d) restart the SAMBA and NMBD service
e) net ads join -Uusername%password
f) After successful domain join run kinit USERNAME_OF_VDI.COM then it will ask for password.
- rdesktop 2k12-DC.2k12test.local
I hope this solution works for you.
@ppokhriyal: Thanks for taking the time to explain it. It works using the GUI remote desktop client.
Windows server:
Computer name: 2k12-dc
Domain: 2k12test.local
This is what my krb5.conf looks:
[libdefaults]
default_realm = 2K12TEST.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
2K12TEST.LOCAL = {
kdc = **2k12-dc**.2k12test.local
default_domain = 2k12test.local
admin_server = **2k12-dc**.2k12test.local
}
2k12test.local = 2K12TEST.LOCAL
.2k12test.local = 2K12TEST.LOCAL
Then the /etc/hosts file: you proposed this:
IP-ADDRESS xyz.vdi.com xyz localhost
IP-ADDRESS xyz xyz.vdi.com
But it is not clear if you intend to create a record for the host to connect or a record for localhost. Anyway, my /etc/hosts looks like this:
127.0.0.1 localhost
127.0.1.1 lampje-pc.2k12test.local lampje-pc
192.168.110.11 2k12-DC 2k12-DC.2k12test.local
lampje-pc is the client. But it is not on the domain 2k12-DC.2k12test.local.
Very important: after configuring krb5.conf, run:
kinit
Anyway, in the GUI remote desktop client I have to enter:
Computer: 2k12-dc.2k12test.local (or 192.168.110.11)
Username: Administrator
Password:
Domain: 2k12-dc (yeah right: the computer name!)
And then select Windows XP/2003
For that matter this works as well:
rdesktop -u administrator -p -f 2k12-dc.2k12test.local
Hit CTRL-ALT-ENTER to toggle full screen.
Thanks again
Hello, I get the CredSSP error when connecting to a remote Windows Server 2012R2.
However, I only have a TCP port forwarding for the RDP port of the server and I can successfully connect to it from Windows 10. I don’t need to configure anything on Windows 10 to connect to the server, only provide the domain along with the username and it just works. It’s not connected to any domain, it’s just a regular standalone installation.
Is this an unrelated issue because setting these kerberos things and ips in /etc/hosts wouldn’t really do anything good when I can only connect to a tunneled TCP 3389, right?
It seems to me the client would only need to create this ticket locally for the connection to succeed or somehow gracefully fail SSP so a normal login would work?
@hifi, rdesktop only support CredSSP with kerberos, mstsc uses CredSSP with NTLM and that is why it works out of the box. See bug #72 for adding NTLM support to rdesktop. And you are right about the kerberos part, that needs a infrastructure and be accessible from the client side of firewall, eg. no single port setup there.
@hean01 Thank you for clearing that up, I’ll subscribe to that issue.
Earlier this year I was annoyed to discover I couldn’t connect to a newly-provisioned Azure VM from my iBook G4, so I compiled rdesktop 1.7 with a CredSSP+NTLMv2 patch from way back in 2011 and was able to login to my new VM without needing to edit krb5.conf or smb.conf.
It would be nice to see this patch in newer versions of rdesktop but in my case the libraries on Mac OS 10.4 were too old to make any headway.
Hello! Any progress using CredSSp over NTLM without the need of Kerberos?
Thanks
Is there a dummy guide how to get this working with rdesktop? I have no idea what to do with the hints about /etc/krb5.conf
and /etc/gssapi_mech.conf
given above. Can somebody dumb it down for me?
This works fine out of the box with Remmina, but I’d prefer the mostly gui-less rdesktop, which fails me for some target machines like this:
$ rdesktop -k de -r clipboard:CLIPBOARD -u user -p password -g 1916x1025 -v target-ip
is_wm_active(): WM name: KWin
Connecting to server using NLA...
Core(warning): Certificate received from server is NOT trusted by this system, an exception has been added by the user to trust this specific certificate.
TLS Session info: (TLS1.2)-(RSA)-(AES-256-GCM)
Failed to initialize NLA, do you have correct Kerberos TGT initialized ?
Failed to connect using NLA, trying with SSL
Failed to connect, CredSSP required by server (check if server has disabled old TLS versions, if yes use -V option).
xfreerdp /u:»abel.comadam» /v:192.168.1.113:3389 works fine!!!
Содержание
- Rdesktop error credssp initialize failed do you have correct kerberos tgt initialized
- Как выглядит ошибка credssp
- Назначение CredSSP
- Windows SSP
- Причины ошибки шифрования CredSSP
- Варианты исправления ошибки CredSSP
- Отключаем credssp в Windows через NLA
- Отключаем шифрование credssp через GPO
- Самый правильный метод, это установка обновлений
Rdesktop error credssp initialize failed do you have correct kerberos tgt initialized
Добрый день! Уважаемые читатели и гости 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 и выставите ему значение , чтобы деактивировать 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
Источник
Обновлено 25.11.2019
Добрый день! Уважаемые читатели и гости 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
Получается двоякая ситуация, что 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% людей и администраторов совершают одну и туже ошибку, они сразу ставят обновления, не дождавшись пары дней после их выхода. Обычно этого времени хватает, чтобы вендор определил проблемы и отозвал глючное обновление.
Уязвимость в протоколе 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. В окне «Система» находим пункт меню «Настройка удаленного доступа»
Снимите галку «Разрешить подключение только с компьютеров, на которых работает удаленный рабочий стол с проверкой подлинности на уровне сети»
После этого вы легко сможете подключиться к данному компьютеру или серверу, но как быть что вы не можете туда попасть и снять эту галку, тут нам на помощь придет реестр Windows. Вы можете удаленно создать нужные ключи реестра, которые отключат галку NLA или политику CredSSP. Для этого вы можете пойти двумя путями:
- Использовать сетевой реестр Windows
- Использовать удаленное управление компьютером, например PsExec.exe, я вам с помощью него уже показывал, как открывать порты в брандмауэре, удаленно.
Давайте попробуем через удаленный реестр, для этого открываем Regedit, через окно «Выполнить».
Из меню «Файл» выберите пункт «Подключить сетевой реестр», далее найдите нужный вам сервер.
У вас подключится дополнительный реестр с двумя кустами. Переходите по пути (Если у вас не будет CredSSPParameters, то нужно будет их создать):
HKLMSoftwareMicrosoftWindowsCurrentVersion PoliciesSystemCredSSPParameters
Тут вам необходимо создать REG_DWORD ключ с именем AllowEncryptionOracle и значением 2. В данном варианте политика CredSSP выставит Уязвимый уровень — это самый низкий уровень защиты. Это позволит вам подключаться к серверам удаленно, используя RDP. Однако это подвергнет серверы атакам.
Или можно так же отключить NLA, для этого найдите ветку реестра:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControl Terminal ServerWinStationsRDP-Tcp
Найдите там ключ SecurityLayer и выставите ему значение 0, чтобы деактивировать Network Level Authentication.
Теперь то же самое вы можете выполнить и через PsExec.exe, выставив для CredSSP минимальный уровень защиты или же отключить NLA, для этого находясь в cmd в режиме администратора введите команду:
PsExec.exe \w10-cl01 -u rootАдминистратор -p пароль cmd
w10-cl01 — это имя компьютера.
Далее имея запущенный сеанс cmd для удаленного компьютера, выполните команду:
REG ADD HKLMSoftwareMicrosoftWindows CurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2 (0 вернет все как было)
Аналогично можно сделать и для отключения 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.
Вам необходимо перейти в ветку:
Конфигурация компьютера — Административные шаблоны — Система — Передача учетных данных — Исправление уязвимости шифрующего оракула (Computer Configuration — Administrative Templates — System — Credentials Delegation — Encryption Oracle Remediation
Открываем настройку «Исправление уязвимости шифрующего оракула (Encryption Oracle Remediation)». Включаем политику, у вас активируется опция «Уровень защиты», на выбор будет три варианта:
- Принудительно применять обновленные клиенты (Force Updated Clients) — она будет стоять по умолчанию из-за максимального уровня защиты, вам данную опцию нужно сменить. Это так сказать максимально безопасный уровень взаимодействия клиент, он должен быть в идеале, после установки обновлений на все сервера и компьютеры.
- Оставить уязвимость (Vulnerable) – клиенты могут подключаться на уязвимые машины.
- Уменьшить риск (Mitigated) – клиенты не могут подключаться к уязвимым серверам, но серверы могут принимать уязвимые клиенты.
Выбираем на время пункт «Оставить уязвимость (Vulnerable)». Сохраняем настройки.
После чего вам нужно обновить политику, для этого откройте командную строку и введите 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
На этом у меня все, надеюсь, что вы разобрались в работе CredSSP и научились ей управлять. С вами был Иван Семин, автор и создатель IT портала Pyatilistnik.org.
I have installed the program rdesktop with the command
sudo apt-get install rdesktop
I use rdesktop with the command
rdesktop -a 32 192.168.0.38
with the error message
Disconnected due to network error, retrying to reconnect for 70
minutes. ERROR: CredSSP: Initialize failed, do you have correct
kerberos tgt initialized ?
How do I fix the error?
Thanks by advance,
Note: Sorry for my english, i’m french
asked Aug 27, 2016 at 9:36
I solved this by using xfreerdp instead. I actually tried configuring the Kerberos authentification, but gave up after an hour.
So an example of an xfreerdp command would be:
xfreerdp /u:'DOMAINjohn' /p:'doe' host:port
Hope that helps even though it’s a bit late
answered Mar 8, 2017 at 11:46
2
another way is to acquire a ticket from the kerberos server in case you are in a domain.
NLA is an extra security layer which requires the client to authenticate against the Domain before logging on.
After krb5.conf is adequately configured for the domain (google it), you can do the following:
kinit <user>
rdesktop -u <user> -d <domain>
You only need to execute kinit
once until the ticket has expired
answered Jul 9, 2019 at 9:23
oneindelijkoneindelijk
2232 silver badges8 bronze badges
1
Failed to connect, CredSSP required by server is an error line returned when trying to connect remotely to a Windows machine using RDP version 6 or newer with the Rdesktop client. It represents a frequent problem for Windows and Linux administrators alike.
Rdesktop client is UNIX based client software for Microsoft’s Remote Desktop Protocol. It is commonly used on ReactOS and Linux installations to connect to Windows machines running Remote Desktop Services, which often leads to the CredSSP required by server error.
Why does CredSSP required by server error happen?
All Windows clients have a credential cache used for authentication against services in a network called NTLM or Windows NT LAN Manager. RDP supports SSO (single sign-on) authentication enabling a user to log in with a single ID and password to gain access to a connected system. However, Linux clients do not support this type of authentication and they require that credentials are provided, either via a Rdesktop command line or via a login window when initiating the remote session.
Linux has Kerberos, which is an authentication mechanism for requesting access to services based on an initial login. Windows Active Directory provides a Kerberos infrastructure, enabling Linux to be configured so it authenticates against AD. This means that upon logging in to Linux, you will be authenticated for a Kerberos TGT (Ticket Granting Ticket), which is used to access other services, such as RDP. When running Rdesktop, CredSSP will check if you have Kerberos TGT to access the remote service and use that for SSO authentication against the remote RDS server. If there is no Kerberos TGT, the Rdesktop will fall back to a lower, insecure level of network connection without the requirement for network-level authentication.
How to fix CredSSP required by server error?
Three solutions are commonly mentioned, though none of them is really THE solution, but still they can help if you stumble upon the CredSSP required by server problem:
Downgrade security on the Windows server to accept SSL/TLSv2
This is generally not a solution, but a workaround. Turning security down is never a good solution, but only a temporary fix.
- Go to Control Panel -> System
- Click on “Allow remote access to your computer”
- Click on the “Remote” tab
- Uncheck the box next to “Allow connections only from computers running Remote Desktop with Network Level Authentication”
This will allow insecure connections without NLA (network-level authentication) and you will no longer be prompted with failed connections to a Windows machine due to the CredSSP requirement.
Initialize Kerberos TGT
This is a solution if you receive the CredSSP required by server error when connecting to a remote computer without proper Kerberos identities set up.
What you need to do is initialize a Kerberos TGT to be able to connect using CredSSP. Here you can find a full guide on how to configure a Kerberos client for Windows Active Directory. You must also configure Kerberos on the client side against MS KDC (Active Directory Service), so that the remote server can obtain a login to pass NLA.
Use the Freerdp client
Freerdp is a free implementation of the Remote Desktop Protocol (RDP) for Linux, released under the Apache license. It works over SSH (Secure Shell), which functions well with the NTML authentication protocol.
It is considerably less frequently used than Rdesktop according to the Debian Popularity Contest stats (in part, because it is newer) but it works very well in our scenario since Rdesktop lacks the much needed support for newer protocols.
What is CredSSP really and why should you use it?
CredSSP (Credential Security Support Provider protocol) is a security support provider that enables an application to delegate the user’s credentials from the client computer to the target remote server. It provides an encrypted transport layer security protocol channel. The client is authenticated over the encrypted channel using the Simple and Protected Negotiate (SPNEGO) protocol with either Microsoft Kerberos or Microsoft NTLM.
CredSSP has many use cases, but perhaps the most common is for remote server management with PowerShell. For example, it is used if a system administrator needs to delegate a user’s credentials to get SharePoint server data from a content database or simply needs to execute a specific PowerShell command on the domain controller.
The SysKit Monitor tool enables you to do just that, providing you with built-in support for CredSSP and an online repository full of PowerShell scripts intended for system administration. SysKit Monitor also enables you to track all sessions via RDP and ICA, which is especially important when a lot of your employees connect remotely. On top of that, Monitor tracks published applications and it shows the real-time performance of your servers.
Related Posts:
- Power BI: workspace permissions, roles, and report on who has access
- External Sharing in Office 365: video and a comprehensive blog
- SharePoint Admin Problem #1: The SQL Server is Out of Disk Space
- New SysKit Monitor Licensing: Introducing a Subscription-Based Model
- Печать
Страницы: [1] 2 Вниз
Тема: rdesktop не коннектится (Прочитано 2672 раз)
0 Пользователей и 1 Гость просматривают эту тему.
Здравствуйте. У меня версия arch linux 4.8.10-pf8 при попытке соединения rdesktop выдаёт след ошибку
CredSSP initialize failed do you have correct kerberos tgt initialized
Версия rdesktop 1.8.3
И синтаксис команды у меня следующий
rdesktop 192.168.0.5
посмотрел в интернете вроде и так можно без дополнительных опций подключаться
« Последнее редактирование: 30 Ноябрь 2020, 09:50:34 от sfs »
Записан
У меня версия arch linux 4.8.10-pf8
Это не дает полезной инфы. Дистр наш? Название исо?
rdesktop — древний, брошеный. К свежей винде вряд ли подключится. К чему подключаетесь?
Используйте в консоле xfreerdp или в графике remmina
Записан
rdesktop — древний, брошеный. К свежей винде вряд ли подключится.
У меня подключается. С параметрами, правда
arch linux 4.8.10-pf8
Что-то в духе ПРА
Записан
Компьютер имеет то преимущество перед мозгом, что им пользуются.
sfsДистр ваш качал с этого сайта. Название ISO не помню. xfreerdp в списке пакетов нет. remmina есть но после установки не запускается. Могу перекачать и новой версии но условию к нему след. чтоб он мог установится на винте и работать с видео картой S3 Trio64V+. Пробова сначала другие версии Linux’а ubuntu, kubuntu,lubuntu разных версий с ней работать не хотят и да у меня не много квалификации в работе с данным семейством ОС.
iphone 6 frame png
« Последнее редактирование: 02 Декабрь 2020, 06:43:53 от Максим »
Записан
Записан
Записан
« Последнее редактирование: 03 Декабрь 2020, 10:27:43 от sfs »
Записан
you have correct kerberos tgt initialized
Удаленная машина в домене находится? Или локальная политика безопасности?
S3 Trio64V+
С такими ресурсами наверно telnet здесь будет более актуальным
Записан
# A78M-E35 Athlon-840 Nvidia-GT-710 DDR3-8GB Win7 64(bit)/PRA03-1612Game
# H96MaxUltraHD RK3318 2/16 aarch64 kernel 4.4.159
Ekim
Нет, в одной локальной сети. Машина пингуется. Машина отвечает на запрос, но вот с таким ответом…
А telnet же консольная утилита она здесь причем?
Записан
sfs
Ставил данную систему LF01-20.10 и при загрузке только мигает экран и все ….
p.s Соообщение отправли еще в пятницу, но што то пошло не так….
« Последнее редактирование: 07 Декабрь 2020, 06:17:40 от Максим »
Записан
Записан
Нет, в одной локальной сети. Машина пингуется. Машина отвечает на запрос, но вот с таким ответом…
Если локальная политика безопасности, тогда пробуйте так:
Меню «Пуск» → Параметры → Система → Удалённый рабочий стол → Дополнительные параметры → Снять галочку с «Требовать использование компьютерами аутентификации на уровне сети для подключения (рекомендуется)»
Telnet тоже может рулить удаленной станцией.
Все зависит от того что именно вам нужно.
Как вариант есть еще Radmin (запускается из под Wine). Если комп не смотрит в WAN, то вполне юзабельная вещь.
Записан
# A78M-E35 Athlon-840 Nvidia-GT-710 DDR3-8GB Win7 64(bit)/PRA03-1612Game
# H96MaxUltraHD RK3318 2/16 aarch64 kernel 4.4.159
Telnet тоже может рулить удаленной станцией.
Не путайте новичка.
Как вариант есть еще Radmin
Есть и попроще
Но rdp самый удобный и т.п.
Записан
Не путайте новичка.
Чем это я его путаю?
Через телнет запускается Far.exe и танцуй свою удаленную систему как хочешь, ну правда это не десктопный вариант.
Free VNS VNC вот не знаю жив ли еще…
« Последнее редактирование: 07 Декабрь 2020, 12:35:41 от Ekim »
Записан
# A78M-E35 Athlon-840 Nvidia-GT-710 DDR3-8GB Win7 64(bit)/PRA03-1612Game
# H96MaxUltraHD RK3318 2/16 aarch64 kernel 4.4.159
Free VNS вот не знаю жив ли еще…
vnc — жив, но неудобен. С клавы не все вводилось и пр. гемор
Записан
- Печать
Страницы: [1] 2 Вверх
#1 2020-09-20 08:38:59
- insciwetrust
- Member
- Registered: 2019-10-19
- Posts: 73
[SOLVED] I can’t connect to a Windows PC
I’m trying to connect to a Windows VDS using rdesktop, but it returns me this error:
Failed to initialize NLA, do you have correct Kerberos TGT initialized ?
Failed to connect, CredSSP required by server (check if server has disabled old TLS versions, if yes use -V option)
What should I do?
Last edited by insciwetrust (2020-10-04 06:14:12)
#2 2020-09-20 14:34:45
- seth
- Member
- Registered: 2012-09-03
- Posts: 35,309
Re: [SOLVED] I can’t connect to a Windows PC
#3 2020-09-20 15:01:20
- ewaller
- Administrator
- From: Pasadena, CA
- Registered: 2009-07-13
- Posts: 19,010
Re: [SOLVED] I can’t connect to a Windows PC
Another client would be krdc
Insciwetrust: What client are you trying to use?
Nothing is too wonderful to be true, if it be consistent with the laws of nature — Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. — Alan Turing
—
How to Ask Questions the Smart Way
#4 2020-10-04 06:13:57
- insciwetrust
- Member
- Registered: 2019-10-19
- Posts: 73
Re: [SOLVED] I can’t connect to a Windows PC
ewaller wrote:
Another client would be krdc
Insciwetrust: What client are you trying to use?
rdesktop.
I solved the problem by having someone do this on the VDS: https://github.com/rdesktop/rdesktop/is … -312788907.
Apparently it also creates a security vulnerability but that’s not a big concern for me.
- Remove From My Forums
-
Question
-
Hello.
In «Remote settings» I have selected «Allow connection only from computers running remote desktop with network level authentication(recommended)» but I can’t logging to my Windows Server from Linux OS. I used «rdesktop -d «Domain
name» -u «User name» IP» but I got an error:Autoselected keyboard map en-us ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ? Failed to connect, CredSSP required by server.
How can I solve it?
Thank you.
-
Moved by
Monday, December 11, 2017 6:36 AM
from Windows Server 2012 General forum
-
Moved by
Answers
-
but I can’t logging to my Windows Server from Linux OS. I used «rdesktop -d «Domain name» -u «User name» IP» but I got an error:
Autoselected keyboard map en-us ERROR: CredSSP: Initialize failed, do you have correct kerberos tgt initialized ? Failed to connect, CredSSP required by server.
Hi,
Network-level authentication (NLA) relies on Credential Security Support Provider (CredSSP) Protocol, seems like that the RDP client you are using doesn’t support CredSSP.
Windows Server 2008 R2: Why Use Network Level Authentication?
https://technet.microsoft.com/en-us/library/hh750380.aspx
You may uncheck the NLA option on the server, which is not recommended, or I suggest you refer to Linux forums to see whether there are other alternatives.
Best Regards,
Amy
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact
tnmff@microsoft.com.Problem Solved via «FreeRDP».
$ xfreerdp /u:»User name» /v:IP:3389
-
Marked as answer by
Windows.Geek
Monday, December 11, 2017 8:26 AM -
Edited by
Windows.Geek
Monday, December 11, 2017 8:26 AM
-
Marked as answer by