Posted on 08-12-2015 05:41 AM
Hey we are trying to come up with some good ideas on how to disable a clients machine who has been terminated or has not checked into the JSS for over 60 days. I would like to take advantage of the Lock command being sent but want to automate this. Is there a way to use a smart group that will send a machine the lock command based on scoping?
Thanks
Posted on 08-12-2015 05:49 AM
I assume the users are mobile users?
I'm sure there are multiples ways to handle this but off the top of my head...
You could use a smart group for the machines not checking in within a given period and an additional smart group looking for those specific users.
You could then scope a config profile to those machines to only allow a specific account (read that as approved service/support account(s)) to login.
This is just my quick answer... off the top of my head without any coffee in me but that should work.
Posted on 08-12-2015 06:11 AM
I think the config profile is likely a more reliable way than we've done it forever, at least if you know who should then be allowed to login and it's not a LOT of other users.
We have a public account to use in our library and only want it used on specific Windows machines. With Windows it's easy to deny them on Windows machines, but Mac can't take advantage of that group policy when bound to AD.
So basically there is a policy that looks for a particular user at login and then does the following command:
killall loginwindow
It's not elegant, but it does the trick.
We found though that it's not always reliable, but it happens so infrequently that it doesn't matter too much. Had one person really abusing it. You'd want the policy to be available offline. As I stated though, the better lock out would be the config profile as @ShaunM9483 suggested and to limit to only certain accounts that CAN login if that works. In my situation that wouldn't work well.
Posted on 08-12-2015 07:03 AM
You mentioned that you're looking to do this with Macs that have not checked in in over 60 days. In that instance I don't know there would be any good solution. If the Mac isn't checking in, how would you expect to run any policies on it to make changes to the OS to disallow login? It has to be pulling policy from Casper for you to do anything with it.
For termed users, it could be done though (again, assuming their Mac is checking in to Casper). One way is to set the UserShell setting for the account to /usr/bin/false
instead of the default /bin/bash
This effectively prevents any login to that account in the GUI, which I assume is what's most important in this case, but would allow other accounts (like your local IT admin account) to log in.