User and Location Data

[agrant]

We're trying to populate user and location data on our iPad devices - But it doesn't seem to work.

We have Azure setup as our Cloud Identity Provider. The test function confirms the lookups & mappings are working properly.  We have an Enrolment customisation that points to our SSO Azure authentication - This is then set on our pre-stage enrolment. 

When a device goes through setup - The users are prompted to sign in. We expected the user & location data to be populated - But it doesn't. 'Collect user and location information from LDAP' is ticked under inventory collection settings.

Has anyone got this to work? Not sure what we're missing.

Cheers

[jcarr]

Does the Enrollment Customization use the SSO auth pane or the LDAP auth pane?  Also, you've configured both the SSO *and* the Cloud Identity Provider, right?

[agrant]

Thanks for the reply. The Enrolment Customisation uses SSO & we've configured both the SSO and CIP. 

One thing we have found is that it does populate the User and Location information when we use a user-initiated enrolment - Just not the pre-stage method. 

[ryanpigeon]

Following this, as I can confirm we are having this happen with Okta as well. 

[peterlewis]

+1 for this (using Azure). I note we don't currently have "Collect user and location information from LDAP" ticked within "Inventory Collection" due to PI008110, though I note that is no longer listed in active PIs.

[kevc]

I also can't get User and Location information to populate during a prestage enrollment. I have the enrollment customization set up to use Azure SSO and Collect User and Location information from LDAP is checked under Inventory Collection for devices.

@agrant Did you ever get this figured out?

[peterlewis]

I have a ticket open about this, now. Once we have arrived at a solution, I will be sure to update you with what that solution was.

[kevc]

Thanks! I opened a ticket as well and was told the issue is related to PI101570. I checked the product issues page and it does sound related but hard to tell. Let me know if you hear anything different in your ticket.

[xEpicFail_O_o]

This was an issue for me as well, I can't find the original post anymore but someone suggested a script to run upon user login. Here is the script that we are currently using. Hope it helps and sorry I can't find the original one! 

#!/bin/sh

#Get current signed in user
currentUser=$(ls -l /dev/console | awk '/ / { print $3 }')

#com.jamf.connect.state.plist location
jamfConnectStateLocation=/Users/$currentUser/Library/Preferences/com.jamf.connect.state.plist
DisplayName=$(/usr/libexec/PlistBuddy -c "Print :DisplayName" $jamfConnectStateLocation || echo "Does not exist")

if [ $currentUser != "root" ];

then

/usr/local/bin/jamf recon -endUsername $DisplayName

fi

exit 0

[janzaldua]

Did anyone get this working yet? Still having trouble.

[eatkins]

This issue just cropped up for us (using Okta). Prior to about a week ago, mappings were coming just fine with Inventory.

[serawl01]

Running into this same issue. User-initiated enrollments populate User and Location information, but pre-stage enrollments do not, using Azure SSO. 

[janzaldua]

Hello. Just wanted to give an update, since we got it working within our environment! We connected Azure AD. Firstly, here are the mappings within Settings > System > Cloud Identity Providers:

~~~

User Id id

User Name userPrincipalName

Real Name displayName

Email mail

Department department

Building officeLocation

Room city

Phone mobilePhone

Position jobTitle

~~~

You can test these mappings and they should populate from the username you provide. Keep in mind, some mappings need to be manually entered within Jamf, in order for them to populate correctly. For example, Department and Building. Both can be found within Settings > Network > Departments/Buildings - Within each of these sections, you'll need to manually add each Department or Building, according to how it shows up within Azure AD. What I did is had my System Admin export a list of the Department and Building attribute from AAD, and I manually created each entry within Jamf. Also an FYI, we have the checkbox enabled for Collect user and location information from Directory Service, within Settings > Computer Management > Inventory Collection.

~~~

As far as the script. For us, it only works if it uses the user's EMAIL, not username. You can gather this two ways.

1. If they use Jamf Connect, you can run this script.

#!/bin/bash
#Find the Current Logged in User
UserFound="No"
    while [[ $UserFound == "No" ]]
    do
    CURRENT_USER=$(/usr/bin/stat -f "%Su" /dev/console)
    if [[ $CURRENT_USER == "_mbsetupuser" ]] || [[ $CURRENT_USER == "root" ]]; then
    echo "User Found is $CURRENT_USER, sleeping 10 seconds for the correct username to populate"
    sleep 10
    UserFound="No"
    else
    UserFound="Yes"
    echo "User Found is $CURRENT_USER"
    fi
    done
#Find the information from Jamf Connect
 jamfConnectStateLocation=/Users/$CURRENT_USER/Library/Preferences/com.jamf.connect.state.plist
 
 DisplayName=$(/usr/libexec/PlistBuddy -c "Print :DisplayName" $jamfConnectStateLocation || echo "Does not exist")
#Update the information on JAMF
/usr/local/bin/jamf recon -endUsername "$DisplayName"
/usr/local/bin/jamf recon
exit 0

If the user does not use Jamf connect, it will display "Does not exist" in the User and Location field. And you can create a separate policy that takes the last user to login and adds an @company.com suffix to populate the fields correctly. That script is here:

#!/bin/bash

#Find the Current Logged in User
UserFound="No"
while [[ $UserFound == "No" ]]
do
CURRENT_USER=$(/usr/bin/stat -f "%Su" /dev/console)
if [[ $CURRENT_USER == "_mbsetupuser" ]] || [[ $CURRENT_USER == "root" ]]; then
echo "User Found is $CURRENT_USER, sleeping 10 seconds for the correct username to populate"
sleep 10
UserFound="No"
else
UserFound="Yes"
echo "User Found is $CURRENT_USER"
fi
done

#Find the information from Jamf Connect
jamfConnectStateLocation=/Users/$CURRENT_USER/Library/Preferences/com.jamf.connect.state.plist

#New Line
DisplayName=$(/usr/libexec/PlistBuddy -c "Print :DisplayName" $jamfConnectStateLocation || echo $CURRENT_USER"@COMPANY.com")

#Update the information on JAMF
/usr/local/bin/jamf recon -endUsername "$DisplayName"
/usr/local/bin/jamf recon

exit 0

Keep in mind this script only works if users are logging in using their AD username. Otherwise you can use the first Jamf Connect script instead.

[iOllie]

It seems like the discussion transformed from iOS devices to computers. Has anyone progressed with the pair of iPad/Okta SSO or iPad/AD SSO?

[xEpicFail_O_o]

@iOllie - used this for AD SSO on iPads. Works like a charm but it does have some nuances that are a pain in the ass such as it forces everything to open up w/ MS Edge and causes issues if anything requires Safari.

Had similar issues w/ MacOS and the SSO Configuration profile. It wouldn't allow compliance on intel macs since it wouldnt open Safari.

https://learn.microsoft.com/en-us/mem/intune/configuration/use-enterprise-sso-plug-in-ios-ipados-mac...