Red screen Unauthorized SEB

[jladders]

Hello,

We have packaged this and uploaded via Jamf and tested. Today we are getting this error and we don't know why.

We have downloaded from the source which is a .dmg and re done as a .pkg for Jamf.

Any help would be great.

Thanks

[danschlet]

If the code signature of SEB is changed, then this error will be displayed, also the BrowserExamKey and AppSignatureKey (ASK) will be wrong. Make sure packaging does not at all alter the Safe Exam Browser.app bundle (also NOT adding any files to the bundle, hidden or not). You can use SEB Verificator to check if a SEB app version has been altered.

Note that if some tool removes the unused architecture (Intel or ARM) from the SEB Universal Binary, the code signature won't be altered, but a wrong ASK will be displayed in SEB Server.

[danschlet]

Hmm, thinking this through probably it's really impossible to not change the app signature when repackaging it into a .pkg installer. Note: It is possible, I tried it out.

That's still quite annoying though and also why a software like Jamf cannot directly distribute app bundles (from .dmg disk images or whatever source).

I guess then we will really have to also provide .pkg versions of SEB releases. I'm trying to avoid any extra efforts, as our resources are limited and any additional format potentially can create new sources of error or support questions. But I guess we'll have to invest that effort...

[jladders]

I am just waiting to get back into the suite and run those diagnostics. Going forward a .pkg would really be helpful as stuff like this is deployed via Jamf to over 100 machines

[jladders]

Just sent the email to you now

[jladders]

Noticed 3.2.5 was installed. Jamf then sent down 3.3.2 and then the issues occurred. Have done some testing. Jamf pushes an update over the top which is causing the issue. When you uninstall and then installed via Jamf, the SEB Verificator comes up ok

[danschlet]

Perfect, thanks for this update!

So the issue in this case seems to have been that the MDM solution you are using didn't remove all resources of the previously installed SEB version (3.2.5) and probably just added the resource files of SEB 3.3.2, overwriting the old resource files with the same name, but keeping the some no longer existing resources of SEB 3.2.5 in the app bundle. This apparently invalidated the code signature of the SEB app.

I don't understand how this is possible with a professional solution like Jamf Pro, maybe it had to do with the fact that you have to create a .pkg file for Jamf MDM deployment and that pkg installer did a kind of incremental update instead of replacing the whole app bundle (which basically is a folder, but macOS interprets it as an app).

How did you in the end forced Jamf to first uninstall the old SEB version? Did you first execute an uninstall action, then an install action (don't remember the right term used in Jamf, but I guess you know what I mean)? Or did you change the .pkg file?

[danschlet]

Might be related to: #376