Questions/discussion regarding Casper in a 1:1 programme

At my school we run a 1:1 program with K7-12 using Macbooks.
All of these users are local administrators in their mobile account.
What I have found is that there is little issue in regards to the users being local admins, we hide the management account so the users don't even know it is there, so no problem with them changing the password, I have found it makes my life considerably easier when just a few students need to download and install something, they can do it without having to come up to IT and asking for us to put the password in or having to create a policy in the JSS.

In my opinion it is a better experience to allow the students the freedom of having local admin rights, but to monitor to make sure they are not abusing that. We keep track of what they are installing, and we have certain restrictions (e.g. torrent software), and we approach the student if we find they are abusing their local admin rights.

As far as restrictions, you can still disable the ability to edit certain system preferences, Profiles for example, the user sees it greyed out and they can't open it so they ignore it.

Have no experience managing a laptop program, but judging by the deliberate destruction students have done to desktops here I'd never allow students to have admin unless they actually purchase and own the machines. It would make things a lot easier with respect to installing things for classes, but would not be worth the headaches of accidental and deliberate settings changes and malware.
For your second question, it's basically an impossible technical challenge to deal with a discipline problem. Admin is admin, they can always get around any tricks you use to keep management software on the devices, but well behaved students will not take it off. The trick I've read for dealing with poorly behaved students is making the Wifi password part of the management profiles, so they lose access to everything when they unenroll.

Hello there!

Here is what we do:

1) Based on the havoc the students have caused in the past, when we opted to do the 1-to-1 program here, we said absolutely no way to Admin accounts for those laptops that the school owns. (Which is now part of the program here so they all have our laptops.) For example - even with no admin accounts - we had kids the first week of the program going into Single User mode and making admin accounts because there were some laptops that didn't get our EFI password...not good.

2) I like the above with the Wifi code being tied in with the profiles. We have an open network where you need to authenticate to a portal page though, so that might not work to well for us.

3) We use mobile accounts with Google Drive. We used to use Network accounts, but the red dot (Network accounts not available) would sit there for the first 5 minutes of every class and people got frustrated. Also Keychain is much nicer to mobile accounts and causes much less of a headache.

We don't give admin rights & set firmware password, & we use AD mobile accounts. Set various security settings via config profile that the tech has to confirm come down post image using login text as visual indicator. Only allowing programs to run out of X folders is a big one for us security wise. Our wifi is computer based 802.1x that is installed via script at image time.

I've been part of a 1-to-1 school since 2005. We started off with 266 iBooks at our junior high, and expanded with 333 at our high school the following year. These days, we have 370 for our combined High School and Junior High campus, and another 350 or so at our Elementary campus.

1) We went with non-admin access from day one. We have a tech room at each campus staffed by people who could do updates, troubleshoot, manage with Apple Remote Desktop, etc. In hindsight, I would still say it was the right choice. We had instances of kids stealing our admin passwords off the printer when we printed out GSX repair forms, we've had kids do the tricks to get the setup assistant to reappear, and our Restricted Software section of JSS is full of games. We might go managed apps in the future but we're trying to save that as a last resort, although it's less threatening now that we can change or even remove that feature with Config Profiles. We did it once in our pre-JSS days with Parental Controls... talk about pressure when it came to testing our image to make sure the apps worked. haha.

As for trends, I have seen a few articles and publications say that you should just "let it go". Let the kids explore. Let the kids make their machines theirs. In my opinion, the people saying this kind of thing don't know what technology in a school is really like and the issues we face. We try to give our students as much freedom as possible, but at the end of the day we have to at least try to make the machines "safe". That's just my opinion, though. I guess it really depends on your student clientele, but even so, I could be concerned about my next point...

2) If you give them admin rights there is always a way they can tear the jamf framework out. You could get rid of terminal to make it less easy, but since they have admin rights nothing would be stopping them from going into the system folders in Finder and ripping it out. I would be concerned about this prospect personally, as losing the jamf framework is essentially losing control of the machine.

Personally, I find that the JSS's Policies and Self Service basically do away with any real need for the students to have admin access. If they need an app, an update, a printer, or much of anything, Self Service and Policies nearly always do the trick.

3) We don't bind to a directory. For our size and needs, it's acceptable. For large districts, I'm sure it offers some features that are beyond my current understanding. However, I've talked with schools that bind Macs and it seems like Apple's support for binding is spotty. One of our people who moved onto a bigger school complained of machines randomly dropping their directory binding and having quite a bit of network home directory issues. Last time I talked to her, which was a couple of years after her initial complaints, she said they were still using AD, but local home folders only and things were much better.

Gotta say, I'm jealous you get to begin your 1-to-1 with the JSS. We started with Firewire cables to image and ARD to manage. It worked at the time, but now that we've had JSS for about four years I don't know how we did it. Good luck with your 1-to-1 program! If you have any further education setting-specific questions I'll answer as best I can.

Thanks for all of the replies so far.

I've got to say that my initial plans were to roll this out without admin rights, given our basically perfect track record in our test year group, but I've been convinced to "let go". Essentially the basis for for me letting go was that without admin rights, students would not be able to add their home printers, and install software. This painted too much of a controlling picture to non technical staff/parents etc.

I admit that it is controlling, and certainly Apple's direction is that of self service and ownership (even if it's just perceived - i.e we own the laptop). My motives for being controlling are focused around a consistent experience for the students, and the guarantee to staff that access to technology will be uninterrupted etc. This is not a case of "wanting" control - evil laugh, etc.

Is there a way, that I'm not aware of, to allow them to install their own printers, and install software without actually being admins?

I also like the suggestion (which we're actually already doing) about hiding the admin account etc. Ultimately if the framework is removed, we'll know about it (check ins, etc), so we can call that child in, and apply the appropriate discipline.

I'd love to hear from schools who have gone down the full admin rights option.

Thanks again.

Gav

So, allow me to offer (again!) a dissenting opinion. I hope you found the old thread(s) on here from the last time this discussion came up. Particularly, this one: https://jamfnation.jamfsoftware.com/discussion.html?id=9329#responseChild51079

We are in Year 5 of our 1:1 laptop program and almost every user is an admin on their MacBook Air. Grades 4-12. We are working on modifying our program so that our youngest students are not admin immediately. This was based on feedback we've collected from the parents and teachers of these students. We are even considering replacing 4th and 5th graders' laptops with iPads and not giving them a laptop until Grade 6. But this is just one possibility of how our program may evolve.

It's possible that we just have a better-behaved student body, but we've had very few issues with our students being admins. Now, a great deal of this is because we spend a great deal of time teaching them digital citizenship and ethics. We have a Code of Conduct that every student is expected to follow. Our AUP is written with this Code of Conduct in mind and there are significant consequences for violating it.

We've found that allowing our student to be local administrators have been very liberating for them. Within the framework of our AUP, they are allowed to install almost anything they want, but they are also expected to keep their systems up-to-date and secure. A few things I've discovered over the years:

1) Adware for the Mac is on the upswing: MacKeeper, Vidx, Geneio, Downlite, etc. I've been using the excellent (and newly-renamed AdMedic to remove some of these installs. I've also been writing Extension Attributes to search for this malware and receive emails when a student has inadvertently installed one. I'm also using Restricted Applications function of Casper to block the execution of MacKeeper and its ilk.

2) You'll never have 100% success or buy-in with your end-users. There will always be a small fraction of students who will push the boundaries and test your controls. We've had it; we continue to have it. Fortunately, we have an Administration that takes our Code of Conduct seriously and supports our Technology Integration thrust, so these issues become not technical issues but disciplinary issues. There's an old adage: You can't use technology to solve social problems. that is germane here.

3) If a student breaks the AUP, a warning issued, his/her advisor is notified, who notifies the parents. If a 2nd violation occurs, there is disciplinary action. On the 3rd violation, administrative rights are taken away.

4) If you have members of your Tech Staff that are completely against allowing your students to be admins, you might ameliorate the issue by using Andrina Kelly's "Make Me Admin" policy in Self Service that will allow a non-admin user to become an admin user for 30 minutes and then demote them automatically. This would allow you to off-load a lot of the common "admin tasks" to your students and also allow them to install or run updates. Its policy log would also give you a historical record of who used it and why. You could easily then compare the "Make Me Admin" policy log against a managed computer's application history log to see what was changed.

When we were planning out 1:1 program, I was adamantly against allowing our end-users to be admins. I envisions a horror show where I'd be constantly re-imaging machines because students borked their laptops. It's true that this occasionally happens, but it's far far less than I that thought it would. And when a student does hork-a-bork his machine because he was dinking around, there's a lesson learned there as well. For this generation, access to technology is like breathing and having to go 24-48 hours without because one decided to try to bypass my Yosemite install restriction, is in itself an important lesson.

The flexibility and agility of the Casper Suite is incredible. I've found that I can write an Extension Attribute to do almost anything: collect a piece of info about an app or version, or watch for a particular file/app to be installed, and then you can write a policy based on the results of the EA collection. In the case where a student removes the framework (which actually hasn't even happened yet; not once!), you can simply watch for computers that have "dropped off" and not reported into the JSS in awhile. I have a Smart Group set up to watch for machines have haven't checked-in in over a week and then JSS will email me with those machines. Then I can contact each students' advisor and ask them to find out where the laptop is, and have the student bring it to me in the Tech Center. In virtually every case, the student shows up the Tech Center with a laptop that has been dropped/damaged and isn't booting, which is why hadn't checked in.

I have a great amount of experience in managing this program we've built and am actually quite proud of it. We feel it gives our student body a sense of ownership of the computer, and so they take better care of it. Because a student is allowed to install games or other apps on it, we do not have the problem of a student managing TWO laptops--the "School" laptop and the "Home laptop". I know the conventional wisdom for many 1:1 programs is to lock down the computers and not grant admin rights, but it doesn't have to be this way. We also like that our program mimics the real world--if a student goes to buy a Mac at the Apple Store, he/she will have an admin account. And if no one has ever shown them how to be a good admin and how to avoid malware, then how can we expect them to know this.

Please feel free to contact me if you have any questions. Happy to share.

Is there a way, that I'm not aware of, to allow them to install their own printers, and install software without actually being admins?

Yes there is! Using the /etc/authorization database is one of the best things that we have come across. We have allowed printers and various other settings to be changed by the user without giving them any admin rights at all.

See http://www.dssw.co.uk/reference/authorization-rights/index.html for a list of the rights and what they do. Depending on your operating system will change how you edit this, but it is rather easy once you get the hang of it. I know some people from here have also written helpful articles about modifying the /etc/authorization db.

As for installing software, that's what we use Self Service for -- once a software is approved for use on our machines we will put it up on there for anyone to install.

The way we saw it was very similar to what you stated above, that we wanted a consistent experience on the laptops and it was stated clearly that they were for educational use only, nothing more than that. This made it quite easy to make that decision in the end.

Let us know if you have any other questions!

This is also a good writeup on the authorization database, specific to Mavericks:

http://www.afp548.com/2013/10/22/modifying-the-os-x-mavericks-authorization-database/

That's very cool! I'm going to look into that next week! Thanks heaps for all of the replies!

Cheers,
Gavin

@GSqared x 2. No full admin rights here.

We are in our second year, and the self-service portal has been a life saver for us. I've got a few scripts as policies for things such as print admin rights, location services and time zone but nothing too extreme. Since admin rights are needed for most destructive tasks, not locking down the applications folder is amenable if you don't want to be overly restrictive. However, we currently restrict applications to only those the applications folder and lock them out of terminal, disk utility, console, etc. We also restrict a few items in System Preferences like Parental Controls, Security and Privacy, Profiles, etc.

In terms of updates, use Autopkgr (https://github.com/lindegroup/autopkgr) on your JSS repo machine, because it keeps packages of common third-party software updated to their latest versions. Just drop the new packages off in your JSS repo and update your policies to use them. There are scripts to do this automatically, but I've been timid about learning that functionality.

FWIW, I am testing a 1-touch deployment with an initial LDAP login (OD), but with only a mobile account on the device. Best part is that its a never-booted image created with AutoDMG. Log in the first time, and credentials are cached for subsequent logins. Since it's a local account, there's no sync that needs to happen and no need to worry about the red light after the first login. So far it works well with an average target disk mode image time lasting only 1:30. We don't have to touch the machine again other than to restart it after imaging to complete the process. However, it also allows anyone with a network account to log into anyone's machine. Fortunately, we can see this because all accounts but admin are visible on the login screen and our AUP and Device Responsibility Contract prohibits logging into another student's device.

21 Years 1:1. I added to another conversation that was similar here, prompted by a post from @damienbarrett

https://jamfnation.jamfsoftware.com/discussion.html?id=12523