Du skickade en enda VPN-profil till alla och den innehåller ditt lösenord
Håll en delad Apple VPN-profil till enbart inställningar och ge varje person egen inloggningsuppgift. Dela upp överlämningen och ersätt sedan läckta lösenord hos utfärdaren.
Profilen installeras rent, alla ansluter och sedan roteras kontolösenordet. Varje enhet som fick filen slutar autentisera i samma minut, eftersom de alla bär samma hemlighet. Det är tecknet: en enda inloggningsuppgift kopierad till en delad artefakt gör en rutinmässig lösenordsändring till ett avbrott för hela flottan. Att hålla den återanvändbara konfigurationen och den individuella identiteten som två separata överlämningar undviker det, och Apples egen dokumentation om enhetshantering behandlar profiler som inställningar och auktorisering, inte som ett hemlighetslager.
Symtomet visar sig vid den första rotationen
En mobileconfig-fil är XML eller en signerad plist. Alla som har en kopia kan avkoda nyttolasten och läsa vad som står i den, så ett AuthPassword-värde i en mall är en inloggningsuppgift i klartext med ett ovanligt filändelse. Signering ändrar integritet och ursprung, inte läsbarhet. Samtidigt är de delar du verkligen vill dela, som gateway-adressen, förväntad serveridentitet och trafikpolicyn, identiska för alla.
Sortera fälten innan du redigerar något, eftersom gränsen inte är där folk tror.
Separera delade inställningar från individuella inloggningsuppgifter
| Item | Shared profile | Individual record |
|---|---|---|
| Gateway address, expected server identity | yes | no |
Traffic policy, IncludeAllNetworks, exclusions | yes | no |
| User password or account token | no | yes |
| Device identity or certificate | no | yes |
Den interaktiva vägen är att lämna lösenordet utanför och låta det stödda autentiseringsupplägget fråga efter det. Läs det noga: att ta bort ett fält som bara ser likt ut är inte en universell omställning till interaktiv inloggning. IKEv2-nyttolasten skiljer AuthName från AuthPassword, och autentiseringsmetoden avgör om en begäran ens är nåbar; en certifikatbaserad metod frågar inte efter lösenord alls.
Certifikat behöver inte heller en delad nyckel
Om gatewayen förväntar sig certifikatautentisering, registrera den avsedda användar- eller enhetsidentiteten via den godkända mekanismen och håll den privata nyckeln utanför mallen. En delad privat nyckel i varje kopia ger dig samma rotationsproblem med en värre radie, eftersom en nyckel inte kan återkallas per person om den inte utfärdades per person.
Registrera utfärdande, förnyelse och återkallande för den identiteten tillsammans med profilrevisionen. När de två spåras tillsammans är en förnyelse en planerad uppgift i stället för en incident.
Obevakade maskiner behöver ett tredje svar
En maskin som måste ansluta innan någon loggar in kan inte svara på en begäran. Det är ett annat krav än att göra installationen enklare för en inloggad person, och det bör lösas med en hanterad identitet eller ett per enhet överenskommet certifikat med gateway-ägaren, inte genom att lagra ett mänskligt lösenord i en profil.
Att lagra ett lösenord tar inte bort en andra faktor heller. Om gatewayen kräver MFA misslyckas en profil med sparat lösenord fortfarande vid start, och felet ser ut som en trasig profil snarare än en saknad faktor.
Kontrollera artefakten som faktiskt genererades
Mallar ljuger genom utelämnande. En hanteringstjänst eller ett exportverktyg kan injicera inloggningsuppgifter i den färdiga filen, och medföljande identitetsnyttolaster eller diagnostiska kopior kan bära material som mallen aldrig visade. Öppna den genererade artefakten innan du avgör vem som får ta emot den. Behåll också inställningarna för betrodd utfärdare och förväntad serveridentitet intakta; att ta bort ett lösenord är ingen anledning att försvaga gateway-förtroendet.
Om ett riktigt lösenord eller en privat identitet redan har rest för vitt, återkalla det hos utfärdaren och ersätt det. Att redigera morgondagens mall gör inget för de kopior som redan är installerade, och de kopiorna fortsätter autentisera tills inloggningsuppgiften bakom dem dras tillbaka.
Acceptera överlämningen med en testidentitet
Installera via det godkända flödet på en enhet registrerad som en separat testidentitet, slutför den avsedda autentiseringen och nå den privata resursen i stället för att bara se tunneln komma upp. Bekräfta att profilen inte innehåller något inloggningsuppgiftsmaterial och bekräfta sedan att inloggningsuppgiften finns i identitetsposten som ska förnyas. Det paret är acceptanstestet.
En revision för delade inställningar, en post per person och en återkallningsväg som du faktiskt har använt en gång.