Certificate policy and Authentication policy

Certificate policy and Authentication policy

It seems that, if you want to deploy a certificate (using a Certificate configuration in a Policy),
you also have to deploy an Authentication policy, according to the warning shown below:

 

So we created an Authentication Policy too, and it surprises us to see that it's not necessary to define a User Password Policy.
The 'Device Administrator Password' setting is enough.

 

Is this logical?

Because, when installing a certificate on a non-MobiControl-managed device (plain, out-of-the-box Android), 
one must configure a pincode on the device before a certificate can be installed...

 

SOTI Support has been contacted & have indicated to us that 'if it's working for you right now, it will be ok',
but I'm interested in the deeper philosophy behind the above... ;)

2 Answers

Order By:   Standard | Newest | Votes
Raymond Chan | posted this 20 May 2019

The warning you mentioned will be shown not just for Certificate profile payload, but also for most other Android profile payloads.  You are right that the actual requirement is not on user password, but rather a mandatory device's administrator password.

 

Historically, before profiles were introduced in MobiControl v12.0,  no such warning had been necessary, primarily because ALL other Android/Android+ configuration payloads ( e.g. application run control,  lockdown menu, Wifi, feature control, ..., etc.) were disabled (i.e. grayed out and not selectable)  unless a a device "administrator password" had been set in an authentication payload associated with a particular device-group node (and automatically inherited by all nodes in the sub-tree under this node).  From v12.0 onwards,  for a device targeted with one or more profiles, just make sure there is one authentication payload with administrator password set successfully deployed onto the device, and any remaining authentication payload will just failed to be deployed and ignored.

 

My educated guess of the most likely logic behind this requirement is related to the following controllability issue under extreme conditions.    If there is no device administrator password added,  and if there is problem with the device or with any MobiControl policies deployed,  it is not possible for anyone to get hold of the device and switch the device to "administrator mode'  from the user interface in the Android device agent to do any debugging or perform any fix.  E.g., if there are stupid conflicting feature control and/or Wifi configuration policies that block all connections between a device and the MobiControl server,  no action or policy update can be sent to the device via the web-console or via any MobiControl API.   The only way is probably to recall the device, enter the admin password in the device agent UI to switch it to administrator mode, and then go to Settings to fix the Wifi/cellular connection settings.

 

 

  • 0
  • 0
Steven | posted this 20 May 2019

Thanks for this insight!

  • 0
  • 0

Give us your feedback
Give us your feedback
Feedback