Deel dit artikel

Enrollment: als we je niet kennen dan kom je er niet in (en beheren we je ook niet)!

Om mobiele apparaten op afstand te kunnen beheren is het nodig dat deze bekend worden gemaakt in het ‘UEM beheersysteem’. Daarvoor moeten de devices van een speciale app van de UEM-leverancier worden voorzien waarmee dit kan gebeuren.

Een goede vraag is: hoe dan?

Abonneren maar!

Het proces van aanmelden bij een UEM beheerservice staat ook wel bekend als het ‘enrollment proces’. Vrij vertaald het ‘abonneerproces’. In het volgende stuk concentreren wij ons op iOS en Android systemen. Voor Windows kan eenzelfde verhandeling worden gehouden, deze wordt in dit document voor nu buiten beschouwing gelaten.

Hoe ging dat eerst?

In het begin van het MDM tijdperk, zo rond 2008, kon het abonneren op een server een tijdrovende en ingewikkelde procedure zijn. De smartphones (met name Apple en Android devices) waren eigenlijk niet berekend op het gebruik binnen een bedrijfsomgeving. Daarvoor koos men in het algemeen voor de Blackberry in combinatie met het BES beheersysteem. De managementmogelijkheden voor iOS en Android waren beperkt en de (of het gebrek aan goede-) beveiliging was een serieus punt van aandacht.

Eigenlijk diende het ‘enrollen’ (abonneren) op een UEM server om de mogelijkheid te installeren om een toestel te kunnen wissen, het paswoord te veranderen of om het toestel te blokkeren. Zowel Apple en Android (Google) implementeerden hun eigen enrollment systematiek die logischerwijs (want concurrenten) op geen enkele manier uitwisselbaar waren. Deze systematiek werd middels een software API aan derden beschikbaar gesteld die aan de hand daarvan hun eigen UEM service konden realiseren. Sindsdien is er gelukkig veel ten goede veranderd want Apple en Android werden en worden beiden op grote schaal in organisaties gebruikt. De roep en noodzaak om deze op een eenduidige manier te kunnen beheren kwam dan ook vanuit het bedrijfsleven. Dit is op evolutionaire wijze gegaan met hier en daar wat ‘glasgerinkel’.

Enrollen 'vroeger': alles of niets!

In het begin beperkte het ‘enrollen’ zich tot het installeren een mobiele app in combinatie met de juiste (digitale) certificaten op het mobiele apparaat dat zich vervolgens aanmeldde bij de UEM server in kwestie. Dit gaf met name bij de verschillende Android versies problemen. Niet alle certificaten werden vertrouwd en het ‘enrollen’ ging daardoor vaak gewoonweg niet of stokte onderweg.

Zowel Apple als Google bepaalden (en bepalen nog steeds) welke beheermogelijkheden er aan UEM leveranciers worden aangeboden. Apple leverde daarvoor de Apple MDM service (en servercomponent) die door een ‘third party’ in een eigen UEM suite, een samenhangende set van beheersoftwareproducten, kon worden ingebouwd. Google leverde een software management API voor Android, genaamd [Device Administrator], op basis waarvan Third Parties ook een eigen UEM service konden realiseren.

Google is deze [Device Administrator] optie overigens aan het uitfaseren ten gunste van het Android Enterprise platform. Vanaf Android 10 wordt [Device Administrator] dan ook in steeds beperktere mate ondersteund. In beide gevallen bepaalden zowel Apple als Google welke management opties op de mobiele platformen werden ontsloten.

Leveranciers onderscheidden zich door de extra functionaliteit die zij via hun proprietary (dus leverancierseigen) oplossingen aanboden. De grote beperking van het beheer in deze periode was dat er sprake was van een alles of niets scenario voor de eindgebruiker. Een gebruiker gaf met het ‘enrollen’ de UEM beheerserver, en daarmee de IT beheerorganisatie, volledige toestemming om als apparaateigenaar op te treden met alle rechten van dien. Als gevolg hiervan zijn veel gebruikers in het begin van het MDM tijdperk hun privé gegevens kwijtgeraakt doordat de beherende organisatie in geval van diefstal of verlies het apparaat van afstand wiste. Dit werd begrijpelijkerwijs niet door de eigenaar van het apparaat in dank afgenomen en gaf aanleiding tot gebruikers die geen weigerden hun eigen device onderdeel van het beheersysteem te maken. Het concept van Bring Your Own Device was meer een soort label dan dat hier echt sprake van was en was bedoeld om een ‘gaat u maar lekker slapen en morgen weer fris op’ gevoel bij de eindgebruikers op te roepen. Veel is gelukkig sindsdien veranderd.

Enrollen 'nu': alles, niets en alles daartussenin!

Zowel Apple als Google hebben grote stappen gezet in het aanbieden van robuuste en ‘enterprise grade’ beheermogelijkheden waarbij de strikte scheiding van privé- en zakelijk gegevens een belangrijk rol is speelt. Bijgevolg heeft er ook een grote ontwikkeling in de wijze van ‘enrollen’ plaatsgevonden. Dit gebeurt aan de hand van een aantal vastgestelde-, en door de platformbouwers geadopteerde-, ‘use-cases’ die een typisch gebruikersgedrag/scenario beschrijven. De use-cases worden aan de hand van ‘persona’s’ beschreven om zodoende inzicht te geven in de praktijksituaties waar deze use-case op van toepassing (kunnen) zijn.

Zo zijn daar de use-cases voor:

  • BYOD (Bring your own Device)
  • COPE (Company Owned Personally Enabled)
  • COSU (Company Owned Single-Use)
  • Work Only Fully Managed company use only
  • Work Only, fully Managed met een persoonlijk user profile.

Enrollment van devices t.b.v. specifiek gebruik (use-cases)

Was het in de beginjaren feitelijk alleen mogelijk om een mobiel apparaat onder volledige controle te brengen (fully managed, dus niks BYOD!) van de UEM beheerserver, tegenwoordig kunnen wij op de mobiele devices de genoemde use-cases inrichten al naar gelang de behoefte en wens van de organisaties en hun gebruikers. Hierbij wordt gebruik gemaakt van softwarematige container technologie die speciaal daarvoor is ontwikkeld. Hierdoor kunnen wij een mobiel apparaat op verschillende manieren inrichten, zowel lokaal als op afstand. Google ging Apple voor in het realiseren van een container voor strikt privé gebruik op basis van het ‘Android for Work’ concept, later (2019!) volgde Apple met het User Profile concept.

De manieren voor enrollment zijn tegenwoordig legio

In het geval van een privés smartphone/tablet (BYOD) zijn er de volgende mogelijkheden:

Publieke Appstore (Apple Appstore, Google Play)

  • Installeren van een App uit de betreffende stores van Apple of Google en deze vervolgens op het device configureren. Men moet dan een app downloaden van de betreffende fabrikant en deze voorzien van een unieke tekststring of unieke URL. De beheerorganisatie stelt deze beschikbaar aan de betreffende gebruiker. Vervolgens wordt een procedure doorlopen waarmee een bedrijfswerkprofiel (‘container-app’ met apps van de organisatie) wordt ingericht.

Eigen App store

    • Installeren van de App op basis van sideloading (direct van een server geïnstalleerd op het mobiele apparaat). De app wordt niet uit de Appstores gehaald maar direct van een externe server op de smartphone geïnstalleerd. Een gebruiker moet dan extra handelingen verrichten omdat de MDM applicatie niet van een vertrouwde locatie wordt geïnstalleerd.

Enrollment: zakelijke mogelijkheden

In geval van een zakelijke smartphone/tablet kan COPE, COSU, Managed device met Work Profile op de volgende wijze plaatsvinden:

NFC (Near Field Communication)

  • De NFC methode baseert zich op het inrichten van een basistoestel die alle enrollment gegevens bevat waarmee kan worden aangemeld op de betreffende server. Ook zijn de gegevens van de WiFi omgeving hiermee over te dragen en andere configuratie instellingen. Hiervoor installeert men een z.g. leverancierseigen staging app die dit proces ondersteund. Met een NFC tik (bump) worden deze gegevens overgezet naar een nieuw toestel zonder dat daar een handmatige actie meer voor nodig is. Hiermee kunnen snel handmatig toestellen worden ingericht. Deze methode is vooralsnog alleen beschikbaar voor Android aangezien Apple de NFC toegang beperkt heeft.

Staged (gefaseerd/stapsgewijs) op basis van bar/QR codering

  • De Bar/QR code methode doet hetzelfde als de NFC methode, maar dan met barcodes die de instellingen voor de enrollment bevatten. Ook hier wordt een leverancierseigen staging app geïnstalleerd die de barcodes/QR-codes van de instellingen genereert en die op het betreffende device kunnen worden ingescand.

URL/Connectiestring

  • De MDM App van de UEM beheersoftware wordt op het toestel geïnstalleerd. Enrollment gebeurt met een URL die bijv. per email is verschaft. Ook kan de IT afdeling en simpeler enrollment string verstrekken (volgens het bitly of TinyURL principe) waarmee het device op de server kan worden ingeschreven.

SoftwareToken

  • Een softwaretoken is een speciale karakterset die typisch voor een UEM leverancier is. Bij Google bestaat een bekende relatie tussen deze speciale karakterset en de UEM leverancier. Als een Android device als managed device (een vastgestelde manier van resetten en opstarten) wordt opgestart dan zal door ingave van dit token (als Android ID) de App client van de betreffende UEM leverancier automatisch worden gedownload. Vervolgens kan het apparaat met een connectiestring ‘enrollen’ in de UEM Server. Het grote voordeel van deze manier van werken is dat veel gebruikersinteractie voor het initiële inrichten van het device kan worden voorkomen. Dit betaalt zich terug in een verbeterde gebruikerservaring en -gemak.

Supervised (Apple only)

  • Apple biedt meerdere beheermodi waaronder de Supervised mode. Deze mode biedt de mogelijkheid om een Apple iOS device geheel onder controle te brengen van de IT Afdeling. Hiervoor moet met het Apple iOS device fysiek koppelen aan een Apple Mac die dus op de locatie van de IT afdeling staat opgesteld. Hier wordt via de Apple configurator het iOS apparaat in Supervised mode gezet. Dit kan alleen op deze manier plaatsvinden. Het nadeel van deze methode is dat het iOS apparaat fysiek in dezelfde ruimte aanwezig moet zijn waar de Apple Mac staat opgesteld.

Via Apple Business Manager (bulk)

  • Om het probleem te ondervangen van de noodzaak van het lokaal fysiek ‘Supervisen’ heeft Apple de DEP optie geïntroduceerd. DEP Staat voor Device Enrollment Program. Tegenwoordig is DEP ondergebracht in het Apple Business Manager programma (ABM) tezamen met het Volume Purchase Program (VPP) en heet nu Automated Device Enrollment. Met DEP kan een Apple iOS device op afstand in Supervised mode worden gezet! Hiervoor moet het apparaat in de Apple Cloud geregistreerd staan en dient er een relatie te bestaan tussen de eigen UEM server en de Apple Cloud. Hier is dus werk aan de winkel voor de IT afdeling. Het grote voordeel van deze manier van werken is dat een iOS apparaat direct uit de verpakking zonder (of minimale) menselijke tussenkomst helemaal op maat voor een gebruiker kan worden ingericht en onder supervisie kan worden gesteld. En dat ongeacht de locatie waar dat gebeurt.

Via Zero Touch technologie (bulk)

  • Naar analogie van Apple heeft Google ook een bulk enrollment methode uitgebracht genaamd ‘zero-touch enrollment for IT Admins’. Zoals de naam aangeeft is dit voor IT afdelingen bedoeld die een grote hoeveelheid devices willen uitrollen en van de juiste inrichting willen voorzien. Dit kan op een willekeurige locatie en tijdstip direct uit de verpakking gebeuren. Bij de eerste opstart (bootstrap) van het Android device wordt er in de Google Cloud gekeken of deze aan een z.g. enterprise configuratie is gekoppeld. Hiervoor moet er een relatie bestaan tussen de UEM server van het bedrijf en de Google Cloud. Ook moeten de devices in de Google Cloud staan geregistreerd en aan het bedrijf zijn toegekend. Dus ook hier is er werk aan de winkel voor de IT afdeling. De beloning is dat een gebruiker geheel zelfstandig het device kan laten abonneren zonder verdere menselijke interventie en dat hij/zij gelijk aan de slag kan met de mobiele bedrijfsomgeving.

 

Duidelijk moge zijn dat er tegenwoordig een ruime keuze is voor het onder controle brengen van mobiele devices. Om de juiste keuzen of combinatie van mogelijkheden te kunnen maken is het verstandig om de verschillende use-cases van de organisaties zelf goed op het netvlies te krijgen en te houden. Deze keuzes hangen af van de mogelijkheden die aan de eindgebruikers worden geboden, de gegevens die moeten worden benaderd en zaken als privacy en databescherming die moeten worden ingeregeld. Klinkt ingewikkeld, het goede nieuws is dat door de juiste keuzen te maken en met de juiste professionele begeleiding er heel veel werk bij de ondersteunende afdelingen van een organisatie kan worden weggehouden en dat de gebruikers een optimale mobiele ervaring kan worden aangeboden!

What's next?

In een volgend artikel zal ik dieper inzoomen op wat er precies tijdens het enrollen op een toestel automatisch kan worden ingericht. Hoe voorkomen wij dat niet-compliant devices kunnen ‘enrollen’ (bijvoorbeeld middels het conditional access principe) en hoe zorgen wij voor de juiste inrichting van het betreffende toestel en/of de betreffende gebruiker in kwestie?

cookie

Deze site maakt gebruik van cookies, zodat wij onze bezoekers ook beter kunnen leren kennen, zoals u ons beter leert kennen. Dit gebeurt volledig anoniem, wij vinden uw privacy en anonimiteit belangrijk. Zouden wij uw geanonimiseerde data middels cookies mogen verzamelen om te analyseren? Lees ons privacy-statement.