Віддалений робочий стіл працює лише зі старими клієнтами

Усі наші комп’ютери Windows 8.1 раптом відмовляються від підключення до віддаленого робочого столу.

Проблема полягає в підключенні до Windows 8.1
У нас немає проблеми під час підключення до інших версій Windows.

редагувати: проблема вирішена з оновленням Microsoft KB2962806. Дякую Бертранту ШІЦС за його відповідь.

Що ми знайшли досі:

• ми завжди можемо підключитися як локальний користувач. Проблема лише для користувачів домену (адміністратора та звичайних)
• ми можемо зв’язатися зі старими версіями mstsc.exe. Наприклад, ми можемо підключитися з комп'ютерів Windows 2003 та 2003 R2. Ми не можемо підключитися з Windows 7, Windows 8.1 та Windows 2012 R2.
  Якщо ми скопіюємо старий mstsc.exe (версія 5.2.xxxx) з Windows 2003 на новий комп'ютер, ми можемо підключити
• якщо ми підключаємося до старої версії mstsc.exe (як зазначено вище), то протягом декількох хвилин ми можемо підключитися з будь-якої версії, яку ми хочемо. Ми повинні знову використовувати стару версію після випадкової кількості часу (від 30 секунд до декількох годин)
• з останніми версіями mstsc.exe ми деколи не можемо з'єднати деяких користувачів, але це працює з іншими користувачами. Така поведінка зникає, як тільки ми використовуємо стару версію, і може з’явитися знову через 2 дні
• (завдяки відповіді Уоррена), якщо ми вручну додаємо enablecredsspsupport:i:0у файл .rdp, облікові дані не запитуються перед з'єднанням (тому поведінка така ж, як і у старих клієнтів), і ми можемо з'єднатися з будь-якою версією клієнта. Але ми не можемо автоматично підключитися, і процес входу передбачає кожен раз вибирати вхід як інший користувач (навіть якщо це той самий користувач)
• (завдяки Pathum Anjana) ми застосували додаткове оновлення KB2830477 з обох сторін з'єднань

Що ми тестували:

• ми протестували від локальної мережі до локальної та віддаленої до локальної. Без різниці
• ми відключили брандмауер
• ми перевірили відключення всіх функцій безпеки за допомогою gpedit.msc Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security
• ми ввімкнули аудит подій входу, і нічого не було в журналах. Нічого очевидного в інших журналах (як увімкнути журнали протоколів RDP?)
• ми протестували на одному комп’ютері, розташованому в іншій мережі (домени не пов'язані), на якому встановлено лише 7-zip. Без драйверів принтерів, без групової політики, нічого іншого. Це лише нова версія Windows 8.1. У нас точно така ж проблема
• ми запитали Google, і він сказав: "Я насправді не знаю". Зараз він направляє нас на цю сторінку, що є дуже хорошою відповіддю, але не дуже корисною
• ми видаляли всі оновлення до 25 лютого (за кілька днів до виникнення проблеми). Поліпшення не має, тому проблемою може бути наявне налаштування, встановлене на інше значення за допомогою недавнього оновлення (а не повернення назад, коли оновлення видалено, що, мабуть, звичайна поведінка)

Коли ми не можемо підключитися, повідомлення про помилку точно збігається з тим, яке ми отримуємо з неправильним паролем (але не входимо в журнал безпеки):

• кожен комп’ютер має дійсні ліцензії
• ми використовуємо MSE як антивірус
• деякі Windows 8.1 попередньо встановлені виробником (Lenovo), а інші встановлені нами. Єдиний загальний чинник, який я бачу, - це те, що ми ними керуємо

Будь-яке уявлення про те, що ми можемо зробити для вирішення цього питання?

Можливо, це пов’язано з KB2962806. Спробуйте застосувати його.
Я не знаю, як застосувати це оновлення, оскільки воно недоступне на сайті Microsoft. Я отримую це лише з автоматичного оновлення Windows, але не на всіх комп'ютерах.

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

Запрошення довіреності зводить мене з розуму протягом останніх кількох днів, і після ланцюжка останніх подій змушує мене повірити, що це пов'язано з KB3035017, який нещодавно встановили наші сервери RDP 2012.

Після пошуку цієї публікації та інших людей я натрапив на те, що поки що вирішує проблему.

Тестування піктограм RDP на моєму боці на одній машині дає помилку підказує помилку на одній і успішний вхід на інший.

http://www.boredsysadmin.com/2008/06/how-to-disable-credentials-prompt-of.html

Сподіваюся, що це допомагає іншим, я продовжуватиму моніторити та шукати правильне виправлення.

Ура

Він, ймовірно, працює зі старими клієнтами RDP, тому що він змушує зменшити версію протоколу там, де не виникає жодна проблема.

Я думаю, що це може бути пов'язано з роздільною здатністю екрана. Microsoft внесла досить багато змін, пов’язаних з роздільною здатністю екрана та обробкою декількох моніторів у RDP в Windows 8.1. Хоча ваші симптоми, схоже, не пов’язані з рішеннями, можливо, узгодження між програмою Windows 7 RDP і Windows 8.1 не вдається?

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

Перевірте, чи впливає зміна роздільної здатності екрана в клієнті RDP (зокрема, перехід між повноекранним режимом і конкретною роздільною здатністю, а також зміна налаштувань мультимонітора).

Більше про це можна прочитати тут: http://blogs.msdn.com/b/rds/archive/2013/12/16/resolution-and-scaling-level-updates-in-rdp-8-1.aspx

Враховуючи терміни побаченого, проблема може збігатися з патчем для CVE-2015-0079 . Бюлетень Microsoft, що стосується цієї вразливості, становить MS15-030, а фактичний виправлення проблеми доступний тут . Якщо цей патч встановлений у ваших системах, ви можете спробувати видалити його з однієї з них, щоб побачити, чи це не призведе до усунення проблеми.

Це був би не перший патч MS, який порушив певні комбінації RDP. Погляньте на це - зокрема про KB2984972.

Проблема, яку MS вирішує з виправленням, є потенційною атакою DoS - зазвичай це не велика проблема в офісному середовищі, але все ж.