Post

Replies

Boosts

Views

Activity

Issues with Password based Platform SSO
We are using Apple's PSSO to federate device login to out own IdP. We have developed our own extension app and deployed it using MDM. Things works fine but there are 2 issues that we are trying to get to the root cause - On some devices after restarting we see an error message on the logic screen saying "The registration for this device is invalid and must be repaired" And other error message is "SmartCard configuration is invalid for this account" For the 1st we have figured out that this happens when the registration doesn't happen fully and the key is not tied to the user so when the disk needs to be decrypted at the FileVault screen the issue is raised. For the "SmartCard configuration is invalid for this account" issue also one aspect is invalid registration but there has been other instances as well where the devices were registered completely but then also the the above error was raised. We verified the registration being completed by checking if the SmartCard is visible in the System Report containing the key. Has anyone seen the above issues and any possible resolution around it?
1
0
120
Oct ’25
Inquiry: Inconsistent VPP UpdateBehavior with DDM (auto-update timing + manual-update gating)
Hi there, We’re testing Declarative Device Management (DDM) for VPP app management and followed the latest declaration template here: https://github.com/apple/device-management/blob/release/declarative/declarations/configurations/app.managed.yaml Our goal is to enable VPP auto-updates via the declaration. The payload we’re using looks like this: "AppStoreID": "1231325957", "InstallBehavior": "{\"Install\": \"Required\", \"License\": {\"Assignment\": \"Device\"}}", "UpdateBehavior": "{\"AutomaticAppUpdates\": \"AlwaysOn\"}" } What we’re seeing Device A (no Apple ID signed into App Store): User can manually update the VPP app with the above declaration in place. ( The same user cannot update the app if UpdateBehavior is not in the declaration payload. Device B (Apple ID signed into App Store, and the same Apple ID doesn't have the above app purchased): User cannot manually update the same VPP app. The App Store shows the error seen when UpdateBehavior is absent: “ cannot be updated because it was refunded or purchased with a different Apple Account.” Also, in this case, the user has no way to purchase the (free) app by their own as the app shows as owned/managed by MDM server. We have to remove the declaration, let the user purchase the same app, then re-deploy the declaration to allow the user to click that "Update" button when a new version for that app is available. Additionally, we’re unsure about the criteria/timing for automatic VPP app updates under DDM. After a new version became available, we waited several hours but the app did not auto-update. Repro summary App: VPP, device-assigned license Declaration: AutomaticAppUpdates = AlwaysOn, install required Device A: not signed into App Store → manual update allowed Device B: signed into App Store → manual update blocked with “refunded/different account” error Auto-update did not occur after waiting several hours post-release Any guidance, confirmation of expected behavior, or tips on additional logging we should collect (e.g., specific App Store / MDM / DDM logs and subsystems) would be greatly appreciated. If this is a known issue or requires a Feedback Assistant report, we’re happy to file one. Thanks,
1
0
421
Oct ’25
macOS login issue with federation
We have couple of devices that are registered into Platform SSO, and we have been noticing an issue when the user tried to login. After the users enters the password and hit the return key nothing happens, they need to hit the return key probably 10-15 times in order for the login to happen, the password entered is the correct one and it's just that hitting the return key doesn't invoke the login. On checking the log of the device one unusual thing that we noticed as compared to a different device where the login is working in a single go is that the AppSSOAgent or AppSSODaemon process were not getting invoked
1
0
320
Oct ’25