Hvorfor fungerer min gamle adgangskode via Activesync?

For at parafrasere Han Solo i "Star Wars" har jeg arbejdet inden for IT i over 20 år og har set en masse mærkelig ting. Jeg har set Exchange-tjenester mislykkes, fordi nogen (andre end mig) troede, det ville være en god ide at slette Microsoft .NET 2.0-filer i stedet for at afinstallere dem. Jeg har set CRT-skærme kastet ind i en dumpster, der sprang to gange og landede med en skramme. Jeg har set stegte systemer mystisk komme tilbage til livet. Jeg har set almindelige tekst-scripts, der nægtede at arbejde rigtigt, selvom de samme kommandoer indtastede direkte i computeren fungerede fint. Jeg ser i øjeblikket på et mærkeligt problem med Active Directory-DNS-poster, der pludselig forsvinder, selv uden DNS-rensning er tændt.

Kort sagt, jeg har set ting, der ikke skal være muligt, men som alligevel sker. Jeg ved, at der altid er en teknologisk forklaring bag det hele (eller det er meningen, at der skal være en), men på grund af mangel på timer på dagen har jeg til at kridt nogle rare mærkeligheder op til Walter Cronkites berømte slogan ("Sådan er det, ") et par gange.

Jeg vil tale om en sådan mærkelighed i dag, da det virkede en smule for betydningsfuldt og underligt at bare pusse ud med et "Åh, ja - det skal jeg tænke på, når jeg får noget driftsstop." Det er faktisk noget, enhver, der arbejder på eller driver en it-afdeling, skal være opmærksom på.

Jeg opretter forbindelse til mit virksomheds lokale Exchange-server via Activesync på min Samsung Galaxy S3. Min adgangskode til Active Directory (som ændres med jævne mellemrum) kontrollerer adgangen til min e-mail.

Den anden uge skiftede jeg min adgangskode, mens jeg var på kontoret, og tænkte så intet videre over det. Min Droid fortsatte med at fungere fint og fik adgang til e-mail uden problemer. Først den næste dag - 30 timer derpå efter ændring af adgangskode - blev jeg endelig bedt af min telefon om at indtaste den opdaterede adgangskode.

Jeg havde set dette før, men det var ikke meget af bekymring, før jeg reflekterede, at dette kunne udgøre en betydelig sikkerhedsrisiko for virksomhederne. Selvom denne opdatering af adgangskodeopdatering muligvis er i orden for nuværende medarbejdere, der ikke er interesseret i, om de skal opdatere deres gemte adgangskode på deres telefoner i dag eller i morgen, så tænk, hvad der ville ske i tilfælde af tidligere ansatte. En afskediget medarbejder - en vred på det - kan have unødig adgang til virksomhedens e-postsystem i over en hel dag. I denne periode med Bring Your Own Device (BYOD) -politikker kan det være vanskeligt for oprykkede IT-administratorer at sikre, at fratrædende medarbejdere frakobler deres telefons e-mail-konti fra virksomhedens mailserver og HR muligvis ikke altid ved, at dette skal være et påkrævet trin.

Hvorfor sker dette?

Først undersøgte jeg, hvordan og hvorfor dette kunne ske. Når alt kommer til alt skal forbindelsen være ligetil, ikke?

Bemærk: En skybaseret situation ville vises på lignende måde med adgang til den eller de lokale servere (r) via internettet og en firewall mellem dem og smartphonen.

Logisk set ser det ud til, at smartphonen skulle passere firewall'en til Exchange Client Access-serveren, autentificere med brugerens Active Directory-konto og derefter få adgang til e-mailen på Exchange Mailbox-serveren. Så hvis adgangskoden ændres i Active Directory, ville det da ikke være fornuftigt, at smartphonen straks ville blive afbrudt, indtil adgangskoden også blev opdateret der?

Det er lidt mere kompliceret end det. Når smartphonen autentificerer til Exchange, udstedes det, hvad der kaldes et bruger-token. Dette token kan bruges til efterfølgende adgang - i en begrænset periode - uden at enheden behøver at præsentere adgangskoden hver eneste gang telefonen går for at indsamle e-mail. Tænk på det som et vandland armbånd, der giver dig mulighed for at gå i blødgørelse af våde lysbilleder uden at skulle konstant vise de deltagere din billet. Så det fungerer virkelig mere sådan:

Bemærk, at "god til fremtidig adgang" del. Det ser ud til, at brugertokenet i nogle tilfælde tillader godkendelse i ganske lang tid, selv efter at adgangskoden er ændret i Active Directory. Nøglen her ser ud til at være, at min telefon bruger direkte push for at få ny e-mail så hurtigt som muligt. Det rapporteres også, at dette også sker med deaktiverede Active Directory-konti. I begge tilfælde ser det imidlertid ud til, at hvis smarttelefonen genstartes, bliver den bedt om den nye adgangskode, næste gang den prøver at indsamle e-mail. Så klart, at brugertoken kun er god i et bestemt tidsrum og skal opdateres ved næste genstart af telefonen.

Hvad har sælgeren at sige om det?

En artikel fra Microsoft hævder, at "af ydeevneårsager cache cache af IIS og opdateres med 15 minutters intervaller." IIS er den webtjeneste, der tillader adgang til Exchange-e-mail. Microsoft siger, at dette interval kan justeres i registreringsdatabasen for at indstille det til under 15 minutter, og at genstart af alle IIS-tjenester (via kommandoen iisreset) vil opdatere token-cachen (denne information vises også i en separat artikel).

Dette ser ikke ud til at være det rigtige svar, da min adgangskode var god i godt over en dag - meget længere end 15 minutter, selvfølgelig - men det repræsenterer kornet af salt, som jeg er vant til at tage, mens jeg læste Microsoft supportartikler, som min erfaring er berygtet for at fortælle jer, at et sådant problem blev løst af en servicepakke, der har været på det aktuelle systemsystem i årevis. Bedre svar findes generelt derude, med tilladelse fra Google (selvom du ikke får din andel af røde sild, såsom den stadig populære "Jeg tror, ​​det er et DNS-problem", der ser ud til at være årsagen til alt fra mandlige skaldethed til UFO bortførelser, i det mindste i nogle cirkler).

Jeg gjorde lidt mere research og fandt, at selvom - ja, en IIS-nulstilling vil løse dette, er det ikke muligt at gå nulstille kritiske tjenester hver gang en medarbejder opsiges, da det kan have en grim tendens til at påvirke andre medarbejdere. Det er også muligt at opnå den samme ende ved at nulstille applikationspuljen, der bruges af ActiveSync (På Exchange Client Access Server, klik på Start, klik på Administrationsværktøjer, klik på Internet Information Services (IIS)) Manager, udvid derefter servernavnet, klik på Application Pools, højreklik på MSExchangeSyncAppPool og klik på Genbrug). Desuden vil det at flytte den afskedigede medarbejders postkasse til en anden Exchange-database også rette dette, men alle disse er lidt mere komplicerede, end de har brug for.

Hvad er den bedste ting at gøre med afskedigede medarbejdere?

Du skal have en skriftlig BYOD-politik eller Mobil enhedspolitik (skabeloner, der findes på Tech Pro Research-webstedet kan ændres for at imødekomme dine behov), koordineret gennem HR og IT-afdelingen, så alle medarbejderejede enheder tændes og medarbejder ved ansættelsesterminering -ejede enheder inspiceres for at sikre, at alle firmakonti, data og andre oplysninger er blevet fjernet. Enhederne skal derefter adskilles fra brugerkontoen og Activesync slukkes for den konto. Din politik eller politik bør også omfatte en prioritering af, at disse enheder kan fjernes fjernet efter IT-afdelingens skøn, hvis det antages, at ovenstående trin ikke er udført fuldt ud.

Uanset om dette er tilfældet, eller du blot skal fjerne mobiltelefonsamarbejdet mellem enheden og brugerens konto, skal du sørge for at følge de relevante trin. For eksempel ville du i Exchange 2010 få adgang til Microsoft Exchange Management Console, udvide bekræftelse af modtagere, vælge postkasse, finde og klikke på brugeren og derefter klikke på "Administrer mobiltelefon" i sæt med indstillinger til højre.

Vælg "Fjern mobiltelefonsamarbejde" eller "Udfør en fjerntørring for at rydde mobiltelefondata" afhængigt af dine behov og klik derefter på "Fjern".

Gå nu til brugerkontoegenskaber i Exchange (adgang til Microsoft Exchange Management Console, udvid modtagerbekræftelse, vælg Mailbox, find og højreklik på brugeren og vælg Egenskaber, vælg derefter fanen Mailbox Features) og deaktiver Activesync. Deaktiver også Outlook Web App, mens du også er der:

Konklusion

Dette er et godt eksempel på noget, der var designet til at gøre teknologien lettere og mere effektiv, men alligevel kunne vise sig at være et problem, hvis det ikke styres korrekt. Det faktum, at bruger-tokenet tillader adgang, når adgangskoden er ændret, foretrækkes frem for at opleve lockout af brugerkontoer ved for mange mislykkede loginforsøg, men kan have mere skræmmende konsekvenser. Gode ​​politikker og administration af bruger / enhed er nøglen til at overvinde denne sikkerhedsrisiko, og glem ikke at holde en sund kommunikation mellem HR og IT, så du er opmærksom på medarbejdernes begivenheder og rejser!

© Copyright 2020 | mobilegn.com