Ponovno povezovanje z Windows VPN brez gesla v opravilu

Vsak recept za nenadzorovano ponovno povezavo prej ali slej naleti na isto vprašanje: kje živi geslo. Priljubljen odgovor je samo dejanje opravila, ki je zanj tudi najslabše mesto. Obstajata še dve zasnovi. Katera ustreza, je odvisno od tega, ali se stroj lahko overi brez osebe in ali strežnik sprejema potrdila.

Kaj dejanje opravila pusti berljivo

Argumenti v načrtovanem opravilu so del njegove definicije, ne skrita vrednost med izvajanjem. Kdor lahko prebere opravilo, obnovi njegovo varnostno kopijo ali izvozi njegov XML, vidi niz natanko tako, kot ste ga vnesli. Med izvajanjem se isti niz pojavi na seznamu procesov. Nadzorni agent ga lahko kopira v dnevnik, ki ga nikoli ne pregledate.

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

Preverite, preden domnevate nasprotno. Prvi ukaz izpiše celotno definicijo, vključno z dejanjem in njegovimi argumenti. Drugi pokaže, katere poverilnice je trenutni račun shranil v predpomnilnik, kar je pomembno za alternativne zasnove spodaj. Če se geslo pojavi v XML opravila, je njegova zamenjava le polovica popravka, ker opravilo še vedno hrani staro vrednost.

Kaj shranjen vnaprej deljeni ključ res prinese

Add-VpnConnection -L2tpPsk zapiše ključ v vnos telefonskega imenika povezave, ne v opravilo. To je manjša površina izpostavljenosti kot dejanje opravila. Še vedno je obnovljiva skrivnost, ker lahko skrbnik na stroju prebere telefonski imenik.

Za laboratorijsko povezavo med dvema strojema, ki ju nadzorujete, je ta izmenjava lahko sprejemljiva. Za uporabniške poverilnice na deljeni končni točki ni. Če jo imenujete šifrirano shrambo, to ne spremeni, kdo jo lahko prebere. Telefonski imenik je konfiguracijska datoteka. Načrtujte za osebo, ki jo lahko odpre, ne le za osebo, ki se lahko prijavi kot uporabnik.

Poverilnice Winlogon odstranijo skrivnost in dodajo odvisnost

-UseWinlogonCredential izbere drugo pot. Povezava se overi z MSCHAPv2 proti poverilnicam prijavljenega uporabnika. Za ta račun se nič dodatnega ne shrani.

Odvisnost, ki jo doda, je pomembna. Obstajati mora interaktivna prijava, iz katere si je mogoče izposoditi, kar izključuje servisni račun in opravilo pred prijavo. Povezava tudi podeduje vse, kar lahko poverilnice tega uporabnika dosežejo na strežniku. Stikalo berite kot izjavo o tem, od kod prihajajo poverilnice, ne kot varnostno nastavitev. Spremeni vir in ničesar v tem, kako strežnik pozneje odobri sejo.

Preverjanje s potrdilom se skalira, ker se nič ne shrani

Kjer strežnik podpira EAP-TLS, potrdilo stroja popolnoma odstrani deljeno skrivnost, preklic pa se zgodi na ravni potrdila. Opravilo, ki teče kot SYSTEM, lahko to potrdilo predstavi brez interaktivne prijave. Potrdite, da strežnik sprejema preverjanje s potrdili, preden na tem gradite. Zasnova, ki je odvisna od nepodprte metode, je načrt in ne rešitev. Nato se odločite, kje živi zasebni ključ: shramba stroja za identiteto naprave, shramba uporabnika za osebo.

Kjer se uporabniškemu imenu in geslu ni mogoče izogniti, ju shranite v Credential Manager, omejeno na lastni račun opravila. Naj jih odjemalec bere od tam namesto iz argumenta. Skrivnost, ki jo opravilo lahko pridobi, ne da bi jo natisnilo, je manjši problem kot tista, zapisana v njegovi definiciji.

Preglejte artefakte pred naslednjo rotacijo

Poglejte, kaj je shranjeno, in ne, kaj ste nameravali. Preverite telefonski imenik za posameznega uporabnika, kopijo za vse uporabnike, XML opravila in vsako skripto, ki kliče ukaz za klicanje. Nato potrdite, da je potrdilo ali predpomnjene poverilnice omejeno na račun, ki ga opravilo uporablja, ker so poverilnice, shranjene za vaš interaktivni račun, za SYSTEM nevidne.

Zapišite metodo preverjanja in račun v opombe samega opravila. Naslednja oseba, ki bo spremenila pravilnik strežnika, mora vedeti, katera zasnova je v igri. Ta odgovor ni viden le iz vedenja pri ponovnem povezovanju. Zapišite ga tam, kam bo naslednja rotacija pogledala najprej.