Students Changing Admin Passwords

Is the firmware password set?

They're booting to single user mode

I didn't set a firmware password.

Is there any way to stop them from booting to single user mode?

@ahopkins

Yes there is! Create a new policy and there is an option to set the EFI Password. see: http://cl.ly/image/143l2V2y0J0T

Hopefully, your Management Account is not the same as your ladmin account. If it is your password to control this action would not work as the passwords won't match.

@justinrummel

Thanks! I was looking at setting up fire vault, but this may be easier.

We have in the past just used one ladmin account. So, create a completely separate admin for Casper actions and the local?

These kids are driving me nuts. We have to lock so much stuff down.

I don't know if our students are going through this much trouble: http://www.nerdsarmy.com/store.html

This a usb device that can bypass an EFI password.

I'm debating if I should block connecting any devices to the MacBooks.

Indeed, do you really think they are going through that much trouble? Spending over $300?

You'll be causing more grief disabling USB access for users who want to do real work on their computers. The person who spends over $300 to break their firmware password will simply be out $300 and have to serve detention/suspension when they get caught.

FileVault 2 is probably overkill on most computers unless you're trying to protect confidential data from being read.

@adamcodega Thanks for the input. I think you are correct on that...

Does the EFI password block also prevent someone from starting in recovery mode and using terminal to reset the password? I have terminal blocked, but I haven't tested if that will stay blocked in recovery mode.

Yeah, it blocks pretty much everything at startup, including booting off of OS X on a USB drive, another thing to keep in mind. Now, by "block" we mean you have to enter the firmware password.

Apple support KB

Also, I just realized the Blackbox only does four digit codes, the kind you use when you lock a Mac from iCloud. This isn't the same as the five digit codes you'd use if you locked a Mac from an MDM, or a alphanumeric password you'd use as a firmware password.

Paging @Chris_Hafner

Ahhh... thanks for the notification Adam. There are a few things at play here that I want to mention in case it's a dis-qualifier in your environment.

In our environment we do NOT use FW passwords (We do use FV with administrators though). It's too restrictive for self diagnosis and repair procedures that we educate users on. Instead we track all users who gain unauthorized administrative access (as described below) and deal with them in one of three general ways.

Once a student has gained administrative access we:

1) Notify the student (via JAMFHelper message) that their violation has been logged. And request that they come down to the office to rectify the issue before disciplinary action is taken. (i.e. The nice approach)

2) Upon refusal to comply, the additional administrative account is deleted out of hand, de-elevated (in the case that the students primary user is the one with administrative rights granted *super rare*)

or

3) The unit is physically recovered and disciplinary policies enacted.

It's important to note that in our environment students attempting this tend to log into single user mode and delete the .AppleSetupDone file, thus re-enabling setup assistant with allows/requires them to create a new administrative user (assuming that they used google and didn't nuke their units). Here's how we determine when this occurs:

• First, we have a local administrative account on all machines that has a known short name (and long name if anyone cares)

• There is also a locked root account and I've played with separating a Casper account but in our environment there's little purpose to that particular security measure.

• Student assigned (we're BYOD but you get the point) units are designated in either a "Student" or "Student-Loaner" department in the JSS.

• I have an extension attribute taken form the Nation, that identifies all users with administrative rights (UID over 500). I call it "Admin Users".

#!/bin/bash

# Script to detect if a computer has a local admin account on it with an UID of above 500

# Initialize array

list=()


# generate user list of users with UID greater than 500

for username in $(dscl . list /Users UniqueID | awk '$2 > 500 { print $1 }'); do

# Checks to see which usernames are reported as being admins. The
# check is running dsmemberutil's check membership and listing the
# accounts that are being reported as admin users. Actual check is
# for accounts that are NOT not an admin (i.e. not standard users.)

    if [[ $(dsmemberutil checkmembership -U "${username}" -G admin) != *not* ]]; then
    # Any reported accounts are added to the array list
        list+=("${username}")
    fi
done

# Prints the array's list contents

echo "<result>${list[@]}</result>"

• Then I have a SMART Group that reports ANY units, that are in the "student" or "student-loaner" department and has an EA result that is NOT "name-of-proper-admin-account". The criteria is as follows:

---------
(
-EA "Admin Users" is NOT "name-of-proper-admin-account"
)
AND (
-Department IS "Student"
OR
-Department IS "Student-Loaner"
)
---------

At this point you can do whatever you feel necessary to notify, you, the student, and/or activate a policy to perform some sort of appropriate response. In my case it's simply a SMART group that I monitor on my dashboard. I could have it do all sorts of things from there but the students quickly get the point that we control everything and stop trying pretty quickly. No matter what I need to do in the course of my duties we've worked had to create an IT integration that focuses on educating the user, even when they screw with stuff. Not all institutions have the level of integration necessary to work within that ideal. We have a well integrated response and level of continuity with the faculty, staff and administrative members of our Academy that allows this type of flexibility within the students course of study.

Rather than seeing these users as the opponent (Not saying you're describing it that way at all, though I've seen that sentiment across the educational spectrum) we see them as an opportunity. They're obviously interested in doing SOMETHING with technology and we try to focus that by either introducing them to our CS course or by offering them a mentored internship, if they appear to have the proper respect that entails. They did break the rules after all, but who of us hasn't at some point in our past!

I'm happy to say that most of our Interns are either running their own successful IT companies, .coms, work very successfully in the IT field or are currently in a CS, CE or other related major. Actually, I believe that 80% of them, over the course of the past 10 years, make far more money than I do ;-)

Great responses! Reading this on the treadmill now, I'll post again if any questions, this has been a grat help.

BTW, Recovery mode launches a separate recovery image and will not respect anything you've done on the primary OS. There are threads that occasionally talk about modifying the Recovery partition but it's a hairy ordeal and I can't remember if there are good solutions out there. I think of this as being a bit to far down the rabbit hole in EDU environments. I hate to say it, but if the students are going into the terminal via recovery mode they've got really awful google skills. May be worth putting forth at the next faculty meeting ;-)

That said, I've seen schools delete the recovery partition only to find out about all the functionality they disabled by doing so... including the ability to utilize Apples location services.

Keep on tredin' and try to enjoy the weekend as opposed to working it!

To help track when students boot to Single-user Mode, I have a script that will:
Send a real-time Notification Center message to the admin computer with the offending devices MAC address (so it can be looked up in the JSS).
external image link
Log the date and time of the intrusion, which is stored in an Extension Attribute

currentDate=$(date "+%Y-%m-%d %H:%M:%S")
/usr/libexec/PlistBuddy -c "Add :SingleUserModeAccessedOn string '$currentDate'" /Library/Preferences/"$orgName".plist &>/dev/null

external image link
Also loaded by the script is a line that logs any commands the user types into the system log with the tag "SUM-IDS" (Single-user Mode Intrusion Detection System) so that the exact commands can be reviewed at a later date.

PROMPT_COMMAND='history -a;tail -n1 ~/.sh_history | logger -t SUM-IDS'

We take a similar approach to @Chris_Hafner in that we monitor an EA with the admin users, and if it changes from our list of expected accounts it sends an alert to the tech, who can then get administration involved for discipline.

However, we go an extra step further and re-image the students laptop to get it back to a known config then I have a Self Service policy the techs can enable/disable the EFI Password. I do like the student notification aspect of it, I hadn't thought to give them a chance to fess up!

@jacob_salmela Do you have a policy or daemon that runs to check the return value on sysctl -n kern.singleuser? Could you share a bit more about the notification center message portion above?

@jacob_salmela yes, do share.

@freddie.cox Trust me. There are certainly those whom we've ended up nuking!

@Chris_Hafner and @freddie.cox below is how I set up my single-user mode intrusion detection:

http://jacobsalmela.com/single-user-mode-on-os-x-intrusion-detection-system-an-efi-password-alternative/

I never knew about the ```
sysctl -n kern.singleuser
``` so that is cool to find out. Thanks!

@jacob_salmela thanks! I was wondering how you were triggering an action on boot since most of the system isn't loaded. Didn't think about the root user profile! Thanks for sharing!

@freddie.cox no problem! It seems to work well on pre-Yosemite machines. In 10.10 launchctl syntax changed and you get the message that services cannot be loaded in single-user mode anymore.