Fiberlink MaaS360 won our Clear Choice test of mobile device management tools in 2011. IBM bought Fiberlink in 2013, so we wanted to see how the product has evolved over the years.
The first thing we noticed is that IBM has leveraged its large SaaS infrastructure to serve as the underpinning for MaaS360’s portal. It’s very simple to get the portal working for anyone with a moderate amount of IT administrative skills, even if you’re adding customization that can present great polish for both administrative details and the all-important user experience. Plus, the number of redundant data servers has increased mightily, allowing geopolitical zoning.
And if you know what you’re doing, you can meet a goodly number of compliance and regulatory standards. Of the many changes to Maas360 since we first reviewed it, most are targeted at regulatory and compliance checkmarks. Of course, there are no magic formulas that state: yes, you’re compliant, so it’s best to talk to your compliance officers and/or legal departments.
MaaS360 allows administrators to place detailed controls on end user mobile phones and equipment. For end users who don’t comply, we could spontaneously wipe their mobile devices.
Despite the sword of Damocles option, we found MaaS360 to be admin and user friendly. It’s also non-aligned, meaning that it doesn’t necessarily follow the footprint and branding identity of other MDM/EMM portals we’ve tried, and we found it refreshing.
Into the portal
Initial client provisioning is fast. The web portal is easily discerned and we became productive quickly. It’s built upon a layout where choices are obvious. To add or change something, one is presented with a form that’s processed in a batch-like mode. We filled in the platform, clicked save, MaaS360 processed the request, and the process was fulfilled.
The user experience has a light touch, and interaction from the enrollment state through day-to-day use is fairly neutral. Our ancient Samsung S3 Android phone could slow down noticeably when changing contexts from User to WorkPlace settings, but we saw no slowdown on our iOS 5C.
+ ALSO ON NETWORK WORLD How MDM works — or doesn’t work — for SMBs +
The controls also work with Mac OS X (10.7+) and Windows 7+. It’s possible to enroll users very quickly, then send email with links for MaaS360 download of the client apps — and there’s even a QR code for convenience as a link to the client app.
Getting ready
It’s possible to enroll a few users immediately into MaaS360’s UI, and succeed in calling the endeavor a success. There’s much, however, to configure if we wanted practical controls and to ensure compliance. There are no checkboxes inside MaaS360 that perhaps say: FIPS-140-2 compliance — CLICK HERE.
Therefore, administrators need to understand compliance and regulatory issues prior to the first device enrollment. It can be done afterwards, ultimately achieving compliance, if desired.
We chose to enable selected Services, set Policies, Compliance Rules, and chose whether or not to collect user location information or their app inventory. Then we deployed our first user.
Enabling the portal
Getting users entered into the portal’s database becomes a choice between doing it manually, or entering a proxy link into an Active Directory or LDAP service with the downloadable IBM Cloud Extender, which, on a Windows machine, serves as a proxy authentication gateway.
The Cloud Extender Windows app is simple to configure, if you have firewall connections appropriately open and therefore a clear communications path. The communications are encrypted, but such gateways mean that an additional partial copy of directory services information is now located somewhere outside of your perceived network security perimeter.
Users can have several mobile devices controlled by MaaS360, and sometimes AD or other directory services don’t have that device-user information, so most administrators will have to build control by using device surveys. There is no MaaS360 Discovery App offered, so it’s a push-pull initial engagement model.
The services opted-in for all users can include:
- Mobile Device Management.
- Laptop and Desktop Management (MacOS and Windows).
- A Secure Mail service containing optional usage restrictions like copy/paste and attachment properties for Microsoft Exchange 2007+, Office365, and, on iOS, IBM Notes Traveler.
- Mobile Application Management (MAM).
- Mobile Content Management.
- Proxy-filterable Secure Browser support (browser provided).
- An end-user portal for self-provisioning.
- Enterprise Email integration.
- Proxy access for internal organizational resources like Microsoft SharePoint via an Enterprise Gateway.
We found it intriguing that Secure Mail is available for not only Microsoft Exchange/Office365 servers, but also Blackberry’s Enterprise Server software — as well as IBM’s own Traveler and Connections Cloud apps.
Getting moving
Our first step was downloading the Cloud Extender, which let the portal use our test Active Directory schema, allowing proxy access on a simple gateway app. The Cloud Extender also enables an Enterprise Gateway that allows resource sharing, such as ad hoc folder access, SharePoint access, and more.
We populated the test users and divided them into Groups. The Groups are important as management objects for purposes of policy control, and are divided into Local Groups (those entered manually) and Directory Groups (AD or LDAP through the Cloud Extender). No matter the group source, they can be manipulated in similar ways for purposes of granting policies.
Groups can have one or more Policies applied to them. We could make our own, but there are “Default” policy examples for OS X, Android, iOS and Windows. Plus, there’s a Workplace default policy for basic policy control and compliance minimums. We found the examples useful, and a good start.
Net results
| COMPANY | IBM |
|---|---|
| PRODUCT | MaaS360 |
| PRICE | Essentials Version starts at $3/seat/month |
| PROS | Great UI/UX; muscular compliance controls |
| CONS | Occasional slightly rough edges; docs/error message problems |
Applied Policies control passwords, app compliance, device system preferences, media (network and device storage media access), device configuration (networking, encryption, certificates, printing, and more) and user settings.
There are also advanced configuration settings for items like login characteristics, energy savings, or the importation of custom settings.
Compliance
After bringing in users, dividing users into groups, and subjecting them to policies according to device type and logical devices, next up was compliance, where we got into the weeds of real-time compliance decisions.
The applied selected rules can be tracked by supported device, including by vendor OS, as iOS, Blackberry, Symbian, Android, Windows Phone and Windows Mobile. There’s a feature that allowed us to exempt devices from the rules, which we guessed was for CEOs. We could check for enrollment (client device has the app running), a pending MaaS360 control or its app removal, and other characteristics to be alerted as an administrator by email.
+ RELATED: 5 affordable MDM options for small businesses +
We could become alerted when encryption was on or off, our choice. We could choose to alert the user and or the administrator when a device was out of compliance with the enforced rules. The same alerts were available to signal non-whitelisted apps were used, and when other application compliance rules were violated.
Or we could choose to selectively wipe the device. We didn’t try this, but we could see the potential need. We could also change the applied policy, which in turn, changes the usage characteristics of the device not under compliance, all the way to just removing the device (and its privileges) from control, and therefore from privileged accessibility. Or, just email us that it happened. We chose email.
Geo-fencing a device is also possible. There is a large chore of entering all possible locations where device use is valid/approved. But there is one useful feature to this. If you walk in the door, and the device knows its location, and someone steals the device and drives away, you can have chosen that once used outside of the approved area, the device can be wiped, selectively wiped, lose its policy privileged access, or just have an alert sent.
We could grant content sources to controlled user devices, such as from Google Drive, Box, OneDrive, SharePoint, or an IBM Connections File source, SAP, IBM’s FileNet, EMC Documentum, and more. We could then assign the resource(s), one by one, to any instantiated Group using Workplace settings, optionally restricting export from these sources, or imposing no restrictions at all.
We could also manage apps, the sources of apps, make bundles of them from a corporate catalog we built, attach their download/use to Apple’s Volume Purchase Plan, but not to a Windows Key server.
In practice most operations went smoothly. We had difficulty with one browser application, Privacy Badger by the EFF, in terms of windowing behavior in Firefox and when we switched to Chrome with Privacy Badger absent, the bad behavior went away. When things went awry, error messages indicating problems were absent, leading us to a few emails with IBM/MaaS360 Tech Support.
We also found a few pages missing from IBM’s online docs for MaaS360, which made us scratch our heads, as the documents are usually pretty complete.
Our final warning is that there are multiple versions of MaaS360, each with gradients of features:
Summary
We found that the Maas360 implementation, although suffering from a dizzying array of options (see the chart), does a very respectable job of establishing a baseline of covered end user device characteristics, and reacting to deviations in user behavior as regards to covered device use. As the basis of an access-to-ecosystem scheme, it works well. Reports are good, and the portal isn’t necessarily self-auditing, so compliance audits need the reports.
The MDM/EMM space is crowded, and MaaS360 lacks some of the SSO, CASB-like, and third-party support of others, but nonetheless stands alone quite well, with only a minimum of rough edges. IBM’s increased data center support for portal control and accessibility is also noteworthy. As a total SaaS MDM/EMM portal, it works well.
How We Tested IBM MaaS360
We used our lab’s test Active Directory (Windows 2012R2, level schema, federated trusts) to feed test users to Maas360 after installing the included Cloud Extender software). The test bed was just 10 users, each having four devices including an Android, iOS, Mac OS X and Windows 10 notebook.
We examined the policies, compliance, and platform workplace defaults, and enrolled users into various rules set to sample them.
The network consisted of Windows 2012R2 server in the NOC, running on VMware 6.0 on a HP DL560Gen9 server. In turn, client devices were Samsung Windows 10 notebooks, MacBook Air notebooks running MacOS 10.9, Samsung S3 smartphones running Android 4, and Apple 5C iOS 9 and 10 smartphones.
The client devices were tested either in the NOC directly, or through various broadband connections using Comcast, AT&T, or T-Mobile LTE transports. The NOC and therefore Active Directory authentication connected the Windows Active Directory through Windows Server 2012R2 through VMware 6.0, through the HP server, to an Extreme Networks Summit Series 10GB switch to Expedient’s Carmel, Ind., location backbone, and in turn, to the internet.
We used our own certificates including our own Apple Push Notification/APNS certificate in testing.
