UNIXS.RU

Сайт присвячено системному адмініструванню та способам вирішення різноманітних проблем, які можуть виникнути в процесі експлуатації операційних систем, у тому числі дуже рідкісних та складних.

Виправлення: збережені облікові дані RDP не працювали у Windows

Вбудований клієнт Windows Remote Desktop (mstsc.exe) дозволяє зберігати ім'я користувача та пароль, які використовуються для підключення до віддаленого комп'ютера. Завдяки цьому користувачеві не потрібно вводити пароль для підключення до відомого вузла Remote Desktop. У цій статті ми розглянемо, як дозволити використання збережених облікових даних для RDP-підключень у Windows і що робити, якщо користувачі не можуть використовувати збережені паролі для підключень до віддаленого робочого столу (запитується кожен раз).

Дозволити делегувати збережені облікові дані для підключення RDP через GPO

За промовчанням Windows дозволяє користувачам зберігати свої паролі для з'єднань RDP. Для цього користувач повинен ввести ім'я комп'ютера RDP, ім'я користувача та встановити прапорець «Дозволити зберігати облікові дані». у вікні Remote Desktop Connection (mstsc.exe). Після того як користувач натисне кнопку «Підключитися«, RDP-сервер запитує пароль, і Windows зберігає його в Credential Manager (а не у файлі .RDP).

При наступному підключенні до віддаленого вузла RDP під тим самим користувачем клієнт автоматично отримає збережений пароль з диспетчера облікових даних Windows і використовуватиме його для автентифікації RDP.

Якщо для цього комп'ютера збережено пароль, у вікні клієнта RDP з'явиться таке повідомлення:

Завантажені credentials буде використовуватися для підключення до цього комп'ютера. Ви можете edit or delete these credentials.

У більшості випадків адміністратори не рекомендують користувачам зберігати паролі для підключення до Windows. Наприклад, у домені Active Directory краще налаштувати SSO (Single Sign-On) для RDP для прозорої автентифікації.

За промовчанням Windows не дозволяє користувачу використовувати збережений пароль RDP (облікові дані) для підключення з комп'ютера, підключеного до домену Active Directory, до вузла, що знаходиться в іншому домені або робочій групі. Хоча пароль підключення зберігається в Credentials Manager, Windows не дозволяє його використовувати і вимагає від користувача щоразу вводити пароль. Крім того, Windows не дозволяє використовувати збережений пароль RDP, якщо ви підключаєтеся до локального облікового запису, а не до домену.

У цьому випадку під час спроби підключення за допомогою збереженого пароля RDP з'являється повідомлення про помилку:

Your credentials did не працює Ваша система адміністратора не може використовувати ваші віртуальні права на log на remote computer CompName because його identity не повністю реалізований. Please enter new credentials. 

Windows вважає з'єднання небезпечним, оскільки між комп'ютером і віддаленим комп'ютером в іншому домені (або робочій групі) немає довіри.

Ви можете змінити ці параметри на комп'ютері, з якого ви намагаєтеся встановити з'єднання RDP:

1. Відкрийте редактор локальної групової політики, натиснувши Win + R ->gpedit.msc;
2. У редакторі GPO перейдіть на адресу Конфігурація комп'ютера -> Адміністративні шаблони -> Система -> Делегування облікових даних. Знайдіть політику з ім'ям Дозволити делегувати збережені облікові дані з автентифікацією тільки на сервері NTLM;
3. Увімкніть політику та натисніть кнопку Показати;
4. Вкажіть список віддалених вузлів, яким можна використовувати збережені облікові дані при доступі до RDP.Список віддалених комп'ютерів повинен бути вказаний у такому форматі:
5. TERMSRV/server1 — дозволити використовувати збережені облікові дані для доступу до певного комп'ютера/сервера RDP;
6. TERMSRV/*.woshub.com - дозволити встановлювати RDP-з'єднання зі збереженими обліковими даними з усіма комп'ютерами в домені woshub.com;
7. TERMSRV/* — дозволити використовувати збережений пароль для підключення до будь-якого віддаленого комп'ютера.

Порада. Обов'язково введіть ключове слово TERMSRV у верхньому регістрі. Ім'я комп'ютера має точно співпадати з ім'ям, вказаним у полі підключення RDP.

Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation] "AllowSavedCredentialsWhenNTLMOnly"=dword:00000001 \CredentialsDelegation\AllowSavedCredentialsWhenNTLMOnly] "1" ="TERMSRV/*" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowSavedCredentials] "1"="TERMSRV/*" [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\CredentialsDelegation] “AllowSavedCredentialsWhenNTLMOnly”=dword:00000001 “AllowSavedCredentials”=dword:00000002 Policies\Microsoft\Windows\CredentialsDelegation\AllowSavedCredentialsWhenNTLMOnly] "1"= "TERMSRV/*" [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows\CredentialsDelegation\AllowSavedCredentials] "1"="TERMSRV/*"

Credential Manager Error Unable to save credentials. Для того, щоб зберегти віртуації в цьому куті, виконати свій комп'ютер налаштування. Error code: 0x80070520 Error Message: Відкритий логічний номер не існує. It may already have been terminated.

Тепер при підключенні до вузла RDP клієнт mstsc зможе використати збережені облікові дані.

Ви можете перерахувати збережені паролі для RDP-з'єднань за допомогою команди:
cmdkey /list ^| findstr "target=TERMSRV"

Щоб очистити збережені паролі підключень, виконайте наступне:

For /F "tokens=1,2 delims= " %G in ('cmdkey /list ^| findstr "target=TERMSRV"') do cmdkey /delete %H

Ви можете змінити політику збереження облікових даних RDP лише на локальному комп'ютері за допомогою редактора локальної групової політики. Якщо ви хочете застосувати ці параметри на кількох комп'ютерах у домені, використовуйте GPO домену, налаштований за допомогою gpmc.msc (Керування груповою політикою).

Чому Windows не зберігає облікові дані віддаленого робочого стола?

Якщо ви налаштували Windows відповідно до наведених вище інструкцій, але ваш RDP-клієнт, як і раніше, просить ввести пароль при кожній спробі підключення, варто перевірити наступне:

1. Натисніть «Показати параметри» у вікні Підключення до віддаленого робочого столу та переконайтеся, що «Завжди вимагати облікові дані» опція не відзначена;
2. Якщо ви використовуєте файл RDP для підключення, переконайтеся, що значення ‘запитувати облікові дані' параметр дорівнює 0 (prompt for credentials:i:0);
3. Відкрийте редактор локальних GPO (gpedit.msc) і перейдіть в розділ Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Connection Client. На сторінці Не дозволяйте зберігати паролі і Запит облікових даних на клієнтському комп'ютері» параметри не повинні бути встановлені або вимкнені.Також переконайтеся, що цей параметр політики вимкнений у результуючій груповій політиці на вашому комп'ютері (ви можете створити HTML-звіт із застосованими параметрами GPO за допомогою gpresult);
4. Видаліть усі збережені паролі з диспетчера облікових даних Windows. Введіть control userpasswords2 і в Облікові записи користувачів перейдіть у вікно Додатково вкладку та натисніть Керування паролями;
5. У наступному вікні виберіть Облікові дані Windows. Знайдіть усі збережені паролі RDP та видаліть їх (вони починаються з TERMRSV/… ).

У цьому вікні можна вручну додати облікові дані для RDP-з'єднань. Зверніть увагу, що ім'я RDP-сервера/комп'ютера має бути вказане у полі TERMRSV\server_name1 форматі. Не забудьте видалити збережені паролі під час очищення історії RDP-з'єднань на комп'ютері.

Після цього користувачі зможуть використовувати збережені паролі для підключення RDP.

Політика автентифікації сервера не дозволяє підключення до збережених облікових даних

При підключенні до хоста RDP або ферми RDS з використанням збережених облікових даних може виникнути помилка:

Windows Security Your credentials не працює На сервері authentication policy не може бути здійснено з'єднання з використанням повідомлень credentials. Please enter new credentials.

У цьому випадку необхідно вимкнути параметр GPO «Завжди вимагати пароль при підключенні» на віддаленому сервері (Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security).

Якщо ця політика увімкнена, хост RDP завжди запитує у клієнта пароль для підключення.

Цю опцію можна вимкнути через реєстр:

REG add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fPromptForPassword /t REG_DWORD /d 0 /f

Windows Defender Credential Guard не дозволяє зберігати облікові дані

Після оновлення до Windows 11 22H2 користувачі стали скаржитися на те, що тепер вони не можуть використовувати збережені паролі для RDP-з'єднань:

Windows Security: Ваші credentials не працювали Windows Defender Credential Guard не може використовувати спроможні credentials. Please enter your credentials.

Windows Defender Remote Credential Guard (який з'явився в Windows 10 1607) покликаний захищати облікові дані для RDP-з'єднань. За промовчанням Windows 11/10 22H2 дозволяє використовувати збережені облікові дані лише при використанні автентифікації Kerberos на хості RDP. Якщо ви не можете використовувати Kerberos (контролер домену недоступний або підключаєтеся до вузла в робочій групі), Remote Credential Guard блокує NTLM автентифікацію.

Цю проблему можна вирішити, відключивши Credential Guard у реєстрі:

New-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\LSA" -Name "LsaCfgFlags" -PropertyType "DWORD" -Value 0 -Force

Користувач не може пройти автентифікацію або проходить її двічі

У цій статті наведено деякі причини проблем з автентифікацією користувачів.

Відмовлено в доступі (обмеження типу входу в систему)

У цьому випадку користувач Windows 10, який намагається підключитися до комп'ютерів з Windows 10 або Windows Server 2016, отримає відмову в доступі до наступного повідомлення:

Підключення до віддаленого робочого стола: адміністратор системи обмежений типом входу в систему (мережа або інтерактивний), який можна використовувати.Зверніться по допомогу до системного адміністратора або до служби технічної підтримки.

Ця проблема виникає, коли для підключень RDP потрібна автентифікація на рівні мережі (NLA), а користувач не входить у групу користувачів віддалених робочих столів. Це також може статися, якщо група користувачів віддаленого робочого столу не була призначена цьому комп'ютеру access від мережевого користувача.

Щоб вирішити цю проблему, виконайте одну з наведених нижче дій.

• Змініть членство користувача у групах або призначені йому права.
• Вимкніть NLA (не рекомендується).
• Використовуйте клієнти віддаленого робочого стола, які відрізняються від Windows 10. Наприклад, клієнти Windows 7 не мають цієї проблеми.

Зміна членства користувача у групах чи призначених йому прав

Якщо ця проблема зачіпає одного користувача, найпростішим рішенням буде додати цього користувача до групи Користувачі віддаленого робочого столу.

Якщо користувач вже є членом цієї групи (або якщо проблема виникає у кількох членів групи), перевірте конфігурацію прав користувачів на віддаленому комп'ютері Windows 10 або Windows Server 2016.

1. Відкрийте редактор об'єктів групової політики (GPE) та підключіться до локальної політики віддаленого комп'ютера.
2. Перейдіть до розділ "Параметри безпеки\" параметрів безпеки параметрів безпеки локальних\ політик \, клацніть правою кнопкою миші доступ до цього комп'ютера з мережі, а потім виберіть "Властивості".
3. Перегляньте список користувачів та груп для групи Користувачі віддаленого робочого столу (або батьківської групи).
4. Якщо список не включає групу Користувачі віддаленого робочого столу або батьківську групу, наприклад Усі, додайте їх. Якщо розгортання включає більше одного комп'ютера, використовуйте об'єкт групової політики. Наприклад, членством за умовчанням для політики Доступ до комп'ютера з мережі буде Усі. Якщо для розгортання використовується об'єкт групової політики для видалення Усі, може знадобитися відновити доступ, оновивши об'єкт групової політики, щоб додати групу Користувачі віддаленого робочого столу.

Відмовлено у доступі (віддалений виклик до бази даних SAM відхилено)

Така поведінка зазвичай виникає, якщо контролери домену працюють під керуванням Windows Server 2016 або пізнішої версії, а користувачі намагаються підключитися за допомогою програми для підключення, що настроюється. Зокрема, відмова в доступі отримають програми, які потребують доступу до відомостей профілю користувача в Active Directory.

Така поведінка обумовлена ​​зміною Windows. У Windows Server 2012 R2 і раніше версіях, коли користувач виконує вхід на віддалений робочий стіл, диспетчер віддалених підключень (RCM) звертається до контролера домену (DC), щоб запросити конфігурацію, що відноситься до віддаленого робочого столу, в об'єкті користувача в доменних службах Active Directory (AD DS). Ця інформація відображається на вкладці "Профіль служб віддалених робочих столів" у вікні властивостей об'єкта користувача в оснастці MMC "Користувачі та комп'ютери Active Directory".

Починаючи з Windows Server 2016, RCM більше не запитує об'єкт користувача в AD DS. Якщо потрібно, щоб RCM звертався до AD DS через те, що ви використовуєте атрибути служб віддалених робочих столів, вам потрібно вручну дозволити надсилання запитів.

У цьому розділі опис методу або завдання включено дії, що містять вказівки щодо зміни параметрів реєстру. Однак неправильна зміна параметрів реєстру може призвести до серйозних проблем. Тому переконайтеся, що ви уважно виконаєте такі дії. Для захисту створіть резервну копію реєстру перед його зміною, щоб можна було відновити його у разі виникнення проблеми. Додаткові відомості про створення резервної копії та відновлення реєстру див. у статті Відомості про резервне копіювання та відновлення реєстру Windows.

Щоб увімкнути застарілу поведінку RCM на сервері вузла сеансів віддалених робочих столів, налаштуйте наступні записи реєстру та перезапустіть службу служб віддалених робочих столів:

• HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\
  • Ім'я: fQueryUserConfigFromDC.
  • Тип: Reg_DWORD
  • Значення: 1 (десяткова)

  Щоб увімкнути застарілу поведінку RCM на сервері, відмінному від сервера вузла сеансів віддалених робочих столах, налаштуйте ці записи реєстру та наступний додатковий запис реєстру (а потім перезапустіть службу):
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server

  Користувачеві не вдається виконати вхід за допомогою смарт-картки

  У цьому розділі розглядаються три типові сценарії, коли користувач не може увійти на віддалений робочий стіл за допомогою смарт-картки.

  Неможливо увійти в систему за допомогою смарт-картки у філії з контролером домену тільки для читання (RODC)

  Ця проблема виникає в розгортанні, в яких задіяний сервер RDSH на сайті філії, де використовується RODC.Сервер RDSH розміщений у кореневому домені. Користувачі на сайті філії відносяться до дочірнього домену та використовують смарт-картки для автентифікації. Контролер домену RODC налаштований на кешування паролів та належить до групі з дозволом реплікувати паролі RODC. Коли користувачі намагаються виконати вхід у сеанс на сервері RDSH, вони отримують повідомлення, наприклад: "Невдала спроба входу в систему. Вказано неправильне ім'я користувача або інші неправильні особисті дані."

  Ця проблема пов'язана з тим, як кореневий контролер домену та RDOC управляють шифруванням облікових даних користувачів. Кореневий контролер домену використовує ключ шифрування, щоб зашифрувати облікові дані, а RODC надає ключ розшифровки клієнту. Коли користувач отримує помилку "неприпустимий", тобто два ключі не збігаються.

  Щоб вирішити цю проблему, виконайте одну з наведених нижче дій:

  • Змініть топологію контролера домену, відключивши кешування паролів у RODC або розгорніть контролер домену, що записується, на сайті гілки.
  • перемістіть сервер RDSH у той же дочірній домен, де перебувають користувачі;
  • дозвольте користувачам виконувати вхід без смарт-картки.

  Врахуйте, що ці рішення передбачають наявність компромісу між продуктивністю та рівнем безпеки.

  Користувач не може увійти на комп'ютер з Windows Server 2008 із пакетом оновлень 2 (SP2) за допомогою смарт-картки

  Ця проблема виникає, коли користувачі входять до комп'ютера Windows Server 2008 з пакетом оновлень 2 (SP2), на якому інстальовано оновлення KB4093227 (2018.4B). Коли користувачі намагаються увійти за допомогою смарт-картки, вони відмовлено у доступі до таких повідомлень, як "Немає допустимих сертифікатів.Переконайтеся, що ця картка вставлена ​​правильно і щільно сидить у роз'ємі". У той же час на комп'ютері Windows Server реєструється подія програми з повідомленням "При отриманні цифрового сертифіката зі вставленої смарт-картки сталася помилка: неправильний підпис."

  Щоб вирішити цю проблему, оновіть комп'ютер Windows Server з повторною версією 2018.06 B 4093227 бази знань, опис оновлення системи безпеки для вразливості протоколу віддаленого робочого столу Windows (RDP) у Windows Server 2008: 10 квітня 2018 року.

  Не вдається залишатися в системі, вхід до якої виконано за допомогою смарт-картки, і служба віддалених робочих столів зависає

  Ця проблема виникає, коли користувачі входять до комп'ютера Windows або Windows Server з оновленням KB4056446. Можливо, спочатку користувачеві вдається увійти до системи за допомогою смарт-картки, але потім він отримує повідомлення про помилку SCARD_E_NO_SERVICE. Віддалений комп'ютер може не відповідати.

  Щоб вирішити цю проблему, перезапустіть віддалений комп'ютер.

  Щоб вирішити цю проблему, оновіть систему на віддаленому комп'ютері, встановивши відповідне виправлення:

  • Windows Server 2008 SP2: KB 4090928 Windows зависає на процесі lsm.exe, а в програмах, для яких використовуються смарт-картки, може відображатися повідомлення SCARD_E_NO_SERVICE
  • Windows Server 2012 R2: KB 4103724, 17 травня 2018-KB4103724 (попередня версія щомісячного накопичувального пакета)
  • Windows Server 2016 та Windows 10 версії 1607: KB 4103720, 17 травня 2018 р. -KB4103720 (складання ОС 14393.2273)

  Якщо віддалений комп'ютер заблоковано, користувач повинен двічі ввести пароль.

  Ця проблема може виникнути, коли користувач намагається підключитися до віддаленого робочого стола під керуванням Windows 10 версії 1709 у розгортанні, де для підключень за протоколом RDP не потрібно використовувати NLA. Якщо в цьому випадку віддалений робочий стіл виявився заблокованим, користувачеві потрібно ввести свої облікові дані двічі при підключенні.

  Щоб вирішити цю проблему, оновіть комп'ютер Windows 10 версії 1709 за допомогою бази знань 4343893, 30 серпня 2018-KB4343893 (складання ОС 16299.637).

  Користувачеві не вдається увійти, при цьому відображаються повідомлення "Помилка автентифікації" та "Захист CredSSP від ​​атак з використанням криптографічного оракула"

  Коли користувачі намагаються увійти за допомогою будь-якої версії Windows з Windows Vista з пакетом оновлень 2 (SP2) та пізніших версій або Windows Server 2008 з пакетом оновлень 2 (SP2) та пізніших версій, вони отримують такі повідомлення:

  Відбулася помилка автентифікації. Ця функція не підтримується. . Це може бути пов'язане з виправленням oracle шифрування CredSSP.

  Помилка "Виправлення шифрування CredSSP" посилається на набір оновлень системи безпеки, випущений у березні, квітні та травні 2018 р. CredSSP — це постачальник автентифікації, який обробляє запити автентифікації для інших програм. Оновлення за 13 березня 2018 р., 3B та всі подальші оновлення зазнали експлойта, коли зловмисник міг передати облікові дані користувача для виконання коду в цільовій системі.

  Початкові оновлення додали підтримку нового об'єкта групової політики, виправлення Oracle шифрування, який має такі можливі параметри:

  • Вразливі: клієнтські програми, що використовують CredSSP, можуть повернутися до небезпечних версій, але ця поведінка надає віддаленим робочим столам атаки. Служби, які використовують CredSSP, приймали клієнти, які не були оновлені.
  • Виправлено. Клієнтські програми, які використовують CredSSP, не можуть повернутися до небезпечних версій, але служби, які використовують CredSSP, приймають клієнти, які не були оновлені.
  • Примусове оновлення клієнтів: клієнтські програми, які використовують CredSSP, не можуть повернутися до небезпечних версій, а служби, які використовують CredSSP, не прийматимуть невиключені клієнти.

  Примітка. Цей параметр не слід розгортати, доки всі вузли підтримки у віддаленому місці не підтримуватимуть останню версію.

  В оновленні за 8 травня 2018 р. значення для параметра за замовчуванням "Захист від атак з використанням криптографічного оракула" змінилося з "Уразливо" на "Усунено". Після реалізації цієї зміни клієнти Видаленого робочого столу, на яких були встановлені оновлення, не можуть підключатися до серверів без цього оновлення (або до оновлених серверів, які ще не були перезапущені). Докладніші відомості про оновлення CredSSP див. у статті бази знань KB4093492.

  Щоб вирішити цю проблему, оновіть та перезапустіть усі системи. Повний список оновлень та додаткові відомості про вразливість див. у розділі CVE-2018-0886 | CredSSP Remote Code Execution Vulnerability (CVE-2018-0886 | Вразливість CredSSP, що дозволяє віддалене виконання коду).

  Щоб вирішити цю проблему до завершення оновлення, перегляньте список допустимих типів підключень в оновленні KB4093492. Якщо немає можливих альтернатив, можна розглянути один із таких методів:

  • На порушених клієнтських комп'ютерах поверніть для політики "Захист від атак з використанням криптографічного оракула" значення Вразливо.
  • Змініть наступні політики в папці \групової політики групи безпеки вузла\сеансів віддалених робітників\столів Windows компонентів Windows Components \ Remote Desktop Services.\
    • для політики Вимагати використання спеціального рівня безпеки для віддалених підключень за протоколом RDP задайте значення Увімкнено та виберіть RDP.
    • для політики Вимагати автентифікацію користувача для віддалених підключень шляхом автентифікації на рівні мережі задайте значення Вимкнено.

    Зміна цих групових політик робить розгортання менш захищеним. Ми рекомендуємо використовувати їх лише тимчасово (або взагалі не використовувати).

    Щоб отримати додаткові відомості про роботу з груповою політикою, див. Змінення блокуючого об'єкта групової політики.

    Після оновлення клієнтських комп'ютерів деяким користувачам доводиться виконувати вхід двічі

    Якщо користувачі входять на Віддалений робочий стіл за допомогою комп'ютера під керуванням Windows 7 або Windows 10 версії 1709, ним відразу відобразиться запит на повторний вхід. Ця проблема виникає, якщо на клієнтському комп'ютері встановлено такі оновлення:

    Щоб усунути цю проблему, переконайтеся, що комп'ютери, до яких користувачі хочуть підключитися (сервери RDSH або RDVI) повністю оновлюються до червня 2018 року. До них відносяться такі оновлення:

    • Windows Server 2016: KB 4284880, 12 червня 2018 р. -KB4284880 (складання ОС 14393.2312)
    • Windows Server 2012 R2: KB 4284815, 12 червня 2018-KB4284815 (щомісячний накопичувальний пакет)
    • Windows Server 2012: KB 4284855, 12 червня 2018 року-KB4284855 (щомісячний накопичувальний пакет)
    • Windows Server 2008 R2: KB 4284826, 12 червня 2018-KB4284826 (щомісячний накопичувальний пакет)
    • Windows Server 2008 з пакетом оновлень 2 (SP2): KB4056564, опис оновлення системи безпеки для вразливості віддаленого виконання коду CredSSP у Windows Server 2008, Windows Embedded POSReady 2009 та Windows Embedded Standard 2009: 13 березня 20

    Користувачам забороняється доступ до розгортання, яке використовує Remote Credential Guard з кількома брокерами підключень до віддаленого робочого столу

    Ця проблема виникає в розгортанні з високим рівнем доступності, в яких використовуються не менше двох брокерів підключень до віддаленого робочого столу та Remote Credential Guard у Windows Defender. Користувачам не вдається увійти на віддалені робочі столи.

    Ця проблема пов'язана з тим, що Remote Credential Guard використовує Kerberos для автентифікації, а також забороняє використовувати NTLM. Але в конфігурації з високим рівнем доступності та балансуванням навантаження брокери підключень до віддаленого робочого столу не можуть підтримувати операції Kerberos.

    Якщо потрібно використовувати конфігурації з високим рівнем доступності та балансуванням навантаження брокерів підключень до віддаленого робочого столу, цю проблему можна усунути, вимкнувши Remote Credential Guard. Щоб отримати додаткові відомості про керування Remote Credential Guard у Windows Defender, див. Protect Remote Desktop Credentials with Windows Defender Remote Credential Guard (Захист облікових даних віддаленого робочого стола за допомогою Remote Credential Guard у Windows Defender).

    Не вдається увійти до облікового запису під час спроби підключитися до віртуальної машини Windows Azure

    У цій статті описано, як усунути помилку "Ми не можемо увійти до облікового запису" під час спроби підключитися до віртуальної машини Windows Azure за допомогою протоколу віддаленого робочого стола (RDP).

    Симптоми

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

    Неможливо увійти до облікового запису
    Ця проблема часто може бути усунена шляхом виходу з облікового запису та наступного входу. Якщо ви не виходите із системи, всі файли, які ви створюєте або змінюєте, будуть втрачені.

    У журналі подій програм відображається ідентифікатор події 1511 кожної спроби підключення RDP.

    Ідентифікатор: 1511
    Рівень: помилка
    Джерело: Служба профілів користувачів Microsoft-Windows
    Комп'ютер: RDPDemo.contoso.net
    Повідомлення: Windows не може знайти локальний профіль і входити до системи за допомогою тимчасового профілю. Зміни, внесені до цього профілю, будуть втрачені при виході із системи.

    Причина

    Ця проблема може виникнути, якщо локальний профіль користувача пошкоджено, і Windows не може створити новий локальний профіль для сеансу RDP.

    Рішення

    Перш ніж продовжити роботу, використовуючи будь-яке рішення в цьому документі, створіть резервну копію диска ОС віртуальної машини, створивши моментальний знімок. Якщо необхідно скасувати всі зміни, внесені під час усунення несправностей, можна використовувати моментальний знімок для повторного створення диска.

    Онлайн-відновлення за допомогою послідовної консолі Azure

    1. Підключіться до віртуальної машини за допомогою послідовної консолі Azure, а потім запустіть сеанс PowerShell.Якщо послідовна консоль Azure не працює, підключіться до віртуальної машини за допомогою віддаленого PowerShell. Для отримання додаткових відомостей див. статтю про використання віддалених інструментів для усунення несправностей з віртуальними машинами Azure.
    2. Після підключення до віртуальної машини виконайте наведену нижче команду, щоб отримати список записів профілів користувачів. Знайдіть усі профілі з розширенням ".bak" наприкінці імені.

    reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList" /s | more
    

    reg delete "HKLM\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList\.bak"
    

    Автономні репліки

    Якщо ви не можете отримати доступ до віртуальної машини за допомогою послідовної консолі Azure або інших віддалених засобів, відновлення має виконуватися в автономному режимі.

    1. Щоб створити віртуальну машину відновлення, виконайте кроки 1–3 процесу відновлення віртуальної машини. Скопійований диск ОС віртуальної машини, на якій стався збій, буде автоматично підключено до віртуальної машини відновлення. Зазвичай диск підключено як F.
    2. Підключення до віртуальної машини відновлення.
    3. Запустіть редактор реєстру (regedit.exe) на віртуальній машині відновлення. Виберіть ключ HKEY_LOCAL_MACHINE, а потім у меню виберіть Файл>Завантажити кущ. Знайдіть та завантажте файл HIVE SOFTWARE у папці F:\Windows\System32\config , а потім введіть RepairSOFTWARE як ім'я куща.
    4. Перейдіть до RepairSOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.
    5. Визначте запис профілю для порушеного користувача, вказавши значення ProfileImagePath.
    6. Видаліть запис резервного копіювання профілю користувача для порушеного користувача (закінчується ".bak"), не видаляйте записи для вбудованих облікових записів S-1-5-18, S-1-5-19 і S-1-5-20.
    7. Виконайте крок 5 процесу відновлення віртуальної машини, щоб підключити відновлений диск ОС до віртуальної машини, на якій стався збій.
    8. Запустіть віртуальну машину, на якій стався збій, та спробуйте підключитися до віртуальної машини за протоколом віддаленого робочого столу. Якщо проблема продовжується, спробуйте видалити запис користувача для користувача.

    Наступні кроки

    Якщо ця стаття не допомогла вирішити проблему з Azure, відвідайте форуми по Azure на сайтах MSDN і Stack Overflow. Опис своєї проблеми можна опублікувати на цих форумах або написати на Twitter (@AzureSupport). Також можна надіслати запит до служби підтримки Azure.

    Щоб надіслати запит на підтримку, перейдіть на сторінку підтримки Azure та виберіть "Отримати підтримку".

    Зв'яжіться з нами для отримання допомоги

    Якщо у вас є запитання або потрібна допомога, створіть запит до служби підтримки або зверніться за підтримкою спільноти Azure. Ви також можете надіслати відгук про продукт до спільноти відгуків Azure.