Hver oppskrift for uovervåket gjenoppkobling ender til slutt på det samme spørsmålet: hvor bor passordet. Det populære svaret er selve oppgavehandlingen, som også er det verste stedet for det. To andre design finnes. Hvilket som passer avhenger av om maskinen kan autentisere uten en person og om serveren godtar sertifikater.

Hva en oppgavehandling etterlater lesbart

Argumenter i en planlagt oppgave er en del av definisjonen, ikke en skjult kjøretidsverdi. Alle som kan lese oppgaven, gjenopprette en sikkerhetskopi av den eller eksportere XML-en, ser strengen nøyaktig slik du skrev den. Under en kjøring vises den samme strengen i prosesslisten. En overvåkingsagent kan kopiere den til en logg du aldri gjennomgår.

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

Kontroller før du antar det motsatte. Den første kommandoen skriver ut hele definisjonen, inkludert handlingen og argumentene. Den andre viser hvilke legitimasjoner den gjeldende kontoen har bufret, noe som er viktig for de alternative designene nedenfor. Hvis passordet vises i oppgavens XML, er rotasjon bare halve reparasjonen, fordi oppgaven fortsatt holder den gamle verdien.

Hva en lagret forhåndsdelt nøkkel egentlig gir

Add-VpnConnection -L2tpPsk skriver nøkkelen inn i tilkoblingens telefonbokoppføring i stedet for i en oppgave. Det er en mindre eksponeringsflate enn en oppgavehandling. Det er fortsatt en hemmelighet som kan gjenopprettes, fordi en administrator på maskinen kan lese telefonboken.

For en laboratoriekobling mellom to maskiner du kontrollerer, kan den utvekslingen være akseptabel. For en brukerlegitimasjon på et delt endepunkt er den ikke det. Å kalle det kryptert lagring endrer ikke hvem som kan lese det. Telefonboken er en konfigurasjonsfil. Planlegg for personen som kan åpne den, ikke bare for personen som kan logge på som brukeren.

Winlogon-legitimasjon fjerner hemmeligheten og legger til en avhengighet

-UseWinlogonCredential tar en annen vei. Tilkoblingen autentiserer med MSCHAPv2 mot legitimasjonen til den påloggede brukeren. Ingenting ekstra lagres for den kontoen.

Avhengigheten den legger til er betydelig. Det må finnes en interaktiv pålogging å låne fra, noe som utelukker en tjenestekonto og en oppgave før pålogging. Tilkoblingen arver også alt legitimasjonen til den brukeren kan nå på serveren. Les bryteren som en uttalelse om hvor legitimasjonen kommer fra, ikke som en sikkerhetsinnstilling. Den endrer kilden, og ingenting ved hvordan serveren autoriserer økten etterpå.

Sertifikatautentisering skalerer fordi ingenting lagres

Der serveren støtter EAP-TLS, fjerner et maskinsertifikat den delte hemmeligheten helt, og tilbakekalling skjer på sertifikatlaget. En oppgave som kjører som SYSTEM kan presentere det sertifikatet uten en interaktiv pålogging. Bekreft at serveren godtar sertifikatautentisering før du bygger på det. Et design som avhenger av en metode som ikke støttes, er en plan snarere enn en løsning. Bestem deretter hvor den private nøkkelen bor: maskinlageret for en enhetsidentitet, brukerlageret for en person.

Der brukernavn og passord ikke kan unngås, lagre dem i Credential Manager begrenset til oppgavens egen konto. La klienten lese dem derfra i stedet for fra et argument. En hemmelighet som oppgaven kan hente uten å skrive den ut, er et mindre problem enn en som er skrevet inn i definisjonen.

Gå gjennom artefaktene før neste rotasjon

Se på hva som er lagret i stedet for hva du hadde tenkt. Kontroller telefonboken per bruker, kopien for alle brukere, oppgavens XML og ethvert skript som kaller oppringingskommandoen. Bekreft deretter at sertifikatet eller den bufrede legitimasjonen er begrenset til kontoen oppgaven bruker, fordi legitimasjon lagret for din interaktive konto er usynlig for SYSTEM.

Noter autentiseringsmetoden og kontoen i oppgavens egne notater. Den neste personen som endrer serverens policy, må vite hvilket design som er i spill. Det svaret er ikke synlig bare fra gjenoppkoblingsatferden. Skriv det der den neste rotasjonen vil se først.

Relaterte artikler