Opětovné připojení k Windows VPN bez hesla v úloze

Každý recept na bezobslužné opětovné připojení dříve či později narazí na stejnou otázku: kde heslo žije. Oblíbená odpověď je samotná akce úlohy, což je pro něj také nejhorší místo. Existují dva další návrhy. Který se hodí, závisí na tom, zda se stroj dokáže ověřit bez člověka a zda server přijímá certifikáty.

Co akce úlohy nechává čitelné

Argumenty v naplánované úloze jsou součástí její definice, nikoli skrytá hodnota za běhu. Kdokoli může úlohu přečíst, obnovit její zálohu nebo exportovat její XML, vidí řetězec přesně tak, jak jste ho napsali. Během spuštění se stejný řetězec objeví v seznamu procesů. Monitorovací agent jej může zkopírovat do protokolu, který nikdy neprocházíte.

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

Ověřte to, než budete předpokládat opak. První příkaz vypíše celou definici včetně akce a jejích argumentů. Druhý ukazuje, které přihlašovací údaje si aktuální účet uložil do mezipaměti, což je důležité pro alternativní návrhy níže. Pokud se heslo objeví v XML úlohy, jeho rotace je jen polovina opravy, protože úloha stále drží starou hodnotu.

Co uložený předem sdílený klíč skutečně přináší

Add-VpnConnection -L2tpPsk zapíše klíč do položky telefonního seznamu připojení, nikoli do úlohy. To je menší plocha expozice než akce úlohy. Stále je to obnovitelné tajemství, protože správce na stroji může telefonní seznam přečíst.

Pro laboratorní spojení mezi dvěma stroji, které ovládáte, může být tato výměna přijatelná. Pro uživatelské přihlašovací údaje na sdíleném koncovém bodě nikoli. Nazvat to šifrovaným úložištěm nemění, kdo ho může číst. Telefonní seznam je konfigurační soubor. Plánujte pro člověka, který ho může otevřít, ne jen pro člověka, který se může přihlásit jako uživatel.

Přihlašovací údaje Winlogon odstraňují tajemství a přidávají závislost

-UseWinlogonCredential volí jinou cestu. Připojení se ověřuje pomocí MSCHAPv2 proti přihlašovacím údajům přihlášeného uživatele. Pro tento účet se nic dalšího neukládá.

Závislost, kterou přidává, je značná. Musí existovat interaktivní přihlášení, ze kterého lze vypůjčit, což vylučuje servisní účet a úlohu před přihlášením. Připojení také dědí vše, na co přihlašovací údaje tohoto uživatele na serveru dosáhnou. Čtěte přepínač jako tvrzení o tom, odkud přihlašovací údaj pochází, ne jako bezpečnostní nastavení. Mění zdroj a nic na tom, jak server poté relaci autorizuje.

Ověřování certifikátem škáluje, protože se nic neukládá

Kde server podporuje EAP-TLS, certifikát stroje zcela odstraní sdílené tajemství a odvolání probíhá na vrstvě certifikátu. Úloha běžící jako SYSTEM může tento certifikát předložit bez interaktivního přihlášení. Potvrďte, že server přijímá ověřování certifikátem, než na něm začnete stavět. Návrh závislý na nepodporované metodě je plán, ne řešení. Poté rozhodněte, kde žije soukromý klíč: úložiště stroje pro identitu zařízení, úložiště uživatele pro osobu.

Kde se nelze vyhnout uživatelskému jménu a heslu, uložte je do Credential Manager omezené na vlastní účet úlohy. Nechte klienta číst je odtud místo z argumentu. Tajemství, které úloha dokáže získat, aniž by ho vytiskla, je menší problém než to zapsané v její definici.

Před další rotací zkontrolujte artefakty

Dívejte se na to, co je uloženo, ne na to, co jste zamýšleli. Zkontrolujte telefonní seznam pro jednotlivé uživatele, kopii pro všechny uživatele, XML úlohy a každý skript, který volá příkaz vytáčení. Poté potvrďte, že certifikát nebo uložené přihlašovací údaje jsou omezeny na účet, který úloha používá, protože přihlašovací údaje uložené pro váš interaktivní účet jsou pro SYSTEM neviditelné.

Zapište metodu ověřování a účet do poznámek samotné úlohy. Další člověk, který změní zásady serveru, musí vědět, který návrh je ve hře. Tato odpověď není vidět jen z chování při opětovném připojení. Napište ji tam, kam se příští rotace podívá nejdřív.