Вашият Mac изпраща грешен профил на Windows през RDP
Здравият тунел и отхвърленото влизане в работния плот са различни слоеве. Проверете профила, запазен за този отдалечен компютър, преди да изтриете нещо от ключодържателя.
Тунелът се свързва отново, Mac отново достига офисната мрежа, а Remote Desktop все още отговаря с неуспешно влизане. Тази грешка не е на 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 е счупен или че проверката на сертификата трябва да се облекчи. Такива промени отслабват връзката и обикновено оставят отказа точно там, където е бил.
Тествайте на възможно най-малки стъпки: потвърдете, че портът е достъпен, че подканата за влизане се появява, че показаният профил е този, който искате, след което въведете паролата. Всяка стъпка има отделна повреда и отделно решение.
Оставете автоматичното повторно свързване на мира
Автоматичното повторно свързване използва съществуващия запис, включително запазения профил. То е удобство, а не ремонт на идентификационни данни, така че изключването му не поправя грешен избор, а включването му не създава такъв. Ако записът вече съдържа правилния профил, повторното свързване ще го използва.
Запазете коригирания запис, свържете се веднъж ръчно и отбележете кой профил е проработил. Точно този ред превръща диагностиката на следващия човек в пет минути вместо в следобед на ключодържателна археология.