Did you get anywhere on this? I seem to have a similar issue with accounts using the OIDCAdminClient value on an M1 running the latest Big Sur release. My Account which is Admin, set by default and is in the OIDCAdminClient list seems to be demoted to standard on a reboot. We often give the user Admin rights to the device and now it would be possible that they get removed. We are looking into why this is happening.
Bumping this, as I am having the same issue with 2 users. One is running Monterey 12.1 and the other is on 11.5.2.
We use Jamf Connect to set all users to Standard accounts, and then manually promote certain people to Admin via a dscl command. But when these 2 users restart their systems, they lose admin privileges and I need to remote in and promote their account again.
For both of these users and systems, I have tried promoting their accounts via the Users & Groups PrefPane, but the same issue happens, they lose admin privileges after restarting.
Jamf Pro Cloud 10.35
Jamf Connect 2.5.0 (on both systems)
Bumping this, as I am having the same issue with 2 users. One is running Monterey 12.1 and the other is on 11.5.2.
We use Jamf Connect to set all users to Standard accounts, and then manually promote certain people to Admin via a dscl command. But when these 2 users restart their systems, they lose admin privileges and I need to remote in and promote their account again.
For both of these users and systems, I have tried promoting their accounts via the Users & Groups PrefPane, but the same issue happens, they lose admin privileges after restarting.
Jamf Pro Cloud 10.35
Jamf Connect 2.5.0 (on both systems)
This sounds like the bug fix after 2.02.. I would have to find it but if you are using OIDC groups (admin and client) to define Admin rights, then after that release it seems Jamf fixed the issue of enforcing the group. We would do the same often promote a user to Admin on their own hardware, however using later versions, the user needed to be in the OIDCAdminClient group to keep permissions (where previously they didn't). Security wise this makes sense to enforce the groups however it isn't practical for our use case.
This sounds like the bug fix after 2.02.. I would have to find it but if you are using OIDC groups (admin and client) to define Admin rights, then after that release it seems Jamf fixed the issue of enforcing the group. We would do the same often promote a user to Admin on their own hardware, however using later versions, the user needed to be in the OIDCAdminClient group to keep permissions (where previously they didn't). Security wise this makes sense to enforce the groups however it isn't practical for our use case.
@bmcdadethank you for the explanation. My Jamf support engineer came back with the same thing right after you did.