IBM MaaS360

Is my suspicion that the Maas360 app doesn't actually launch on the phone until after the user has signed in? This is for handsets that boot fully to the login screen before requiring any form of authentication, not for ones that require a password/PIN prior to boot.

Periodically we get handsets returned where the user has changed their password and not handed over the details when they leave[1]. In theory we should be able to start the handset, go into Maas and issue a password reset, but these never seem to go through. The policy keeps WiFi on, and SSID details for all of our work locations are forced onto the system so they will be able to connect even without a SIM, or if the SIM has been blocked by the time we get the handset back. So there should be a route to the app, if it's running, but last check-in time doesn't update, and Message, Buzz, etc. all go nowhere.

Obviously if the app isn't running until after sign-in, then this is doomed to failure, so am I right, that this is the case?

If so, how do people handle this situation? Sadly we can't rely on a human system to obtain the information at handover for reasons beyond our control. We do now have factory reset protection with authorised accounts configured, but historically this aspect of the policy was configured incorrectly, and I currently have a device that I'm fairly sure is on the older policy version, locally, despite what Maas says on the web, so don't want to risk that yet - if I'm right and it's got the incorrect details, we'll never be able to get out of the reset protection loop.


[1] Which is another issue: I cannot find a way to stop this under Android Enterprise, and nor can I find a way to set a kind of secret admin master key (which does make sense from a security viewpoint, but is annoying)

------------------------------
Pete Croft
------------------------------

Hi, Pete.  I am finding myself in a similar situation and wanted to see if you were able to figure out a solution for this issue.  We recently implemented MaaS360 on all of our devices, both iPhone and Android, and this issue impacts them both.  

We recently had somebody surrender their Android device, and powered down the device.  When I powered it up, and attempted to reset the passcode, I noticed the changes never applied and the dashboard continued to show "pending."  I eventually booted into the bootloader, and factory reset the device from there and was able to format the device. This is fine and all, but if there was something on the device that I needed to get access to, the MaaS360 service doesn't seem to run and accept commands until a user has signed into the device.  This issue isn't exclusive to Android, I tested this out with an Apple device, powered it down, marked it as lost, powered it back on, and it didn't mark it as lost until I signed into the device.  I also tried the passcode reset on a device that has been powered down and then powered back up, and the device still requires the previous passcode to get signed into before it will triggers the passcode reset.  This seems like a major issue for folks who cannot sign into their device.  The general rule is if something doesn't work try a reset.  I can see this being an issue for a handful of users in the future if we implement periodic passcode changes every X number of days.

This was the first time this issue surfaced since we started using it, and I'm hoping you may have come up with a good solution for helping to manage a device. Thank you!

------------------------------
Troy Benedict
------------------------------

Original Message:
Sent: Mon February 21, 2022 05:24 AM
From: Pete Croft
Subject: Android: when does the app actually start? (Handling unknown changed passwords)

Is my suspicion that the Maas360 app doesn't actually launch on the phone until after the user has signed in? This is for handsets that boot fully to the login screen before requiring any form of authentication, not for ones that require a password/PIN prior to boot.

Periodically we get handsets returned where the user has changed their password and not handed over the details when they leave[1]. In theory we should be able to start the handset, go into Maas and issue a password reset, but these never seem to go through. The policy keeps WiFi on, and SSID details for all of our work locations are forced onto the system so they will be able to connect even without a SIM, or if the SIM has been blocked by the time we get the handset back. So there should be a route to the app, if it's running, but last check-in time doesn't update, and Message, Buzz, etc. all go nowhere.

Obviously if the app isn't running until after sign-in, then this is doomed to failure, so am I right, that this is the case?

If so, how do people handle this situation? Sadly we can't rely on a human system to obtain the information at handover for reasons beyond our control. We do now have factory reset protection with authorised accounts configured, but historically this aspect of the policy was configured incorrectly, and I currently have a device that I'm fairly sure is on the older policy version, locally, despite what Maas says on the web, so don't want to risk that yet - if I'm right and it's got the incorrect details, we'll never be able to get out of the reset protection loop.


[1] Which is another issue: I cannot find a way to stop this under Android Enterprise, and nor can I find a way to set a kind of secret admin master key (which does make sense from a security viewpoint, but is annoying)

------------------------------
Pete Croft
------------------------------

Hi Troy,

I'm afraid I never got any further with this, so they only option I've found is to force a factory reset and lose any local unsynchronised data.

In our case, all users should be putting any local data into OneDrive immediately anyway, so in theory there shouldn't be anything, But of course, there almost always is, and sometimes it's important to the business that we recover it. It's really quite frustrating.

If I had more control over the HR processes I would work around it by requiring a physical handover of equipment to another colleague, along with a surrendering of device passcodes and a test of the supplied passcodes before verifying the handover, but ... in our situation, I can't make that happen, and the client doesn't have the will to do so.

Sorry - a response that is both delayed and ultimately unhelpful!

------------------------------
Pete Croft
------------------------------

Original Message:
Sent: Fri August 05, 2022 11:25 AM
From: Troy Benedict
Subject: Android: when does the app actually start? (Handling unknown changed passwords)

Hi, Pete.  I am finding myself in a similar situation and wanted to see if you were able to figure out a solution for this issue.  We recently implemented MaaS360 on all of our devices, both iPhone and Android, and this issue impacts them both.  

We recently had somebody surrender their Android device, and powered down the device.  When I powered it up, and attempted to reset the passcode, I noticed the changes never applied and the dashboard continued to show "pending."  I eventually booted into the bootloader, and factory reset the device from there and was able to format the device. This is fine and all, but if there was something on the device that I needed to get access to, the MaaS360 service doesn't seem to run and accept commands until a user has signed into the device.  This issue isn't exclusive to Android, I tested this out with an Apple device, powered it down, marked it as lost, powered it back on, and it didn't mark it as lost until I signed into the device.  I also tried the passcode reset on a device that has been powered down and then powered back up, and the device still requires the previous passcode to get signed into before it will triggers the passcode reset.  This seems like a major issue for folks who cannot sign into their device.  The general rule is if something doesn't work try a reset.  I can see this being an issue for a handful of users in the future if we implement periodic passcode changes every X number of days.

This was the first time this issue surfaced since we started using it, and I'm hoping you may have come up with a good solution for helping to manage a device. Thank you!

------------------------------
Troy Benedict

Original Message:
Sent: Mon February 21, 2022 05:24 AM
From: Pete Croft
Subject: Android: when does the app actually start? (Handling unknown changed passwords)

Is my suspicion that the Maas360 app doesn't actually launch on the phone until after the user has signed in? This is for handsets that boot fully to the login screen before requiring any form of authentication, not for ones that require a password/PIN prior to boot.

Periodically we get handsets returned where the user has changed their password and not handed over the details when they leave[1]. In theory we should be able to start the handset, go into Maas and issue a password reset, but these never seem to go through. The policy keeps WiFi on, and SSID details for all of our work locations are forced onto the system so they will be able to connect even without a SIM, or if the SIM has been blocked by the time we get the handset back. So there should be a route to the app, if it's running, but last check-in time doesn't update, and Message, Buzz, etc. all go nowhere.

Obviously if the app isn't running until after sign-in, then this is doomed to failure, so am I right, that this is the case?

If so, how do people handle this situation? Sadly we can't rely on a human system to obtain the information at handover for reasons beyond our control. We do now have factory reset protection with authorised accounts configured, but historically this aspect of the policy was configured incorrectly, and I currently have a device that I'm fairly sure is on the older policy version, locally, despite what Maas says on the web, so don't want to risk that yet - if I'm right and it's got the incorrect details, we'll never be able to get out of the reset protection loop.


[1] Which is another issue: I cannot find a way to stop this under Android Enterprise, and nor can I find a way to set a kind of secret admin master key (which does make sense from a security viewpoint, but is annoying)

------------------------------
Pete Croft
------------------------------

Thank you for the response, Pete.  I appreciate knowing that I'm not the only one with this particular concern, and I'll be keeping my eyes out for other MDM services that may be able to communicate with the phone without the user needing to be signed in.  

You make a good suggestion about working with HR to make it a requirement during the employee separation process to have the manager get and test the PIN for phone access.  

I was able to confirm that I could regain access to both Android and Apple devices using their respective factory reset steps (Android through the recovery/boot option and iOS devices using recovery mode and restore via iTunes).  Both options are a PITA and destroys all local data on the phone, but like you, our services are all cloud-based, so not a huge issue.  

My biggest concern though it being able to assist a user remotely with a passcode reset or shooting a message to the phone's screen if it's lost, stolen, or misplaced.  We have people who travel for weeks at a time and if a situation arises where the user cannot access their phone until I get my hands on it, then that's a big negative in my book. One of the MaaS360 support staff suggested assigning a profile that doesn't require a passcode (I don't think that removes the current passcode though, it just makes it not mandatory), but even then the MaaS360 service doesn't update the profile if the user isn't signed in... 

Anyway, thank you for taking the time to respond.  It was helpful!

------------------------------
Troy Benedict
------------------------------

Original Message:
Sent: Wed August 10, 2022 09:58 AM
From: Pete Croft
Subject: Android: when does the app actually start? (Handling unknown changed passwords)

Hi Troy,

I'm afraid I never got any further with this, so they only option I've found is to force a factory reset and lose any local unsynchronised data.

In our case, all users should be putting any local data into OneDrive immediately anyway, so in theory there shouldn't be anything, But of course, there almost always is, and sometimes it's important to the business that we recover it. It's really quite frustrating.

If I had more control over the HR processes I would work around it by requiring a physical handover of equipment to another colleague, along with a surrendering of device passcodes and a test of the supplied passcodes before verifying the handover, but ... in our situation, I can't make that happen, and the client doesn't have the will to do so.

Sorry - a response that is both delayed and ultimately unhelpful!

------------------------------
Pete Croft

Original Message:
Sent: Fri August 05, 2022 11:25 AM
From: Troy Benedict
Subject: Android: when does the app actually start? (Handling unknown changed passwords)

Hi, Pete.  I am finding myself in a similar situation and wanted to see if you were able to figure out a solution for this issue.  We recently implemented MaaS360 on all of our devices, both iPhone and Android, and this issue impacts them both.  

We recently had somebody surrender their Android device, and powered down the device.  When I powered it up, and attempted to reset the passcode, I noticed the changes never applied and the dashboard continued to show "pending."  I eventually booted into the bootloader, and factory reset the device from there and was able to format the device. This is fine and all, but if there was something on the device that I needed to get access to, the MaaS360 service doesn't seem to run and accept commands until a user has signed into the device.  This issue isn't exclusive to Android, I tested this out with an Apple device, powered it down, marked it as lost, powered it back on, and it didn't mark it as lost until I signed into the device.  I also tried the passcode reset on a device that has been powered down and then powered back up, and the device still requires the previous passcode to get signed into before it will triggers the passcode reset.  This seems like a major issue for folks who cannot sign into their device.  The general rule is if something doesn't work try a reset.  I can see this being an issue for a handful of users in the future if we implement periodic passcode changes every X number of days.

This was the first time this issue surfaced since we started using it, and I'm hoping you may have come up with a good solution for helping to manage a device. Thank you!

------------------------------
Troy Benedict

Original Message:
Sent: Mon February 21, 2022 05:24 AM
From: Pete Croft
Subject: Android: when does the app actually start? (Handling unknown changed passwords)

Is my suspicion that the Maas360 app doesn't actually launch on the phone until after the user has signed in? This is for handsets that boot fully to the login screen before requiring any form of authentication, not for ones that require a password/PIN prior to boot.

Periodically we get handsets returned where the user has changed their password and not handed over the details when they leave[1]. In theory we should be able to start the handset, go into Maas and issue a password reset, but these never seem to go through. The policy keeps WiFi on, and SSID details for all of our work locations are forced onto the system so they will be able to connect even without a SIM, or if the SIM has been blocked by the time we get the handset back. So there should be a route to the app, if it's running, but last check-in time doesn't update, and Message, Buzz, etc. all go nowhere.

Obviously if the app isn't running until after sign-in, then this is doomed to failure, so am I right, that this is the case?

If so, how do people handle this situation? Sadly we can't rely on a human system to obtain the information at handover for reasons beyond our control. We do now have factory reset protection with authorised accounts configured, but historically this aspect of the policy was configured incorrectly, and I currently have a device that I'm fairly sure is on the older policy version, locally, despite what Maas says on the web, so don't want to risk that yet - if I'm right and it's got the incorrect details, we'll never be able to get out of the reset protection loop.


[1] Which is another issue: I cannot find a way to stop this under Android Enterprise, and nor can I find a way to set a kind of secret admin master key (which does make sense from a security viewpoint, but is annoying)

------------------------------
Pete Croft
------------------------------