Kumokonekta muli ang tunnel, naaabot muli ng Mac ang network ng opisina, at sumasagot pa rin ang Remote Desktop nang may pagkabigo sa pag-login. Ang error na iyon ay hindi ng VPN. Dinadala ng tunnel ang Mac sa isang aprubadong network; isang Windows account ang naglo-log in sa remote na computer, at ang entry ng koneksyon ay maaaring patuloy na magpadala ng account na itinigil mong gamitin ilang buwan na ang nakalipas.

Suriin ang entry bago hawakan ang keychain.

Ang VPN account at ang Windows account ay magkaibang bagay

Ang pagkakakilanlang VPN ay nagpapatunay ng device o tao sa gateway ng tunnel. Wala itong sinasabi tungkol sa kung aling Windows account ang tatanggapin ng remote host, at hindi ito maaaring pumalit. Kapag malusog ang tunnel at tinatanggihan ng desktop ang pag-login, nalampasan na ng problema ang network layer. Ituring ang dalawang pagpapatunay bilang magkaibang kaganapan na may magkaibang log. Maaaring magpakita ang gateway ng malinis na session habang ang log ng seguridad ng Windows ay nagtatala ng nabigong pag-login dahil sa lubos na ibang dahilan.

Ipagpalagay na sinabi ng administrator na gamitin mo ang EXAMPLE\alex at ang nakaimbak na entry ay pumipili pa rin ng hubad na alex. Magkaibang account iyon. Ang hindi kwalipikadong pangalan ay nireresolba laban sa mga lokal na account ng remote na computer, at sa makinang kabilang sa domain ay maaaring hindi ito maresolba sa pagkakakilanlan ng domain.

Kaya ang pag-alis ng domain prefix ay hindi pangkalahatang pag-aayos. Binabago nito kung aling account ang hinihiling, at maaari itong gumawa ng pagtanggi na mukhang problema sa password habang hindi naman kailanman naging isyu ang password.

Buksan ang entry ng koneksyon, hindi ang buong keychain

Sa kasalukuyang Windows App para sa macOS, hanapin ang remote PC sa ilalim ng Mga Device, buksan ang aksyong I-edit at tingnan ang account na nakakabit sa partikular na entry na iyon. Nagpapakita ang app ng mga kontrol ng nakaimbak na kredensyal na nagbibigay-daan sa iyong pumili ng ibang nakaimbak na account o mag-alis ng lipas na. Ito ang sinusuportahang lugar para itama ang pagpili. Baguhin ang isang property sa isang pagkakataon, para malaman mo kung aling pagbabago ang talagang mahalaga. Ang pagbabago ng kredensyal at pagbabago ng hostname na ginawa nang sabay ay gumagawa ng resultang walang makapag-uugnay.

Huwag magsimula sa pagbura ng bawat item sa keychain na may pangalan ng server. Ang mga item sa keychain ay hinahati sa mga app, at ang malawak na pagbura ay maaaring mag-alis ng walang kaugnayang access nang walang binabago sa panig ng Windows. Sinisira rin nito ang ebidensiyang kakailanganin mo kung ang tunay na problema pala ay ang hostname, ruta o serbisyo ng RDP.

Kung isang nakaimbak na kredensyal ang ginagamit ng maraming remote PC, suriin ang mga dependency na iyon bago ito alisin. Ang pag-edit ng entry ng isang PC ay maibabalik; ang pagbura ng pinagsasaluhang kredensyal ay pagbabagong may mas malawak na epekto at mas masamang audit trail.

Gamitin ang anyo ng account na ibinigay ng administrator

I-type ang account nang eksakto ayon sa inilabas, sa anyong inaasahan ng kapaligiran: DOMAIN\user para sa domain na istilong NetBIOS, o ang user principal name kung iyon ang ginagamit ng direktoryo. Pagkatapos ay i-save ito para sa PC na ito at gumawa ng isang sadyang pagtatangkang kumonekta.

Pansinin kung aling account ang ipinapakita ng prompt ng pag-sign in. Ang prompt na may ibang pangalan na ay nangangahulugang hindi napalitan ang nakaimbak na pagpili, at ang pagtatangka na ginawa mo lang ay muling sinubukan ang lumang kredensyal.

Ilayo ang password sa mga tala, ticket at screenshot. Itala sa halip ang pangalan ng account at ang eksaktong error code, dahil ipinag-iiba ng code ang masamang kredensyal sa pagtanggi ng patakaran, nag-expire na password, o makinang hindi tumatanggap ng RDP.

Ang nabigong koneksyon bago mag-login ay ibang depekto

Kung nabigo ang viewer bago lumitaw ang anumang pag-login ng Windows, hindi ang kredensyal ang pinaghihinalaang. Suriin kung nireresolba ang hostname, kung may ruta patungo sa host sa ibabaw ng tunnel, at kung nakikinig ang serbisyo ng RDP. Ang koneksyong TCP na hindi kailanman nabubuo ay hindi kailanman umaabot sa layer ng account.

Sa kabaligtaran, ang tahasang pagtanggi ng account ay hindi ebidensiya na sira ang DNS o dapat luwagan ang pagpapatunay ng certificate. Ang mga pagbabagong iyon ay nagpapahina sa koneksyon at karaniwang iniiwan ang pagtanggi sa mismong kinaroroonan nito.

Subukin sa pinakamaliit na hakbang: tiyakin na maabot ang port, lumilitaw ang prompt ng pag-sign in, ang ipinakitang account ay ang nilalayon mo, pagkatapos ay ibigay ang password. Ang bawat hakbang ay may natatanging pagkabigo at natatanging pag-aayos.

Hayaang mapayapa ang awtomatikong muling pagkonekta

Ginagamit muli ng awtomatikong muling pagkonekta ang umiiral na entry, kasama ang nakaimbak na account nito. Ito ay kaginhawahan, hindi pag-aayos ng kredensyal, kaya ang pag-off nito ay hindi nagwawasto ng maling pagpili at ang pag-on nito ay hindi gumagawa ng isa. Kung may tamang account na ang entry, gagamitin iyon ng muling pagkonekta.

I-save ang naitamang entry, kumonekta nang isang beses nang manwal at itala kung aling account ang gumana. Ang nag-iisang linyang iyon ang nagpapaging-limang-minuto sa diagnosis ng susunod na tao sa halip na isang hapon ng arkeolohiya sa keychain.

Kaugnay na mga artikulo