La tunelo rekonektiĝas, la Mac denove atingas la oficejan reton, kaj Remote Desktop ankoraŭ respondas per malsukcesa ensaluto. Tiu eraro ne estas de la VPN. La tunelo venigas la Mac en aprobitan reton; Windows-konto ensalutas la foran komputilon, kaj la konekta ero povas daŭre sendi konton, kiun vi ĉesis uzi antaŭ monatoj.

Trairu la eron antaŭ ol tuŝi la ŝlosilujon.

La VPN-konto kaj la Windows-konto estas malsamaj aferoj

VPN-identeco aŭtentikigas la aparaton aŭ la personon ĉe la pordego de la tunelo. Ĝi diras nenion pri tio, kiun Windows-konton la fora gastiganto akceptos, kaj ĝi ne povas anstataŭi ĝin. Kiam la tunelo estas sana kaj la labortablo rifuzas la ensaluton, la problemo jam pasis la retan tavolon. Traktu la du aŭtentikigojn kiel apartajn eventojn kun apartaj protokoloj. La pordego povas montri puran seancon dum la sekureca protokolo de Windows registras malsukcesan ensaluton pro tute alia kaŭzo.

Supozu, ke la administranto diris al vi uzi EXAMPLE\alex kaj la konservita ero ankoraŭ elektas nudan alex. Tiuj estas malsamaj kontoj. La nekvalifikita nomo estas solvata kontraŭ la lokaj kontoj de la fora komputilo, kaj sur domajne ligita maŝino ĝi eble tute ne solviĝos al la domajna identeco.

Forigi la domajnan prefikson do ne estas ĝenerala riparo. Ĝi ŝanĝas, kiun konton oni petas, kaj ĝi povas produkti rifuzon, kiu aspektas kiel pasvorta problemo, dum la pasvorto neniam estis la afero.

Malfermu la konektan eron, ne la tutan ŝlosilujon

En la nuna Windows App por macOS, trovu la foran komputilon sub Aparatoj, malfermu ĝian agon Redakti kaj rigardu la konton ligitan al tiu specifa ero. La aplikaĵo montras regilojn de konservitaj akreditaĵoj, kiuj lasas vin elekti alian konservitan konton aŭ forigi eksvalidiĝintan. Tio estas la subtenata loko por korekti la elekton. Ŝanĝu unu econ samtempe, por ke vi sciu, kiu redakto vere gravis. Akreditaĵa ŝanĝo kaj gastigantnoma ŝanĝo faritaj kune produktas rezulton, kiun neniu povas atribui.

Ne komencu forigante ĉiun ŝlosilujan eron, kies nomo enhavas la servilan nomon. Ŝlosilujaj eroj estas kunhavataj inter aplikaĵoj, kaj vasta forigo povas forpreni nerilatan aliron sen ŝanĝi ion ajn ĉe la Windows-flanko. Ĝi ankaŭ detruas la pruvojn, kiujn vi volus, se la vera problemo montriĝos la gastigantnomo, la vojo aŭ la RDP-servo.

Se unu konservita akreditaĵo estas uzata de pluraj foraj komputiloj, kontrolu tiujn dependecojn antaŭ ol forigi ĝin. Redakti la eron de unu komputilo estas reigebla; forigi kunhavatan akreditaĵon estas ŝanĝo kun pli vasta efiko kaj pli malbona revizia spuro.

Uzu la kontformon, kiun la administranto donis

Tajpu la konton ĝuste tiel, kiel ĝi estis eldonita, en la formo, kiun la medio atendas: DOMAIN\user por domajno laŭ NetBIOS-stilo, aŭ la user principal name se tio estas, kion la adresaro uzas. Poste konservu ĝin por ĉi tiu komputilo kaj faru unu intencan konektoprovan.

Rigardu, kiun konton la ensaluta invito montras. Invito, kiu jam enhavas alian nomon, signifas, ke la konservita elekto ne estis anstataŭigita, kaj la provo, kiun vi ĵus faris, denove testis la malnovan akreditaĵon.

Tenu la pasvorton ekster notoj, biletoj kaj ekrankopioj. Anstataŭe notu la kontnomon kaj la ĝustan erarkodon, ĉar la kodo distingas malbonan akreditaĵon de politika rifuzo, eksvalidiĝinta pasvorto aŭ maŝino, kiu tute ne akceptas RDP.

Malsukcesa konekto antaŭ ensaluto estas alia fuŝo

Se la rigardilo malsukcesas antaŭ ol aperas iu ajn Windows-ensaluto, la akreditaĵoj ne estas la suspektato. Kontrolu, ke la gastigantnomo solviĝas, ke la vojo al la gastiganto ekzistas tra la tunelo kaj ke la RDP-servo aŭskultas. TCP-konekto, kiu neniam establiĝas, neniam atingas la kontan tavolon.

Inverse, eksplicita kontrifuzo ne estas pruvo, ke DNS estas rompita aŭ ke atestila validigo devus malstriktiĝi. Tiaj ŝanĝoj malfortigas la konekton kaj kutime lasas la rifuzon ĝuste tie, kie ĝi estis.

Testu per la plej malgrandaj eblaj paŝoj: konfirmu, ke la pordo atingeblas, ke la ensaluta invito aperas, ke la montrata konto estas la intencata, kaj poste donu la pasvorton. Ĉiu paŝo havas apartan fuŝon kaj apartan riparon.

Lasu aŭtomatan rekonekton trankvila

Aŭtomata rekonekto reuzas la ekzistantan eron, inkluzive de ĝia konservita konto. Ĝi estas oportuneco, ne akreditaĵa riparo, do malŝalti ĝin ne korektas malĝustan elekton kaj ŝalti ĝin ne kreas unu. Se la ero nun tenas la ĝustan konton, rekonekto uzos ĝin.

Konservu la korektitan eron, konektu unufoje permane kaj notu, kiu konto funkciis. Ĝuste tiu unu linio faras la diagnozon de la sekva persono kvinminuta anstataŭ posttagmezo da ŝlosiluja arkeologio.

Rilataj artikoloj