Questions about Binding Laptops to AD

niacobelli
New Contributor III

Good afternoon all,
We are trying to work something out with laptops in our school. We are trying to share laptops between students at a particular grade level. In the past, we had each computer assigned to the student that they used the whole school year. With space and policy changes, we are trying to have the laptops be stored in a central location during the day and the students can just grab any computer when they need it and log in and use it.

So I set up Directory Binding in Jamf Pro and tested on a laptop. Ideally, I want students to be able to login using their AD user and password do what they need to and then log out. We are a Google school so everything is saved in Drive.

My question is, will we have long term issues with these computers when multiple students log in and out throughout the course of the school year?

Am I overlooking anything or am I making this harder than it is?
We don't need mobile accounts as the computers won't leave campus and will be on our network.

6 REPLIES 6

jefff
Contributor II

Unless the computers have an active network connection (or you have some kind of device authentication happening on your network), a new user won't be able to log to a MacBook, because a network connection is required for the authentication against AD. That is, unless you have loaded a cert and installed a profile to allow the user to select your wireless network from the login screen.

What happens when you hand a MacBook on WiFI to a user who has never logged into it before?

cbrewer
Valued Contributor II

Your scenario is a common one for school districts. You shouldn't have any problems as long as you have wireless configured on a system level so that your Macs have a network connection while at the login window.

don_cochran
New Contributor III

We also run a maintenance script that deletes the users at the end of every semester or quarter. This keeps the laptops from filing up with to many user profiles.

!/bin/bash

if [[ "$(/usr/bin/whoami)" != "root" ]]; then printf ' Must be run as root! '; exit 1; fi

OPATH=$PATH
export PATH=/usr/bin:/usr/sbin:/bin:/sbin

OIFS=$IFS
export IFS=$' '

declare sudo=/usr/bin/sudo

Set user variable

declare user=student

if [[ -z "$user" ]]; then printf ' No user specified! Please, try again! '; exit 1; fi

make sure the user exists

usertest="$(/usr/bin/dscl . -search /Users name "$user" 2>/dev/null)"

if [[ -z "$usertest" ]]; then printf " User does not exist: $user "; exit 1; fi

Deleting user

sudo /usr/bin/dscl . -delete "/Users/$user"

make sure home folder exists

if [[ ! -d /Users/$user ]]; then printf 'this directory does not exist'; exit 1; fi

Delete user home folder

sudo rm -rf /Users/$user

prl
Contributor

I suggest using this open source tool https://nomad.menu makes it so that you can have multiple users associated with machines without having to bind. And the end users still use their AD credentials so you can still manage the user at the AD level.

Here is a demo https://m.youtube.com/watch?v=d_eGMsspeAQ

Look
Valued Contributor III

For the sake of sanity you might find mobile accounts and some kind of cleaning delete function works better than network only.
The devices are laptops, people wander around and sometimes want to log in at points where the network is no longer available.
But yeah other than ensuring logins work over WiFi in general it works fine having shared laptops bound to AD.
One thing we had for loan laptops was a remove all users option in Self Service to quickly allow loan centre staff to clear off any residual content from student users, along with a complete wipe and reinstall option as well.

Gascolator
New Contributor III

This is a small detail but you'll need to think through things like screen saver/screen lock passwords and forcing log outs. We only have a handful of multi user machines in our environment so I just enabled "log our after X minutes of inactivity" under security and privacy. Inevitably, there's that user that seems to be incapable of logging out and the next user is presented with a screen saver password. There are probably other ways to achieve a similar result and there may be better ways to manage it for a larger scale deployment.