Submit User Information From AD Into The JSS At Login v2

Standard

A couple of years ago I posted on how we “Submitted 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). Screen Shot 2014-05-04 at 00.36.30     One 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. Screen Shot 2014-05-04 at 00.29.54Submitting 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:

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.

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.

19 thoughts on “Submit User Information From AD Into The JSS At Login v2

  1. Fabian

    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.

      • Fabian

        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….

  2. Tim kimpton

    Hi Ben

    What’s your extensionAttribute5?

    I didn’t know it was possible to do that with the Department field 🙂

    • WordPress.com Support

      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.

  3. 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.

  4. Stephan Peterson

    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.

    • Stephan

      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.

  5. 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?

  6. Taylor A

    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.

    • Taylor A

      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: http://macmule.com/2014/05/04/submit-user-information-from-ad-into-the-jss-at-login-v2/
      #
      # GitRepo: https://github.com/macmule/SubmitUsernameAtReconForLDAPLookup
      #
      # License: http://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

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.