Aliĝi al domajno per uzanta VPN, poste postvivi la restarton

Vi povas plenumi domajnan aliĝon per punkto-al-eja VPN. Kion tiu konekto kutime ne povas fari, estas resti aktiva tra la sekva restarto, kiam la unua domajna uzanto provas ensaluti. Mi nun trairas la aliĝon en tri etapoj: pruvi la vojon kaj la eltrovon dum lokala administranto estas ensalutinta, plenumi la aliĝon, kaj poste testi la unuan domajnan ensaluton antaŭ ol mi transdonos la tekkomputilon. Ĉiu etapo havas teston, kiu malsukcesas aliloke.

La apartigo de tiuj etapoj estas tio, kio malhelpas la projekton finiĝi per tekkomputilo, kiu sukcese aliĝis kaj ne povas esti uzata.

Antaŭ ol konekti: eldono, loka administranto, DNS

La maŝino bezonas eldonon, kiu subtenas domajnan aliĝon, kaj lokalan administranton, kiu rajtas plenumi ĝin. La VPN devas esti aktiva en la sama seanco, ĉar la aliĝo ruliĝas en la sekureca kunteksto, kiun vi uzas.

Direktu la klienton al la kataloga DNS de la organizaĵo, ne al publika solvilo kaj ne al kontribuaĵo en la hosts-dosiero. La aliĝo devas trovi la servajn rikordojn kaj poste atingi la gastigantojn, kiujn tiuj rikordoj nomas. Malnova sufikso aŭ publika solvilo sendas la eltrovon tute aliloken.

Kontrolu ankaŭ la horloĝon. Kerberos ne toleras tempan malsamaron, kaj tekkomputilo, kiu estis eksterrete dum monato, estas ofta kaŭzo de konfuzaj aliĝaj eraroj.

Konfirmu, ke la domajno estas eltrovebla, ne nur pingeble

Solvu la LDAP SRV-rikordon de la domajno antaŭ ol provi la aliĝon. Por ilustra unu-domajna medio nomita ad.corp.example, la demando estas:

Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.ad.corp.example

Redonita rikordo estas necesa sed ne sufiĉa. Solvu ĉiun DC-nomon, kiun ĝi listigas, kaj konfirmu, ke vi atingas la bezonatajn servojn tra la tunelo. Ping al la domajna nomo pruvas preskaŭ nenion pri eltrovo.

Permesu la dokumentitajn AD-dependecon: aŭtentikigon, SMB- kaj RPC-trafikon, kaj tempan sinkronigon. Kontrolu ĉiun el ili laŭ la fajroŝirmaj reguloj, kiujn vi efektive deplojis. Publikigi la pordojn de la domajna regilo al la interreto ne estas ŝparvojo inda je konsidero.

Plenumu la aliĝon kaj legu la eraron

Uzu la subtenatan aliĝan komandon aŭ la sisteman dialogon, kaj registru la ĝustan erartekston. „La indikita domajno aŭ ne ekzistas aŭ ne eblis kontakti ĝin“ indikas eltrovon aŭ atingeblon, ne akreditaĵojn.

Se objekto kun la sama nomo jam ekzistas, ne forigu ĝin per reflekso. Ĝi povas esti antaŭpreparita konto, kaj malmoligo de netjoin limigas kelkajn reuzajn kazojn laŭ posedado kaj politiko. Petu la katalogposedanton inspekti aŭ korekti la objekton.

Sukcesa aliĝo estas la mezpunkto, ne la finlinio. La sekva paŝo estas tiu, kiun la uzanto efektive testas.

Planu la unuan domajnan ensaluton

Kompletigita aliĝo ne kreas kaŝmemoritajn akreditaĵojn por ĉiu domajna uzanto. Ĉe la unua ensaluta ekrano, la tekkomputilo bezonas vojon al DC antaŭ ol iu ajn uzanto ensalutis. Se via uzanta VPN ekfunkcias nur post ensaluto, tiu vojo mankas. Tio estas manko en la dezajno, ne klienta cimo.

Uzu subtenatan antaŭ-ensalutan aŭ aparat-tunelan laborfluon, ekzistantan ejan vojon aŭ aprobitan alternativon por tiu unua ensaluto. Poste testu la tutan sinsekvon: restartu, atingi la akreditaĵan ekranon, ensalutu kiel la celata domajna uzanto, kaj konfirmu, ke la tunelo kondutas laŭ la dezajno.

Uzantŝanĝo kaj VPN-daŭro varias laŭ kliento. Ne supozu, ke konekto startigita kiel loka administranto postvivos en la seanco de alia uzanto.

Konservu lokan reakiran aliron

Konservu aprobitan lokan reakiran vojon antaŭ ol transdoni la tekkomputilon. Se la unua domajna ensaluto malsukcesas, vi volas vojon reen, kiu ne dependas de la sama tunelo, kiu ĵus malsukcesis.

Skribu, kion vi pruvis: SRV-solvon, DC-atingeblon, la aliĝan eraron, la metodon de la unua ensaluto kaj la reakiran konton. Tiu registro estas la diferenco inter ripetebla konstruo kaj tekkomputilo, kiu funkcias nur en la oficejo.