Ĉu domajna fido malsukcesis post monato senrete? Kontrolu unue

Tekkomputilo restas ses semajnojn ekster la VPN, revenas, kaj la uzanto ne povas ensaluti per domajna konto. La eraro mencias fidan rilaton, do iu restarigas la komputilan konton aŭ devigas la uzanton al plena tunelado, kaj la problemo ŝajne malaperas. Neniu el la du agoj pruvis, kio rompiĝis. Windows-membro povas resti senrete multe preter la kutima maŝina pasvorta intervalo sen aŭtomate perdi fidon, do la unua tasko estas apartigi atingomalsukceson de vera malkongruo de la sekreto.

La eraro aspektas kiel fido, sed tri statoj similas

Uzanto povas ensaluti per kaŝmemorigitaj domajnaj informoj, la laborstacio eble ne trovos domajnan regilon, aŭ la membro kaj la domajno eble vere malkonsentos pri la komputila konto. Nur la tria estas rompita fida rilato en la strikta senco.

La sano de AD-replikado estas kvara observo, kaj ĝi tute ne temas pri ĉi tiu laborstacio. Ĝi priskribas interkonsenton inter domajnaj regiloj, kaj sana replikada panelo ne pruvas, ke la loka sekreto de ĉi tiu maŝino kongruas kun ĝia komputila konto.

La konata defaŭlto de 30 tagoj estas ŝanĝa politiko, ne senreta finiĝa limdato. La klarigo de Microsoft pri la maŝinkonta pasvorto priskribas kunordigitan ŝanĝan procezon, kaj organizo povas agordi alian intervalon.

VPN-ikono pruvas nenion pri la sekura kanalo

La konektebleco devas esti sufiĉe bona por atingi domajnajn servojn antaŭ ol iu ajn testo signifas ion. Tio signifas la celitan DNS-risolvilon de la domajno, troveblan regilon, atingeblajn aŭtentikigajn servojn kaj horloĝon sufiĉe proksiman por Kerberos.

Plena tunelado povas esti tute valida dezajno ĉi tie. Ŝanĝi al dividita tunelado ne estas antaŭkondiĉo por sana domajna rilato, kaj trakti ĝin kiel tian transformas diagnozon en arkitekturan ŝanĝon. Kontrolu, kiun regilon la laborstacio efektive elektas, kaj konservu tiun nomon kun la eraro.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

Notu la DNS-servilon, la solvitan regilon kaj la precizan erarotekston. VPN-kliento, kiu raportas konekton, diras al vi, ke la tunelo ekzistas, ne ke la domajna vojo funkcias. Regilo, kiu respondas sur la Kerberos-pordo sed ne sur la dosieruja pordo, estas trovitaĵo de fajroŝirmilo, ne de fido.

Testu la membron antaŭ ol ripari ĝin

Sur rajtigita Windows-domajna membro, Test-ComputerSecureChannel -Verbose estas nurlega kontrolo de la kanalo inter la maŝino kaj la domajno. Rulu ĝin en la maŝina kunteksto, kiun vi esploras, ne de domajna regilo, kiu havas alian rolon kaj aliajn riparajn regulojn. Kaptu la eligon kaj la eliran staton anstataŭ la vorton sukcesis aŭ malsukcesis. Se la cmdlet mankas en tiu versio, la modulo estas aparta problemo.

La rezulto ankoraŭ bezonas kuntekston. Se la maŝino ne povas atingi aŭ aŭtentikigi al la elektita regilo, malsukcesa testo ne estas sendependa pruvo, ke senreta pasvorto eksvalidiĝis. Konservu la faktan eraron kaj la uzitan regilon, kaj ripetu la teston post kiam la vojo estas konata bona.

Korelaciu Netlogon-okazaĵojn sur la membro kaj sur la koncerna regilo ĉirkaŭ la incidento. Konservu la maŝinan nomon, la fontan adreson, la tempon kaj ajnan pruvon de konta ŝanĝo. La sukcesa ensaluto de alia uzanto, aŭ sana regila panelo, ne povas anstataŭigi la interŝanĝon de ĉi tiu maŝino.

Riparu nur la rilaton, kiun vi pruvis

Post kiam la konektebleco estas stabila kaj administranto konfirmis, ke riparo taŭgas, la reĝimo -Repair de la cmdlet kun rajtigitaj akreditaĵoj estas unu subtenata operacio por membra laborstacio. Ĝi ŝanĝas la rilaton, kaj ĝi ne estas alia nurlega testo.

Antaŭ la ŝanĝo tenu pretan aprobitan lokan reakirakonton kaj administran vojon. Domajnaj regiloj havas alian reakiran rolon kaj ne rajtas esti traktataj kiel ordinaraj laborstacioj de ĉi tiu procedo. Uzu la reakiran laborfluon de la organizo anstataŭ sekve ruli plurajn restarigilojn kaj esperi, ke unu el ili estas la ĝusta.

Post la riparo kontrolu novan teston de la sekura kanalo kaj la originalan domajnan operacion. Konservu uzantprofilojn kaj aplikaĵan staton, kaj ne faru forigi-kaj-realiĝi la unuan neklarigitan agon.

Kion kontroli, kiam la malsukceso revenos

Se la malsukceso revenas, rigardu restarigon al antaŭa stato, duoblan identecon kaj la tempon de kontaj ŝanĝoj anstataŭ restarigi la saman konton denove. Restaŭrita bildo, momentkopiaĵo, klonita maŝina identeco aŭ komputila konta restarigo farita aliloke ĉiuj meritas esploron.

Portempe sukcesa restarigo estas utila reakira pruvo, sed ĝi ne pruvas, ke intermita VPN kaŭzis la originalan malkongruon. La sekva okazo estas tiu, kiu diras al vi, ĉu la kaŭzo iam estis forigita.

Skribu la regilon, la DNS-servilon kaj la testan eligon en la bileton. Tiu registro estas tio, kio distingas veran fidan malsukceson de tekkomputilo, kiu simple ne povis trovi la domajnon.