Dual-SIM Whatsapp problem / 2 neat solutions

Standard

Most Whatsapp Dual SIM owners complain against the lack of DUAL-SIM Support for Whatsapp. I found two neat solutions working on most Android smartphone

Solution 1: Add a second user

Most Android smartphones support multiple users. In order to use Whatsapp, you will have to add a second user on your smartphone and add a new Google Play Account.

From the Administrator user, you must grant some privileges to access SMS and the telephone. Here’s an example to administrate Whatsapp for the association “Repair Café Fribourg”

Advantages

  • Whatsapp works for each user account, data is clearly separated
  • The switch between the two users is efficient
  • The second SIM is only used for the activation. It’s OK to use the same SIM card for data connection, for both users

Drawbacks

  • Contacts are not shared across the two profiles. You should also synchronize your contacts for the second user
  • You have to customize the whole second user profile. I would suggest to only use Whatsapp on the second profile and disable/uninstall all other apps
  • You have to switch to the second user to see the notifications

 

Solution 2: Add a work profile

The second solution I have found is even better and works flawlessly. The goal is to setup a Work profile with the TestDPC application from Google, as if you would use a “business profile” on your smartphone. A second Whatsapp will be whitelisted and made available in the work profile.

Step 1: Download the TestDPC application from Google and setup a work profile.

https://play.google.com/store/apps/details?id=com.afwsamples.testdpc&hl=en_US

     

Step 2: Whitelist Whatsapp

Open the badged version of Google Play (in the work profile), add a Google Play account and proceed with the standard activation. You will have two Whatsapp activated: the application in the private profile and the Badged version in the work profile.

    

 

On Samsung smartphones, you will find the “work profile” in the “Workspace directory”.

Advantages

  • The two Whatsapp apps can be accessed quickly
  • Notifications are working for both apps without switching the user
  • You could even protect the access to the work profile with a PIN code in the work profile settings.

Drawbacks

  • This method does not work if your device already has a work profile (MDM registration from your Company with Android Enterprise)
  • Contacts are not synced between the personal and business space.
  • Data exchange between the private profile and work profile might be limited, depending on the settings you have in the TestDPC application. Media received in the work profile will not appear in the photo, video application of the personal space. You may have to download more application in the “business” profile to actually play videos, enable a gallery app etc.
  • Warning: if you remove the work profile, all business data will be wiped and you will lose the Whatsapp data for the work profile (messages, images etc.)

 

The TestDPC application offers many other settings – explaining them is out of scope of this blog article. However, feel free to post a comment on this thread if you have a question!

Other solutions

Some manufacturers proposes a “Dual mode” for applications like Whatsapp. This is of course the best solution.

 

Testing Android Enterprise

Link

There are two useful tools to test Android Enterprise on a device:

TestDPC Application on Google Play

https://play.google.com/store/apps/details?id=com.afwsamples.testdpc

I mainly use this application while developing Android applications, e.g. to setup a work profile in two clicks and distribute a custom application in the work profile (debug mode). It’s very handy to test a managed app configuration (so called Android restrictions) and to load the default restrictions registered in the Android Manifest file.

Recap: DPC = Device Policy controller, the UEM client application managing all policies and configurations, making the link with the UEM server.

Android Enterprise Management Experience

https://enterprise.google.com/android/experience

  • First Android Enterprise Experience without UEM
  • Test some features that are not implemented in a UEM yet
  • Make sure the “promised” feature is working in Android Enterprise and possibly detect a buggy behavior with the UEM configuration
  • You will need to download the Google Android Device Policy app – the same DPC is used for the Google MDM. Alternatively, you may use a hashtag for DO devices (see below)

https://play.google.com/store/apps/details?id=com.google.android.apps.work.clouddpc

The hashtag afw#demo will allow you to set a device Owner devices (COBO, COSU or COPE).
Recap: the hashtag should be entered in the Google Account field during the device provisioning

Migrate MDM/UEM without downtime

Chat

There are multiple reasons to migrate UEM servers, e.g. move to a private cloud, move from phyiscal to virtual appliance, installing fresh VMs etc. Have you every wondered how to migrate you favorite UEM solution without downtime, and with 100% confidence?

I am giving you some tips and tricks to achieve the following goals:

  • Migration with zero downtime
  • Full testing of your MDM configurations, policies before the production cutover
  • Efficient rollback in case of downtime
  • Migrate all the data (apps, configurations, policies, devices, users etc.)

Safe migration to a new environment – geese crossing the road with 100% confidence!

What UEM data should be migrated ?

The following data buckets should be considered:

  • Devices and their logs
  • Audit logs
  • Configuration, policies
  • Applications
  • System configuration (IP routes, certificates etc.)

How shall to transfer the data from the old sever to the new server?

  1. Use the UEM Backup / restore utility
  2. Use the UEM High-Availability (HA) mode that will copy data from the Primary to the Secondary server.

Possible risky migration paths

  1. Setup new Servers with new internal IP addresses. Migrate the data with HA (High Availability) and change the NAT or load balancer configuration so that the new servers are being used
  2. New installation on the same server (the Firewall should block all incoming traffic during the maintenance window), then import a backup containing all EMM-data
  3. New installation on separate server, migrate the data, poweroff the old server and reuse the old IP addresses

All these paths prevent testing the new infrastructure without impacting the current production setup and testing is never done end-to-end on the end device.

Preferred solution

The best solution in my eyes is to install the new server in parallel to the existing infrastructure, providing a new set of internal and external IP addresses.

In order to test the migration on mobile devices, we shall inject a fake DNS record, resolving to the new MDM server. This technique is called DNS Masquerading.

Of course, the data has to be either synced or imported with the Backup/restore utility.

On iOS and Android it is possible to edit the WIFI settings and add a custom DNS server easily (don’t forget to remove this configuration after the testing phase!)

An Administrator can setup such a DNS server in the Amazon Cloud in minutes by using the dnsmasq utility (on Linux). The following article will give you more details about the procedure:

iOS DNS configuration

Add the DNS server on iOS

Android DNS configuration (choose a static IP first)

How To: DNS spoofing with a simple DNS server using Dnsmasq

Test cases

There are plenty of test cases to create, based on the enabled services. I would at least test the following:

  • MDM communication
  • App downloads and push
  • Device registration and checkins
  • System checks
  • Activesync and backend-relevant traffic for your inhouse apps

Migration cutover

Start by performing a fresh HA sync or data import with the current production environment.

Once everything has been tested, you may simply change the external DNS record and resolve it to the new external IP address, or alternatively keep the same external IP and change the nating in your firewall or load-balancer settings.

After a “grace period” of about 1-2 weeks, you may decomission the old servers

Rollback

The rollback is very simple. Just rollback the old DNS record. If needed you might want to synchronize data from the new server to the old server, assuming of course that the data is not corrupted.

Possible drawbacks of this method

  • Firewall rules for the new server are required
  • Sometimes Amazon IPs are blocked in the WIFI zone, preventing devices to access the temporary DNS server
  • You will need at least one free external IP address

Important checks

  • The new UEM server must have the same version as the current server
  • The TTL of the official DNS record should be reduced to some minutes a few weeks before the production cutover and reset back to normal after the migration. This will allow a fast propagation on all end devices. Setting a 5 Minutes Time-to-Live is a good practice during the migration window.

There exist other tools on the Market that may allow cross-UEM and per-device migrations, have a look for instance at the EBF onboarder

Apple DEP reseller ID database / list

Image

It’s always difficult to find a DEP reseller ID while setting up Apple DEP with a MDM. Apple does not provide an official list of DEP reseller IDs, so let’s create a list here:

ResellerCountryID
BechtleSwitzerlandB0C2FD0
BrackSwitzerland98F7840
SunriseSwitzerland102A6C50
SwisscomSwitzerland9E3BAF0
Art ComputerSwitzerlandD4A6500
DataquestSwitzerland4A3CAA0
Digital DimensionFrance6217A00
EconocomFrance15ECB690

(if you have some more entries to complete the list, feel free to post a comment and I’ll complete the table)

There is also a nice list available from this link.

 

The dangers of M2M SIM cards

Standard

Carriers are pushing a new kind of SIM card these days: the so-called M2M (Machine-to-Machine) SIM cards. They can be used in IoT (Internet of Things) devices so that these devices can communicate together over a (sometime) dedicated cellular network.

One big advantage of these M2M SIM cards is that the devices are all in the same “Internal” network : they can be physically distant and however communicate together as if they were in the Enterpise LAN. They can also communicate with services in the company’s network, e.g. a server collecting data from sensors.

I’ve seen recently M2M SIM cards being misused on tablets like iPads. This presents a real danger for companies that don’t take serious precautions.

I would see the following dangers (confirmed by a nice discussion with a Swiss Carrier)

  • The iPad is directly connected to the company network. No compliance check is done, the M2M gateway does not check if the device is jailbroken or if dangerous apps are installed.
  • Any application installed on the tablet will have access to the internal network
  • The SIM card can be used on any device and an unofficial device could have access to the company’s network
  • The device does not need to be managed to access the network

This is a dream for an attacker. They could just steal a SIM card and be connected in the internal network.

The risks can be minimized by applying the following measures:

  1. Create a dedicated IoT network zone (some kind of DMZ) which is clearly separated from the LAN and other company’s subnets. Firewall rules are crucial and they should follow the DENY-ALL principle
  2. Register your device in a UEM solution so that the compliance is checked regularly. If possible deploy a MTD solution (Mobile Threat defense)
  3. Deploy a cellular (APN) configuration from the UEM – the UEM will be able to remove the configuration if the device is NOT compliant and block the access to the network
  4. Define SIM-changed alerts, make sure your administrator reads the notifications and automatically block unknown devices. The SIM-changed events can be defined in the M2M management Portal and in the UEM
  5. If possible use a NAC solution (Network access control) in conjunction to your favorite UEM so that only managed devices can be connected to your internal network

In spite of these measures, I would not recommend the use of M2M SIM cards on smartphones or tablets. This is far too dangerous.

IoT is definitely the next goldmine for hackers – protecting the network access is by far the most important step towards a better security for IoT devices. Carriers have found a nice way to reuse the 3G-4G network for the IoT and companies should be careful before deploying these revolutionary M2M SIM cards!

32 vs. 64 bit mobile applications check (iOS)

Standard

Here’s a nice way to check 32-bit vs. 64 bit application support  (64-bit support is a prerequisite so that an application can be used on iOS 11+)

Solution 1 (on a MacOS environment)

/bin/echo -n "Architecture: "

CFBUNDLEEXECUTABLE=`/usr/libexec/PlistBuddy -c "Print :CFBundleExecutable" Payload/*.app/Info.plist`

xcrun -sdk iphoneos lipo -info Payload/*.app/"${CFBUNDLEEXECUTABLE}" | sed -e 's/^.*are: //' | sed -e 's/^.* is architecture: //'

Solution 2 (on Linux)

Prerequisite: File version 5.25 (at least – check it with file –version command)

unzip myapp.ipa
file Payload/<myapp.app>/app (assuming app is the name of the application bundle in the Application folder)

Solution 3 (manual)

Inspect the Info.plist file and check for the following entry – please note this might not work for old iOS applications

<key>UIRequiredDeviceCapabilities</key>
<array>
<string>armv7</string>
</array>

Meaning of the app architecture for iOS

64-bit: armv7s, arm64
32-bit: armv6, armv7

Note also that on Android there will soon be a requirement for all Google-Play uploaded apps to be 64 bit compatible (in 2019) – see the following article for more information

Kerberos and Android Enterprise SSO

Standard

Single-Sign on has always been a challenge on mobile phones. Now that companies have to switch to Android Enterprise (Device Admin’ is being deprecated), the Android world is kind of lacking an important feature which used to work with EMM Proprietary solution: Native Kerberos SSO or Kerberos Constrained Delegation.

Fortunately there is some neat solution, swiss-made and cross-EMM compatible, called Hypergate. Hypergate is an Android application that can be configured with Android Enterprise (AppConfig) and that will fill the gap on Android Enterprise – it allows native Kerberos for all your Android Apps (Chrome, cordova based or native Android Apps) and offer a nice SDK for the integration.

Here’s a nice example of App Configuration (example with MobileIron)

I had the chance to integrate it in some test labs and I have to say that it does a great job – Single-Sign On can even be achieved without user interaction, as the application supports certificate-based authentication to a KDC (Key-Distribution Center)

It will definitely work with Linux and Microsoft Application backends, or for example for an authentication to and IDP (ADFS, PingOne etc.)

I could test it with Apache for a ticketing system integration and I know some customers are already using it for Office 365 SSO on Android.

Of course, the connectivity has to be done with a per-App VPN like MobileIron Tunnel. The application is highly customizable and most IT admins will just love it.

In short, it provides what Android was lacking and what iOS was providing since iOS v7: a nice SSO configuration for your apps.

More details can be found on the following web page:

https://hypergate.com

Android zero-touch enrollment – one year later, where do we stand?

Image

Android zero-touch enrollment was revealed with Android 8.0, about a year ago. What can we say one year later? How does it compete against Apple DEP?

Is the “zero-touch” promise really working as advertised?

I could test zero-touch enrollment with the first compatible Tablet, a Huawei Mediapad M5 (Wifi only, model CMR-W09). The result is impressive, when compared to a traditional BYOD setup. It’s however not much faster than the traditional Device Owner Setup.

I see two advantages of the zero-touch approach: first, it provides a factory reset protection and you can rest assured that the device will be enrolled in the UEM, even if the user wants to bypass the Wifi connectivity setup. Also, the URL of the UEM Server can be configured so that the user only has to provide their username/password. It’s a good step towards more productivity and flexibility for companies.

I was however disappointed by the following facts:

  • my “Android recommended” tablet was not whitelisted in the Google API and I had to escalate to Google so that the model was recognized, although it was listed in the official device directory (zero-touch compatible)
  • Zero-touch does not really mean zero-touch: the user still has to go through some setup screens, and this might depend on the OEM.

We see that Google is catching up really fast, zero-touch is a nice solution but we still see some challenges for a smooth worldwide adoption.

The following paragraph will list some advantages and drawbacks of each solution. Event though I’m a big Android fan, I have to say that Apple DEP is still faster & more reliable than zero-touch enrollment.

Apple DEP vs. Android zero-touch enrollment

Pro’s Apple DEP

  • A new business Portal (business.apple.com) has been released
  • More customizations in regard to the setup screens
  • Fast and reliable. The big advantage is that it works seamlessly across all iPhones, iPads
  • Provisional DEP let you add standard devices (iOS 11+) to DEP

Con’s Apple DEP (device enrollment)

  • The initial setup is very time consuming for the customers, with a very challenging “company validation” until the customers can use their Apple DEP Account
  • A yearly token has to be renewed for the UEM pairing – it often gets forgotten

Pro’s zero-touch enrollment

  • The enrollment only depends on the UEM and carrier, reseller.
  • The setup on the zero-touch portal is really fast. A change of configuration is done in a few clicks
  • No specific configuration has to be created on the EMM
  • the DPC (client MDM app) can receive parameters

Con’s zero-touch enrollment

  • One year after the zero-touch release, we don’t find many partners and resellers around the world. It’s a challenge for international companies that have to buy devices in multiple countries. Well, it also took a long time to Apple to be available in multiple countries – so we just have to give more time to Google and they will surely catch up.
  • the listed devices on the zero-touch page do not always work out-of-the-box – even if the device is listed as “zero-touch compatible” (Android Enterprise recommended), it does not mean that the model will be listed in the API and recognized in the zero-touch portal.
    Have a look at the following page to check the compatible models:

Devices directory
https://androidenterprisepartners.withgoogle.com/devices/
API compatibility
https://developers.google.com/zero-touch/resources/manufacturer-names

  • Samsung is not zero-touch compatible yet.
  • In spite of the zero-touch approach, some devices may still have some more “branded” screens, e.g. from Huawei (terms and conditions) and we end up with more than 5 touches on the screen.

Speed Comparison (GIFs, courtesy of Nomasis AG, Switzerland)

Android zero-touch enrollment

Android Device Owner enrollment

Android BYOD

Apple DEP

Some images have been downloaded from the following link for the Apple DEP GIF:

https://learn.winona.edu/WSU_iPad_First_Time_Setup_iOS_8_DEP