Hey @josiah, Thanks for reaching out to Hexnode Connect.
The error you are referring to can be seen in certain scenarios, and is tied to how macOS handles user identity during MDM enrollment.
When a macOS device is enrolled, Hexnode maps the policy association to the user account that performed the enrollment. If the device is later being used or logged into with a different local user account, macOS won’t return the required user token, which leads to the failure you’re seeing in the user profile part of the policy.
That explains why your device profile applies successfully (since that’s machine-level), while the user profile fails.
Here’s how you can fix it:
Please try the following steps on the devices where user profile policies are failing:
Ensure the same user account that enrolled the device is currently logged in.
If you’re using a different account, run this command in Terminal:
Script to reset current logged-in user as the default enrolled user
1
sudo profiles renew-type enrollment
This resets the current logged-in user as the default enrolled user, which allows macOS to generate a fresh user token. After this, your user profile policies should start associating successfully.
If you run into anything else or need further assistance, feel free to reach out; we’re always happy to help.
Our Hexnode tenant is synced with our EntraID tenant, and my macOS device was enrolled at activation (linked to Hexnode via Apple Business Manager) using an EntraID account. During the enrollment process, I am prompted to create a local user account (which is what I am currently logged in as). When I look in my portal, I see that this local account has “Secure Token” as “Granted”. Is that the same thing? I am currently unable to push user profile policy settings as it is.
Looks like you’re running into the same issue I had.
Also, Secure Token is a different thing altogether, so it’s not the same as the user token needed for user profile policy association.
I’d suggest running the same command @george mentioned while you’re logged in to the local account you’re currently using. That should resolve it:
Script to reset current logged-in user as the default enrolled user
1
sudo profiles renew-type enrollment
From what you described, it sounds like your device was enrolled through ADE. Usually, a managed admin account is created automatically during enrollment. But since you mentioned you were prompted to create a new local user account during setup, this might be a separate local account (not the managed admin account).
If your enrollment profile was configured to create a user during enrollment, that would explain this behaviour.