Admin Password best strategies

[pty10]

having an issue here at school where we need to constantly keep changing the admin password that we use on the Macbooks. We change the password, all is good for a couple of weeks then kids find out what the password is and share them among each other. It makes it difficult when trying to manage computers using casper since what they normally do is delete the JSS folder in Applications/application support since they know what the password is. Whether they have keyloggers installed on their computers to hack the password or something else I'm not sure.

1.Can I stop the deletion of the JSS folder by blacklisting it in manage preferences? (Library/Application Support/JAMF) I'm thinking that If I blacklist the folder the JSS might not work properly?

1. Can anyone share their strategies when it comes the keep the admin password from falling in the wrong hands.

Cheers,

Enrique

[daz_wallace]

Hey Enrique,

Damn those pesky kids! Sometimes they think so far out of the box it makes interesting reading to find out the 'how', but to answer your questions:

1) I'm not sure if this will actually do anything other than prevent apps and scripts from running from this location. I don't think it will stop them trashing the folder. I do think it'll cripple the local jamf tools but the simplest way to find out is to test.

2) Generally speaking, most of our installs are in an Active directory environment with the local admin account very rarely used except if the AD connection is down. Is that a possibility for your setup? If a password is compromised, you can reset / change it through AD and then not have to do anything to the client devices?

Another method is to make use of Rich's Casper Check solution to repair the Casper install on the client device:
http://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

Hope that helps!

Darren

[RobertHammen]

You sure they're cracking the password, or are they using Recovery or Single User Mode to either reset the password, or create another admin account?

If you don't have a Firmware password on these machines, this is a good reason to do so...

[mm2270]

Agreed with Robert Hammen. If possible, set a Firmware password on the Macs. With that in place, it will be impossible for them to use any alternate boot method to reset the password without actually knowing the Firmware password first.

Also, how many people in your environment know the local admin password? I'm not suggesting anything, but is it possible someone who knows it is accidentally revealing it along the line? All it takes is for one student to know it and it would spread like wildfire. I assume its the same password across all the Macs.

Lastly, I would not recommend changing the permissions on the JAMF directory as that will likely just cause you headaches. You could however hide it from the Finder so its just not visible. That should be safe and wouldn't affect any functionality I believe. There are still ways to locate it, but it could stop the majority of the cases of deleting it in the Finder.

[pty10]

Hi daz_dar,

We use both Mac's and Windows here at school. Students use Mac's (Unibody, Mac Air's) Admin staff and teachers use Windows. I'm new at the school, The school has it setup where students authenticate (login to their computers) via AD. We do also use an Apple mini server to manage the Macbooks and that setup includes the admin password for the Mac's.

I actually don't mind having it that way because if the kids know the admin password, all they can do is gain full access to their computers and can't compromise the school network. but it's annoying because you then get teachers and parents complaining about kids playing games, chatting, streaming music,etc while in the class. If we where to setup the Mac admin password via AD and they find out what it's, that might be a huge problem. Last thing we want is kids helping themselves to the Windows servers.

Sometimes kids come to the helpdesk having issue with their Macs and we need to then type the admin password to access settings,etc. So whether we need not to type the password in front of them or they have a keylogger capturing what we type not sure. School hasn't really paid attention when it comes to these things. I will look at the link you sent me. I appreciate your input and thanks for listening to my rant!

[pty10]

Robert,

In some cases kids have setup their own admin accounts. I guess once you know what the admin password is you can just then login and setup your own account. We do have firmware passwords but kids can get around that by just removing one of the RAM modules and rebooting the Macbook.

[pty10]

mm2270,

Hard to say how many kids know the password but I will say lots of them which is why we always try to change it frequently. We use Lan School here at school as well and one day while doing some random checks, I spotted one kid logging to one of the iMacs in the lab using the admin credentials. Once I saw the kid logged in to the computer I went to the classroom and confronted him about it and he basically told me that everyone knew what the password was.

Like you said, all it takes is for one to know for everyone to know. We have a list of restricted software and on the list we have Spotify. So the other day while on Lan School I saw this girl trying to open Spofity on her computer and when she did that she got the prompt saying that it was restricted. What she did then was to go the JAMF folder, sent it to the bin (trash) got prompted for the admin credentials, she typed in, trashed the jamf folder, went back to the Spotify and was able to use it with no problems. How can I hide the JAMF folder? will I have to create a policy and then send it out to all computers?

[Chris_Hafner]

Hrm... it seems like you have a bunch of systemic issues here.

• You do mind if the student's get the administrative password. Don't fool yourself. That's why you're posting here right? The students are mucking with the methods you use for managing their systems. If they weren't admins then they couldn't do that. So yes, you care and care very much!

• You need to sort out your admin access/credentials and stop trying to hide the JAMF binaries and whatnot. If your users have administrative access then there's going to be nothing you can do in the long run except make your job completely impossible. This probably means eliminating any possibility that the students can gain access to any password. Also, passwords should never be kept in clear text. I see that you're saying that you have a Mac mini to setup the Mac's and that it has the password. I'm not following you. What do you mean by this? Are you imaging the computers? Are you BYOD? what's your setup?

• You need to figure out how your password is getting out. I agree that you should set the firmware password. That is rather difficult to get around when someone is being supervised. Secondly, you can set an EA to report if a firmware password is no longer present. A few different versions exist here on jamfnation. Beyond that, if you really do keep changing the admin password something is super wrong because you're student seem to know it quickly. The only way that happens is if you (your department, admin or whatever) are sharing it.

• There shouldn't be any need for anyone outside of IT to have an admin password. This is why Self-Service policies are great. There's nothing that you can't create for the users!

• You should be blocking keyloggers. Beyond that, your help desk staff should be trained to look for key loggers and their behavior. If your helpdesk staff needs to enter a password I recommend that they do it either out of site or better yet, in the management account itself (after logging out of the students AD user). Better yet, you can create a lot of IT/Helpdesk tasks as policies for use in Self-Service. Since you're AD you can password restrict that access to just your IT staff based on their AD creds.

• Your management account shouldn't be an AD account. Perhaps others will jump on me for this, but I can't see this doing anything other than completely overcomplicating a simple management account. However, I can't give any specific recommendations without know more about your setup/environment.

• I may be barking up the wrong tree but on the surface, it seems that your teachers are completely out to lunch if students are open violating the policies THIS much in class/lab. Seriously? Opening banned applications, subverting restrictions and removing system files while a teacher with LANSchool is watching? Again, I know these things may be outside of your control but they should be part of the discussion. Training faculty and staff may be difficult but it's never impossible. Also, is your school/district) making restrictions that you (I.T.) can't back up realistically?

[pty10]

Hi Chris,

I agree with you. there's only so much we can and the teachers need to do their bit if they want this sort of behaviour to stop. Totally up to them. I'm new at the school so I will make a raft of changes in Casper to have better control on what the kids can or can't do with their MacBooks. In an environment where you have three IT staff (four with me) where they trying to manage 800 macbooks, 300 iPads, Windows Laptops and desktops, Servers, etc , is easy to understand why Casper hasn't been managed more efficiently.

We use policy in the JSS to setup the local admin account for the Macbooks, we don't do it via AD. I think that is asking for more trouble. So what I'm going to do is create a brand new username and password for the local admin password and deploy it to the macbooks so that way they no longer have access to the old user and password. The computers that don't check in with the JSS after the deployment of the policy, will bring them in to the helpdesk and re-image them. I will also setup a new firmware password via policy. I'm also thinking about have a hidden local account and setup another one where the password changes randomly.

We use deploy studio to image our Mac's. Once a computer is image it gets enrolled automatically in casper. Will have BOYD's next year, school hasn't decided if we put our image on them or they just used them has it's.. You also have to deal with the school politics where non IT people think they know what's best.

We currently have a long of software restricted.To make more efficient, Im going to use manage preferences and configuration profiles to further restrict what they can do.

Cheers,

Enrique

[Chris_Hafner]

Ahhh... it's always fun to be the new guy trying to fix everyones bad habits! My hats off you to sir! BYOD is fun. We're BYOD here and image every students computer on the first day of orientation. It is fast, clean and ensures that teachers aren't going to have any surprises on the first day of school. I'd love to hear what you folks end up deciding on.

P.S> No one, is ever free from politics or users who know better ;-) Thats part of the reason that I'm in love with Self-Service!w

[pty10]

Yeah I will let you know. I'm bit baffled as to why kids will have BOYD's and the school wouldn't put a school image on their computers. I like Self Service as well which I why I'm going to restrict things as far as I can and if any software needs to be installed it would be done via Self Service.

Cheers

[Chris_Hafner]

There are many ways to skin this cat. Thin imaging can work just fine. Standard restrictions can work in that environment as well... but I agree. It's a huge amount of work for little benefit (for BYOD K-12).

[Simmo]

Sounds like a fresh start is in order, re-imaging of all the machines.
You're going to have absolutely no luck if students already have admin accounts they have access to on the machines.

If it was in my environment, I'd be re-imaging everything, with a completely new admin username and password (this should obviously be a hidden account), along with a firmware password, and keep gatekeeper to app store only, along with a config profile set to dis-allow overriding gatekeeper restrictions via control+click/right click open. I would also say it may be necessary to have your IT staff to all change their passwords, if they have been using their own credentials to log in to any student machine, because that's really not smart.

I certainly don't envy the position you've been dropped in to!

[pty10]

I have started the process. new admin username and password, new hidden admin account as well. Using config profile to limit access to things on the computer. will re-image computer where the policies aren't applying. Just working on setting up a firmware password. Thanks!

[Chris_Hafner]

Good to hear! Also, after having a discussion with some fellow Casper admins and one of our local JAMF reps it was suggested that you create a separate profile for each item you want to configure or restrict. This is in-elegant but recommended by those who use and update their profiles regularly. I don't tend to heavily use profiles at the moment (but AM NOT using MCX) so I'm just passing that along.

[damienbarrett]

This is a bit off-topic, but I wonder how your school is going to manage BYOD next year, given you have two seeming incompatible tenets at work:

1) your school wants to "lock down" the school-owned computers, which it has every right to do so
2) in a BYOD, the school doesn't own the computers; which means the students will by right be allowed to have an admin account on the machine.

Have you had discussions about how you're going to reconcile this problem? Trying to have a very locked-down environment where students are admins sound like a recipe for endless frustration and a war between two competing factions. Will you have a policy in place that prohibits the students from having an admin account? On their own personally-owned equipment? Also, how will you justify managing student-owned machines with Casper? Yes, of course it can be done, but it sounds like your school needs to take the 10,000-foot view and consider how next year's BYOD + management will operate.

In this business, perception is the reality, whether what is being perceived is true or not. Placing even moderate controls on equipment will invariably be seen as Orwellian and intolerable. My advice is to have very open and public communication about what's being managed and why it's being managed.

[Look]

@Matt.Sim

You probably don't need to hit every machine.

Even if they have created admin accounts you could concievably still deal with it.
It should be possible to created an EA script to check for Admin accounts that aren't staff or known locals (well as long as you have some kind of appropriate groupings in AD).
At the very least you could use it to selectively target the machines where extra accounts were detected.
You should then also be able to script removing the admin rights from them as well if you wanted, although this might result in a few accidental accounts losing their rights and depending on what those accounts were doing, it might piss people off :)

[Chris_Hafner]

@damienbarrett being a BYOD school for the past 4-5 years (and 1:1 for 21+) we've found this reconciliation rather simple (our case may not be yours of course). Since we require students to submit a properly qualified laptop (Apple with specific minimum requirements). We've maintained the philosophy that submitting their owned computers for use during the academic school year is not just BRINGING a device to use as they see fit. By "submitting" a computer for use within our academic programs both users and parents are required to agree to our AUP which includes management, etc. Thus allowing the school to integrate the users technology in an intentional and instructional manner. This is one of those things that just NEEDS to be an agreed upon policy for ANY successful laptop integration. At least at the k-12 level. Beyond that, it's certainly less restrictive (in our case) than most business I find which is why there's been such a BYOD backlash at the enterprise level. Again, we sell all of the GOOD that we provide the academic process. After all, that's what our parents/taxpayers pay us for!

As for transparency... give them your reasons. Your reasons may be different than mine but no less relevant to your users. Here's what we tell our users when asked, which isn't often. Our academic model requires that students have a universal set of applications and settings so as to ensure equality of instruction and compatibility between students and teachers units. This prevents the teacher form having to become part time IT staff in order to deal all of the resulting issues regarding incompatibility or security thus degrading the overall quality of instruction. I could go on and on but that's the big part of it. We could list a thousand reasons for both parents and students based off our extensive history, having seen exactly what students can and will do when left to their own devices (pun intended).

Here our students own their computers but are NOT admins. We elevate certain permissions and preferences to make it so that they can initiate things like TimeMachine backups and install their own printers without the need for admin access. Even if you didn't image their units as we do, there are plenty of ways to create a new management account (admin) and turn their administrative user into a standard one (I can post commands if you care). Our faculty and admin/staff are administrators on their assigned units and we manage out anything really troublesome. So long as they are managed we're A-OK. This is a requirement of employment and that's that. Regardless, there are many ways to deal.

I'd love to talk offline about this as well if anyone is interested. I'm also hoping that we can put together more edu tracks for next years JNUC!

@Matt.Sim Absolutely! I've borrowed the following EA which I've named "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>"

I've then used this result in a smart group with the criteria set as
FYI the EA is called "Admin Users" and the management account is called "admin" for this example

Admin Users IS NOT admin and
department IS 'student'

so the resulting list is any unit marked form the student department that has an administrative account beyond the single "admin" account.

You can do what you want with them from there. I suggest following http://managingosx.wordpress.com/2010/01/14/add-a-user-to-the-admin-group-via-command-line-3-0/ or simply deleting the account if you don't have the time to turn it into a teachable moment (Which I prefer to do).

Hopefully this is coherent as I don't have a lot of time to re-read this here at the end of the day. It's a great and important discussion!

[pty10]

@ Chris_Hafner

I actually started doing it that way (having multiple profiles for each restriction) but then decided to have just the one. I guess what you saying make sense since if one of the profiles isn't working at least the other ones will still provide some level of restriction. I started using MCX but moved away from it because I found it to be a bit temperamental so just using configuration profiles now.

Can I ask you. with firmware password, If I setup a policy in casper (Open Firmware/EFI Password) to deploy firmware passwords, is there anything else I need to do? I tried doing that but I can still access the boot options (HDD and Recovery HD) without getting that initial prompt to enter the firmware password.

[Chris_Hafner]

@pty10][/url I actually DON'T like the concept of having multiple profiles (one for each profile setting). It's inelegant and cumbersome. However I was advised that given the reality of potential failures, it's better to spread the risk around so to speak. Like you said, it something fails, you have the rest of your profiles in place and won't lose all of your settings. As for MCX you're quite right. MCX has been getting temperamental because Apple really stopped supporting it some time ago. With Yosemite it's toast from everything I know.

Now, firmware passwords are fun eh! Unfortunately I don't use them with our users. Mostly because I value their ability to zap their own darned PRAM if they wish ;-) Besides, Casper sends up warning flares for me if anyone ends up changing anything I care about or un-managing their system, which almost never happens to us luckily! That said, I prefer the older method of setting a password in single user mode or better yet, using FV2. This is my significantly less than humble opinion of course. Again, I get to work with things that make sense. Not a compliance board making crazy recommendations. With that said folks here have come across this issue before. While I can't verify from personal experience it seems that you need to install the Apple “setregproptool” binary. JAMF has a thread on it here:

https://jamfnation.jamfsoftware.com/article.html?id=58

Again, this is not from personal experience. I trust folks here in the nation to steer me right when I head astray! I should point out that any time I end up being concerned about security I simply go straight for FV2. I handle my errant users mucking with stuff in other ways ;-)