I know the title sounds illogical, but bear with me.

I've been testing NoMAD and NoMAD Login AD as a replacement for our AD bind. We use LDAP group limitations regularly for policies, and also for a couple of user-level Configuration Profiles. I try to steer clear of these in general, but for things like Chrome managed preferences we're basically stuck with them.

Policies seem to work fine. For example we have login Policies to mount SMB shares, scoped at the relevant machines and using an LDAP group limitation. A NoMAD Login account will pick up these policies and mount them at login. Despite being a local account, it apparently satisfies the limitation since the account name matches the LDAP account in AD (which is part of the relevant LDAP group). NoMAD itself ensures the user has a Kerberos ticket, so the share mounts without prompting for credentials, just as if we were still using an AD bind and mobile accounts.

However, when doing the same thing with user-level Configuration Profiles, Jamf Pro doesn't seem to match the local account name to the LDAP account, thus limitation isn't satisfied and the user-level Configuration Profiles aren't installed.

Is this by design/an unavoidable part of the way Configuration Profiles are deployed? Since it works fine with Policies, I was hoping it'd be possible to get it working with Configuration Profiles as well. Unfortunately the rare instances where we use user-level Configuration Profiles + LDAP group limitations are a requirement, so this will be a roadblock to us replacing AD bind with NoMAD and NoMAD Login AD.

Any advice would be greatly appreciated.