I took notes during the "What's new in managing Apple Devices" session. If interested, please see the attached "Notes from session": Session Notes For the session video, please see the following link: https://developer.apple.com/wwdc22/10045

On a supervised device running iOS 18 without any AirDrop restrictions applied, when a profile with allowListedAppBundleIDs restriction key is installed, the AirDrop sound plays. But still the accept prompt does not appear, making it impossible to accept files. The prompt works as expected on iOS 18 devices to which the allowListedAppBundleIDs restriction is not installed. This issue occurs only on supervised iOS 18 devices to which the allowListedAppBundleIDs restriction is being applied. Device must be in iOS 18 version > Install the (allowListedAppBundleIDs restriction) profile with the device > Try to AirDrop files to the managed device. The expected result is that the accept prompt must pop up but it does not appear. This issue is occurring irrespective of any Whitelisted bundle ID being added to the allowListedAppBundleIDs restriction profile. Have attached a few Whitelisted bundle ID here com.talentlms.talentlms.ios.beta, com.maxaccel.safetrack, com.manageengine.mdm.iosagent, com.apple.weather, com.apple.mobilenotes, gov.dot.phmsa.erg2, com.apple.calculator, com.manageengine.mdm.iosagent, com.apple.webapp, com.apple.CoreCDPUI.localSecretPrompt etc. Have raised a Feedback request (FB15709399) with sysdiagnose logs and a short video on the issue.

Sometime since July 2024 the list of devices in our Enterprise Account is showing the same device and UDID 6 times. Looking at the DATE REGISTERED field it is apparent that each instance of the device represents the 'old' device that should have been 'deleted' when the annual device reset was actioned. The date registered field shows dates with 2019, 2020, 2021, and so till 2024 (most recent). I have 'disabled' two of the entries to see what happens, and those instances were disabled as expected without impacting the other instances. However, when attempting a re-enable of them, an error throws saying that they cant be enabled because that UDID already exists - obviously the other instances. For now, I have left 4 active duplicates in place, and the 2 disabled ones as they are, and plan to deal with this again - if it re-occurs in 2025. It does not seem to have impacted provisioing profiles - so will leave well enough alone. I am sure if I disable all of them, I will not be able to re-enabled any of them. Is this a know issue? Is this the best strategy? - ie, wait till device reset next year and hope issue is resolved. This post had similar issue, in 2023, but no response Forum Post 733264

I'm developing an ACME server to issue identity certificates to macOS/iOS devices for MDM attestation, following RFC 8555. Per RFC, the client creates an order, performs authorization, verifies the challenge, and finalizes the order by submitting a CSR to the CA. In my setup, the CA sometimes takes longer to issue the certificate (around 50 seconds). According to RFC 8555, if certificate issuance isn’t complete after the /finalize call, the server should respond with an "order" object with a "processing" status. The client should then send a POST-as-GET request to the order resource (e.g., /order/<order_id>) to check the current state. If the CA still hasn’t issued the certificate, the server should return the order object with the same "processing" status and include a "Retry-After" header, indicating when the client should retry. The client is expected to poll the order resource at this specified interval with POST-as-GET requests. However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation. Has anyone found a reliable solution to this issue? Or does Apple supports asynchronous order finalization? Ref -https://datatracker.ietf.org/doc/html/rfc8555#:~:text=A%20request%20to%20finalize%20an%20order%20will%20result%20in%20error,to%20the%20%22certificate%22%20field%20of%20the%20order.%20%20Download%20the%0A%20%20%20%20%20%20certificate. To work around this, I’m holding the /finalize call until the CA issues the certificate. This works when issuance is quick (under 20 seconds), but if it takes more than that , the client times out. Interestingly, the Apple ACME client’s timeout appears shorter than the usual 60-second URLSession default.

I'm reaching out to discuss a significant issue related to how iOS handles app login sessions, particularly in the context of MDM (Mobile Device Management) and the Outlook app. In our organization, we use MDM to distribute applications, including Outlook, with certificate-based authentication for BYOD (Bring Your Own Device) devices. This setup allows users to log in seamlessly to their accounts. However, we've encountered a concerning behavior: when a user unenrolls from MDM, which automatically removes the distributed apps and certificates, they can later reinstall the app from the App Store and find themselves automatically logged back into their previous accounts without any authentication prompts. Here’s a detailed breakdown of the situation: Initial Installation: Users enroll their devices in MDM, which installs the necessary apps and certificates on those devices. Session Storage: After the initial login, the app stores the session locally on the device. App Deletion: When users un enroll their devices from MDM, it automatically removes the distributed apps and certificates. Reinstallation: Days or weeks later, when they reinstall the Outlook app from the App Store, they find themselves automatically logged back into their accounts. This behavior raises important concerns: Lack of Authentication: The app retaining user sessions even after deletion allows users to access their accounts without re-authentication, which could lead to potential unauthorized access and undermines the effectiveness of certificate-based authentication and two-factor authentication (2FA). Note: This issue is not limited to Outlook; we've observed similar behavior with many other apps. Need for a Solution - Given the implications of this behavior, we are looking for effective solutions to prevent it. Specifically, we need options within the MDM framework to: Restrict Session Retention: Implement settings that ensure any app deleted via MDM will lose all stored sessions and require re-authentication upon reinstallation. Default Settings for MDM-Distributed Apps: Ideally, this would be a default feature for all apps distributed through MDM, ensuring that user sessions are not retained after app deletion. Has anyone else experienced this issue? Are there any existing settings or workarounds within MDM platforms to mitigate this problem? Your insights and experiences would be invaluable as we navigate this challenge. Thank you!

There could be a case where-in multiple transparent proxies might exist in the system (for ex., Cisco AnyConnect, GlobalProtect, etc). We want to know if there is a way to order transparent proxies so that the desired transparent proxy gets the request first. During our research, we found a resource which talks about ordering transparent proxies through MDM. https://developer.apple.com/documentation/devicemanagement/vpn/transparentproxy Using this reference, we tried to create a profile and push it through JAMF. Below is the profile that we created and pushed with JAMF. Property List - &lt;?xml version="1.0" encoding="UTF-8"?&gt; &lt;!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"&gt; &lt;plist version="1.0"&gt; &lt;dict&gt; &lt;key&gt;TransparentProxy&lt;/key&gt; &lt;array&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.paloaltonetworks.GlobalProtect.client.extension&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;1&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.cisco.anyconnect.macos.acsockext&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;2&lt;/string&gt; &lt;/dict&gt; &lt;dict&gt; &lt;key&gt;ProviderBundleIdentifier&lt;/key&gt; &lt;string&gt;com.mydomain.transparentproxy&lt;/string&gt; &lt;key&gt;Order&lt;/key&gt; &lt;string&gt;3&lt;/string&gt; &lt;/dict&gt; &lt;/array&gt; We are not sure if this is the right way to create the profile, though JAMF is not throwing any error while pushing this profile. We see this profile on the local machine as "/Library/Managed Preferences/com.apple.networking.vpn-transparent-list.plist". Is there a way to know if the profile took effect and the order of transparent proxies has changed. Thanks in advance.

I was able to setup a release test for an iOS app for distribution using a web server. It works perfectly fine for all the devices I registered for the deployment profile. However every time I try to distribute a Unity based Vision Pro application using the same process for building the package and set up for distribution it does not work. Safari only shows a message telling me: "Cannot connect to ." When trying to install the iOS app from the same server it shows the message "Do you want to install ?" and installation completes correctly. My iOS is a simple hello world app generated by Xcode. My Unity app is an AR app targeting com.apple.platform.xros. According to documentation there should not be any difference in deployment profiles/signing for iOS apps vs. visionOS apps. What am I doing wrong? Any hint is appreciated how to continue.

Since this file is protected by SIP, it can't just be changed by an installer/app without prompting the user. If the user chooses to deny the request, the sudo file won't be updated with a security critical pam module. I need to insert our custom pam module into /etc/pam.d/sudo without the user being able to deny the operation.

When the user pushed the lock device action on a macOS 14, it returned an acknowledgement but the device wasn't locked. Which resulted in loss of data on the device.

I'm developing an ACME server to issue identity certificates to macOS/iOS devices for MDM attestation, following RFC 8555. Per RFC, the client creates an order, performs authorization, verifies the challenge, and finalizes the order by submitting a CSR to the CA. In my setup, the CA sometimes takes longer to issue the certificate (around 50 seconds). According to RFC 8555, if certificate issuance isn’t complete after the /finalize call, the server should respond with an "order" object with a "processing" status. The client should then send a POST-as-GET request to the order resource (e.g., /order/<order_id>) to check the current state. If the CA still hasn’t issued the certificate, the server should return the order object with the same "processing" status and include a "Retry-After" header, indicating when the client should retry. The client is expected to poll the order resource at this specified interval with POST-as-GET requests. However, it seems the Apple ACME client ignores the "Retry-After" header and instead returns the error: "Profile failed - Order status is processing, not yet valid" immediately upon the first poll response with "processing." Apple ACME client deviating from the RFC documentation. Has anyone found a reliable solution to this issue? Ref -https://datatracker.ietf.org/doc/html/rfc8555#:~:text=A%20request%20to%20finalize%20an%20order%20will%20result%20in%20error,to%20the%20%22certificate%22%20field%20of%20the%20order.%20%20Download%20the%0A%20%20%20%20%20%20certificate. To work around this, I’m holding the /finalize call until the CA issues the certificate. This works when issuance is quick (under 20 seconds), but if it takes more than that , the client times out. Interestingly, the Apple ACME client’s timeout appears shorter than the usual 60-second URLSession default.

We have network system extension which is fundamental part of our application and needs to be installed before the application can run. In many cases we need the installation to be automated, i.e. without logged-in user (with the help of MDM solution like JAMF). Is there a way to activate the extension fully automated without logged-in users? I tried to call 'open -W -a /Application/' from the package's post install script. But seems launch fails if no user is logged in.

Hello, I am writing a NetworkExtension VPN using custom protocol and our client would like to able to use 5G network slice on the VPN, is this possible at all? From Apple's documentation, I found the following statement: If both network slicing and VPN are configured for an app or device, the VPN connection takes precedence over the network slice, rendering the network slice unused. Is it possible to assign a network slice on a NetworkExtension-based VPN and let the VPN traffic uses the assign network slice? Many thanks

Hi, I have a question regarding reading the configuration of a managed app deployed via an MDM system. The application has an Action Extension and can receive shared files via this extension. The problem I am facing is that I can read the managed configuration in the host app by accessing the UserDefaults.standard.object(forKey: "com.apple.configuration.managed") dictionary. With this, I can configure the host app. However, I am unable to read this configuration key in the Action Extension part of the application. My question is whether there is any possibility to read the managed configuration even in the extension. So far, I have been unable to figure out how to read it. I found the sample code, but it was not very helpful since it is very basic and does not deal with extensions at all. Any hints are appreciated.

https://support.apple.com/en-gb/guide/deployment/dep6fa9dd532/web dangles a carrot about being able to facilitate "A list of domains that the Shared iPad sign-in screen displays. The user can pick a domain from the list to complete their Managed Apple ID." - this sounds ideal! In the absence of this seemingly being supported by Apple Configurator or iMazing Profile Editor at the time of writing, I have tried to create my own but I fall foul of knowing what PayloadIdentifier or PayloadType to use? This is the draft/work in progress/doomed to failure config so far (which doesn't - as expected - work): <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>HasRemovalPasscode</key> <false/> <key>PayloadContent</key> <array> <dict> <key>PayloadDescription</key> <string>Configures Managed Domains</string> <key>PayloadDisplayName</key> <string>Domains</string> <key>PayloadIdentifier</key> <string>com.apple.domains.DE12211A-CFDD-4F8C-8D7B-72E569CE3B6C</string> <key>PayloadType</key> <string>com.apple.domains</string> <key>PayloadUUID</key> <string>DE12211A-CFDD-4F8C-8D7B-72E569CE3B6C</string> <key>PayloadVersion</key> <integer>1</integer> <key>WebDomains</key> <array> <string>domain.com</string> </array> </dict> </array> <key>PayloadDescription</key> <string>For Shared iPad login convenience</string> <key>PayloadDisplayName</key> <string>DefaultDomain</string> <key>PayloadIdentifier</key> <string>Tom.77CF3CA5-4A48-41DD-9179-EF6F4C5E786E</string> <key>PayloadRemovalDisallowed</key> <true/> <key>PayloadType</key> <string>Configuration</string> <key>PayloadUUID</key> <string>A5594F17-155B-4A1C-8696-3F502D118C37</string> <key>PayloadVersion</key> <integer>1</integer> </dict> </plist> The support article is probably ~2-year old information so I'd have thought that by now that this would be documented somewhere - am I just not looking hard enough?

Hello, I have a system, which is able to execute bash/zsh scripts on a set of machines. The default behaviour is that the signature of the script is checked on the machine, which is executing it, and in case if it is not signed properly, the system rejects the execution. An own certificate has to be created for signing the scripts, which means that the certificate has to be installed and marked as trusted on the target machines (which are executing the script). I've been using : "/usr/bin/security add-trusted-cert ..." command to install the certificate on the machines as trusted. Since macOS Big Sur, the above command was prompting the local user for admin credentials. To avoid this, Apple suggested to use the following command to temporarily disable and re-enable the confirmation dialog : 1.: /usr/bin/security authorizationdb write com.apple.trust-settings.admin allow 2.: /usr/bin/security authorizationdb write com.apple.trust-settings.admin admin Now with the release of macOS Sequoia, the above command : "/usr/bin/security authorizationdb write com.apple.trust-settings.admin allow" does not work any more. It gives the following output : NO (-60005) I have the following questions : 1.: Could you please suggest an alternative way for IT administrators to install certificates on their machines, without any user confirmation? 2.: Could you please suggest how the same could be achieved using a bash/zsh script? In which context could the above commands : "/usr/bin/security authorizationdb write com.apple.trust-settings.admin allow" and "/usr/bin/security authorizationdb write com.apple.trust-settings.admin admin" still work? Thank you for your help in advance!

I am looking into bypassing the following popup when setting up an iPhone 15 Pro: Would the SkipKey SIMSetup allow to bypass having the following window popup upon initial setup? So far all settings are bypassed during the initial setup of the phone and the application of Wi-Fi. The only issue present in the setup I want to achieve is prohibiting this window regarding eSIM set up.

We are in the process of replacing the TripleDES algorithm with AES in our MDM solution. However, after switching the encryption algorithm, we encountered the following error on Apple devices during enrollment: Error: "-26275 error decrypting response payload (mdmclient(SCEP))" Do Apple devices support AES encryption during the enrollment process, or are there any known limitations that prevent its use? Technical Details: During enrollment, when the device attempts to install the Management Profile, it requests the MDM server to retrieve the device certificate from the SCEP URL. We send the certificate by creating Enveloped CMS content, using TripleDES as the algorithm identifier. If we switch the algorithm to AES, we observe the error mentioned above. We are also using TripleDES when preparing the CMS content for the enrollment profile, which works without issues.

A profile that contains setting of allowVPNCreation is false was installed duiring activation in my requirements. The iOS version is 18. AllowVPNCreation is first, setting the app's network is second, the app can't use network. Setting the app's network is first, AllowVPNCreation is second, the app works well. For example: Scene 1 Step 1: Install a profile that contains a setting where allowVPNCreation is false during activation. Step 2: Complete activation and enter the main screen. Step 3: Tap App Store, the screen displays network unavailable, needs to be set in Setting. Step 4: Open the network setting for App Store, but still closed.And the network settings for other apps are all closed; Step 5: Remove the profile. Step 6: After a minute, opening the network setting for App Store is work. Result: AllowVPNCreation effects app's newtork after entering the system for the first time. It don't happen below iOS 18. Scene 2 Step 1: The app's network setting is ok. Step 2: Install a profile that contains a setting where allowVPNCreation is false. Result: No effect。The same result below iOS 18. Is this a bug or new features, how to handle？

Could you please provide guidance on what is required to set up an Apple MDM server from scratch? Specifically, I would like to understand the necessary steps, tools, certifications, and best practices involved in the process. Any resources or documentation you could recommend would also be appreciated.

I have a macOS app with Network Extension. It requests VPN permission with the code like this: self.tunnelManager = [NETunnelProviderManager new]; NETunnelProviderProtocol *protocol = [NETunnelProviderProtocol new]; protocol.providerBundleIdentifier = @"com.myapp.macos.tunnelprovider"; self.tunnelManager.protocolConfiguration = protocol; [self.tunnelManager setOnDemandRules:nil]; [self.tunnelManager setOnDemandEnabled:NO]; [self.tunnelManager setEnabled:YES]; [self.tunnelManager saveToPreferencesWithCompletionHandler:^(NSError * _Nullable saveError) {}]; A lot of my app users are businesses and they would like to have pre-install VPN config. We currently do it like this: <array> <dict> <key>PayloadDisplayName</key> <string>MyAppName</string> <key>PayloadType</key> <string>com.apple.vpn.managed</string> <key>UserDefinedName</key> <string>MyAppName</string> <key>VPN</key> <dict> <key>AuthenticationMethod</key> <string>Password</string> <key>ProviderBundleIdentifier</key> <string>com.myapp.macos.tunnelprovider</string> <key>ProviderDesignatedRequirement</key> <string>anchor apple generic and identifier "com.myapp.macos.tunnelprovider" and (certificate leaf[field.1.2.3] /* exists */ or certificate 1[field.1.2.3] /* exists */ and certificate leaf[field.1.2.3] /* exists */ and certificate leaf[subject.OU] = "123")</string> <key>RemoteAddress</key> <string/> </dict> <key>VPNSubType</key> <string>com.myapp.macos</string> <key>VPNType</key> <string>VPN</string> </dict> </array> Now, if the users installs my app first and allows the VPN permission, then MDM will set the profile above to the user, the user will end up with two VPN profiles in settings. They will be called "My App" and "My App 1" At first we thought it's harmless, but users with two VPN profiles sometimes have app update issues, where after update the newer version of client fails to communicate with the older version of tunnel, it cannot even tell it to quit. The tunnel must be force-quit by the user in this case. We suspect two profiles to be the reason for that. Is there a way to make sure duplicate VPN profiles do not happen?

Under iOS 18.0.1, I can't do any development that uses HTTPS, because I can't authorize my generated certificates on my phone. This was not a problem in the past. Normally you AirDrop a root certificate authority to your phone, install the "profile" for it, and then trust it in Settings / General / About / Certificate Trust Authority. Then you can connect to another server on your network that's using the accompanying certificates. But after sucessfully installing two profiles on my phone, neither shows up in Certificate Trust Authority. Anybody else seeing this? This problem, in combo with this one (which prevents running on my Mac as an iPad app) has completely halted my project. I've found reports of this problem that blamed an empty "common name" field in the certs, but that field is populated in both of these.