Dummy Receipts in Casper

Hello, this document will briefly touch on the dummy receipt system one can employ with Casper.  First, and foremost I suppose I should outline the concept of what exactly this is.  A "dummy receipt" is a file which is stored on a system due to it meeting certain criteria to build a report off of.  For example, you want to know how many machines in your enterprise have a certain version of an application, or maybe a certain user account present.  The concept is you create a script that checks these conditions out and depending on the outcome either exits the script, or installs a text file based on a manual triggered policy.  After it is all said and done you can then go into that manual trigger policy log file and see how many machine it was installed on and exactly which ones.  This will help you build a report of the desired results.

Since I work in academia in a 1:1 with K-12 students we always have to wonder, how many kids are hacking their machines?  The bottom line is, that if you give a teenager unlimited physical access to a laptop on and off campus, and they are willing to spend their free time trying to "hack" or "jailbreak" your organization's laptop, they will most likely eventually find a way.  Simply doing proper Google searches asking the right questions would point them to documentation on how to do such things.  So I needed to come up with a method of checking for local admin accounts and building reports on which machines had them.  This is a mere way to audit such things.

*Side Note*:  Our system images are designed to not contain any local admin accounts where the home folders are located in /Users.  This means that by design I know that any user that has a home folder in /Users should never be part of the admin group.  When building your images you should think of methods like this for later use.

Here is an example of how the work flow of the policies will go from Casper, with the example of checking for local admin accounts:

1. Run a single script on all machines that loop through /Users and check their group membership against the admin group.  If they test with a positive result, a manual trigger policy installs adding my receipt file.
2. Create a custom trigger policy that simply echo's out a file name and then outputs it to /Library/Receipts/hasadmin.txt
3. Now check policy logs for my custom trigger poiicy and every system that has it installed, has a local admin account in /Users and it should not.

Now that you know the concept and have a basic idea of the work flow of this particular set of policiies, lets look at the pieces to make it all coalesce.  First let us look at the simple script I wrote to check for each user account's membership against the admin group.

#!/bin/bash
 
##################################################################
# check local admin script for dummy package
# if a local admin account exists in /Users, then dummy package will be installed
# Use policy logs to generate a report of macihnes that have AUP violations on them
# where a local admin account has been enabled by the student hacking around built in
# securities
#  by Thomas Larkin
#  for KCKPS 
#
#  created on 01/11/10
#################################################################
 
# set check admin variable
 
# make sure no FEU folders got in there from a composer pkg
 
checkExistingAdmin="/Users/hadmin"
 
if [[ -e $checkExistingAdmin ]]
 
    then /bin/rm -rf $checkExistingAdmin
 
    else /bin/echo "$checkExistingAdmin is not present"
 
fi    
 
# now loop through /Users and check the admin status
 
for i in `/bin/ls /Users | /usr/bin/grep -v "Shared"` ; do
 
if [[ `/usr/bin/dscl . read /Groups/admin GroupMembership | /usr/bin/grep $i -c` == 1 ]]
 
    then /usr/sbin/jamf policy -trigger hasadmin
 
    else /bin/echo "No admin accounts found in /Users"
 
fi
 
done
 
exit 0

If you notice the first part of the script is to check for an existing admin account that may be present in /Users due to FEU.  FEU is a term that stands for 'fill existing user' and is used in the Casper Suite when building Composer packages that need to also capture user level files.  Mainly things like user specific preference files may need to be copied out to every user account.  Well, when it does this, it also copies out the package contents of the user you used to create the package with.  Hadmin, is an admin account I use here at work, and while some folders maybe be copied out to /Users from the hadmin template from my Composer package, the actual hadmin account has it's home folder somehwere else.  So, I check to see if it exists in /Users first and if it does then i remove it.  That way it reduces the chances of me producing a false positive on my policy logs.

You may notice the line of code /usr/sbin/jamf policy -trigger hasadmin, which is my custom trigger policy in Casper to add my receipt file.  To do so you want to log into your JSS and create a new policy.  Since this is going to be a manual trigger policy you can scope it out to every machine and have it run off every subnet.  Now, if you want to lock it down even further you can do so, but since this has to be manually triggered by a human or a script, I think it should most likely only be invoked when it is suppose to be.  Look at the screen shot here:

So, if you look at the Triggered By and Manual Trigger fields, you can see that I set this policy to trigger by a manual command.  That command is hasadmin.  If you scroll back up and see where I invoked that command in the script, you can see where I invoked the manual triggered policy via a command.  Now, the payload of this policy is a simply, one liner Unix command, which is simply:

/bin/echo "This is a receipt proving that users in /Users have been promoted to admin against the AUP" >> /Library/Receipts/hasadmin.txt

So, if you click on the advanced tab and put that into your run command field, when the hasadmin policy gets triggered, it wil execute the echo command.

To recap, I have my script run on all computers in my enterprise.  If any user accounts, which home directories reside in /Users have admin access, a text file is then placed in /Library/Receipts called hasadmin.txt.  I can then view the policy logs of what computers have this installed on their computers and build a report from with in Casper.  That report would contain both the end user information and the machine information.

The only thing I think is missing is maybe basing a smart group off of policy logs in Casper.  If I could create a smart group of computers that have a certain package installed, like my hasadmin.txt file, it would be great.  Then I could go even further to manage those machines in a different manner to demote the accounts from the admin group.  Most importantly though, is the ability to build reports of AUP (acceptable usage policies) and the ability to generate these things for administrators so they can audit student's behavior with state own school technology.

This is a way to audit integrity of your machines and at the same time maintain a level of privacy from the user base which may lead to unforeseen consequences like we have seen with the PA school and the web cam scandal.

Thanks for reading.

-Tom