A Mac rossz Windows-fiókot küld RDP-n keresztül

Az alagút újra csatlakozik, a Mac ismét eléri az irodai hálózatot, és a Távoli asztal továbbra is bejelentkezési hibával válaszol. Ez a hiba nem a VPN hibája. Az alagút engedélyezett hálózatra viszi a Macet; a távoli számítógépre Windows-fiók jelentkezik be, és a kapcsolatbejegyzés továbbra is küldhet egy fiókot, amelyet hónapokkal ezelőtt abbahagyott használni.

Nézze át a bejegyzést, mielőtt a kulcskarikához nyúl.

A VPN-fiók és a Windows-fiók két külön dolog

A VPN-identitás az eszközt vagy a személyt hitelesíti az alagút átjárójánál. Semmit nem mond arról, hogy a távoli gazdagép melyik Windows-fiókot fogadja el, és nem helyettesítheti azt. Amikor az alagút egészséges, és az asztal elutasítja a bejelentkezést, a probléma már túllépett a hálózati rétegen. Kezelje a két hitelesítést külön eseményként, külön naplókkal. Az átjáró tiszta munkamenetet mutathat, miközben a Windows biztonsági naplója teljesen más okból rögzít sikertelen bejelentkezést.

Tegyük fel, hogy az adminisztrátor azt mondta, használja a EXAMPLE\alex azonosítót, a mentett bejegyzés viszont továbbra is egy csupasz alex nevet választ. Ezek különböző fiókok. A minősítés nélküli nevet a távoli számítógép helyi fiókjaihoz oldja fel a rendszer, és egy tartományhoz csatlakoztatott gépen lehet, hogy egyáltalán nem oldódik fel a tartomány identitására.

A tartományi előtag eltávolítása tehát nem általános javítás. Megváltoztatja, melyik fiókot kéri a rendszer, és olyan elutasítást okozhat, amely jelszóproblémának látszik, holott a jelszó soha nem volt a kérdés.

A kapcsolatbejegyzést nyissa meg, ne az egész kulcskarikát

A macOS-hez készült jelenlegi Windows Appban keresse meg a távoli PC-t az Eszközök alatt, nyissa meg a Szerkesztés műveletét, és nézze meg az ehhez a konkrét bejegyzéshez kapcsolt fiókot. Az alkalmazás mentett hitelesítőadat-vezérlőket kínál, amelyekkel másik mentett fiókot választhat, vagy eltávolíthat egy elavultat. Ez a támogatott hely a kiválasztás javítására. Egyszerre egy tulajdonságot módosítson, hogy tudja, melyik szerkesztés számított valóban. A hitelesítő adatok módosítása és a gazdagépnév módosítása együtt olyan eredményt ad, amelyet senki nem tud visszavezetni.

Ne kezdje azzal, hogy töröl minden kulcskarikaelemet, amelynek nevében szerepel a kiszolgáló neve. A kulcskarikaelemek alkalmazások között megosztottak, és egy széles törlés eltávolíthat nem kapcsolódó hozzáférést anélkül, hogy bármit változtatna a Windows oldalán. Tönkreteszi a bizonyítékokat is, amelyekre szüksége lenne, ha a valódi probléma a gazdagépnév, az útvonal vagy az RDP-szolgáltatás.

Ha egy mentett hitelesítő adatot több távoli PC használ, ellenőrizze ezeket a függőségeket az eltávolítás előtt. Egy PC bejegyzésének szerkesztése visszafordítható; egy megosztott hitelesítő adat törlése szélesebb hatókörű és rosszabb auditnyomú változás.

Használja az adminisztrátor által megadott fiókformát

Írja be a fiókot pontosan úgy, ahogy kiadták, abban a formában, amelyet a környezet elvár: DOMAIN\user NetBIOS-stílusú tartományhoz, vagy a user principal name, ha ezt használja a címtár. Ezután mentse ehhez a PC-hez, és tegyen egyetlen szándékos kapcsolódási kísérletet.

Figyelje, melyik fiókot mutatja a bejelentkezési kérés. Ha a kérés már más nevet tartalmaz, a mentett kiválasztás nem cserélődött le, és az iménti kísérlet ismét a régi hitelesítő adatot tesztelte.

Tartsa a jelszót távol a jegyzetektől, jegyektől és képernyőképektől. Jegyezze fel helyette a fióknevet és a pontos hibakódot, mert a kód megkülönbözteti a rossz hitelesítő adatot a szabályzati elutasítástól, a lejárt jelszótól vagy a géptől, amely egyáltalán nem fogad el RDP-t.

A bejelentkezés előtti sikertelen kapcsolódás más hiba

Ha a nézegető a bejelentkezés előtt meghiúsul, mielőtt bármilyen Windows-bejelentkezés megjelenne, nem a hitelesítő adatok a gyanúsak. Ellenőrizze, hogy a gazdagépnév feloldódik, hogy az útvonal a gazdagéphez az alagúton keresztül létezik, és hogy az RDP-szolgáltatás figyel. Az a TCP-kapcsolat, amely soha nem jön létre, soha nem éri el a fiókréteget.

Fordítva, egy kifejezett fiókelutasítás nem bizonyíték arra, hogy a DNS meghibásodott, vagy hogy lazítani kellene a tanúsítvány-érvényesítésen. Az ilyen változtatások gyengítik a kapcsolatot, és általában pontosan ott hagyják az elutasítást, ahol volt.

A lehető legkisebb lépésekben teszteljen: erősítse meg, hogy a port elérhető, hogy megjelenik a bejelentkezési kérés, hogy a megjelenített fiók az, amelyet szándékozik, majd adja meg a jelszót. Minden lépésnek külön hibája és külön javítása van.

Hagyja békén az automatikus újracsatlakozást

Az automatikus újracsatlakozás a meglévő bejegyzést használja újra, a mentett fiókjával együtt. Ez kényelem, nem hitelesítőadat-javítás, ezért a kikapcsolása nem javítja a rossz kiválasztást, a bekapcsolása pedig nem hoz létre egyet. Ha a bejegyzés most a helyes fiókot tartalmazza, az újracsatlakozás azt fogja használni.

Mentse a javított bejegyzést, csatlakozzon egyszer kézzel, és jegyezze fel, melyik fiók működött. Pontosan ez az egy sor teszi a következő ember diagnózisát ötpercessé egy délutáni kulcskarikás régészet helyett.