Rekonekti Windows-VPN sen meti la pasvorton en la taskon

Ĉiu recepto pri senhoma rekonekto fine alvenas al la sama demando: kie loĝas la pasvorto. La populara respondo estas la taska ago mem, kiu ankaŭ estas la plej malbona loko por ĝi. Ekzistas du aliaj dezajnoj. Kiu taŭgas dependas de tio, ĉu la maŝino povas aŭtentigi sen persono kaj ĉu la servilo akceptas atestilojn.

Kion taska ago lasas legebla

Argumentoj en planita tasko estas parto de ĝia difino, ne kaŝita rultempa valoro. Ĉiu, kiu povas legi la taskon, restarigi ĝian sekurkopion aŭ eksporti ĝian XML, vidas la ĉenon ĝuste tiel, kiel vi tajpis ĝin. Dum rulo la sama ĉeno aperas en la proceza listo. Monitora agento povas kopii ĝin en protokolon, kiun vi neniam revizias.

schtasks /query /tn "VPN Reconnect" /xml
cmdkey /list

Kontrolu antaŭ ol supozi la malon. La unua komando presas la plenan difinon, inkluzive de la ago kaj ĝiaj argumentoj. La dua montras, kiujn akreditaĵojn la aktuala konto kaŝmemorigis, kio gravas por la alternativaj dezajnoj sube. Se la pasvorto aperas en la XML de la tasko, ĝia rotacio estas nur duono de la riparo, ĉar la tasko ankoraŭ tenas la malnovan valoron.

Kion vere aĉetas konservita antaŭe dividita ŝlosilo

Add-VpnConnection -L2tpPsk skribas la ŝlosilon en la telefonlibran enskribon de la konekto anstataŭ en taskon. Tio estas pli malgranda ekspona surfaco ol taska ago. Ĝi tamen restas rekuperebla sekreto, ĉar administranto sur la maŝino povas legi la telefonlibron.

Por laboratoria ligo inter du maŝinoj, kiujn vi regas, tiu interŝanĝo povas esti akceptebla. Por uzanta akreditaĵo sur dividita finpunkto ĝi ne estas. Nomante ĝin ĉifrita stokado oni ne ŝanĝas, kiu povas legi ĝin. La telefonlibro estas agorda dosiero. Planu por la persono, kiu povas malfermi ĝin, ne nur por la persono, kiu povas saluti kiel la uzanto.

Winlogon-akreditaĵoj forigas la sekreton kaj aldonas dependecon

-UseWinlogonCredential sekvas alian vojon. La konekto aŭtentigas per MSCHAPv2 kontraŭ la akreditaĵoj de la salutinta uzanto. Nenio kroma estas konservita por tiu konto.

La dependeco, kiun ĝi aldonas, estas signifa. Devas ekzisti interaga saluto, el kiu prunti, kio ekskludas servan konton kaj taskon antaŭ saluto. La konekto ankaŭ heredas ĉion, kion la akreditaĵoj de tiu uzanto povas atingi sur la servilo. Legu la ŝaltilon kiel aserton pri tio, de kie venas la akreditaĵo, ne kiel sekurecan agordon. Ĝi ŝanĝas la fonton kaj nenion pri tio, kiel la servilo poste rajtigas la seancon.

Atestila aŭtentigo skalas ĉar nenio estas konservita

Kie la servilo subtenas EAP-TLS, maŝina atestilo tute forigas la dividitan sekreton, kaj revoko okazas ĉe la atestila tavolo. Tasko rulanta kiel SYSTEM povas prezenti tiun atestilon sen interaga saluto. Konfirmu, ke la servilo akceptas atestilan aŭtentigon antaŭ ol konstrui sur ĝi. Dezajno dependanta de nesubtenita metodo estas plano anstataŭ solvo. Poste decidu, kie loĝas la privata ŝlosilo: la maŝina konservejo por aparata identeco, la uzanta konservejo por persono.

Kie uzantnomo kaj pasvorto neeviteblas, konservu ilin en Credential Manager limigitaj al la propra konto de la tasko. Lasu la klienton legi ilin de tie anstataŭ el argumento. Sekreto, kiun la tasko povas preni sen presi ĝin, estas pli malgranda problemo ol unu skribita en ĝian difinon.

Revizu la artefaktojn antaŭ la sekva rotacio

Rigardu tion, kio estas konservita, anstataŭ tion, kion vi intencis. Kontrolu la telefonlibron por uzanto, la kopion por ĉiuj uzantoj, la XML de la tasko kaj ĉiun skripton, kiu vokas la vokkomandon. Poste konfirmu, ke la atestilo aŭ la kaŝmemorigitaj akreditaĵoj limiĝas al la konto, kiun la tasko uzas, ĉar akreditaĵo konservita por via interaga konto estas nevidebla al SYSTEM.

Notu la aŭtentigan metodon kaj la konton en la propraj notoj de la tasko. La sekva persono, kiu ŝanĝos la politikon de la servilo, devas scii, kiu dezajno estas en ludo. Tiu respondo ne videblas nur el la rekonekta konduto. Skribu ĝin tie, kie la sekva rotacio unue rigardos.