EA data being blanked out

[Taylor_Armstron]

Running into a new one that I've not encountered before.

We use Centrify to bind to AD. I have a fairly simple EA, which basically uses Centrify's "adquery" command to pull the computer's .ou and stick it into the computer record. This allows us to sort machines by their .ou in AD.

When I run "sudo Jamf -recon", it seems to update perfectly, no issues. However, if I let it sit for more than a day or so, the values start to disappear. Right now, I only have a SINGLE computer still reflecting a value (we update inventory daily). Forcing an inventory update via Jamf Remote will re-populate the values, and then again, within a day or two, I see the fields start showing up blank again.

thoughts? Any suggestions on where to even start?

EA below for reference, although again, seems to work 100% when I run recon manually.

#!/bin/bash
Machine=$(hostname -f | cut -f1 -d".")
OU=$(adquery user $Machine$ -C | cut -d"/" -f2)
echo "<result>$OU</result>"
exit 0

[Taylor_Armstron]

Still happening, and so far I'm clueless.

Used Recon to force an inventory update earlier today on a group of systems, and set up a smart group for machines with valid entries for this EA. After updating inventory, had 10 systems in the group.

Then flushed logs for my daily inventory policy, and waited. Within about 90 minutes, I was down to 2 systems left in the group, as the inventory data somehow flushed the EA values.

Anyone have a clue?

[mm2270 · Accepted solution]

@Taylor.Armstrong That's a strange issue.

I'm wondering if the main difference between when the EA is populated, and when it gets blanked out is in how the recon is being triggered. For example, if you manually run sudo jamf recon, or select it in a Jamf Remote session, it runs it one way, but when the Recurring check-in trigger runs it, it's being called by a LaunchDaemon. It sounds like that's the case here, correct?

What I would do is modify the EA to pipe the results into a local file or log with a timestamp on it, like echo "$(date): $OU" >> /some/file. Append to the file each time, then after about a day, take a look at the log file and match up the time in the file to when your recurring check-in inventory collection runs. What I suspect you're going to see is that the data populated on those lines in the log will be blank. I think (can't be sure since I haven't used Centrify in a number of years now) is that when it's run entirely in a root context (from the LaunchDaemon calling it) it can't populate the info, but it can when run with elevated rights as a regular admin user. There is likely some difference happening there.
The way EA scripts work is they must upload some value, even if it ends up being blank. I think that's what's happening here.

Hope that helps.

[Taylor_Armstron]

Thanks @mm2270 . Something along those lines is the only thing that makes any sense right now. So far no pattern found re: users logged in/out, or anything else, so the root vs. user context may be. I'll give it a try on a couple of machines and see what I get. If so, I may just modify my approach to write the file at startup, or something along those lines, and then have the EA simply read it in. Something along those lines. Values should not change often at all, but having it in the database will help a lot with organizing.

[Taylor_Armstron]

Hmm.

Well, may be something ALONG those lines, but don't know definitively yet.

Set it to output to file, and ran a few instances. 1st two were manual "sudo jamf recon", 3rd was "sudo jamf policy" to trigger the normal inventory policy, 4th was another "recon". Flushed my inventory log again, only thing left to try here is to just let it fire off on its own instead of forcing the policy update.

Tue Feb 20 15:57:34 EST 2018: Office1 Tue Feb 20 15:58:56 EST 2018: Office1 Tue Feb 20 15:59:58 EST 2018: Office1 . <-- Inventory policy Tue Feb 20 16:01:14 EST 2018: Office1

[Taylor_Armstron]

Looks like you nailed it, Mike.

Tue Feb 20 15:57:34 EST 2018: Office1 Tue Feb 20 15:58:56 EST 2018: Office1 Tue Feb 20 15:59:58 EST 2018: Office1 Tue Feb 20 16:01:14 EST 2018: Office1 Tue Feb 20 16:34:47 EST 2018: Tue Feb 20 16:35:27 EST 2018: Tue Feb 20 16:36:16 EST 2018: Office1

Don't know why it appears to have run twice during the inventory cycle, but... there you have it.

Going to re-write this to see if I can just make a policy to write out the info at user login, and then have the EA read it. Meanwhile, I blame Centrify :) . Appreciate the insight!

[Taylor_Armstron]

Spoke too fast. Seems the same issue strikes when using a policy to write the text file.

Going to give it a day or two to settle down - we had a scheduled reboot fire off last night as well, so want to make sure that wasn't part of the issue, but I'm seeing the following when the policy runs at recurring checkin:

Executing Policy Set Office Info Running script Get Office... Script exit code: 0 Script result: rm: /Library/Application Support/JAMF/Scripts/ADGroup.txt: No such file or directory<br/>/Library/Application Support/JAMF/tmp/Get Office: line 4: adquery: command not found<br/>

Looks like the Centrify adquery command doesn't like being run by launchd. Will test with full path as well and see if that helps.

[Taylor_Armstron]

Last followup, just in case anyone else runs into a similar situation:

Adding the full path to Centrify's "adquery" command appears to have resolved the issue. My educated guess is that the Centrify installer adds the command to normal user's local path, but it isn't in the local path for the root context when called by the LaunchDaemon (as @mm2270 suggested). Adding the full path (/usr/local/bin/adquery) to the script appears to have resolved the issue, I've had no machines' results blanked out in the interval since making the change.

Lesson-learned - when using non-built in commands in a script, use the full path just to be safe.

[mm2270]

@Taylor.Armstrong I'm glad you figured that out! It didn't even occur to me that it was the lack of the full path to the adquery binary, but that actually makes sense. LaunchDaemons use a slightly different PATH than regular accounts. /usr/local/bin/ isn't included in the path. We've had to include the full path to the Jamf binary in scripts called by LaunchDaemons for the same reason.

[Taylor_Armstron]

Thanks Mike. The logs gave it away, when I started seeing "adquery: command not found".