A couple of years ago I posted on how we “Submit User Information From AD Into The JSS At Login” Since the Casper Suite 8.61 was release, the JSS has been able to perform this function. Below is a guide on how to leverage this.
Prerequisites
Your JSS needs to have at least one LDAP server specified, with the correct attribute mappings for your environment. Below is an example of the mappings that we use, (you can use Directory Utility to find these attributes as shown here).
Once you have verified that the LDAP servers attribute mappings are correct for your environment, you will also need to enable collection of user & location data at inventory collection. In JSS v9 this is under Computer Management > Inventory Collection > General. The option to tick is shown below.
Submitting User Information
Now if your run a recon via a policy, Casper remote or the below.. you’ll notice that the users information does not get updated in the JSS:
sudo jamf recon
This is because you’ve not told the JSS what username you wish to perform the LDAP lookup for. To do that, create a policy that runs at login with the below in the “Execute Command” field found under the “Files and Processes” payload.
sudo jamf recon -endUsername $3
This will update the users users name on the JSS & then instruct the JSS to perform an LDAP lookup using that username.
However, as the above uses Casper’s $3 variable, it will only work at login. Also as jamf binary runs as root you can’t use the $USER variable.
The below can be ran at anytime & if the above mentioned prerequisites are met, should start to populate user information in the JSS.
Departments
It’s a bit of an oddity, but Departments need to be manually defined in the JSS before they will show. This is done under Network Organisation > Departments.
If you try & submit a users department that isn’t defined in the JSS, then this field will not update until the department is added to the JSS.
Also, if your network segments are set to override the department for devices within them, then that method takes precedence over LDAP & so will not be updated via this method.
Buildings
As per Departments, if your network segments are set to override the building. Then the LDAP method will not update the Building field.
Hi there,
actually I am running a script to pull those informations from my AD via dscl, because I always ran into problems using the JAMF way. I used to put in the same attribute names as you did, but never checked Directory Utility to see if the attributes are correct. Now I checked this, and figured out that…for example pulling the users email, obviously the attribute is ‘EMailAddress’, as well as for UserID, the attribute is ‘dsAttrTypeNative:sAMAccountName’.
Do you think that’s the problem? I am wondering, because when I do the LDAP connection test, all informations are pulled correctly. Any ideas?
Cheers,
Fab
Definitely verify what’s in the script is also being used for the mappings in Caspers LDAP servers..
But using a script does work still, so no need to change.
Thanks for your response. There is definetly a need for me, because I cannot pull the informations for single attributes if I am out of our internal network. I now mapped the needed attributes to different fields like Position, although it’s thei class group. Creating the departments also helped me to get this running. Without my script, I now can initiate the policy on the client computer using the login name, but the informations are now coming from LDAP to JSS directly which fixed my problem with the external network.
Thanks again….
Great. Glad it helped.
This is excellent thanks for sharing it!
Hi Ben
What’s your extensionAttribute5?
I didn’t know it was possible to do that with the Department field 🙂
Our is company I think, our parent company is the same across all. But we have 11 brands.. So each extensionAttrubute5 is set to the brands name.
Hey Ben, thanks for the script. Useful that it can be run with any trigger and not just at login…
I have two questions:
1. Why is there a sudo in the script? (isn’t the script run as root)
2. I have an inventory update policy that runs once everyday at check-in.
Does the line jamf recon -endUsername $loggedInUser in the above script run a complete recon?
Im trying to avoid the added overhead on the server.
Hey fella.
1) True. I think I left the sudo in by mistake.
2) Full recon, because: https://jamfnation.jamfsoftware.com/featureRequest.html?id=78
Thanks for coming back to me dude. I’ll combine my autopopulate location and daily inventory as one policy then.
As always love your work!
PS – Bring back the verbs 😉
Nice. FWIW, we do a recon @ login using the above.
Where is the script?
Hi Adam,
It’s in the post, via a plugin that links to GitHub.
Direct link: https://github.com/macmule/SubmitUsernameAtReconForLDAPLookup/blob/master/SubmitUsernameAtReconForLDAPLookup.sh
I’ve gone down the path of using the original at login version. It seems to be working but I am seeing some weirdness. When looking at users in the JSS, some folks have a 0 in the computer column, which makes no sense to me. Also, we have a couple of local accts on all machines (going away, but there for now) and they seem to get an AD user associated with them and it changes over time. These local accts DO NOT exist in AD. It’s very puzzling. I’ve got a call into our TAM, but thought I’d comment here.
I think I understand why users have a 0 in the computer column. They’ve since logged out of a computer and another user has logged into it. Only one user per computer in the JSS, makes sense. Still not sure about the local user acct picking up name and email address from AD.
Ben, I’m running your script exactly as you have it. It’s scoped to run once per user per computer at login and check-in, limited to two user groups in LDAP. For some reason, after it runs, the computers are getting dumped into my smart group that have one criteria: management account not jamfadmin (this is our local jamf management account). I just verified that once the script runs, even if it does a normal recon afterwards, the computer gets pulled into that smart group. Looking at the record you can see that the management account is still jamfadmin, but for some reason the JSS doesn’t think so any more after that script. Any ideas?
Ben, One other thing that I’m noticing on our system. We use a standard local admin account, let’s call it “admin”. On machines that are at the login window when recon runs, it is reporting the user as “admin” Would it make more sense to have a bit of logic in the script basically saying “if who | grep console; then” to make sure a user is on the system? I’ll probably test this out later today if I get a chance, but it would seem to make sense to me to abort if the machine is not in use rather than over-write the actual user’s info. I’m not sure why it thinks “admin” is using it, the only thing that occurs to me without digging into it is that that account is used for regular Nessus scans over ssh, so perhaps it is the “last used” account in that sense. I’ll report back once I’ve had a chance to test more.
Just to followup – the following appears to work well. I’m a lousy scripter, so I’m sure it could be cleaned up, but adding the “if who | grep” line means that it skips reporting anything if there is nobody logged on at the console, only reports back for users logged into the gui.
#!/bin/sh
####################################################################################################
#
# More information: https://macmule.com/2014/05/04/submit-user-information-from-ad-into-the-jss-at-login-v2/
#
# GitRepo: https://github.com/macmule/SubmitUsernameAtReconForLDAPLookup
#
# License: https://macmule.com/license/
#
####################################################################################################
#Verify user is logged in, exit if not
if who | grep console; then
# Get the logged in users username
loggedInUser=`/bin/ls -l /dev/console | /usr/bin/awk ‘{ print $3 }’`
echo “Running recon for $loggedInUser `date`…”
# Run recon, submitting the users username which as of 8.61+ can then perform an LDAP lookup
sudo jamf recon -endUsername $loggedInUser
echo “Finished running recon for $loggedInUser `date`…”
exit 0
fi
exit 1
can you pls define how to get the AD user email ID to jamf inventory