Skip to main content

Our organisation recently went from a horrible system using only AD bind and Apple Profile Manager, to Jamf Pro + Jamf Connect Login.



We have an on-prem Active Directory that is synchronised with Azure AD. Our Jamf Pro instance is connected directly to the Azure AD instance to allow for User/Group synchronisation, and this connection appears to function.



We have some user-level configuration profiles that we want to be applied based on a user being a member of a certain group... For example, "non-admin settings" (blocking off certain Preferences Panes, etc.), and "admin settings" (allowing access to all options). We target these profiles based on membership, or lack of, in an AD group (synced up to Azure AD) for administrators.



When I log into a Mac using Apple's default login window, bound to our on-prem Active Directory, the profiles apply perfectly, every time. I've tested this on several computers and with admin and non-admin accounts. However, when I install Jamf Connect Login and log in that way, no User Profiles are applied at all, on any computer, with any user. Nothing changed on the scope of the configuration profiles, just the method of logging in on the computer.



Has anyone else had this issue, where configuration profiles will apply using the default Login Window, but not using Jamf Connect Login?



Sadly, our Jamf Connect onboarding was literally two days before our Jamf Pro was updated to 10.27 (which added the Azure AD sync for scoping policies/profiles), so we were unable to test this during the Jamf Connect onboarding.



Thanks,
Sam

We don't use Azure for auth, but from earlier exploration of moving away from AD binding via NoMAD-Login (Jamf Connect's precursor), I think I may know the issue....



It comes down to the difference between 'network' accounts (which get created when you bind to AD and login with an AD account), which can have profiles scoped via AD group membership, and 'local' accounts, which don't allow you to scope profiles via AD group membership.



Again, I haven't tried Jamf Connect, but with NoMAD-Login I found it creates a local account on the device, then does some magic in the background to keep passwords synced. Unfortunately this means that you end up with a local account on your Mac, which does not work with the AD group scoped profiles.



You can investigate a bit more yourself to confirm. If you run id user_name on the two different account types, you'll get very different user id numbers. A local account will have shorter uids and group ids, something like:



uid=501(admin) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),502(com.apple.local.ard_admin),701(com.apple.sharepoint.group.1),702(com.apple.sharepoint.group.2),704(com.apple.sharepoint.group.4),33(_appstore),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),703(com.apple.sharepoint.group.3)


Whereas an AD bound network account will have much longer ids and look more like:



uid=1794919922(test_student) gid=719152363(CSFDomain Users) groups=719152363(CSFDomain Users),12(everyone),62(netaccounts),490678126(CSFcsf-gr-e-adobe-manuel),1204802487(CSFcsf-gr-adobe-vir-fictm12),1614066433(CSFegr-ag-e-niv05),701(com.apple.sharepoint.group.1),702(com.apple.sharepoint.group.2),704(com.apple.sharepoint.group.4),98(_lpadmin),100(_lpoperator),703(com.apple.sharepoint.group.3),1193849965(CSFcsf-ag-e-niv05),1253809429(CSFcsf-ag-tous),1389372409(CSFcsf-ag-e-tous),118003752(CSFegr-ag-tous),1478193451(CSFegr-ag-e-tous)

Hi Jeff,



Our scoping isn't actually by necessarily by group membership - it's sometimes based on simply the user's login name.



Apparently, the issue comes down to the this:
1. AD accounts seem to be made "MDM-capable" by default.
2. Accounts made by Jamf Connect Login cannot be made "MDM-capable" by default. You can manually run a command from the account to make it "MDM-capable", at which point it starts working as expected... but this isn't acceptable in a lab setting where you need the settings to apply without the user manually taking action to accept them.



More info here: https://www.jamf.com/jamf-nation/feature-requests/9634/enabling-user-level-mdm-via-jamf-connect-login



In our case, unfortunately, Jamf has not been able to provide a solution (unclear whether this is an Apple limitation or a Jamf feature that's missing), and we'll probably have to go back to AD bind.

I hear you, Apple has definitely been pushing a move away from AD Binding, but there are features like this that we lose in our testing, so we haven't made the move yet. It's a bit frustrating to be honest.

Reply


Terms & ConditionsCookie settings