Skip to main content
Question

SSO & LDAP Device Assignments


Forum|alt.badge.img+4

We are deploying a large number of iOS devices and want to use our Google SSO configuration for users to self assign their device.

Users log in and their device is assigned correctly, but we would like to pull additional data from LDAP for the equivalent user. Is there a way to do this automatically?

5 replies

JoshRouthier
Forum|alt.badge.img+8
  • Valued Contributor
  • 67 replies
  • October 22, 2020

Looking at doing this with Azure as well, if anyone has any insight on marrying an SSO user and LDAP user


Forum|alt.badge.img+7
  • Contributor
  • 23 replies
  • October 26, 2020

@astrugatch If your user mapping in Single Sign-On matches that of Username in your LDAP server mapping then Jamf should automatically populate the device's User and Location record with the details that it can pull from LDAP. To get phone number for instance, you would need to make sure that field was correctly configured in the LDAP user attribute mapping.

@JoshRouthier With Azure, if you have a sAMAccountName that differs from userPrincipalName, you may want to consider setting SSO User mapping to a custom attribute from the SAML assertion so Jamf can tie an SSO user to LDAP.

Here we use Azure to send an additional claim of the sAMAccountName and use that rather than UPN to map the users and scope policies. If you want to see what details are sent in an SSO claim, SAML Message Decoder Chrome extension can be helpful to see what claims are being sent. Additional claims are configured in Azure under the Jamf Pro enterprise applications Single Sign on pane.


Forum|alt.badge.img+9

@dtommey Thanks for posting this information. I was stuck trying to figuring out why scoping policies in self-service after enabling SSO in Azure and Jamf Pro was not working. In my AD sAMAccountName and UPN are different. If anyone is interested here are the additional steps needed:
1. Login into Azure AD
2. Click on Enterprise applications
3. Search for Jamf Pro, click on it
4. In the left-hand pane click on Single sign-on
5. Edit User Attributes & Claims (looks like a pencil)
6. Enter the Claim name: sAMAccountName
7. Enter the Value: user.onpremisessamaccountname
8. Save
Should look like this

  1. Login to Jamf Pro
  2. Click on settings
  3. Click on Single Sign-On
  4. Edit
  5. Under User Mapping change Identity Provider User Mapping to "Custom Attribute" and enter "sAMAccountName"


14. Save.
15. I restart Tomcat


Forum|alt.badge.img+8
  • Valued Contributor
  • 109 replies
  • June 29, 2021

Hey @luke.michelson

Can you confirm that this behaviour populates the fields on the Create Account screen when setting up macOS? If so, can you please configuration for Jamf Pro User Mapping.

With the default settings (ie. no additional claim), the Full Name field is populated with the user's full name, and Account Name defaults to the user's UPN.

With an additional claim (ie. using user.onpremisessamaccountname) I'm able to populate the Account Name with the sAMAccountName value however the Full Name field doesn't populate.

I've gone back and through throwing several combinations and have finally raised a support request and have confirmation that Jamf SE have recreated the issue on 10.29.1.


Forum|alt.badge.img+3
  • New Contributor
  • 3 replies
  • January 6, 2022
jimmy-swings wrote:

Hey @luke.michelson

Can you confirm that this behaviour populates the fields on the Create Account screen when setting up macOS? If so, can you please configuration for Jamf Pro User Mapping.

With the default settings (ie. no additional claim), the Full Name field is populated with the user's full name, and Account Name defaults to the user's UPN.

With an additional claim (ie. using user.onpremisessamaccountname) I'm able to populate the Account Name with the sAMAccountName value however the Full Name field doesn't populate.

I've gone back and through throwing several combinations and have finally raised a support request and have confirmation that Jamf SE have recreated the issue on 10.29.1.


@jimmy-swings 

Any luck? I am set everything back to default and used the $PHONE user variable as the samaccountonpremise as a workaround for the issue you are describing. 


Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings