Maximum passcode age on iOS

N

Hello !

We have set up a reactive profile for iOS. I want to enforce the use of a passcode on the iPhone, but without it expiring. In Configurations > Passcode, I have therefore selected a minimum length, but there is also the ‘maximum passcode age’ setting, which, according to the documentation, accepts values from 0 to 730... but I cannot select 0. If I enter ‘0’, it reverts to ‘1’, and the passcode needs to be changed every day... I simply want to disable the expiry, but this does not seem to be possible. Does anyone know why, whether I am doing something wrong or if it is a bug? I wanted to add a screenshot to this post but I keep getting a 400 error :-)

I should point out that we are not yet Mobicontrol customers; we are currently in a trial period on a trial licence, which expires in a few days, so I cannot create a ticket. Thank you 

Edited 9 days ago
SOTI MobiControl
ANSWERS
RS
Rafael Schäfer
9 days ago (edited 9 days ago)

The minimum is 1: https://developer.apple.com/documentation/devicemanagement/passcode

maxPINAgeInDays

The number of days for which the passcode can remain unchanged. After this number of days, the system forces the user to change the passcode before it unlocks the device.

Not sure if the MDM could "not send" this option to avoid setting it but this should be a question from you to your trial contact at Soti and would most likely then a feature request to be made to make this option to be turned on/off.
I would guess yes, as no "default" setting is defined in the documentation but for others.

 

Btw: Yes, i also get always http400 error when trying to upload a picture or insert it by Copy&Paste.

N
Nicolas
9 days ago

Thank you Rafael for your very quick reply!

So I understand that this is a limitation on Apple’s side once the “maxPINAgeInDays” parameter is sent. However, I believe (based on the documentation) that this parameter is not mandatory and that Mobicontrol might not send it?

In other words, there could be an option to tick or untick the expiry setting. (Or allow the option to be set to ‘0’, and if the user enters 0, this parameter is not sent). We currently use Sophos as our MDM to manage iPhones, and there is indeed an option that specifies ‘Maximum password validity in days (1 to 730 or 0 for unlimited)’, and this works because the lock codes do not expire for us. In my view, this should therefore also be possible on the Mobicontrol side, but in that case I understand that it would require development and therefore a support ticket

At least looks for me like that.

I'm not an apple guy and also not from Soti so can't tell by sure but including your experience with Sophos it sounds like fitting my assumption. And i think it's worth mentioning for you, if you speak to your trial contact from Soti, if this is a "killing" missing feature, if they could make it happen (maybe even within the 730 days, so you can start with 730 days and when it gets in place, remove it), ideally soon as this change sounds relatively easy to implement but Soti can tell you that better than I😁.

RC
Raymond Chan
2 days ago

There is no actual programming needed to fix this GUI related problem in Soti MobiControl web-console design.   Instead of using the built-in password profile payload,  just edit a MobiControl custom profile payload defining password policy without any lines mentioning about the key "maxPINAgeInDays".   With an existing profile reusable template including standard XML header and payload header fields,  it takes less than one minute to leave out the "maxPINAgeInDays" field, and just include the other keys such as

 

<key>allowSimple</key>

<true/>

<key>forcePIN<//key>

 <true/>

<key>maxFailedAttempts</key>

<integer>10</integer>

<key>maxGracePeriod</key>

<integer>15</integer>

<key>maxInactivity</key>

<integer>15</integer>

<key>minComplexChars</key>

<integer>1</integer>

<key>minLength</key>

<integer>8</integer>

<key>requireAlphanumeric<//key>

 <true/>

 

to get the custom profile XML ready for deployment via MobiControl.

 

Nice thing and would help him right away.

But a feature request in this case would also make sense for the long run (or maybe a issue report as it's no working as it should).