När organisationer arbetar för att säkerställa produktivitet på distans kommer problemet med cachade referenser oundvikligen att visas, vilket orsakar ett problem för den drabbade användaren och IT-servicedesken.

det är ingen hemlighet att någon väsentlig del av nästan varje arbetsstyrka fungerar på distans. Du har tillbringat de senaste månaderna ilande att etablera fjärranslutning, molnbaserad produktivitet, och någon form av omfattar säkerhet-allt för att låta dina fjärranställda att få sitt jobb gjort samtidigt uppfylla kraven bolagsstyrning kring säkerhet och efterlevnad till så bra en grad som möjligt. Men med ungefär 40% av fjärrarbetskrafterna som använder företagsenheter medan de arbetar hemifrån finns det ett problem som kan vara precis runt hörnet som sannolikt är på väg att bli ett problem som kommer att innebära den delmängden av hela din avlägsna arbetskraft – som löper ut lokalt cachade referenser.

För de av er som inte är bekanta med lokalt cachade referenser, här är den mycket korta primern: eftersom användaren är avlägsen kan de inte enkelt (om alls) ansluta till en domänkontrollant (DC) på företagsnätverket. Så, windows håller en kopia av användarens referenser cachade på den lokala enheten och användaren kan fritt logga in lokalt medan fjärrkontrollen utan att behöva ansluta till företagets nätverk. Trots att Microsoft dödade kravet att kräva att användare byter lösenord ofta finns det fortfarande scenarier där lösenord måste återställas:

• gammal policy förblir på plats och ett lösenord går ut
• användarens referens misstänks ha äventyrats av insiderhot eller cyberattack och måste återställas administrativt
• det för närvarande etablerade lösenordet visar sig använda ett kompromissat/läckt lösenord och återställs administrativt
• användaren glömmer sitt lösenord (som i, det har cachats så länge, de vet inte ens vad det är)

lösenordet är frågan till hands är när lösenordet måste återupprättas på Active Directory-sidan av ekvationen, Hur uppdaterar du lokalt cachade referenser? Den berörda användaren måste vara ansluten till företagets nätverk (specifikt till en domänkontrollant (DC)) för att ha en nyetablerad uppsättning referenser cache lokalt. Nu är några av er redan framför mig och tänker: ”mina användare använder en VPN och är därför logiskt på nätverket, så vi har det bra.”Men enligt en ny studie av Proofpoint har endast 39% av användarna en VPN installerad och endast 47% av dessa människor använder det konsekvent. Dessutom är många VPN-anslutningar till DC etablerade efter inloggning så inte alla potentiella scenarier som kan uppstå kommer att lösas utan IT-stöd.

kort sagt, så småningom kommer problemet med lokalt cachade referenser att komma ikapp med dig.

Så, vad är dina alternativ för att uppdatera utgångna referenser, och vad är säkerhetsförgreningarna för varje?

först och främst, eftersom problemet vi löser för är att den fjärranslutna slutpunktsenheten behöver uppdatera de cachade autentiseringsuppgifterna, är den underliggande processen i stort sett densamma: Enheten måste vara logiskt ansluten till företagsnätverket (igen, specifikt med åtkomst till en DC) via VPN, och måste (förutsatt att du kör Windows 10) trycka på Ctrl-Alt-Del och välj Ändra ett lösenord.

när man ser denna process i praktisk tillämpning finns det några scenarier att överväga kring uppdatering av lokalt cachade referenser och hur varje påverkar företagets säkerhet och IT.

1. Känt, icke-utgått lösenord, som kan ansluta-det här är guldstandarden för möjliga scenarier. Den tekniskt kunniga användaren ansluter helt enkelt till VPN, och ändrar sitt lösenord och går om sin dag. Ren det nirvana.

2. Känt, utgått lösenord, kan inte ansluta – utan lösningar för återställning av lösenord från tredje part är VPN ett krav här. Servicedesken kommer att vara involverad för att underlätta åtminstone ”ansluta till företagsnätverket” genom att manuellt återställa sitt lösenord till det befintliga som en potentiell lösning och få dem att ändra det omedelbart, vilket kan innebära att hjälpa till med att hitta nycklarna som behövs för att få ändra ett lösenord.

3. Okänt lösenord-att sätta anslutningsfrågan åt sidan, det är här den verkliga säkerhetsrisken börjar. När användarna inte vet vad deras lösenord är att börja med, det kräver uppenbarligen en initial återställning av Servicedesk, och sedan ett lösenord förändring vid första inloggning, precis som scenariot ovan. Säkerhetsrisken kommer i form av att identifiera användaren som behörighetsägare innan han överlämnar återställningslösenordet. I det första scenariot åtminstone visste de det gamla lösenordet, men inte en mycket säker verifieringsmetod, det är en början. Så, i det här fallet, utan någon form av en andra autentiseringsfaktor som går utöver, ”vem är det här?”eller” vad är ditt anställdas ID?”är verkligen riskabelt.

4. Tvingad återställning-i fall där det tvingar en återställning av en användares referens (igen, på grund av problem som att misstänka att det har äventyrats av cyberattack), måste arbetet med att arbeta med användaren för att kommunicera ett nyåterställt lösenord involvera en mycket specifik och säker form av validering av referensägaren innan du överlämnar återställningslösenordet.

få cachad referens uppdatering korrekt

problemet här är tvådelad, cachade referenser kommer i slutändan att leda till en ökning av IT-supportsamtal och förlust i produktivitet men det finns ett säkerhetsproblem till hands här. Handoff mellan användaren som påstår sig vara behörighetsägaren och Servicedesk-agenten som behöver lämna ett tillfälligt lösenord för att underlätta uppdateringen kan lämna en organisation utsatt för attacker.

användare inom din organisation har olika åtkomstnivåer och därmed inneboende risk. Så lägg till mixen här att de med förhöjda nivåer av tillgång till känslig, proprietär och annars värdefull information behöver mycket mer validering än någon av de förenklade metoderna som ofta används vid IT-servicedisken.

uppdatering av lokalt cachade referenser är ett säkerhetsproblem. Och den bästa säkerheten är den som användaren inte vet om. Lägg till det, den bästa lösningen är den som den inte behöver engagera sig med. Det är uppenbart, från scenarierna ovan uppfyller scenariot med en proaktiv, tekniskt kunnig användare kriterierna. Men det är bara inte verkligheten för det mesta. Så, det kan finnas ett behov av att titta till tredje part lösenord självbetjäningslösning som integreras med Windows inloggningsprocessen för att förenkla de tre okända jag har nämnt i den här artikeln: användarens tekniska förmåga, deras förmåga att ansluta till företagets nätverk, och det är förmågan att validera den person som begär en återställning av lösenord är i själva verket behörighetsägaren.

utan någon tredjepartslösning är svaret enkelt: VPN, ändra lösenordet. När det i allmänhet inte är möjligt rekommenderar jag att du letar efter en lösning som uppfyller din avlägsna arbetskraft där de är samtidigt som du hjälper till att upprätthålla produktivitet och företagssäkerhet.