Ваш Mac надсилає неправильний обліковий запис Windows через RDP

Тунель перепідключається, Mac знову потрапляє в офісну мережу, а «Віддалений робочий стіл» усе ще відповідає помилкою входу. Ця помилка не від VPN. Тунель виводить Mac у дозволену мережу; на віддалений комп'ютер входить обліковий запис Windows, і запис з'єднання може продовжувати надсилати обліковий запис, яким ви перестали користуватися кілька місяців тому.

Перегляньте запис, перш ніж торкатися зв'язки ключів.

Обліковий запис VPN і обліковий запис Windows — різні речі

Ідентичність VPN автентифікує пристрій або людину на шлюзі тунелю. Вона нічого не каже про те, який обліковий запис Windows прийме віддалений хост, і не може його замінити. Коли тунель здоровий, а робочий стіл відхиляє вхід, проблема вже вийшла за межі мережевого рівня. Розглядайте обидві автентифікації як окремі події з окремими журналами. Шлюз може показувати чисту сесію, тоді як журнал безпеки Windows фіксує невдалий вхід зовсім з іншої причини.

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

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

Відкрийте запис з'єднання, а не всю зв'язку ключів

У поточному Windows App для macOS знайдіть віддалений ПК у розділі «Пристрої», відкрийте дію «Редагувати» і подивіться на обліковий запис, прив'язаний саме до цього запису. Застосунок показує елементи керування збереженими обліковими даними, які дають змогу вибрати інший збережений обліковий запис або вилучити застарілий. Це підтримуване місце для виправлення вибору. Змінюйте по одній властивості за раз, щоб знати, яка зміна справді мала значення. Зміна облікових даних і зміна імені хоста, зроблені разом, дають результат, який ніхто не зможе приписати.

Не починайте з видалення кожного елемента зв'язки ключів, в імені якого є ім'я сервера. Елементи зв'язки ключів спільні для застосунків, і широке видалення може прибрати сторонній доступ, нічого не змінивши на боці Windows. Воно також знищує докази, які знадобляться, якщо справжньою проблемою виявиться ім'я хоста, маршрут або служба RDP.

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

Використовуйте ту форму облікового запису, яку надав адміністратор

Введіть обліковий запис точно так, як його було видано, у формі, яку очікує середовище: DOMAIN\user для домену в стилі NetBIOS або user principal name, якщо саме це використовує каталог. Потім збережіть його для цього ПК і зробіть одну свідому спробу підключення.

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

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

Невдале підключення до входу — це інша несправність

Якщо засіб перегляду збоїть до появи будь-якого входу Windows, облікові дані не є підозрюваними. Перевірте, чи розв'язується ім'я хоста, чи існує маршрут до хоста через тунель і чи прослуховує служба RDP. TCP-з'єднання, яке так і не встановлюється, ніколи не досягає рівня облікового запису.

І навпаки, явна відмова облікового запису не є доказом, що DNS зламано або що перевірку сертифікатів слід послабити. Такі зміни послаблюють з'єднання і зазвичай залишають відмову рівно там, де вона була.

Перевіряйте найменшими можливими кроками: переконайтеся, що порт доступний, що запит на вхід з'являється, що показано потрібний обліковий запис, а потім введіть пароль. Кожен крок має окрему несправність і окреме виправлення.

Залиште автоматичне перепідключення в спокої

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

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