A follow-up to this ticket, but different enough I wanted to start anew.
Essentially, we're trying to do zero-touch with our next batch of MacBooks, so I've been working on a new Enrollment Profile. We want to primary account information (name and username) to be filled-in and locked during setup. Initially we tried to pull the data via prestage (see prior ticket), but since that isn't working, we tried via Google SSO and Secure LDAP:
I followed these directions for the Google SSO:
https://docs.jamf.com/technical-articles/Configuring_Single_Sign-On-with_Google_Workspace.html
Along with adding the SSO pane to the prestage. The pane seemed to work fine — asked for login, went through two-factor authentication, continued the setup afterword — but it never passed the variables to the Create a Computer Account screen, so the name and the username were still blank. I tried both Custom Details and Device Owner's Details in the Pre-fill Primary Account Information, neither worked.
So then I tried using the Google Secure LDAP Integration using the directions here and on Google:
https://docs.jamf.com/10.42.0/jamf-pro/documentation/Google_Secure_LDAP_Integration.html
If I go to System Settings >> Cloud Identity Providers >> [name of Google LDAP] and run a test, I can see information for particular users, so I know it at least partially worked. But when I set that up as a pane in the prestage, I can't get past the password of my Google account — it doesn't seem to recognize it.
I only need one of these to work, so if anyone has any thoughts on where I may have gone wrong in either direction, I'd appreciate it. I'm happy to give more specific details about my setup if it helps.
Pre-filling primary account information with Google SSO/LDAP
+8
You actually need both to work. The SSO gives you the authentication part, so that the user can authenticate to enroll the device. You then need to cloud identity provider so that Jamf can look up the user that authenticated in your directory. You'll need to make sure that the mapping is correct (so that a lookup on the username or email returns the correct user value). I haven't set up Google, but with Azure the user signs in with their userPrincipalName (e.g. username@domain.com), but I map the Jamf User Name to the Azure mailNickname attribute. This gives me the everything up to the @ as the Jamf username (and therefore short name for the local user account in macOS).
One thing I found in my testing is to make sure you have a test account, that is not also a Jamf Pro admin account. I found that if a user with the same username already exists as a Jamf Pro admin, the cloud LDAP lookup will fail.
Hope this helps!
+3hi,
You should check mappings in SSO or LDAP authentication, whatever you use, what type username is set for authentication, full email (with @domain.com) or just a user name (without @domain.com)
Also, if you using SSO with MFA, try temporarily to disable MFA for that account and test it, I remember reading somewhere about the issues with MFA and SSO.
+8You actually need both to work. The SSO gives you the authentication part, so that the user can authenticate to enroll the device. You then need to cloud identity provider so that Jamf can look up the user that authenticated in your directory. You'll need to make sure that the mapping is correct (so that a lookup on the username or email returns the correct user value). I haven't set up Google, but with Azure the user signs in with their userPrincipalName (e.g. username@domain.com), but I map the Jamf User Name to the Azure mailNickname attribute. This gives me the everything up to the @ as the Jamf username (and therefore short name for the local user account in macOS).
One thing I found in my testing is to make sure you have a test account, that is not also a Jamf Pro admin account. I found that if a user with the same username already exists as a Jamf Pro admin, the cloud LDAP lookup will fail.
Hope this helps!
@jcarr wrote:You actually need both to work.
...One thing I found in my testing is to make sure you have a test account, that is not also a Jamf Pro admin account.
Those were two pieces of info I needed — thanks! Still having some mapping issues, but I'm seeing the email address at least in the username field, just not the full name in the name box. I'll play around with this when I have some time, but it's at least transferring *something* now.
Found this, which might be useful for anyone in the future trying to set this up:
https://hcsonline.com/images/PDFs/Google_SSO.pdf
We had the same issue, we ended up using LDAP for auth and Mappings. This resolved the autofill issues for us. this is just a hold over until we switch to Okta/jamf connect as it skips 2 factor using this method.
+4
@jcarr wrote:You actually need both to work.
...One thing I found in my testing is to make sure you have a test account, that is not also a Jamf Pro admin account.
Those were two pieces of info I needed — thanks! Still having some mapping issues, but I'm seeing the email address at least in the username field, just not the full name in the name box. I'll play around with this when I have some time, but it's at least transferring *something* now.
Found this, which might be useful for anyone in the future trying to set this up:
https://hcsonline.com/images/PDFs/Google_SSO.pdf
Hey! How did it go? Did you have any success with setting up the data mapping? Thanks to that helpful observation about not being able to use already-in-use admin accounts (why on earth!), I've also managed to at least get the user's email in a new user's name field in Jamf Pro after enrollment and logging in, but nothing more.
+4We had the same issue, we ended up using LDAP for auth and Mappings. This resolved the autofill issues for us. this is just a hold over until we switch to Okta/jamf connect as it skips 2 factor using this method.
Hi, how were you able to use LDAP for authentication and set up mapping? Do you also use Google?
Thanks!
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.