Define Inventory Info in Scripts

So,

You just want a script that promotes certain users to admin? If you
want a self service plug in to read data off the JSS database you will
have to upgrade to get API support then write your own little plug in to
read the data off that machine to verify. If that is what you are
asking to do?

Thanks, Tom

Basically all I want to do is take the Location:username that is entered in JSS database and insert it into a script. We only want to promote one person per machine to admin status, and only on that machine (the person the machine is assigned to).

The only spot where a user/machine relationship would be defined is an inventory database or in Casper's DB.

Chris

How about a script that pulls the username from the Casper API? Then
that script could be ran in a Policy or maybe even an Extended
Attribute. With the Extended Attribute you could even report back if the
user was successfully added to the admin group, adds a nice inventory
search option. To connect to the Casper API use curl commands with
xmllint. I'm thinking it can all be done in Bash, the scripting experts
here would know.

Ryan

bash, to my knowledge doesn't parse XML. You'd be looking at a python or ruby solution most likely, unless I am wrong? I will be diving into the API soon, but I need to upgrade my Casper stuff and rebuild my test environment before I can start messing with it.

-Tom

I'm not sure there is....whenever you flush the logs, it just seems to remove it. I haven't found any record of this happening, but it may exist somewhere in the JAMF database.

I was thinking that you could set this up kinda like how we do it for local admin access on PCs...the user has to be in the local admin security group in AD, and the PC has to be in the correct OU in order for the user to actually have local admin rights on the machine. You could do this with a policy assigned to a static group of machines (the static group would be equivalent to the OU portion) and limited to a certain group of Users (like the AD local admin group...you could even use an AD security group for this if you're using it in your environment). Set the policy to run once, and if that user is in the right group, they will get admin rights on the first machine they log into that's in the static group.

I know that sounds a little confusing, but basically there are 2 checks, one for the user, one for the computer. The policy is allowed to run once. If you reimage the machine or something like that, you're most likely going to flush the logs anyway, allowing it to re-run.

I hope that helps someone...

--benji

Thank you Michael!

I'll give this a shot and see how it goes… as I was driving home I thought of a non-scripting solution (possibly). I would love to run it by the list and see if anybody has any concerns. Again the goal is to set a single user as admin on each machine, with the user being defined as the 'owner'/main user of the machine.

1) Create a Script to promote current user to admin group. (easy & done already)
2) Create a self-service option that runs once per computer that calls that script.
3) Have the person run the self-service at time of pick-up. (thus promoting themselves to admin status)

My question is if there is any way this could be exploited (excluding human error). Such as being able to force the script to run a second time for another user, without direct interaction from a Casper Admin. I was thinking that if we needed to add another admin, I could clear the history of the task for that computer, have another user log in and they would be able to promote that user to admin as well. But I would only want that option if it was controlled by a Casper admin, not by the local admin.

Seems like it would work, it would take a bit more human interaction than the script, but we sit down with every person who gets a new machine, so this wouldn’t add any extra time to the process.

I'll give the script a shot as well, as this seems like a good solution that requires even less human interaction/error.

Chris

--

Chris Tangora
Senior Technology Specialist
Middlebury College
ctangora at middlebury.edu

If the user has local admin, can't they just run a sudo jamf flushPolicyHistory and run it for another logged in user? This would flush all policy history, meaning the JSS would have no record that this was ever run.

And it looks like there is no log file of the flushing.

Correct?

--

Chris Tangora
Senior Technology Specialist
Middlebury College
ctangora at middlebury.edu

This is close… it works on some, on others it pulls the room instead of the username. Looking closer at the sed part because the xml definitely has the <username> field.

-c

--

Chris Tangora
Senior Technology Specialist
Middlebury College
ctangora at middlebury.edu

If you used an XML parser you wouldn't need the fancy sed
hieroglyphics, FYI.

I am a sed noob so that looks like sandskrit to me

Modfied part of the script to trim around the <username> and </username>
tagsŠ not as pretty or efficient as Michael's, but works on the systems
I've tested so far.

Benji, there has to be a way to log flushes. It has to be, right?

Changed part of code...

# Ask JSS for info on machine jssxml=`curl --silent --insecure -u $JSSapiUSER:$JSSapiPASS
$JSSserverURL/JSSResource/computers/macaddress/$macEN0/subset/Location -X
GET`

# Trim response at <username> and after
trim=echo ${jssxml#*"<username>"}

# Trim response at </username> and after
usernameINjss=echo ${trim%"</username>"*}

Š continue with Mike's script as beforeŠ

Thanks again Mike. Would have been lost without this!

Chris

--

Chris Tangora
Senior Technology Specialist
Middlebury College
ctangora at middlebury.edu