Increasing timeout of endpoint security authorization request

Endpoint security clients are expected to respond to the authorization requests within 60 secs. If not responded within 60 secs timeout, the client is killed.

There are use cases where the processing of authorization request can take beyond 60 secs. Is there any API or MDM setting to override default 60 secs timeout?

I understand the purpose behind 60 secs timeout, secure application to respond rather than waiting. But there are legitimate use cases and if enterprise admin can make that can via MDM, it won't be exposed to all consumer software using endpoint security.

We also thought of denying the request if timeout reaches and letting application to raise the request again. However it results into user experience issues.

Any thoughts/comments/ideas?

Replies

Is there any API or MDM setting to override default 60 secs timeout?

No.

Any thoughts/comments/ideas?

My recommendation is that you file an enhancement request that describes your requirements. Make sure to include concrete details about your use case, and what you have to do in the absence of this feature.

Please post your bug number, just for the record.

Share and Enjoy

Quinn “The Eskimo!” @ DTS @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

WWDC runs Mon, 22 Jun through to Fri, 26 Jun. During that time all of DTS will be busy with conference duties.
60 seconds is not API, nor should it be considered a "default" value. Each AUTH message contains its own unique deadline value, and there is no guarantee that all messages allow for the same amount of response time. Your products should always inspect the deadline field of every message to know how much time is allotted and must also be robust to this value changing over time.
Thanks for your response.

Comments by Security Engineer:

> Each AUTH message contains its own unique deadline value, and there is no guarantee that all messages allow for the same amount of response time.

Follow up Question:
a) Could you elaborate on how the deadline value is decided? What factors are considered?
b) As requested, could you relax deadline via MDM setting per App so that enterprise admin can make that decision to allow deadline for given application. There are legitimate use cases in security software where deadline can break the workflow.

a) Could you elaborate on how the deadline value is decided? What factors are considered?

The value is not considered API and the factors can change over time. In general, we try to balance impact to end users with needs of ES clients.

b) As requested, could you relax deadline via MDM setting per App so that enterprise admin can make that decision to allow deadline for given application. There are legitimate use cases in security software where deadline can break the workflow.

We do not currently have plans to support this. Please file a request via radar for further consideration.
I had the same question and found this thread. I just put in an enhancement request. This would be very helpful to our case as well.
Post not yet marked as solved Up vote reply of iMDB Down vote reply of iMDB
Every time someone asks for a longer deadline we actually make it slightly shorter.

If you need perform IO in order to make your authorisation decision then you should respond with ES_AUTH_RESULT_DENY and cache=false. Inform the user that a decision is pending and they should re-try. Scan the file asynchronously and cache the result locally, then use that result the next time authorisation is requested.

You must respond by the deadline.
It is not configurable.
It won't get longer, but it will get shorter.
Looking for the same.
While end use experience is important, allowing administrators finer control to protect company data via user enrolled MDM sounds like a good tradeoff.

If timeout is there to protect against buggy applications which may never respond, would it make sense to ask app to check-in proactively before deadline to extend it on a per request basis. In this case timeout can be made shorter than a minute.
Typically out of all the file system activity, we are interested in only a limited number of operations out of which only a few might take more than 1 minute. However, in those situations they might take considerably more than a minute.

Asking users to retry also doesn't have a good user experience in cases like bulk copy where some operations would succeed and others user would have to track (or we list those user) and retry.